Need U V1 → V2 DB 무중단 마이그레이션 설계 - 100-hours-a-week/KTB4-4th-wiki GitHub Wiki

1. 무중단 조건

1.1 데이터 유실 허용 여부

V1 DB에서 성공 처리된 요청이 마이그레이션 후 RDS에 없을 수 있는가? = RPO

데이터 유실 허용: 0건 (RPO 0)
중복 데이터 허용: 0건
MySQL과 PostgreSQL 모두 동일한 기준 적용

1.2 쓰기 제한 가능 여부

DB를 최종 전환하는 동안 데이터 정합성을 위해 쓰기 요청을 잠시 제한할 수 있는가?

안전한 전환을 위해 필요한 경우 일부 쓰기 기능을 제한한다.
조회 기능은 가능한 한 계속 제공한다.
V1 DB와 RDS가 동시에 Writer가 되는 상태는 허용하지 않는다.
제한할 기능과 최대 시간은 Staging 리허설 결과를 바탕으로 확정한다.
제한 중인 쓰기 요청에는 재시도 또는 점검 안내를 제공한다.

1.3 롤백 기준

RDS에서 사용자 쓰기를 시작하기 전까지는 V1 DB로 롤백할 수 있어야 한다.
RDS에서 사용자 쓰기를 시작한 이후에는 RDS를 새로운 원본 DB로 판단한다.
RDS 쓰기 시작 이후에는 V1 DB로 단순 복귀하지 않고 RDS를 기준으로 문제를 수정한다.
애플리케이션 문제 발생 시 RDS와 호환되는 이전 이미지로 롤백한다.
V1 DB는 검증과 비상 대응을 위해 일정 기간 읽기 전용으로 보관한다.
구체적인 보관 기간은 운영 전환 계획에서 별도로 확정한다.

2. 마이그레이션 기법 조사

2.1 Dump/Restore

Dump/Restore는 Source DB의 스키마와 데이터를 파일로 추출한 뒤 Target DB에 복원하는 방식이다.

Source DB
→ 스키마와 데이터 추출
→ Dump 파일 생성
→ Target DB에 Restore
→ 데이터 검증
→ 애플리케이션 연결 전환

MySQL: mysqldump와 mysql
PostgreSQL: pg_dump와 pg_restore 또는 psql

Dump 파일에는 추출 시점까지의 데이터만 포함된다. Dump 이후 Source에서 발생한 변경은 자동으로 반영되지 않으므로, 운영 중 쓰기가 계속되는 DB에 단독으로 적용하면 데이터 유실 위험이 있다.

반대로 Dump 시점부터 연결 전환까지 쓰기가 발생하지 않는 DB라면 별도 CDC 없이 사용할 수 있다. 기존 Source가 조회 요청을 계속 처리하는 동안 Target에 복원할 수 있으므로 사용자 조회 서비스는 유지할 수 있다.

2.2 Full Load + CDC

Full Load + CDC는 기존 데이터를 전체 복사하면서, 복사 중과 복사 이후에 발생한 변경을 계속 Target에 반영하는 방식이다.

기존 데이터 → Full Load ─────────────→ RDS
운영 중 변경 → Binlog 또는 WAL → CDC → RDS

CDC는 Source DB의 변경 로그를 읽어 INSERT, UPDATE, DELETE를 Target에 적용한다.

MySQL: Binary Log
PostgreSQL: WAL과 Logical Decoding 또는 Logical Replication

2.3 AWS DMS

AWS Database Migration Service는 Source Endpoint, Target Endpoint, Replication Instance와 Replication Task를 사용해 Full Load와 CDC를 관리한다.

AWS DMS Task는 다음 세 가지 방식으로 실행할 수 있다.

Full Load: 기존 데이터만 이전
Full Load + CDC: 기존 데이터와 이후 변경을 함께 이전
CDC only: 별도 방식으로 초기 적재한 뒤 변경만 이전

