1. 글로벌 트렌젝션 ID

• Replication 이란 고가용성 및 부하 분산을 위한 기능
• 마스터 노드 에서 수행 된 Transaction 을 슬레이브 노드에 로그를 이용해 읽기 전용으로 복제

GTID 사용 이전 버전에서는

• 마스터 노드의 바이너리 로그 파일 이름과 위치를 전달하는 방법 사용
• 파일 위치와 정보 등은 서버 내에서만 의미 있는 정보이므로 여러 슬레이브 노드 간 호환되지 않음

1) GTID 란

• 파일의 물리적 위치정보가 아니라 전체 node 간 호환 가능한 가상의 트렌젝션 ID
• 각 노드들의 바이너리 로그파일 및 Offset 정보가 다를지라도 글로벌 ID 값은 동일
• 트렌젝션을 지원하는 스토리지 엔진에서는 거의 트렌젝션 단위로 GTID 채번, 미 지원 엔진에서는 SQL 단위로 채번

MySQL 의 GTID 는

• GTID 시퀀스에서 누락 값을 허용하지 않음
• 멀티 스레드 복제 시 바이너리 로그의 순서와 무관하게 수행 가능

MariaDB 의 GTID 는

• GTID 시퀀스에서 누락 값을 허용
• 멀티 스레드 복제 시 바이너리 로그의 순서대로 수행

2) GTID 의 필요성

하나의 마스터에 두 개 이상의 슬레이브가 연결 된 복제 DB 에서 마스터 서버에 장애 발생 시

• 슬레이브 중 하나의 노드를 마스터로 승격시키고
• 다른 하나의 슬레이브를 새로 생긴 마스터 노드를 바라보게 전환
• 이 때 장애 발생 전 슬레이브 노드 간 전송 지연등에 의해 시점 차이가 있었을 경우 장애 이후 자동 동기화 불가

글로벌 ID 를 사용한다면

• 모든 노드 간 동일한 ID 값을 사용하므로
• 마스터 노드가 바뀌더라도 무관
• 전송 지연이 된 슬레이브라도 새로 승격 된 마스터에서 동일한 GTID 값을 이용해 따라잡을 수 있다

1) Maria DB 의 GTID

• "도메인 ID - 서버 ID - 트렌젝션 ID" 의 형식
• 도메인 ID 는 멀티 소스 레플리케이션 시 사용할 수 있는 마스터 노드의 정보

GTID 를 스용한 복제 구축 절차

1. 바이너리 로그 파일과 위치 기반 복제를 GTID 로 변경
2. 기존 DB 서버의 데이터 백업
3. 새 슬레이브에 데이터 복구
4. 백업 시점의 바이너리 로그 파일명과 위치 확인
5. 바이너리 로그와 위치로 GTID 확인
6. 슬레이브의 GTID 값을 마스터의 GTID 로 변경
7. 슬레이브에서 CHANGE MASTER 명령 수행하여 마스터와 연결

GTID 를 이용하여 슬레이브에서 복제 건너뛰기

• 사용자의 실수나 장애로 인해 특정 이벤트의 중복 키 에러가 자주 발생한는 편이다
• 복제가 에러로 멈췄을 때 마지막 TGID 값을 확인하여 그 다음 GTID 값으로 재 설정

1) MySQL 의 GTID

• "서버 UUID : 트렌젝션 번호" 의 체계를 갖춤
• GTID 컨시스턴스 모드를 활성화 해야 한다는 제약이 있음
• --> 이 때 CTAS와 같은 명령을 사용할 수 없다 - DML 과 DDL 이 결합 된 형태이므로 에러 발생 시 롤백이 불가능하다고 함

GTID 를 스용한 복제 구축 절차

• Maria DB 와 동일

GTID 를 이용하여 슬레이브에서 복제 건너뛰기

• Marai DB 와 다르게 트렌젝션 번호의 누락을 허용하지 않는다.
• 건너 뛸 GTID 로 슬레이브 DB 의 파라메터 값을 맞춰주고 더미 트렌젝션(BEGIN; COMMIT;) 을 수행