![[팀 BackFro💯] ArtZip: 세상 모든 전시회를 한 번에](https://www.notion.so/image/https%3A%2F%2Fnoticon-static.tammolo.com%2Fdgggcrkxq%2Fimage%2Fupload%2Fv1586271553%2Fnoticon%2Fnus6dsqgee1cfqy78el1.gif?table=block&id=8db56ad1-304e-441e-8abe-0b7045207852&cache=v2)
논의사항왜 사용할까?간단 설명사용시 주의사항 (Rules)적용하기의존성 및 properties 설정DB schema 변경(또는 entity 변경) 후 마이그레이션 파일 작성법merge 후에 다른 팀원이 작성한 버전과 같은 버전의 마이그레이션 파일을 작성한 경우활용하기1. local에서 테스트할 때 더미 데이터 넣어주기(작성중)2. 첫번째 버전 migration 파일 작성하기참고자료
토글로 접어두지 않은 부분은 필수적으로 읽고 적용해주셔야 합니다‼️
공식문서에서는 Java 12까지 Gradle 6.x까지 지원한다고 쓰여있지만, 여러 적용 사례를 봤을 때 최신버전에서도 대체로 잘 작동하는 편인 것 같습니다
논의사항
- 어떤 환경(local, dev)에서 사용할 것인지
- CI할 때 data container를 만드는 방법도 있는데 다들 어떻게 생각하지는지요
왜 사용할까?
- 배포 후 운영 환경에서는 DB shema에 변경이 생기면 직접 DB 서버에 접속해서 하나하나 수정해주어야 함 → 에러 발생 가능성 커짐
- DB 변경내역 확인 가능
간단 설명
용어 정리
- Migration: DB에 대한 모든 변경 사항
- 작성 가능 언어: sql, java, 스크립트 언어
- 종류
- Versioned Migration
- version, description, checksum이 있음
- 순서대로 정확히 한 번 적용됨
- 일반적인 마이그레이션
- 사용되는 경우
- Creating/altering/dropping tables/indexes/foreign keys/enums/UDTs/…
- Reference data updates
- User data corrections
- Undo Migration
- Versioned migration의 반대
- versioned migration과 같은 버전의 마이그레이션을 undo하는 효과
- Repeatable Migration
- description, checksum이 있음
- checksum이 변경될 때마다 (재)적용됨
- 사용되는 경우
- (Re-)creating views/procedures/functions/packages/…
- Bulk reference data reinserts
sql로 작성된 버전 마이그레이션 동작 예시 (참고링크)
- 2개의 마이그레이션(db schema 변경 sql문 작성된 파일)을 갖고 있고 DB는 비워져 있는 상태
- 대상 DB에 SCHEMA_VERSION(flyway가 변경이력을 관리하는 meta table) table이 존재하는지 확인하고 없으면 새로 생성됨
- flyway가 지정된 classpath에서 마이그레이션 파일을 탐색하여 버전 순서대로 실행
- 마이그레이션 실행 후에 SCHEMA_VERSION table에 실행이력을 저장
사용시 주의사항 (Rules)
- SQL-based migration으로 작성 (마이그레이션은 sql, java, 스크립트 언어로 작성될 수 있음)
- File Naming
- prefix (
V) - V: 버전 마이그레이션
- R: 반복 마이그레이션
- ❗️V나 R로 시작해야 flyway가 인식 가능
- version (
2) - 버전 마이그레이션에서만 사용
- 숫자, 점, 언더바 조합으로 사용
- ❗️반복 마이그레이션에서 version을 명시하면 파일명 제약 위반으로 에러 발생
- separator (
__) - description 부분을 구분하기 위한 구분자
- ❗️언더바 2개 써야함
- description (Add_new_table)
- schema_version 테이블에 저장시 설명으로 사용됨
- 언더바, 스페이스로 단어 사이 구분
- suffix (
.sql) - 확장자
- migration file 위치
- default,
classpath:prefix가 붙은 location → Java classpath (src/main/resources/db/migration) - filesystem: prefix가 붙은 location → 파일 시스템에서 찾음 (예시:
filesystem:/my-project/my-other-folder) s3:prefix가 붙은 location → AWS S3 버킷에서 찾음- AWS SDK v2사용해야 함. dependencies도 추가해야 함
- (참고) 필요하다면 나중에 추가해볼 예정
gcs:prefix가 붙은 location → GCS 버킷에서 찾음
: application.yml에서
spring.flyway.locations의 옵션으로 위치 설정 가능적용하기
의존성 및 properties 설정
- build.gradle
implementation 'org.flywaydb:flyway-core' implementation 'org.flywaydb:flyway-mysql'
- application.yml
spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/test_db username: root password: root1234! flyway: enabled: true baseline-on-migrate: true locations: classpath:db/migration baseline-version: 0 # jpa ddl-auto 옵션은 validate로 설정(create, update 말고)
DB schema 변경(또는 entity 변경) 후 마이그레이션 파일 작성법
- 위 파일명 규칙에 맞게 마이그레이션 파일을 생성
- 생성 위치:
src/main/resources/db/migration
- 마이그레이션 파일에 sql로 변경사항 작성
하나의 파일에 1개의 DDL만!!
flyway는 checksum을 파일 단위로 관리하며 파일에 문제가 생겼을 때 이 이후의 로직을 실행하지 않기 때문.
merge 후에 다른 팀원이 작성한 버전과 같은 버전의 마이그레이션 파일을 작성한 경우
- 버전을 겹치지 않게 변경
활용하기
1. local에서 테스트할 때 더미 데이터 넣어주기(작성중)
src/main/resources/db/seed에 R로 시작하는 Repeatable migration 파일 작성 (이때 파일명 규칙 참고해서 작성!!)
- 1)에서 만든 repeatable migration 파일에 sql INSERT문을 사용하여 데이터 삽입하는 스크립트 작성
- 1)에서 만든 repeatable migration 파일명과 동일하게
.conf를 붙인 설정파일 생성
2. 첫번째 버전 migration 파일 작성하기
- jpa auto-ddl 이용해서 일단 table을 다 만들고
- 그 이후에 추가되는 부분부터 migration 파일 작성하기
- 자동 생성된 ddl 복붙해서 V1 migration 파일 작성하기
이 둘 중에 하나의 방식으로 진행하면 될 것 같음
