MySQL-GTID

MySQL Replication GTID 실습입니다.
기존 방식인 File/Position 방식과 GTID 방식의 차이를 실습을 통한 비교입니다.

---

GTID(Global Transaction Identifier)란?

MySQL 복제 환경에서 소스(Master)와 복제본(Replica)의 모든 트랜젝션에 부여되는 고유한 식별자

• 핵심

  • 복제 환경에서 각 Transaction에 고유한 ID를 부여하여 Replica가 "내가 이미 실행한 GTID 목록"을 Source에 보내서 부족한 것만 달라고 요청하는 방식으로, 자동 장애 조치(Failover), 편리한 복제 구성 및 관리, 데이터 무결성을 보장
  • server_uuid와 transaction_id 조합으로 생성

• 장점

  • 손쉬운 장애 조치 및 복구(Failover)
  • 복제 구조 단순화 및 자동화
  • 데이터 일관성 보장
  • 복제 위치 오류 감소

---

File/Position 방식과 GTID 방식 비교

항목	전통적 방식 (File/Position)	GTID 기반 복제
복제 위치 추적	binlog 파일명 + 위치를 수동으로 설정	GTID 기반으로 자동 추적
장애 복구	복잡하며 수동 작업 필요	자동 추적으로 비교적 간단
마스터 전환	Replica 재설정 등 수동 작업 필요	AUTO_POSITION=1로 쉽게 처리
운영 안정성	binlog 삭제 시 복제 실패 가능	상대적으로 안정적

---

직접 해보기

이거 이전은 강의에서 했던 실습과 똑같이 만듦.

GTID를 사용하지 않았을 때

GTID를 쓰지 않을 때 위치(binlog pos) 기반으로 복제를 추적

• Read_Source_Log_Pos
  • Replica의 IO Thread가 Source의 binlog를 어디까지 읽었는지
• Exec_Source_Log_Pos
  • Replica의 SQL Thread가 그중 어디까지 실제로 적용했는지

GTID 사용했을 때

아래와 같이 추가해줌.

Source

gtid_mode=ON

• GTID 기반 복제 활성화
• 트랜잭션마다 UUID:번호 형식의 ID 부여

enforce_gtid_consistency=ON

• GTID와 충돌나는 SQL 실행 금지 (안전 모드)

Replica

log_replica_updates=ON

• Replica가 Source에서 받은 트랜잭션도 자기 binlog에 기록함 (이 Replica를 나중에 또 다른 Replica의 Source로 쓰게 하기 위해서 - 체인 복제)

이렇게 추가해주고 dump 적용해서 확인.

잘 복제됨.

• SOURCE_AUTO_POSITION=1
  • replica가 binlog 파일/위치 대신 GTID 집합 기준으로 source에 요청하겠다는 의미
  • replica가 Executed_Gtid_Set 까지의 GTID들은 이미 실행했고, 이후의 트랜잭션만 요구 → source에서 이후의 gtid만 binlog에서 찾아서 보내주겠다.

이제 REPLICA RESET 시나리오 가정

기존에는

여기까지 데이터가 복제되어있는 상태. (22번까지)

Replica

Replica 멈춤

Source

Source에 새로운 데이터 추가

Replica

Replica에서 RESET

GTID 방식으로 다시 연결 및 복제

이후 SHOW REPLICA STATUS\G 해보면