프로젝트에 Flyway 적용 및 검증 등에 대한 설정

[JJ503]

Flyway란?

오픈소스 데이터베이스 마이그레이션 툴로 형상관리를 목적으로 한다.
즉, 데이터베이스의 변경 사항을 추적하고 업데이트나 롤백을 보다 쉽게 할 수 있도록 도와주는 도구다.

마이그레이션 해야 하는 이유는?

프로젝트를 진행하다 보면 스키마가 변경되는 경우가 발생하게 된다. 스키마가 변경될 경우 DB에 바로 적용이 되지 않기에 스키마를 삭제한 후 다시 생성하거나 수정하는 쿼리문을 작성해줘야 한다. 이때, create-drop과 같은 ddl-auot를 사용하게 변경된 엔티티 구조에 맞춰 수정할 수 있지만, 저장되어 있던 데이터들은 모두 삭제될 것이다. 그렇기에 프로덕션에서는 해당 설정을 사용할 수 없다.
그래서 drop 없이 수정하기 위해 직접 DB에서 테이블을 수정하는 쿼리문을 날릴 수 있지만, 번거롭고 사람이 하는 일이기에 실수가 발생할 수 있다.
이러한 문제를 해결하기 위해 flyway를 사용할 수 있다.

프로젝트에 Flyway 적용하기

• 의존성 주입

  implementation 'org.flywaydb:flyway-core'
  implementation 'org.flywaydb:flyway-mysql'

• application.yml에 flyway 사용 설정 추가

  • enable : flyway를 사용할지 여부를 설정, 기본은 true
  • baseline-on-migration : flyway_schema_history 테이블이 없다면 생성하도록 하는 설정, 기본은 false

spring:
  flyway:
    enabled: true
    baseline-on-migrate: true

• 최초 마이그레이션 스크립트 작성

  • flyway 적용 시점이 이미 대부분의 테이블을 생성한 상태이므로, 현재 존재하는 모든 테이블 및 제약 조건에 대한 스크립트를 작성한다
  • 이때 스크립트는 /resources/db/migration 하위에 작성한다
  • 파일명 : V1.0__init_table.sql
    • 버전과 파일 설명 사이에 언더스코어가 2개임을 주의해야 한다
    • 버전은 정수로 인식되기에 1.10과 1.2 중 1.2가 먼저 실행됨

• 블루밍 flyway 스크립트명 컨벤션

  • prefix{version}__{description}.sql
    • prefix : 항상 대문자 (V, R / U는 유료 버전만 사용 가능)
    • version : x1.x2로 진행
      • x1: 배포 버전에 따름
      • x2: x1 중 몇 번째인지에 따름 (0부터 시작)
    • description
      • 테이블 초기 세팅 : init_table → V1.0만
      • 테이블 생성 : add_{테이블명}
      • 테이블 업데이트 : update_{테이블명}
      • 테이블 삭제 : delete_{테이블명}

만약 flyway 스크립트가 실패하면 어떻게 될까?

실패하는 경우 flyway_schema_history에 해당 버전에 대해 success 값이 false로 설정되어 저장된다. 그렇기에 실패한 버전을 수정해 다시 실행하려면 flyway_schema_history에 있는 기록을 제거해주어야 한다. 만약 삭제하지 않고 실행한다면, 스크립트가 수정되더라도 해당 버전은 수행한 것으로 인식해 다시 수행하지 않는다.

flyway 스크립트 실패 시 자동으로 롤백하는 방법

• 참고자료

• db/callback/afterMigrateError__repair.sql 에 콜백 파일을 생성한다

  DELETE FROM flyway_schema_history WHERE success=false;

• application flyway 설정에 콜백에 대한 설정을 추가 → 해당 설정이 없어도 자동으로 매핑되는 지 확인하기

  spring:
      flyway:
          locations: classpath:db/migration,classpath:db/callback

• 해당 스크립트를 적용하지 않은 경우, success가 fail인 경우가 flyway_schema_history에 남은 것을 확인할 수 있다
  

• 스크립트 적용 후, success가 fail이었던 V1.1는 제거된 것을 확인할 수 있다
  하지만, 서버는 죽어 있으므로 장애가 발생한 것을 확인했다면 롤백 후 배포해두거나 빠르게 고칠 것을 추천한다
  

flyway 스크립트의 문제를 방지하는 방법

롤백을 자동화하더라도 스크립트 수정 후 서버를 다시 배포해야 한다는 점은 불편하고 재배포 때까지 시간이 걸리 것이다. 그렇기에 미연에 방지하는 방법이 있다면 더 좋을 것이다.

flyway 스크립트들을 검증은 flyway 플러그인을 설정한 후 flywayValidate를 통해 진행할 수 있다.

plugins {
	id 'org.flywaydb.flyway' version '9.22.3'
}

• No database found to handle jdbc:sqlserver://localhost;databaseName=~ 라는 오류가 발생하는 경우 (참고, 아직 정확한 원인은 잘 모르겠음)

buildscript {
	dependencies {
		classpath 'org.flywaydb:flyway-mysql:9.22.3'
	}
}

Github Actions를 통해 CI 단계에서 문법적 문제, 그 전 스크립트와의 관계에서의 문제, 버저닝의 문제를 검증하도록 한다. 이때, 해당 CI는 검증은 /resources/db/migration 패키지에 sql 파일이 추가된 경우에만 수행되도록 했다.

• 문제 발생 상황
  이미 있는 테이블을 또 생성함

• CI 스크립트 수행 결과
  

• 문제가 없는 경우에 대한 결과