[데이터베이스] Flyway validate와 마이그레이션 검증

개요

Flyway를 사용하면 DB 변경을 마이그레이션 파일로 관리할 수 있습니다.

마이그레이션을 실행하기 전에 validate를 사용하여 적용 이력과 파일의 일관성을 검사할 수 있습니다.

Q) validate가 성공했다면 해당 SQL을 실행해도 안전할까요?

A) validate가 확인하는 것은 적용된 마이그레이션과 현재 마이그레이션 파일의 일관성입니다. SQL 실행 시 발생할 영향까지 확인하는 것은 아닙니다.

validate 동작 과정

Flyway는 마이그레이션을 적용한 이력을 저장하고, validate 실행 시 현재 사용할 수 있는 마이그레이션과 비교합니다.

검사 항목에는 이름, 타입, 체크섬의 차이와 마이그레이션 누락 등이 포함됩니다. 구체적인 검증 결과는 설정과 마이그레이션 상태에 따라 달라집니다.

SQL 마이그레이션의 경우 실행 시 기록한 체크섬과 현재 파일의 체크섬을 비교합니다.

따라서 이미 적용한 마이그레이션 파일이 이후에 변경된 경우를 발견하는 데 사용할 수 있습니다.

validate와 migrate의 차이

Q) validate로 아직 적용하지 않은 SQL이 정상적으로 실행되는지도 확인할 수 있을까요?

A) validate는 해당 SQL을 실행하는 명령이 아닙니다. 실제로 실행되는지 확인하는 단계는 별도로 필요합니다.

파일의 체크섬이 일치하더라도 SQL이 업무 규칙에 맞는지, 큰 테이블에서 락을 오래 잡는지는 다른 문제입니다.

마이그레이션 검증 단계

DB 변경 절차를 구성할 때는 다음과 같이 검증 대상을 나눠볼 수 있습니다.

이는 검증 대상을 구분한 예시입니다. 각 단계에서 확인하는 내용이 다르므로 validate의 성공만으로 전체 검증을 대체할 수는 없습니다.

MySQL DDL과 롤백

Q) 마이그레이션 실행이 실패하면 트랜잭션으로 모두 롤백할 수 있을까요?

A) MySQL의 여러 DDL 문장은 실행 전이나 후에 암묵적 커밋을 발생시킵니다.

CREATE TABLE, ALTER TABLE 등이 여기에 해당합니다. 여러 DDL을 트랜잭션으로 감싸더라도 전체 변경이 함께 롤백된다고 가정하면 안 됩니다.

임시 테이블처럼 별도의 규칙이 적용되는 경우도 있으므로 실행할 문장의 동작을 확인해야 합니다.

변경 전에 복구 방법도 함께 검토해야 합니다.

• 삭제하거나 변환한 데이터를 복원해야 하는지
• 스키마 변경을 단계적으로 적용할 수 있는지
• 변경 도중에도 기존 애플리케이션이 동작할 수 있는지

Flyway 명령의 성공 여부와 DB 변경의 안전성은 각각 확인해야 합니다.

Learning Point

1. validate는 마이그레이션 이력과 파일의 일관성을 검사한다는 점
2. SQL 실행 여부, 변경 영향, 승인 대상은 별도로 확인해야 한다는 점
3. MySQL DDL의 암묵적 커밋을 고려하여 복구 방법을 준비해야 한다는 점

참고 자료

• Redgate Flyway — Validate
• Redgate Flyway — Migrate
• MySQL 8.4 — Statements That Cause an Implicit Commit