Full Load + CDC의 동작 순서는 다음과 같다.

Source 변경 로그의 시작 지점을 기록한다.
기존 데이터를 Full Load한다.
Full Load 중 발생한 변경을 로그에서 수집한다.
테이블별 Full Load가 끝나면 누적된 변경을 적용한다.
이후 변경을 계속 Target에 반영한다.
최종 전환 시 Source 쓰기를 제한한다.
남은 변경이 모두 반영됐는지 확인한다.
데이터 검증 후 애플리케이션 연결을 전환한다.

2.4 Native Replication

Native Replication은 AWS DMS 대신 MySQL과 PostgreSQL이 제공하는 복제 기능을 직접 사용하는 방식이다.

MySQL은 Snapshot과 Binary Log 위치를 기준으로 Source의 변경을 Replica에 적용한다.
PostgreSQL은 Publication, Subscription과 Replication Slot을 이용한다.

별도의 관리형 복제 계층이 없다는 장점이 있지만, 엔진별 초기 동기화와 상태 확인, 장애 복구, 데이터 검증 절차를 각각 구성해야 한다.

2.5 Debezium, Airbyte와 Dual Write

Debezium은 일반적으로 Kafka와 Kafka Connect, Sink 또는 별도 Consumer까지 구성해야 한다.
Airbyte는 Destination 반영 방식과 Delete, 중복, 순서, CDC drain을 별도로 검증해야 한다.
Dual Write는 애플리케이션이 V1과 RDS에 동시에 저장하므로 부분 실패, 재시도, 멱등성과 데이터 불일치 복구가 필요하다.

세 방식 모두 변경 데이터를 전달할 수 있지만, 관리해야 할 구성 요소와 애플리케이션 책임 범위가 서로 다르다. 실제 적용 여부는 마이그레이션 목적, 장기 운영 필요성, 부분 실패 처리와 운영 부담을 기준으로 판단해야 한다.

2.6 관리형 Database Migration Service 비교

관리형 Database Migration Service는 AWS뿐 아니라 Google Cloud와 Azure에서도 제공한다. 다만 각 서비스는 주로 자사 클라우드의 관리형 데이터베이스를 Target으로 하는 마이그레이션 경로에 맞춰져 있다.

서비스	대표 Target	주요 특징
AWS Database Migration Service	Amazon RDS, Amazon Aurora 등	AWS의 VPC, IAM과 CloudWatch를 이용해 Source·Target 연결, 권한과 복제 상태를 관리한다.
Google Cloud Database Migration Service	Cloud SQL, AlloyDB	Google Cloud의 관리형 데이터베이스를 Target으로 하는 마이그레이션 경로를 제공한다.
Azure Database Migration Service	Azure SQL, Azure Database for MySQL·PostgreSQL 등	Azure의 관리형 데이터베이스를 Target으로 하는 마이그레이션 시나리오를 제공한다.

서비스를 선택할 때는 Full Load·CDC 지원 여부뿐 아니라 최종 Target DB, 네트워크 위치, 권한 체계, 모니터링과 기존 IaC 환경을 함께 고려해야 한다.

3. Need U 적용 판단

3.1 판단 기준

성공 처리된 데이터의 유실과 중복을 허용하지 않는다.
필요한 경우 일부 쓰기 기능을 잠시 제한할 수 있다.
V1과 RDS를 동시에 Writer로 사용하지 않는다.
RDS 쓰기 시작 전까지 V1으로 롤백할 수 있어야 한다.
최종 Target은 Amazon RDS다.
MySQL과 PostgreSQL의 쓰기 특성과 스키마 차이를 분리해서 판단한다.

3.2 MySQL 적용 판단

마이그레이션 기법 선정

V1 MySQL은 사용자, 인증, 친구, 채팅과 추천 데이터를 저장한다. 서비스 운영 중에도 사용자 요청에 의해 데이터가 계속 변경되므로 Dump/Restore만으로는 RPO 0을 만족할 수 없다.

