[DataBase] Flyway 톺아보기
0. 들어가기 전에
테코톡을 준비하면서 알아본 flyway를 정리해보았습니다.
1. Flyway란?
오픈소스 데이터베이스 마이그레이션 툴
Flyway의 공식 홈페이지에서는 flyway를 오픈소스 마이그레이션 툴이라고 소개하고 있습니다. 일반적으로 마이그레이션은 데이터나 소프트웨어를 한 시스템에서 다른 시스템으로 이동하는 것을 의미합니다. 그렇지만 flyway에서는 데이터베이스의 변경을 마이그레이션이라고 합니다. 즉, 데이터베이스에 테이블이 추가, 삭제, 수정되는 행위를 마이그레이션이라고 합니다.
2. 특징
Flyway는 7가지의 특징이 있습니다.
2.1 Migrate
SQL파일을 추가해서 테이블을 변경할 수 있습니다.
자세한 방법은 아래에서 알아보겠습니다.
2.2 Clean
테이블을 삭제할 수 있습니다.
전체 테이블을 삭제할 수 있습니다. 하지만 운영DB에서는 조심해서 사용해야합니다.
2.3 Info
flyway_schema_history 테이블을 통해 모든 Migration 이력을 제공합니다.
history 테이블은 버전 별로 SQL 파일들을 정렬하고, 마이그레이션 정보를 저장합니다.
2.4 Validate
존재하는 데이터베이스와 유효성 검사를 할 수 있습니다.
Flyway_schema_history에 체크섬이라는 column이 존재해서 기존 마이그레이션 파일이 변경되었는지 확인할 수 있습니다.
2.5 Undo
최근 적용된 마이그레이션을 취소할 수 있습니다. 유료 버전에서 사용할 수 있습니다.
2.6 Baseline
Flyway를 도입하기전에 존재하는 테이블을 기준으로 Flyway를 도입할 수 있게 도와줍니다.
flyway_schema_history가 기존 테이블을 Baseline이라고 지정해 flyway가 무시할 수 있게 해줍니다. 그 뒤에 생성되는 테이블들과 테이블 변경 사항들은 flyway가 관리할 수 있게 됩니다.
2.7 Repair
데이터베이스에서 실패한 마이그레이션을 제거할 수 있습니다.
3. 동작방식
동작 방식은 의외로 간단하게 동작합니다.
- Flyway가 flyway_schema_history라는 테이블을 생성합니다.
- Flyway가
classpath:db/migration
에서 migration 파일들을 스캔해서 데이터베이스에 반영합니다. - 각각의 migration이 적용이 될 때, history 테이블을 업데이트합니다.
이때, 마지막에 적용된 SQL 파일의 버전이 최신으로 적용된 SQL 파일의 버전보다 낮으면, 무시되기 때문에 주의해야 합니다.
4. 사용법
스프링에서 build.gradle
에서 아래와 같은 의존성을 추가시켜줍니다.
dependencies {
implementation 'org.flywaydb:flyway-mysql' // mysql 8.x 이상
// implementation 'org.flywaydb:flyway-core' // 일반적
}
그 다음 application.yml
에 flyway관련 설정을 추가합니다.
spring:
flyway:
enabled: true #flyway를 실행
url: jdbc:mysql://localhost:3306/${SCHEMA_NAME} #DB 주소
user: ${DB_USER} #DB user 아이디
password: ${DB_USER_PASSWORD} #DB user 비밀번호
#baseline-on-migrate: true #baseline을 적용하려면 설정
#location: ${NEW_LOCATION} #migration 파일 위치를 custom
기본적인 migration 파일들의 위치는 classpath:db/migration
입니다. 따라서 스프링 프로젝트를 사용하고 있다면 src/resources/db/migration
하위에 SQL 파일들을 위치시켜 두면 됩니다.
Migration 파일들의 이름의 명명 규칙이 있는데 다음과 같습니다.
- Prefix
- V는 가장 많이 사용되는 Prefix로 SQL의 문의 버전(Versions Migrations)을 의미합니다. flyway는 이 버전의 순서대로 script 파일을 실행합니다. 또한 최신으로 실행된 스크립트보다 더 작은 버전의 스크립트가 새로 생기면 무시하기 때문에 버전은 항상 기존의 파일들보다 크게 만들고 unique 하게 만들어야 합니다.
- U는 Undo Migrations를 의미합니다. migration 하기 전으로 되돌리는 기능이지만 유료 기능이므로 자세한 건 생략하겠습니다.
- R는 Repeatable Migrations를 의미합니다. 모든 마이그레이션이 적용된 후에 적용이 되며, 체크섬이 변경될 때마다 재적용됩니다. Description 순서대로 적용이 됩니다. 보통 대용량의 기본 데이터를 삽입할 때 사용됩니다.
- Version
- 버전의 이름은 아래와 같이 다양하게 사용할 수 있습니다.
- 1
- 001
- 5.2
- 1.2.3.4.5.6.7.8.9
- 205.68
- 20130115113556 (%Y%m%d%H%M%S)
- 2013.1.15.11.35.56
- 2013.01.15.11.35.56
- 버전의 이름은 아래와 같이 다양하게 사용할 수 있습니다.
- Separator
- 구분자로 언더바(_)가 두 개를 사용해야 합니다.
- Description
- history 테이블에 입력되는 내용으로 해당 스크립트가 무엇을 하는지 요약하여 작성합니다.
5. 왜 사용해야 될까요?
프로젝트에서는 다양한 테이블이 존재하고, 여러 prod, dev, local 등과 같은 여러 DB가 존재합니다. 만약 로컬 DB 변경하고, dev와 prod의 DB는 변경하지 않으면 어떻게 될까요? 아니면 dev와 local DB 모두를 변경하고 배포를 한 뒤 prod의 DB를 변경 안 했다는 사실을 늦게 알게 되면 어떨까요?
이런 문제들을 해결할 수 있는 게 flyway라고 생각이 듭니다. 비록 dry run이나 undo 같은 기능은 못 쓴다는 단점(비싸서)이 있습니다. 하지만 휴먼에러를 예방해 준다는 장점은 이 단점을 모두 커버하고 남는다고 생각합니다. 프로젝트를 진행할 때 flyway를 사용하는 걸 고려해 보면 어떨까요?
※ 참조
'CS > [DATABASE]' 카테고리의 다른 글
[Database] 클러스터링 인덱스와 논 클러스터링 인덱스 (0) | 2023.09.17 |
---|---|
[Database] 인덱스 (1) | 2023.09.10 |
[데이터베이스] 인덱스 (0) | 2022.05.23 |
Chapter14 트랜잭션 (0) | 2022.02.01 |
Chapter12 정규화 (0) | 2022.01.27 |