sql 파일을 버전별로 작성하면, history를 남겨주는 Golang migration tool 에 대해 정리해 보고자 한다.

Why?

• 개발을 하다보면 컬럼을 수정하거나 테이블을 수정하는 일 발생
• local db가 아닌 경우 직접 테스트 하는 것은 위험 → 치명적인 오류 발생 가능성 매우 높음

➡️  따라서 나의 로컬 db에서 테스트 한 후 개발이 완료되어 원격서버에 배포할 때 데이터베이스 변경 사항 적용되도록 해보자!

• DB를 언제, 누가, 무엇을 수정했는지 알 수가 없다
• 직접 history를 작성하는 것은 휴먼에러 발생 확률이 높다

➡️ 따라서 versioning 관리가 되는 db migration 툴 사용해보자!

1. Golang-migrate 설치

brew install golang-migrate

https://github.com/golang-migrate/migrate

2. migration file 만들기

migrate create -ext sql -dir ./migrations -seq test_schema

3. create table은 up 파일에, rollback command는 down 파일에 작성

000001_test_schema.up.sql

CREATE TABLE users (
   id BIGSERIAL primary key,
   first_name TEXT not null,
   last_name TEXT,
   created_at TIMESTAMP default now()
);

000001_test_schema.down.sql

DROP TABLE IF EXISTS users;

4. CLI로 Migration 실행하기

migrate -source file:<path> -database 'postgresql://<username>:<password>@<host>:<port>/<db_name>?sslmode=disable' 1 up

#ex) migrate -source file:./migrations -database "postgresql://postgres:password@localhost:5432/postgres?sslmode=disable" -verbose  up 1

Success! version 2가 적용되었으며, 실패하지 않았을 경우

5. 적용 후 다음 버전의 sql 파일 생성(처음 생성할 때와 똑같은 명령어 사용 시, 다음 버전의 sql 파일 자동생성)

migrate create -ext sql -dir ./migrations -seq test_schema

💡 쿼리문을 잘못 작성하거나 migration이 실패한 경우

version 3으로 up 시도했으나, 실패했다 → dirty=true

실패한 migration 위에 더 많은 migration을 시도하는 것을 방지하기 위해 dirty 플래그가 설정됨

해결 방법

down 명령어를 이용해 버전을 낮추기

error! 버전 2가 더럽혀졌기 때문에 수정 후 force 를 이용하여 버전을 지정하라

sql 파일이 적용되지 않고 version이 올라갔기 때문에 force를 이용하여 버전 2로 강제

migrate -source file:./migrations -database "postgresql://postgres:password@localhost:5432/postgres?sslmode=disable" force 2

버전이 2로 다운되고 dirty 값은 다시 flase

다른 툴과 비교

liquibase

• change_log가 상세하게 남는다
• 공식문서 가독성이 좋지 않다
• 유료이다
  • 무료버전도 있지만, DB 상태 비교에 한계가 있다
  • 롤백은 가능하나 특정 버전으로의 롤백은 불가능하다

Flyway

• 지정한 스키마가 없으면 자동 생성
• 다른 폴더에 저장되어 있더라도 버전명 순서에 따라 실행
• rollback이 없다
• 어떤 작업을 수행했는지 change_log 가 자세하게 남는다
• spring에서 많이 쓰이므로 레퍼런스가 많다