실제 V1과 전달받은 V2 스키마를 비교한 결과, DMS 대상인 공통 테이블은 대부분 기존 컬럼의 이름과 타입이 유지된다. V2에는 신규 테이블과 일부 nullable 컬럼·인덱스가 추가된다.

Dump/Restore와 Full Load Only는 운영 중 변경분을 자동으로 반영하지 못한다. Native Replication은 가능하지만 초기 적재와 복제 위치, 장애 복구를 직접 관리해야 한다. Debezium·Kafka와 Airbyte는 마이그레이션 이후에도 별도 CDC 플랫폼을 운영해야 하며, Dual Write는 애플리케이션 변경과 부분 실패 처리가 필요하다.

따라서 MySQL 마이그레이션 기법은 기존 데이터 적재와 운영 중 변경분 복제를 함께 관리할 수 있는 관리형 Full Load + CDC로 결정한다.

AWS DMS 선정

관리형 DMS 가운데 AWS DMS를 선정하는 이유는 다음과 같다.

Source가 AWS EC2에서 실행 중인 MySQL이다.
최종 Target이 Amazon RDS MySQL로 확정되어 있다.
V1·V2 네트워크와 Security Group이 AWS VPC에 구성되어 있다.
IAM으로 DMS 리소스 권한을 관리하고 CloudWatch에서 Task 상태와 CDC 지연을 모니터링할 수 있다.
기존 AWS Terraform 구성과 함께 DMS 리소스를 관리할 수 있다.

Google Cloud Database Migration Service와 Azure Database Migration Service는 각각 Cloud SQL·AlloyDB 및 Azure 관리형 데이터베이스를 주요 Target으로 한다. 이를 사용하려면 현재 확정된 Amazon RDS Target과 맞지 않거나 Cross-Cloud 네트워크·권한·모니터링 구성이 추가된다.

따라서 다른 DMS보다 기능적으로 항상 우수해서가 아니라, Source와 Target 및 운영 인프라가 모두 AWS에 있는 현재 구조에 가장 적합하기 때문에 AWS DMS를 선정한다.

공통 테이블의 운영 중 변경분은 AWS DMS로 이전한다. Backend팀 확인 결과 기존 사용자의 users 값 변경과 V2 신규 테이블 초기화가 필요하지만, 아직 세부 규칙을 전달받지 않았다. 구체적인 변환 대상·방법·실행 시점은 내용을 전달받은 뒤 후속 세부 설계에서 확정한다.

3.3 PostgreSQL 적용 판단

V1 PostgreSQL은 다음 네 개의 카탈로그 테이블만 사용한다.

catalog_products
catalog_product_documents
catalog_embedding_models
catalog_sync_runs

사용자 채팅이나 인증 데이터는 PostgreSQL에 저장되지 않는다. PostgreSQL 쓰기는 catalog_import, catalog_sync, catalog_enrich 같은 카탈로그 작업이 실행될 때 발생한다.

마이그레이션 기간에는 상품 데이터를 추가·수정하지 않으며 카탈로그 쓰기 작업도 실행하지 않는다. 따라서 PostgreSQL은 마이그레이션 동안 읽기 전용 원본으로 유지할 수 있다.

실제 V1 PostgreSQL에는 이미 최신 001~005 스키마가 적용되어 있다. catalog_products에는 카테고리·선물·세부 카테고리 컬럼까지 존재하며, 완성된 설명·분류·임베딩과 HNSW 인덱스도 저장되어 있다.

이 조건에서는 PostgreSQL CDC를 새로 구성하거나 wal_level=logical로 변경할 필요가 없다. V1이 조회 요청을 계속 처리하는 동안 pg_dump/pg_restore로 현재 데이터를 그대로 옮길 수 있다.

3.4 최종 결론

MySQL: AWS DMS Full Load + CDC
PostgreSQL: 변경이 없는 상태에서 pg_dump/pg_restore

