🎯 문제상황
프로젝트를 진행해감에 따라서 데이터 베이스 변경사항을 기록해놓으면 좋을 것 같다고 생각해서, 그동안은 resource 경로에 직접 테이블 변경 사항 sql문을 적어주었다.
이렇게 기록을 해주고, 어플리케이션을 시작할 때마다 모든 변경사항들이 자동으로 반영되어 최신화 되도록 하기 위해서 application-local.yml에서 아래 처럼 설정해주었다.
위는 실제 애플리케이션 구동마다 해당 sql문을 순차적으로 실행하게 된다.
문제는 여기서 발생하는데,
아래처럼 init_schema.sql은 이미 테이블이 생성되어 있다면 생성하지 않도록 되어있다.
하지만 아래 제약 조건을 거는 파일(즉, 테이블 내부의 설정을 변경하는 파일)의 경우에는, 애플리케이션이 시작될 때마다 제약 조건이 걸리게 되고, 그에 따라 인덱스 테이블이 애플리케이션 시작할 때마다 계속해서 생성되는 문제가 발생했다.
그래서 아래처럼 유니크 제약조건에 직접 이름을 명시해봤는데, 이미 제약 조건이 존재하는 경우에 같은 이름으로 제약조건을 걸면 예외가 발생해버린다.
-- 유니크 제약 조건 추가
ALTER TABLE member ADD CONSTRAINT unique_email UNIQUE (email);
ALTER TABLE member ADD CONSTRAINT unique_nickname UNIQUE (nickname);
그래서 이번에는 제약 조건 전에 기존에 존재하는 제약조건을 드랍하도록 했는데, 문제는 해당 제약조건 이름이 없는경우에 또 예외가 발생해버린다.
-- 유니크 제약 조건이 있다면, 제거해준다.
ALTER TABLE member DROP CONSTRAINT unique_email;
ALTER TABLE member DROP CONSTRAINT unique_nickname;
-- 유니크 제약 조건 추가
ALTER TABLE member ADD CONSTRAINT unique_email UNIQUE (email);
ALTER TABLE member ADD CONSTRAINT unique_nickname UNIQUE (nickname);
이렇게.. 헤매다가.. 결국 근본적으로 데이터베이스 마이그레이션 수동 관리가 문제라고 생각해서 도와주는 도구는 없을지 찾아보게 되었다.
🎯 flyway
flayway는 쉽게 말해 Database 형상 관리 도구다.
데이터 베이스의 변화사항들을 기록하고 관리할 수 있다.
의존성을 추가하고 yml파일을 설정해주었다.(자세한 내용은 아래 링크의 유튜브 영상과 구글링 자료들에 잘 나와있다)
-> data 생성 파일도 flyway로 관리해야하나..?(이 부분은 더 찾아봐야겠다)
flyway 마이그레이션 기록을 해주는 flyway_schema_history 테이블이 생성되었고 내용은 아래와 같다.
+--------------+-------+-----------------------------+----+-------------------------------------+-----------+------------+-------------------+--------------+-------+
|installed_rank|version|description |type|script |checksum |installed_by|installed_on |execution_time|success|
+--------------+-------+-----------------------------+----+-------------------------------------+-----------+------------+-------------------+--------------+-------+
|1 |1 |init |SQL |V1__init.sql |536675083 |local_user |2024-09-10 01:35:25|704 |1 |
|2 |2 |alter member table for unique|SQL |V2__alter_member_table_for_unique.sql|-1006602410|local_user |2024-09-10 01:35:25|85 |1 |
+--------------+-------+-----------------------------+----+-------------------------------------+-----------+------------+-------------------+--------------+-------+
이제 애플리케이션 시작할 때마다 인덱스 테이블이 중복 생성되는지 확인해보자.
재시작하니까 로그가 이번에는 변경사항이 없다고 나온다!
짜잔!
이제 DB 마이그레이션 관리도 잘되는 것 같구, 인덱스 테이블이 중복으로 생성되지도 않는다!!
로컬 개발 환경에서는 flyway를 이용해서 db 변화 과정을 기록해보고, 실제 개발 환경에서는 직접 SQL문으로 유지보수를 해볼생각이다.
springboot 환경에서 flyway 관련 주의사항과 운영관련 팁 내용들 자료가 많이 있으니 참고해보면 좋을 것 같다.
flyway 사용법의 여러 주의사항과 사용방법에 대해서는 아래 참고자료를 적극 활용했다.
[참고자료]
https://youtu.be/_fgOxPRo8tU?si=eLk21AWBYdLDCD4v
'프로젝트 > CStar' 카테고리의 다른 글
[프로젝트] 패키지 구조에대한 고민 (0) | 2024.09.09 |
---|---|
[프로젝트] 게임 엔진 ThreadPool Size는 어떻게 설정해야 할까? [작성중] (1) | 2024.09.08 |
[프로젝트] CStar 조회 쿼리 개선해보기 (0) | 2024.09.08 |
[프로젝트] Redis 아키텍처 적용해보기(feat. sentinel) [작성중] (0) | 2024.09.07 |
[프로젝트] Redis 를 Queue로 활용했을때 성능 & 동시성 체크해보자 (0) | 2024.09.04 |