Aurora + DMS 환경에서 GTID

DMS는 MySQL 입장에서 보면 "가짜 슬레이브(Replica)" 역할을 합니다. DMS가 데이터를 긁어오다가 네트워크가 끊기거나, DMS 태스크가 재시작될 때 "나 어디까지 읽었지?"를 기억해야 하는데, 이때 GTID가 결정적인 역할을 합니다.

1. Aurora Failover (리더 교체) 대응

Aurora는 리더가 죽으면 1분 내외로 레플리카 중 하나가 새로운 리더가 됩니다.

• GTID 미사용 시 (Binlog File/Position 방식)

  • DMS는 mysql-bin-changelog.000123 파일의 Position 500까지 읽었다고 기억합니다.
  • 리더가 죽고 새로운 리더가 선출됩니다.
  • 새로운 리더는 mysql-bin-changelog.000001부터 새로 로그를 쌓기 시작할 수도 있고, 파일 이름 규칙이 달라질 수도 있습니다.
  • DMS는 "어? 123번 파일 내놔"라고 하는데, 새 리더는 "나 1번부터 있는데?"라고 답합니다.
  • 결과: 복제 깨짐 (Replication Error), 태스크 실패, 또는 데이터 누락/중복 발생.

• GTID 사용 시

  • DMS는 "나 트랜잭션 ID abc-123-uuid:500까지 읽었어"라고 기억합니다.
  • 새로운 리더가 선출되어도, 클러스터 내에서 트랜잭션 ID(GTID)는 고유하게 유지되고 공유됩니다.
  • DMS가 "500번 다음부터 줘"라고 요청하면, 새 리더는 파일 이름이 뭐든 상관없이 501번 트랜잭션부터 찾아서 줍니다.
  • 결과: 중단 없이 자연스럽게 재개

2. Kinesis Stream으로의 "Exactly-Once" 전송 지원

• DMS가 Kinesis로 데이터를 보낼 때, 중복 전송을 막고 순서를 보장하는 것이 중요합니다.
  • DMS가 데이터를 읽다가 잠깐 멈췄을 때, GTID가 있으면 정확히 멈춘 그 트랜잭션 다음부터 가져올 수 있습니다.
  • Binlog File/Position 방식은 파일이 정리(Purge)되거나 꼬이면 정확한 지점을 찾기 어려워, 데이터를 처음부터 다시 붓거나(Full Load), 일부를 놓칠 위험이 있습니다.

3. 온프레미스 vs Aurora 비교

구분	온프레미스 (Master-Slave)	Aurora (Writer-Reader)
Binlog 위치	각 서버가 별도의 디스크에 Binlog 보유	Writer가 생성하여 공유 스토리지에 저장 (Cluster Volume)
GTID의 역할	마스터가 바뀌어도(Failover) 슬레이브가 복제를 이어갈 수 있게 함	리더가 바뀌어도(Failover) DMS가 CDC를 끊김 없이 이어갈 수 있게 함
DMS 설정 권장	필수 권장	필수 권장 (특히 패치나 장애 대비)

요약

DMS가 메세지 큐로 데이터를 쏘는 상황이라면, 데이터의 순서와 누락 방지가 생명일 것입니다.
Aurora가 단일 인스턴스로 평생 죽지 않고 재부팅도 안 한다면 Binlog File/Position만으로도 충분합니다. 하지만 Aurora는 패치, 스케일링, 장애 시 언제든 리더가 바뀔 수 있는 구조입니다.
따라서 "리더가 바뀌었을 때 DMS가 길을 잃지 않게 하기 위해" GTID 설정이 반드시 필요합니다.