Evolve your Database Schema easily and reliably across all your instances
데이터베이스 스키마의 변화를 손쉽게 관리
하는 기능을 가진 기술
1. FlywayDB 소개
1.1. 왜 DB Migration 을 사용하는가?
각기 다른 데이터베이스에서 동일한 DB스키마를 유지할 수 있는 기능이 필요하다. ![Shiny DB migration](http://flywaydb.org/assets/balsamiq/Environments.png)
2. FlywayDB 동작방식 설명
![Empty Database](http://flywaydb.org/assets/balsamiq/EmptyDb.png)
마이그레이션 버전 1, 버전 2가 있는 상황에서 flyway는 SCHEMA_VERSION
라는 이름의 비어있는 단독 테이블을 생성한다.
![Emtpy schema version table](http://flywaydb.org/assets/balsamiq/EmptySchemaVersion.png)
테이블이 생성되면 flyway는 즉시 파일시스템 혹은 애플리케이션의 마이그레이션을 위해 지정된 클래스패스에서 SQL 혹은 JAVA 파일을 탐색한다. 탐색된 파일들은 버전에 따라서 정렬하여 실행한다. ![execute migration](http://flywaydb.org/assets/balsamiq/Migration-1-2.png)
마이그레이션 버전1, 버전2가 각각 실행되면 SCHEMA_VERSION
테이블에는 다음과 같이 마이그레이션 이력이 저장된다.
![Table schema_version](http://flywaydb.org/assets/balsamiq/SchemaVersion-1-2.png)
애플리케이션이 실행될때마다 flyway 설정에 따라서 파일과 SCHEMA_VERSION
의 변동사항을 확인하나. 새로운 버전의 파일이 추가되면 실행하고 그 변경이력을SCHEMA_VERSION
에 추가한다.
![Pending Migration](http://flywaydb.org/assets/balsamiq/PendingMigration.png)
![마이그레이션 버전 2.1 후 변동사항](http://flywaydb.org/assets/balsamiq/Migration21.png)
![SCHEMA_VERSION의 변동사항](http://flywaydb.org/assets/balsamiq/SchemaVersion21.png)
참 쉽죠??
3. 프로젝트 적용
3.1. SpringBoot 설정
스프링부트에서는 데이터베이스 마이그레이션을 지원한다. 그 중에서 Flyway를 채택했다. 이전 프로젝트에서는 Carbon5(c5-db-migration) 라고 하는 마이그레이션 도구를 사용했는데...
그러다가 발견한 것이 Flyway. 손쉽게 사용가능함.
3.1.1. 의존성 추가
Maven
Gradle
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.h2database:h2:1.3.170'
classpath 'org.flywaydb:flyway-gradle-plugin:3.2.1'
}
}
apply plugin: 'org.flywaydb.flyway'
apply plugin: 'java'
flyway {
url = 'jdbc:h2:file:target/foobar'
user = 'sa'
}
SpringBoot
dependencies {
/**
* http://flywaydb.org/
* Database Migration tool
*/
compile "org.flywaydb:flyway-core"
}
3.1.2. application.yml(or properties)
설정
DB를 초기화하는 다양한 방법들이 있다.
- JPA 에 의한 초기화
- Hibernate 에 의한 초기화
- JDBC에 의한 초기화
- Batch를 이용한 초기화
그보다 높은 차원에서 손쉽게할 수 있는 것들이 있는데, 그중 하나가 바로 Flyway
flyway:
enabled: true
check-location: true # 마이그레이션 스크립트 파일이 존재하는지 여부를 확인
locations: classpath:db/migration # 마이그레이션 스크립트 위치
baseline-version: LATEST # 마이그레이션을 시작할 번호
sql-migration-prefix: V
sql-migration-suffix: .sql
url: jdbc:h2:file:~/.database/flywaydb;DB_CLOSE_DELAY=-1;AUTO_SERVER=TRUE;DB_CLOSE_ON_EXIT=FALSE; # Flyway 소유의 데이터소스를 생성하려고 하는 경우 사용
user: sa # Flyway 소유의 데이터소스를 생성하려고 하는 경우 사용
password: # Flyway 소유의 데이터소스를 생성하려고 하는 경우 사용
Flyway에 지정할 수 있는 속성은 다음과 같음
# FLYWAY (FlywayProperties)
flyway.*= # Any public property available on the auto-configured `Flyway` object
flyway.check-location=false # check that migration scripts location exists
flyway.locations=classpath:db/migration # locations of migrations scripts
flyway.schemas= # schemas to update
flyway.init-version= 1 # version to start migration
flyway.init-sqls= # SQL statements to execute to initialize a connection immediately after obtaining it
flyway.sql-migration-prefix=V
flyway.sql-migration-suffix=.sql
flyway.enabled=true
flyway.url= # JDBC url if you want Flyway to create its own DataSource
flyway.user= # JDBC username if you want Flyway to create its own DataSource
flyway.password= # JDBC password if you want Flyway to create its own DataSource
3.1.2. 디렉토리 설명
3.2. 스키마 관리방법 설명
- 프로젝트의 소스코드와 함께 관리한다.
- 로컬, 테스트와 출시 버전을 분리한다.
- 로컬, 개발은 update로도 충분...
- 테스트, 운영 등 서버는 validate 모드로 관리
- 프로젝트의 버전관리시스템에 기능을 활용하여 버전관리가 가능
3.2.1. DB 스키마 추출방법
어디까지나 수동.... 처음에는 수동처리가 필요함...
로컬 테스트에서 Hibernate에서 DDL 쿼리를 생성하도록 정의 생성하도록 설정
jpa:
hibernate:
ddl-auto: create-drop
테스트를 실행
![](https://t1.daumcdn.net/cfile/tistory/26035F4A55EE450D35)
사용할려는 DB에 따라 생성하는 SQL 스크립트가 달라질 수 있는데, 이는H2Database 에서 제공하는 기능을 활용하여 MySQL, Oracle 등으로 변경하면 하이버네이트의 방언Dialect 에 의해 적절한 쿼리가 생성됨
쿼리를 복사하여 손질
![](https://t1.daumcdn.net/cfile/tistory/2361104E55EE457B31)
- 처음 쿼리는 V1__init_db_schema.sql 로 생성
![](https://t1.daumcdn.net/cfile/tistory/2711CF4055EE46312C)
3.2.2. 변경이력 관리
프로젝트 내에 포함되어 있으니 모든 것을 형상관리시스템에 맡긴다.
3.3. 활용방안
- 제품 출시 후 DB 스키마를 초기화하는 것이 아니라, 출시 이후 변경된 사항들에 대한 형상을 관리할 수 있다.
- 위에서 설명한 동작방식을 상기하기 바란다.