Flyway

Flyway

Flyway는 데이터베이스 마이그레이션 툴이다. 여기서 마이그레이션이란, 스키마의 버전을 관리한다고 이해할 수 있다.
왜 버전을 관리해야 할까? 수많은 이유가 있을 것이다. 개발 환경에서 스키마를 변경하고 운영환경에 적용하지 않는 실수를 막는다거나, 이전 버전으로 rollback이 필요할 수도 있다.

Flyway의 작동방식

flyway는 지정된 schema history table을 찾는다. 이제 막 flyway를 적용해서 아직 스키마 히스토리 테이블이 존재하지 않는다면 새롭게 생성한다.

여기서 schema history table이란 말 그대로 flyway가 스키마의 버전을 관리하는 테이블을 말한다.

히스토리를 관리하는 테이블이 생성되면, Flyway는 마이그레이션을 위해 classpath에서 db/migration이라는 디렉터리를 찾는다. 이 디렉터리 아래에 있는 마이그레이션 파일(.java or .sql)을 읽는다. 마이그레이션 파일은 버전 번호를 기준으로 순서대로 읽는다. 맨 처음 이미지를 보면 Migration1과 Migration2가 있는데, 이 파일을 순서대로 읽어서 데이터베이스에 적용한다.

이런 순서다. 새로운 마이그레이션 버전이 생기면 역시 그 버전에 맞게 싱크한다.

schema history table의 형식

스키마 히스토리 테이블은 이런 식으로 버전 별로 관리된다. 테스트 해본 결과 싱크에 실패하면 checksum이 음수(-)로 나오는 듯하다.

프로젝트 적용

환경

• springboot2.4.5
• mysql

의존성 추가

implementation("org.flywaydb:flyway-core:5.2.4")

application.properties

#flyway
flyway.user=root
flyway.password=root

그 다음 /resources/db/migration폴더를 만들고 그 밑에 V__1.init.sql 파일을 생성한다. 네이밍 컨벤션이므로 맞춰줘야 한다.

V1__init.sql

create table if not exists user
(
    id    bigint not null auto_increment,
    phone varchar(255),
    primary key (id)
) engine=InnoDB;
...

이렇게 설정하고 애플리케이션을 실행하면 위에 설명했던 flyway_schema_history라는 테이블이 생성되면서 아래와 같은 필드가 자동으로 추가되고, 테이블도 생성된다.

그런 다음 두 번째 스키마 버전을 설정해주면 같은 방식으로 작동한다.
V__2.test.sql

create table if not exists test_table
(
    id          bigint not null auto_increment,
    test varchar(255),
    primary key (id)
) engine=InnoDB;

이 sql을 /db/migration 밑에 추가하고 서버를 재실행해보면 스키마 히스토리 테이블에 두 번째 버전에 대한 레코드가 추가되고, test테이블도 정상적으로 생성되는 것을 확인할 수 있다.