MySQL 8.0의 GTID 복제(Replication) 및 mode 변경 실습

GTID(Global Transaction ID)란?

원본 서버에서 Commit된 트랜잭션과 연결된 식별자를 말한다.

• GTID = server_uuid:transaction_id

복제의 일관성 - 모든 트랜잭션에 대해서 전역 고유 식별자를 부여

자동 복구 - Slave 서버가 손실된 트랜잭션을 자동 감지 및 복구 가능

Master-Slave 전환 용이성 - 복제 위치를 명시적으로 지정하지 않고 페일 오버 가능

트랜잭션 기반 복제 - 트랜잭션 단위로 복제해서 복제간 충돌 방지 및 데이터 일관성 유지

 

 

GTID 기반 복제(Replication)

gtid 브랜치에서 my.cnf 변경사항 확인하기

 

https://github.com/downfa11/mysql-replication/tree/gtid

GitHub - downfa11/mysql-replication: MySQL 8.0 기반 데이터베이스 복제와 GTID mode 실습

 

 

기본적인 my.cnf 구성은 일반적인 복제 실습때처럼 timezone 동기화, server-id 식별 구분과 함께 처리한다.

gtid_mode = ON
enforce-gtid-consistency = ON

 

추가적으로 각 노드별로 GTID MODE를 활성화해야한다.

 

 

Slave Node의 복제 구성에서 변경 사항 적용하기

CHANGE MASTER TO
  MASTER_HOST='mysql-master',
  MASTER_USER='repl',
  MASTER_PASSWORD='replpw',
  MASTER_AUTO_POSITION = 1;
START SLAVE;

 

덤프 파일만 잘 옮기면 나머지 Log Position 계산 없이 자동으로 동기화된다.

 

이전 복제 구성처럼 위치(Position)이나 로그 파일을 따로 관리할 필요가 없어서 클러스터, 페일오버에 매우 유리하다.

Slave Node가 잠시 끊겨도, 복귀할 때 자동으로 그동안 놓친 트랜잭션만 받아와서 복구 및 재동기화에 용이하다.

 

 

 

기본 복제와 차이점이 뭘까?

Slave Node를 유연하게 붙였다가 뗄 수 있어서 관리가 편리하다.

복제 위치 추적을 자동으로 해주니, 장애 조치시 수동으로 binlog 파일을 추적하지 않아도 된다.

 

어떤 트랜잭션이 처리됐는지 명확히 추적하기 어려운 기존 복제 방식에 비해서, GTID를 통해 각 트랜잭션의 이력을 명확하게 추적할 수 있다는 장점이 있다.

 

특히 대규모 환경이나 다중 슬레이브 환경 혹은 자동화를 원한다면 GTID 기반 복제를 고려해볼 수 있다.

 

다만, 일단 GTID를 활성화해버리면 전환이 까다로우니 할거면 초기부터 활성화해버리는게 낫다.

SQL 관리시, GTID 없는 트랜잭션이 존재하는 경우 복제가 불가능하니 유의해야한다.