일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- conda base 기본 설정
- 려려
- window netstat time wait 제거
- time wait port kill
- 실행중인 포트 죽이기
- conda 기초 설정
- 3000 port kill
- 오블완
- conda base 활성화
- conda 가상환경 설정 오류
- 티스토리챌린지
Archives
- Today
- Total
모도리는 공부중
[Alembic] 운영/개발 DB Alembic 동기화 및 SQL DDL → Alembic 전환 관리 방법 좌충우돌 중 본문
내 지식 정리/날것 그 자체
[Alembic] 운영/개발 DB Alembic 동기화 및 SQL DDL → Alembic 전환 관리 방법 좌충우돌 중
공부하는 모도리 2024. 12. 26. 14:18728x90
반응형
개발단은 과거 운영 디비 상태를 복제해서 만든 후 sql ddl로 관리하고 있었고, 운영단은 계속 alembic으로 관리하고 있었다. 그걸 모르고 있다가 sql ddl문으로 운영단에 추가해둔 인덱스가 alembic이 autogenerate 기능으로 없애버린 것(drop... ㅠㅠ)을 발견하고, 해결하기 위해 db 관리 방식을 하나로 정리해야겠다는 생각이 들었다.
합의 도출 결과 'alembic으로 모두 관리하자'가 되었고, 그럼 개발단에서도 문제없이 alembic으로 되는지, 개발단에서는 문제 없었지만 테스트단으로 올렸을 때, 그리고 운영단으로 올렸을 때 문제없이 변경사항 적용이 되는지를 점검할 필요가 생겼다.
아래는 gpt와 대화한 내용이다.
현재 상황을 정리한 뒤, 예상되는 문제점과 해결 방안을 제안하겠습니다.
1. 현재 상황 요약
- 운영 DB는 Alembic으로 관리되고 있으며, 최신 alembic_version 해시값과 히스토리를 가지고 있음.
- 개발 DB는 과거 운영 DB를 복제한 상태에서 SQL DDL 문으로 인덱스나 컬럼 등을 관리하며, Alembic의 alembic_version 값이 운영과 다름.
- 공통된 코드 (common):
- common/alembic/versions/에는 운영과 동일한 Alembic 히스토리가 존재.
- common/models/에도 운영과 동일한 모델이 존재.
- 앞으로는 운영/개발 모두 Alembic으로 인덱스 및 변경 사항을 관리하기로 결정됨.
2. 목표
- 운영 DB:
- 기존 Alembic 히스토리를 유지하면서, 개발에서 추가된 인덱스를 적용.
- 개발 DB:
- 운영의 Alembic 히스토리와 동기화하면서, 기존 SQL DDL로 관리되던 인덱스를 Alembic으로 전환.
- 공통 코드 (common):
- common/alembic/versions/에 추가된 히스토리 파일을 운영과 개발 모두 문제없이 동기화.
- 운영에서 적용된 변경 사항이 개발로 내려와도 충돌 없이 받아들여짐.
3. 문제 상황 분석
문제 1: 개발 DB의 Alembic 상태 불일치
- 원인:
- 개발 DB는 과거 복제된 운영 상태를 기준으로 SQL DDL 문으로 관리되었고, alembic_version 값이 운영과 다름.
- 운영과 동일한 alembic_version을 동기화하지 않으면, Alembic이 개발 DB에서 추가 작업(예: 인덱스 드롭)을 수행하려 할 수 있음.
- 결과:
- 개발 DB에서 alembic upgrade를 실행하면, 현재 Alembic 버전(alembic_version)이 운영과 다르기 때문에 운영 DB에는 없던 작업이 실행되거나 충돌이 발생할 가능성이 있음.
문제 2: 운영에서 Alembic으로 개발의 변경 사항을 반영
- 원인:
- 개발에서 SQL DDL 문으로 생성된 인덱스를 Alembic으로 전환한 후, 운영에 이를 적용하려면 Alembic 히스토리가 운영과 연속성을 가져야 함.
- 그러나 운영 DB는 개발에서 생성된 Alembic 스크립트와 alembic_version 정보를 가지고 있지 않음.
- 결과:
- 운영에서 alembic upgrade를 실행하면, 연속성이 없는 revision_id가 운영 DB에 반영될 가능성이 있음.
문제 3: common 동기화 시 충돌
- 원인:
- 운영에서 반영된 Alembic 변경 사항이 common 코드로 내려왔을 때, 개발 DB와 alembic_version 상태가 불일치하면 충돌 가능.
- 개발 DB는 운영의 최신 Alembic 히스토리를 동기화하지 않았으므로, 동일한 작업을 다시 시도하거나 불필요한 작업을 실행할 가능성이 있음.
4. 해결 방안
Step 1: 개발 DB를 운영 DB와 동기화
- 운영의 alembic_version 값을 개발로 복사:
- 운영 DB의 alembic_version 값을 개발 DB로 동기화.
UPDATE alembic_version SET version_num = 'latest_revision_id_from_operating';
- 운영 DB의 alembic_version 값을 개발 DB로 동기화.
- 개발 DB에서 SQL DDL로 생성된 작업을 삭제:
- SQL DDL로 관리하던 인덱스나 컬럼은 삭제하고, Alembic으로 다시 생성.
ALTER TABLE my_table DROP INDEX index_name;
- SQL DDL로 관리하던 인덱스나 컬럼은 삭제하고, Alembic으로 다시 생성.
- 개발 DB에서 Alembic으로 동일 작업 생성:
- Alembic 명령어를 사용해 인덱스나 컬럼 생성 작업을 작성:
alembic revision --autogenerate -m "Add new index" alembic upgrade head
- Alembic 명령어를 사용해 인덱스나 컬럼 생성 작업을 작성:
- 검증:
- 개발 DB에서 SHOW INDEX FROM my_table;로 인덱스가 올바르게 생성되었는지 확인.
Step 2: 운영 DB에 Alembic 변경 사항 반영
- 개발에서 생성된 Alembic 스크립트를 운영에 반영:
- 개발에서 생성된 Alembic 스크립트를 common/alembic/versions/에 추가하여 운영 DB에서 동기화.
- 운영에서 변경 사항 적용:
- 운영 DB에서 Alembic 변경 사항을 적용:
alembic upgrade head
- 운영 DB에서 Alembic 변경 사항을 적용:
- 운영 DB의 상태 확인:
- 운영 DB에서 SHOW INDEX FROM my_table;로 변경 사항이 올바르게 반영되었는지 확인.
Step 3: common 동기화 시 충돌 방지
- 운영에서 반영된 Alembic 상태를 개발에 동기화:
- 운영 DB에서 적용된 Alembic 히스토리를 개발 DB로 내려받습니다.
- 개발 DB에서 alembic upgrade head를 실행하여 동일한 상태로 유지.
- 개발과 운영에서 alembic_version 값 동기화:
- 운영 DB와 동일한 alembic_version 값을 개발 DB에도 반영합니다.
5. 최종 결과 예상
- 운영에서 변경 사항 적용:
- 운영 DB에서 alembic upgrade head를 실행하면, 새롭게 생성된 Alembic 스크립트가 문제없이 적용되고 alembic_version이 업데이트됨.
- 개발에서 충돌 방지:
- 개발 DB에서 운영의 alembic_version 상태를 동기화했으므로, alembic upgrade 시 불필요한 작업이나 충돌 없이 적용 가능.
- common 동기화:
- common의 Alembic 히스토리와 모델이 개발과 운영 모두 동일하게 유지되며, 버전 관리에 문제가 발생하지 않음.
6. 주의 사항
- Alembic 연속성 유지:
- 개발에서 새로운 Alembic 스크립트를 생성할 때, 반드시 운영 DB와 연속성을 유지해야 합니다.
- DDL로 관리되던 작업 정리:
- 기존 SQL DDL로 관리되던 작업을 모두 Alembic으로 전환하고, 운영과 개발이 동일한 상태로 유지되도록 합니다.
- 충돌 시 대처:
- 만약 운영과 개발에서 동일 작업이 중복되었다면, 기존 작업을 먼저 삭제한 후 Alembic으로 다시 생성해야 합니다.
추가 질문이 있거나 특정 단계에 대한 자세한 설명이 필요하면 알려주세요! 😊
728x90
반응형
'내 지식 정리 > 날것 그 자체' 카테고리의 다른 글
[git submodule] 'git submodule update'와 'git submodule update --init --recursive'의 차이 (feat.ChatGPT) (0) | 2024.12.30 |
---|---|
[MySQL] 유니크 키(논리적 인덱스)와 유니크 인덱스(물리적 인덱스)의 차이 (feat.ChatGPT) (1) | 2024.12.27 |
2024.12. 개발 궁금증 링크 일기 (1) | 2024.12.03 |
2024.11. 개발 궁금증 링크 일기 (1) | 2024.11.12 |
2024.08. 개발 궁금증 링크 일기 (0) | 2024.08.04 |
Comments