MariaDB GTID(Global Transaction ID)


1. GTID가 나온 배경

Master와 여러개의 Slave 구성에서 Master가 다운되었을 때, Slave 군 중 복제 지연이 가장 적은 Slave를 새로운 마스터로 승격 시키게 된다. 다른 Slave들은 새로운 Master에게 CHANGE MASTER를 실행하여 Master를 전환해야하는데, 이때 기존의 전동적인 방식에는 문제가 발생한다. 각 Slave마다 이전 Master의 binlog 이름과 포지션에서 어디까지 복제했는지는 알고 있지만, 새로운 Master에서의 파일 이름, 포지션이 어디인지는 모르기 때문이다. 이를 해결하기 위해서 GTID라는 개념이 나오게 된 것이다.

2. GTID의 장점

2-1. Master서버 변경이 쉽다.

Slave 는 GTID를 이용하여 기존 Master DB에서 마지막으로 적용된 이벤트를 알고 있기 때문에 새로운 Master DB에서 어디서 부터 재개를 해야하는지 쉽게 알 수 있다.
(모든 DB가 GTID를 알고 있고 이 값은 유니크하기 때문에 가능)

2-2. Slave의 상태가 크래시에도 안전하게 기록된다.

2-2-a. 기존의 방법

slave의 상태는 relay-log.info에 파일로 자장이 되었고, 이것은 실제 데이터의 변화와 독립적으로 업데이트가 되어 CRASH가 잘생할 경우 쉽게 sync 맞추기가 어려웠다.

2-2-b. GTID를 이용한 방법

3. GTID의 구성 및 특징

4. GTID에 대한 시스템 변수

gtid_slave_pos

gtid_binlog_state

gtid_binlog_pos

gtid_current_pos

gtid_slave_pos VS gtid_current_pos

예시) 146(Master) -> 143(Master이자 Slave) -> 144(Slave)로 구성되었을 때, 143서버의 GTID 변경 상태