Global Transaction Identifiers (GTIDs)
MYSQL 5.6 버전까지 레플리카는 소스에 연결할 때 읽고 있던 바이너리 로그 파일과 로그 위치를 추적해야했다.
EX)
1. 레플리카가 업스트림 소스에 연결되어 위치 2749의 binlog.000002에서 데이터를 읽는다.
2. 레플리카는 바이너리 로그를 읽을때 마다 위치 이동.
3. 그러던 중 재해 발생하여 소스가 손상하여 백업에서 데이터를 다시 작성해야함
4. 바이너리 로그가 다시 시작 된다면 레플리카를 어떻게 다시 연결해야 하는가? 너무 복잡하다.
그래서 전역 트랜잭션 식별자가 추가 됨.
소스 서버가 커밋하는 모든 트랜잭션에 고유 식별자(server_uuid + 트랜잭션 번호)가 할당.
트랜잭션이 바이너리 로그에 기록되면 GTID도 함께 기록.
레플리카가 바이너리 로그 이벤트를 로컬 릴레이 로그에 복사하고 SQL 스레드를 사용하여 로컬 복사본에 변경사항을 적용하는데
SQL 스레드는 트랜잭션을 커밋할 때 GTID도 완료된것으로 기록
EX)
1. server_uuid + 트랜잭션 번호 : b9acac5a07bbe-11eb-a043-42010af8001a:1트랜잭션을 완료 후 기록
2. 레플리카에서 MYSQL을 중지
3. 단일 트랜잭션을 커밋하면서 계속하여 소스에서 쓰기를 수행하면 b9acac5a07bbe-11eb-a043-42010af8001a:2 ... 늘어남
4. 레플리카가를 다시 살렸을 때 레플리카는 트랜잭션 1이 이미 처리 된것을 확인 후 2부터 시작.
GTID를 사용하면 각 트랜잭션이 발생한 서버에서 커밋되고, 모든 복제본(레플리카)에서 동일하게 적용되며, 이러한 트랜잭션을 고유하게 식별하고 추적 가능.
GTID를 사용하면 새로운 레플리카를 시작하거나 소스를 다른 서버로 전환할 때 로그 파일이나 파일 내의 위치를 참조할 필요가 없어 이러한 작업이 크게 단순화된다.
이 방식 덕분에 소스와 레플리카가 동일한 트랜잭션을 가졌는지 여부를 쉽게 판단가능.
-참고
https://dev.mysql.com/doc/refman/8.4/en/replication-gtids.html
MySQL :: MySQL 8.4 Reference Manual :: 19.1.3 Replication with Global Transaction Identifiers
19.1.3 Replication with Global Transaction Identifiers This section explains transaction-based replication using global transaction identifiers (GTIDs). When using GTIDs, each transaction can be identified and tracked as it is committed on the originating
dev.mysql.com
'Database > RDS' 카테고리의 다른 글
| MYSQL - 단일 RDB 환경 에서 계층형 엔티티 저장 최적화, 벌크 인서트 (0) | 2025.05.24 |
|---|---|
| InnoDB - Undo Log, Redo Log (0) | 2024.08.14 |
| InnoDB - Replication (0) | 2024.08.13 |
| InnoDB - Transaction Isolation Levels (0) | 2024.08.12 |
| InnoDB - Locking (0) | 2024.08.12 |