Article
AWS DMS 마이그레이션 데이터 검증 가이드
도입
AWS DMS(Database Migration Service)는 강력한 도구지만, 마이그레이션을 완료한 후 “복제는 끝났는데 값이 미묘하게 다르다”는 상황을 경험하는 개발자들이 많습니다. 이 글은 그런 상황에서 어떤 순서로 점검해야 하는지 실무 기반으로 정리한 가이드입니다. DMS만 탓하기보다는 체계적으로 문제를 진단하고 해결하는 접근 방식을 제시합니다.
먼저 확인할 3가지
데이터 불일치가 발생했을 때 가장 먼저 봐야 할 항목은 다음 세 가지입니다:
- 스키마 검증: DMS에만 맡기지 말고 소스 DB와 타깃 DB의 스키마를 직접 비교
- 외래 키 제약: 타깃 endpoint의 추가 연결 속성에서
FOREIGN_KEY_CHECKS확인 - 시간대 설정: 소스와 타깃 endpoint의 시간대 설정이 일치하는지 확인
데이터 불일치의 일반적인 원인
| 증상 | 의심 지점 | 확인 방법 |
|---|---|---|
| 일부 컬럼 값이 예상과 다름 | 기본값, NULL 허용 여부, 시간대 | SHOW CREATE TABLE 비교 |
| 특정 테이블만 적재 실패 | 외래 키 제약, 테이블 적재 순서 | DMS 태스크 로그, target endpoint 설정 |
| 시간 관련 컬럼만 계속 어긋남 | 소스/타깃 시간대 불일치 | endpoint 설정값 비교 |
스키마 차이에서 비롯되는 경우가 가장 많습니다. DMS는 데이터 적재와 변경 복제에 집중하고, 스키마는 소스 기준 덤프를 신뢰하는 것이 더 안전합니다.
1단계: 스키마 검증부터 시작
테이블 정의 비교
예상치 못한 값이 들어가거나 기본값이 다를 때는 레코드부터 보지 말고 테이블 정의를 먼저 비교하세요:
SHOW CREATE TABLE source_table;
SHOW CREATE TABLE target_table;
특히 다음 항목을 확인합니다:
- DEFAULT 값: 기본값이 동일한지 확인
- NULL 허용 여부: nullable 설정이 같은지 확인
- TIMESTAMP/DATETIME: 자동 업데이트 설정 확인
- 트리거와 제약: 숨겨진 트리거나 제약이 있는지 확인
- 문자 집합: 컬럼의 문자 집합(charset) 확인
스키마 불일치 시 대응
스키마 차이가 발견되면 데이터를 다시 적재하기 전에 먼저 스키마를 바로잡는 것이 훨씬 덜 복잡합니다:
-- 예: deleted_at 기본값 추가
ALTER TABLE target_table
MODIFY deleted_at TIMESTAMP NULL DEFAULT NULL;
2단계: 외래 키 제약 조건 확인
Foreign Key Checks 설정
AWS DMS 문서는 MySQL 호환 타깃으로 전체 적재할 때 foreign key checks를 비활성화해야 한다고 명시합니다.
타깃 endpoint의 추가 연결 속성(Extra Connection Attributes)에 다음을 추가:
Initstmt=SET FOREIGN_KEY_CHECKS=0;
일부 행이 빠지거나 “제약 조건 위반” 에러가 날 때 이 설정부터 확인하세요.
주의사항
이 설정은 “문제를 영구적으로 숨기는” 것이 아닙니다:
- 전체 적재 시 참조 무결성 충돌을 줄이는 운영 설정입니다
- 적재 완료 후 참조 무결성을 실제로 검증해야 합니다
- CDC(변경 데이터 캡처)를 포함한 작업이면 적재 후 애플리케이션 쓰기 순서와 제약 조건 복구 시점도 함께 검토하세요
3단계: 시간대 설정 확인
MySQL 소스 Endpoint 설정
MySQL 소스 endpoint의 ServerTimezone 설정을 확인:
aws dms describe-endpoints --filters Name=engine-name,Values=mysql
또는 생성 시 지정:
--my-sql-settings '{"ServerTimezone":"Asia/Seoul"}'
MySQL 타깃 Endpoint 설정
MySQL 호환 타깃 endpoint의 추가 연결 속성에 시간대 추가:
Initstmt=SET time_zone='+09:00';
또는 지역명 사용:
Initstmt=SET time_zone='Asia/Seoul';
시간 불일치 진단
시간 컬럼 문제는 한 곳만 봐서는 안 풉니다. 앱, DB, DMS 세 군데를 모두 확인:
| 확인 항목 | 명령어 |
|---|---|
| 소스 DB 시간대 | SELECT @@global.time_zone, @@session.time_zone; |
| 타깃 DB 시간대 | SELECT @@global.time_zone, @@session.time_zone; |
| 애플리케이션 시간대 | 코드에서 TimeZone.getDefault() 확인 |
| DMS 소스 endpoint | AWS 콘솔 또는 CLI로 ServerTimezone 확인 |
| DMS 타깃 endpoint | AWS 콘솔에서 Extra Connection Attributes 확인 |
마이그레이션 전 체크리스트
마이그레이션을 시작하기 전에 다음 항목들을 확인하세요:
- 소스와 타깃의
SHOW CREATE TABLE결과를 비교하고 스키마가 일치하는지 확인 - full load인지, CDC 포함인지 작업 방식을 명확히 함
- 외래 키 오류가 예상되면 target endpoint에
Initstmt=SET FOREIGN_KEY_CHECKS=0;설정 - 시간 컬럼이 있으면 source의
ServerTimezone과 target의time_zone을 동일하게 설정 - 일부 테이블만 문제가 있으면 태스크 로그와 샘플 row를 함께 비교
- 마이그레이션 후 적재된 데이터를 샘플로 검증하고 로우 카운트 비교
마치며
AWS DMS 마이그레이션에서 데이터가 어긋날 때는 “DMS가 이상하다”보다 “스키마, 제약 조건, 시간대 중 어디가 다르지?”라고 보는 편이 훨씬 빠르게 문제를 해결합니다. 특히 MySQL 계열에서는 foreign key checks와 time zone 설정이 반복적으로 문제를 만들곤 합니다. 이 가이드의 세 가지 점검 항목을 먼저 확인하면 대부분의 데이터 불일치 문제를 빠르게 찾아낼 수 있습니다.
댓글