MySQL
V1 MySQL ── Full Load + CDC ──→ RDS MySQL
            최종 전환 때만 짧게 쓰기 제한

PostgreSQL
V1 PostgreSQL ── pg_dump/pg_restore ──→ RDS PostgreSQL
                 Catalog 쓰기 작업 중지, 사용자 조회는 유지

이 설계의 무중단 기준은 다음과 같다.

데이터 이전 중 사용자는 기존 V1 서비스를 계속 사용한다.
PostgreSQL 조회 서비스는 이전 중에도 유지한다.
MySQL 최종 전환 시에만 필요한 범위의 쓰기를 짧게 제한한다.
전체 서비스 점검이나 장시간 중단은 수행하지 않는다.
성공 처리된 데이터의 유실과 중복은 허용하지 않는다.

3.5 방식 비교 요약

DB	검토 방식	판단
MySQL	Dump/Restore	운영 중 변경분이 자동 반영되지 않아 미선정
MySQL	Native Replication	가능하지만 초기 적재·복제 위치·오류 복구를 직접 관리해야 하므로 미선정
MySQL	DMS Full Load Only	Full Load 이후 변경분이 누락되므로 미선정
MySQL	DMS Full Load + CDC	기존 데이터와 운영 중 변경분을 함께 이전할 수 있어 선정
PostgreSQL	Catalog 전체 재구축	기존 설명·분류·임베딩 결과가 달라질 수 있어 미선정
PostgreSQL	Logical Replication 또는 DMS CDC	카탈로그 쓰기를 멈출 수 있는 현재 조건에서는 구성 부담이 커 미선정
PostgreSQL	pg_dump/pg_restore	기존 pgvector 데이터와 임베딩을 그대로 보존할 수 있어 선정

4. 실제 환경 확인 결과

4.1 V1 및 RDS 엔진

V1 Production

MySQL 8.4.11
- log_bin=ON
- server_id=1
- binlog_format=ROW
- binlog_row_image=FULL
- binlog_expire_logs_seconds=2592000 — 30일
- binlog_transaction_compression=OFF
PostgreSQL 18.6
- vector 0.8.1
- 현재 wal_level=replica
- Dump/Restore 방식을 사용하므로 logical 변경과 재시작은 필요하지 않음

V2 RDS 기준

MySQL 8.4.11
PostgreSQL 18.6
두 RDS 모두 Private Subnet에 배치

4.2 데이터 규모와 객체

구분	MySQL	PostgreSQL
테이블 수	14개	4개
크기	약 12.14MB	약 287MB
PK 없는 테이블	없음	없음
사용자 Trigger	없음	없음
사용자 Sequence	해당 없음	없음
특수 객체	없음	`vector 0.8.1`, HNSW 인덱스

PostgreSQL 데이터의 대부분은 약 275MB인 catalog_product_documents가 차지한다.

5. MySQL 마이그레이션 설계

5.1 스키마 차이와 이전 범위

V1에는 14개 테이블이 있고 V2 기준 스키마에는 18개 테이블이 있다.

DMS 대상: 공통 11개 테이블

users
user_taste_profiles
auth_sessions
friends
ai_chat_rooms
ai_messages
products
personal_recommendations
gift_recommendations
error_reports
taste_analyses

공통 테이블은 기존 컬럼의 이름과 타입이 유지된다. 다음 항목만 V2에서 추가된다.

personal_recommendations.deleted_at — nullable
gift_recommendations.deleted_at — nullable
friends.idx_friends_friend_user_id
products.category 코멘트 변경

실제 V1 products.category 값은 이미 VOUCHER, LIVING, BEAUTY 등 V2 코드 형식이다. 따라서 별도의 카테고리 데이터 변환은 현재 Production 기준으로 필요하지 않다.

DMS 제외: V1 전용 3개 테이블

