1. Flyway 소개
우선, `Flyway` 공식 홈페이지에서는 `Flyway`를 다음과 같이 정리하고 있다.
"Flyway is an open-source database migration tool"
해석하자면 오픈 소스로 누구나 사용할 수 있는 데이터베이스 마이그레이션 툴이다.
여기서 데이터베이스 마이그레이션 툴?이 무슨 의미일까?
본래 데이터베이스 마이그레이션이라는 말은 한 데이터베이스에서 다른 데이터베이스로 이동하는 것을 의미한다.
하지만, `Flyway`에서는 모든 데이터베이스의 변경을 마이그레이션이라고 칭하고 있다.
즉, `Flyway`에서 데이터베이스 마이그레이션 툴이란 데이터베이스 변경 관리도구가 된다.
마치, 소스코드 변경을 관리하는 깃허브처럼 데이터베이스의 변경은 flyway가 관리하게 된다.
2. Flyway 특징
- Migrate
- 데이터베이스의 변경을 의미
- Baseline
- 비어있지 않은 데이터베이스에서 flyway를 적용할 때 사용하는 키워드
- Info
- 데이터베이스의 변경이력을 저장한다는 의미
- Repair
- 실패한 마이그레이션 파일을 다시 복구할 수 있다는 의미
- Validate
- `Flyway`를 DB에 적용할 때 적용될 수 있는지 없는지를 확인한다.
- Undo
- 최근에 적용됐던 `Migration` 파일을 적용하지 않은 상태로 돌리는 키워드
- Clean
- 데이터베이스를 깨끗이 지운다는 의미이다.
위의 크게 7가지 특징이 존재한다.
우리는 여기서 중요한 `Migrate`, `baseline`, `Info`에 대해 좀 더 알아보자.
Migrate
아까 언급했던 것처럼 `Migrate`는 데이터베이스의 변경을 의미한다.
위와 같이 비어있는 `DB`에서 `Flyway`를 사용해 `Crew`라는 테이블을 만드려면 어떻게 해야 할까?
위의 사진처럼 `V1__init.sql`이라는 파일을 만들고,
해당 파일 안에 `CREATE TABLE crew...` 라는 내용의 SQL문을 작성해준다.
그 다음, `Flyway`가 적용된 스프링부트 어플리케이션을 실행시키면
자동적으로 `Crew`라는 테이블을 생성해준다.
이때, `Flyway`가 처음 적용되었으므로 `history` 테이블도 자동적으로 만들어지게 된다.
이 `history` 테이블은 데이터베이스 변경 이력을 저장하는 테이블이 된다.
해당 `history` 테이블은 체크섬과 함께 변경 이력을 저장해두는데
만약, `V1__init.sql` 파일이 변경되면 체크섬 값이 달라지므로 오류가 발생된다.
그리고 `V1__init.sql` 처럼 `Migrate` 파일 이름에는 몇 가지 규칙이 존재한다.
- V: Version Migration
- 버전에 따라 관리되는 마이그레이션 파일을 의미한다.
- 빨간색 1: 파일의 버전(unique)
- 파일의 버전은 유니크하다는 특성을 가지고 있다.
- 만약에 적용되지 않는 마이그레이션 파일 중에 같은 버전이 2개 이상 있으면
`Flyway`는 어떤 걸 적용할 줄 몰라 에러를 뱉게 된다.
- __: seperator
- 항상 언더바가 두 개로 이루어져있다.(구분자)
- 노란색 부분: 파일 설명
- 히스토리 테이블에 `description` 항목에 들어갈 내용으로 자세히 적는게 좋다.
파일 버전 추가 설명
새로 적용하려는 파일은 기존에 적용된 파일의 버전보다 높아야 한다.
버전 표현의 여러 방식
- 005
- 5.2
- 1.2.3.4.5.6
- 205.68
- 20130115113556(yyyymmddhhmmss)
baseline
비어있지 않은 데이터베이스에서 `Flyway`를 적용할 때 사용하는 키워드이다.
(이미 다른 DB가 존재하고 있을 때 새롭게 `Flyway`를 도입하는 경우)
- `V1__baseline.sql` 파일을 만든 이후 아무 입력을 하지 않는다.(빈 파일)
- 이후 새로 제작할 table의 SQL를 `V2__table.sql`에 넣는다.
- 스프링부트 실행 시 `Flyway`가 SQL 문에 따라 새로운 테이블을 생성한다.
- 이 경우에도 처음 `Flyway`를 적용시킨 것이기에 `history` 테이블이 생성된다.
즉, 새롭게 `Flyway`를 도입하는 경우 사용하면 좋을 것 같다.
Info
앞서 말한 `history` 테이블은 `flyway_schema_history` 테이블이다.
위의 사진에서 가장 중요한 컬럼은 `version`과 `checksum`으로,
version
- `version`의 값에 따라 앞의 `installed_rank`가 결정 됨.
- 따라서, 항상 최근에 적용됐던 파일의 version 보다 높은 version으로 등록해야 함
checksum
- 마이그레이션 파일의 해시값
- 만약, 적용된 마이그레이션 파일 중에 변경이 일어나면 checksum 값이 바뀜
- 이 경우 `flyway`는 파일의 오염되었다고 판단