flyway를 이용한 db migration

 

사용이유

로컬에서 변경한 데이터베이스의 스키마나 데이터를 운영 데이터베이스에 반영하는 것을 누락하는것을 막기 위함.(형상관리 용이)
개발 DB와 운영 DB의 스키마를 비교하거나, 운영 DB에 수작업을 가하는 비용과 위험성을 줄이기 위해 사용

적용 방법

migrate를 하기 위한 선택지는 2개가 있다.
1. 기존 DB data를 지우고 baseline-on-migrate: true 옵션을 주고 초기화 + flyway_schema_history table을 생성하는 방법
2. 기존 DB data를 유지한 상태에서 baseline을 현시점으로 잡고 flyway_schema_history table만 생성하는 방법

 

적용

* 예시는 위의 1번 방법으로 적용

build.gradle 
/* flyway dependency 추가 */
implementation 'org.flywaydb:flyway-core'

/* flyway config 추가 */
application.yaml
spring:
  flyway:
    enabled: true
    baseline-on-migrate: true
    baseline-version: 0
    
/* directory 생성 */
src/main/resourcesdb/migration

+ flyway default 경로는 /resources/db/migration(location 수정 가능)

 

file 생성

ex) V1.0__init.sql
*naming rule 존재(하단 이미지 참고)

 
주의할 점

만약 예를 들어 작성한 V1.0__init.sql 파일이 migrate 실패 시 flyway_schema_history에 남으므로,
실패한 V1.0__init.sql을 삭제하지 말고 V1.1__init.sql 이런식으로 파일을 추가해서 migrate를 시도한다.
왠만하면 ddl과 sql을 혼합하지 않고 version 분리해서 migrate 하는 편이 나음.
왜냐하면 migrate 도중 실패 시 성공한 스크립트까지만 적용되기 때문에 누락될 확률도 크기 때문.
JPA 사용시 운영환경에선 ddl-auto: validate 옵션 설정해서 변경사항 감지를 하며 migrate를 하는 편이 좋음.
 

 

참고 https://flywaydb.org/documentation/