personal_products
- 실제 행 수 0건
gift_products
- 실제 행 수 0건
products_catalog_promotion_20261011
- products와 구조가 같고 현재 두 테이블 모두 7,969건
- 주요 데이터 차이가 없으며 현재 AI 서버도 products를 원본으로 사용

세 테이블은 DMS 대상에서 제외한다. V1에서는 마이그레이션과 안정화가 끝날 때까지 삭제하지 않는다.

V2 신규 7개 테이블

user_consents
kakao_tokens
shedlock
notification_settings
product_feedbacks
product_link_clicks
purchase_checks

V1에 동일한 이름의 테이블이 없으므로 이 테이블들은 테이블 단위 DMS 복제 대상이 아니다. V2 RDS에는 스키마를 미리 생성한다. V1의 다른 테이블·컬럼에 대응 데이터가 있는지는 추가 확인하고, 필요한 경우 별도 Migration Script로 변환·적재한다.

다만 기존 사용자 데이터에 대해서는 다음 정책을 Backend팀과 확정해야 한다.

기존 사용자에게 user_consents 초기 데이터가 필요한지

kakao_tokens는 Need U 로그인 세션을 유지하기 위한 토큰이 아니라, 친구 자동 동기화와 향후 캘린더 연동을 위해 서버가 카카오 API를 호출할 때 사용하는 Access Token과 Refresh Token을 저장하는 테이블이다.

따라서 kakao_tokens가 비어 있다는 이유만으로 기존 사용자가 즉시 다시 로그인해야 하는 것은 아니다. 기존 사용자가 유효한 카카오 Access Token 또는 Refresh Token을 가지고 있다면 로그인 상태는 유지할 수 있다.

다만 친구 자동 동기화를 계속 제공하려면 기존 토큰의 현재 저장 위치와 kakao_tokens로의 이전 방법을 추가로 확정해야 한다. 다음 사항은 MySQL 전환 전에 확인한다.

V1에서 카카오 Access Token과 Refresh Token이 저장된 테이블·컬럼
V2 kakao_tokens로 옮길 데이터와 사용자 연결 기준
기존 토큰의 암호화 여부와 V2 KAKAO_TOKEN_ENCRYPTION_KEY로 읽을 수 있는지
만료된 Access Token을 Refresh Token으로 갱신할 수 있는지
토큰을 이전하지 못했을 때 친구 자동 동기화 및 캘린더 연동에 필요한 재동의·재인증 절차

5.2 Target 스키마 준비

V2 스키마를 RDS에 먼저 적용한다. DMS가 V1 구조로 테이블을 다시 만들지 않도록 TargetTablePrepMode=DO_NOTHING을 사용한다.

전제 조건은 다음과 같다.

DMS 대상 11개 테이블이 비어 있어야 한다.
V2 신규 테이블과 추가 컬럼·인덱스가 실제로 생성돼 있어야 한다.
CREATE TABLE IF NOT EXISTS는 이미 존재하는 테이블을 변경하지 않으므로 컬럼과 인덱스를 직접 확인한다.
V2 애플리케이션의 쓰기는 운영 전환 전까지 허용하지 않는다.

5.3 DMS 리소스와 네트워크

DMS 3.5.4 이상 사용
MySQL Source Endpoint와 RDS MySQL Target Endpoint 생성
전용 Source·Target DB 사용자 사용
CloudWatch Logs와 Data Validation 활성화
V1과 V2 VPC 사이의 Private 연결 구성
DMS Security Group에서 V1 MySQL 3306과 RDS MySQL 3306 접근 허용
Endpoint 연결 테스트와 Premigration Assessment 수행

현재 V1과 V2는 서로 다른 VPC에 있으며 활성화된 Peering이 확인되지 않았다. DMS를 구성하기 전에 VPC Peering 또는 동등한 연결, Route, DNS와 Security Group을 먼저 준비해야 한다.

5.4 Target Endpoint와 Task 설정

