FlywayDB 소개, DB SCHEMA 관리

Evolve your Database Schema easily and reliably across all your instances

데이터베이스 스키마의 변화를 손쉽게 관리

하는 기능을 가진 기술

---

• 참고: Flyway
  • 참고문서
  • Database initialization

---

1. FlywayDB 소개

1.1. 왜 DB Migration 을 사용하는가?

각기 다른 데이터베이스에서 동일한 DB스키마를 유지할 수 있는 기능이 필요하다. 

• 코드쪽에서는 꽤 괜찮은 해결책들이 있다.

  • 버전관리 도구는 보편적으로 사용되고 있다
  • 재현가능한 빌드와 지속적인 통합을 실시
  • 괜찮게 정의된 릴리스 및 배포 프로세스를 가지고 있다.

• 그런데 데이터베이스는??

  • 많은 프로젝트가 수동으로 SQL을 실행하는 방식 수행
  • 이 과정에서 많은 문제가 발생함
    • 각 데이터베이스마다 DB 스키마의 구조가 달라질 수 있는 문제가 발생
  • 관련된 많은 질문들
    • 이 시스템의 데이터베이스는 어떤 상태입니까?
    • 이 스크립트는 이미 적용 했습니까?
    • 제품에 적용한 긴급수정사항은 테스트 데이터베이스에 적용했습니까?
    • 어떻게 새로운 데이터베이스 인스턴스를 설정합니까?

      보다 많은 질문들에 대해서는: 모르겠다!!

• 데이터베이스 마이그레이션으로 이 무제들을 해결할 수 있다!

  • 처음부터 데이터베이스를 재작성하고
  • 데이터베이스가 어떤 상태인지 확인가능하고
  • 새로운 데이터베이스에 현재 적용되어있는 방식으로 마이그레이션 가능

---

2. FlywayDB 동작방식 설명

마이그레이션 버전 1, 버전 2가 있는 상황에서 flyway는 SCHEMA_VERSION 라는 이름의 비어있는 단독 테이블을 생성한다.

테이블이 생성되면 flyway는 즉시 파일시스템 혹은 애플리케이션의 마이그레이션을 위해 지정된 클래스패스에서 SQL 혹은 JAVA 파일을 탐색한다. 탐색된 파일들은 버전에 따라서 정렬하여 실행한다. 

마이그레이션 버전1, 버전2가 각각 실행되면 SCHEMA_VERSION 테이블에는 다음과 같이 마이그레이션 이력이 저장된다.

애플리케이션이 실행될때마다 flyway 설정에 따라서 파일과 SCHEMA_VERSION의 변동사항을 확인하나. 새로운 버전의 파일이 추가되면 실행하고 그 변경이력을SCHEMA_VERSION에 추가한다.

참 쉽죠??

---

3. 프로젝트 적용

3.1. SpringBoot 설정

스프링부트에서는 데이터베이스 마이그레이션을 지원한다. 그 중에서 Flyway를 채택했다. 이전 프로젝트에서는 Carbon5(c5-db-migration) 라고 하는 마이그레이션 도구를 사용했는데...

• Maven만 지원했음
• 지원이 사라짐...

그러다가 발견한 것이 Flyway. 손쉽게 사용가능함.

3.1.1. 의존성 추가

Maven

• Flyway: maven

  <project ...>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.flywaydb</groupId>
        <artifactId>flyway-maven-plugin</artifactId>
        <version>3.2.1</version>
        <configuration>
          <url>jdbc:h2:file:target/foobar</url>
          <user>sa</user>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <version>1.3.170</version>
          </dependency>
        </dependencies>
      </plugin>
    </plugins>
  </build>
  </project>

Gradle

• Flyway: 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) 설정

• Database initialization

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 스키마 추출방법

어디까지나 수동.... 처음에는 수동처리가 필요함...

1. 로컬 테스트에서 Hibernate에서 DDL 쿼리를 생성하도록 정의 생성하도록 설정

   jpa:
   hibernate:
    ddl-auto: create-drop

2. 테스트를 실행
   

   

   사용할려는 DB에 따라 생성하는 SQL 스크립트가 달라질 수 있는데, 이는H2Database 에서 제공하는 기능을 활용하여 MySQL, Oracle 등으로 변경하면 하이버네이트의 방언Dialect 에 의해 적절한 쿼리가 생성됨

3. 쿼리를 복사하여 손질
   

   

   
   

4. 처음 쿼리는 V1__init_db_schema.sql 로 생성
   

3.2.2. 변경이력 관리

프로젝트 내에 포함되어 있으니 모든 것을 형상관리시스템에 맡긴다.

3.3. 활용방안

• 제품 출시 후 DB 스키마를 초기화하는 것이 아니라, 출시 이후 변경된 사항들에 대한 형상을 관리할 수 있다.
• 위에서 설명한 동작방식을 상기하기 바란다.