RDS MySQL은 다음 조건을 만족해야 한다.

local_infile=1
문자셋, Collation과 Time zone 확인
PK, Unique Key와 AUTO_INCREMENT 정의 확인
Full Load 중 DMS 연결에만 FK 검사 비활성화

Initstmt=SET FOREIGN_KEY_CHECKS=0;

Task 설정은 다음을 기준으로 한다.

항목	설정
Migration type	Full Load + CDC
Target table preparation	Do nothing
Table mapping	공통 11개 테이블 개별 선택
CloudWatch Logs	활성화
Data validation	활성화
Batch apply	비활성화 상태로 우선 검증
DDL 변경	리허설·운영 이전 중 금지
LOB mode	실제 최대 TEXT·JSON 크기 측정 후 설정

MySQL에는 TEXT와 JSON 컬럼이 있으므로 LOB를 제외하는 설정을 사용하지 않는다. Limited LOB Mode를 사용한다면 실제 최대값보다 큰 LobMaxSize를 설정하고 잘림 여부를 검증한다.

5.5 MySQL 검증 기준

11개 테이블 모두 Full load complete
DMS Validation 상태 Validated
Table error, Mismatched records, Suspended records 0건
테이블별 COUNT(*), PK MIN·MAX 일치
날짜 범위와 주요 NULL 개수 일치
Unique Key 중복 0건
FK Orphan 0건
TEXT·JSON 잘림 0건
Target AUTO_INCREMENT가 현재 최대 ID보다 큼
로그인, 세션, 친구, 채팅과 추천 조회 Smoke Test 성공

6. PostgreSQL 마이그레이션 설계

6.1 이전 범위

다음 네 테이블 전체를 이전한다.

catalog_products
catalog_product_documents
catalog_embedding_models
catalog_sync_runs

실제 V1에는 001~005 스키마가 모두 적용되어 있다.

catalog_products: 24개 컬럼
카테고리·선물·세부 카테고리 컬럼 존재
catalog_product_documents.embedding: vector, 실제 차원 1024
vector Extension: 0.8.1
ix_catalog_documents_embedding_hnsw 존재

따라서 PostgreSQL은 V1→V2 데이터 변환이 아니라 동일한 구조로 스키마와 데이터를 복원하는 작업이다.

6.2 쓰기 동결 조건

Dump 시작 전부터 연결 전환 완료까지 다음 작업을 실행하지 않는다.

catalog_import
catalog_sync
catalog_enrich
기타 카탈로그 테이블을 수정하는 수동 작업

상품 데이터 추가·수정 계획이 없다는 팀 확인을 기준으로 한다. 사용자 추천 조회는 기존 V1 PostgreSQL을 계속 사용하므로 중단하지 않는다.

운영 전환 직전에는 ECS Scheduled Task, EventBridge 등 EC2 밖에서 카탈로그 작업을 실행하는 경로가 없는지도 확인한다.

6.3 Dump/Restore 절차

V2 RDS PostgreSQL 버전과 vector 0.8.1 지원 여부를 확인한다.
카탈로그 쓰기 작업을 모두 중지한다.
V1에서 pg_dump를 수행한다.
V2 RDS에 Dump를 pg_restore한다.
테이블·제약조건·인덱스와 데이터를 검증한다.
AI 서비스의 읽기 연결을 V2 RDS로 전환한다.
Smoke Test 성공 후 V1 PostgreSQL을 읽기 전용으로 보관한다.

복원 방식은 Staging에서 다음 두 가지 중 하나를 검증한 뒤 고정한다.

전체 DB Dump에 스키마와 데이터를 포함
Target에 Extension과 스키마를 미리 만들고 데이터와 인덱스를 선택 복원

6.4 PostgreSQL 검증 기준

네 테이블의 COUNT(*) 일치
PK별 데이터 일치
catalog_products 24개 컬럼과 제약조건 일치
vector Extension 버전 확인
모든 embedding의 vector_dims()=1024
임베딩 NULL·잘림 0건
embedding::text Hash 또는 표본값 일치
HNSW 인덱스 존재 및 유효 상태 확인
대표 추천 검색의 거리 값과 정렬 순서 일치
AI 추천 API Smoke Test 성공

7. DB 및 서비스 전환 절차

MySQL과 PostgreSQL의 데이터 이전 방식은 다르지만, 실제 서비스가 사용할 DB를 V1에서 RDS로 변경하는 작업은 아래 순서에 따라 함께 진행한다.

V1·V2 스키마와 배포 이미지 버전을 고정한다.
PostgreSQL 카탈로그 쓰기 작업을 중지한다.
PostgreSQL Dump/Restore와 검증을 완료한다.
MySQL DMS Full Load와 사전 Validation을 완료하고 CDC를 계속 실행한다.
V2 Backend와 AI를 RDS 연결 기준으로 사전 배포하되 사용자 쓰기는 열지 않는다.
사용자에게 MySQL 쓰기 제한을 안내하고 Backend 쓰기 API, Scheduler와 Batch를 제한한다.
진행 중인 MySQL 요청과 Transaction이 종료됐는지 확인한다.
CDCIncomingChanges와 CDC 메모리·디스크 대기 변경이 0인지 확인한다.
CDCLatencySource, CDCLatencyTarget이 사전에 정한 기준 이하인지 확인한다.
DMS Validation과 직접 검증을 다시 수행한다.
MySQL DMS Task를 중지한다.
후속 설계에서 확정한 기존 사용자 데이터 변환·초기화 작업을 수행하고 결과를 검증한다.
Backend와 AI의 DB Endpoint 또는 Secret을 RDS로 전환한다.
로그인, 세션, 친구 동기화, 채팅, 추천, 상품과 벡터 검색을 확인한다.
RDS 테스트 쓰기를 수행해 정상 저장을 확인한다.
오류율과 DB 연결 상태가 정상일 때 사용자 쓰기를 다시 허용한다.
V1 MySQL과 PostgreSQL을 읽기 전용으로 보관한다.

DMS 지연 지표가 낮더라도 Validation이나 직접 검증에서 차이가 있으면 전환하지 않는다. “지연 0을 3회 확인” 같은 세부 기준은 AWS의 보장이 아니라 Need U의 운영 기준이므로 Staging 측정 후 확정한다.

8. 롤백

8.1 RDS 쓰기 시작 전

V1을 원본 DB로 유지한다.
애플리케이션 연결을 V1으로 유지하거나 되돌린다.
MySQL 쓰기 제한을 해제한다.
PostgreSQL은 V1 조회를 계속 사용한다.
DMS를 다시 시도할 경우 Target을 비우고 처음부터 실행한다.

8.2 RDS 쓰기 시작 후

V1 DB로 단순 복귀하지 않는다.
RDS를 새로운 원본 DB로 유지한다.
애플리케이션 문제는 RDS와 호환되는 이전 이미지로 롤백한다.
데이터 문제는 RDS를 기준으로 수정한다.
V1 DB에는 새로운 쓰기를 허용하지 않는다.

9. Staging 리허설에서 확인할 항목

MySQL

DMS Endpoint 연결과 권한
Full Load 시간
평상시·Burst CDC 지연과 해소 시간
TEXT·JSON 및 nullable 추가 컬럼 반영
Validation 결과
최종 쓰기 제한 시간
DB Endpoint 전환과 롤백 시간

PostgreSQL

Dump와 Restore 시간
vector 0.8.1과 HNSW 복원
행 수·벡터 차원·검색 결과 일치
V1 조회를 유지한 상태의 연결 전환
Catalog 작업 중지 여부

리허설 결과는 가장 빠른 시간이 아니라 같은 절차를 반복했을 때 안정적으로 재현되는 시간을 기준으로 기록한다.