MySQL 복제 방식 전환: Binary Log에서 GTID

오형상·2025년 12월 25일

TodayTable

목록 보기
13/13

기존의 Binary Log File + Position 기반 복제 방식은 관리가 까다롭습니다. 마스터의 로그 파일 번호와 위치(Pos)를 일일이 확인해야 하고, 장애 발생 시 시점을 맞추는 과정에서 실수가 발생하기 쉽기 때문입니다.

오늘은 이를 해결하기 위해 MySQL의 현대적인 복제 방식인 GTID(Global Transaction Identifier)를 도입하고 설정하는 과정을 공유하려 합니다.


1. GTID란 무엇인가?

GTID(Global Transaction Identifier)는 MySQL 서버 내에서 발생하는 모든 트랜잭션에 부여되는 전역 고유 식별자입니다.

  • 형식: Source_UUID:Transaction_ID (예: 03227f56-3c35-11f0-bc85-327251d557b2:1-2)
  • 특징: 어떤 서버에서 발생한 트랜잭션인지, 몇 번째 작업인지가 고유하게 정의됩니다.

왜 GTID를 도입해야 할까?

  1. 위치 관리 불필요: "몇 번 파일의 몇 번 위치부터 복제해"라고 말할 필요가 없습니다. "내가 여기까지 처리했으니 다음 GTID부터 보내줘"라고 자동으로 통신합니다.
  2. 장애 복구(Failover) 용이: 마스터가 죽었을 때, 여러 슬레이브 중 어떤 데이터가 더 최신인지 GTID만 비교하면 바로 알 수 있습니다.
  3. 데이터 일관성: enforce_gtid_consistency 옵션을 통해 복제 오류를 유발할 수 있는 안전하지 않은 쿼리를 사전에 차단합니다.

2. 변경 과정: 실전 가이드

Step 1. MySQL 설정 파일(my.cnf) 수정

먼저 Master와 Slave 서버의 설정 파일에 GTID 관련 옵션을 추가하고 서버를 재시작해야 합니다.

[mysqld]
# GTID 모드 활성화
gtid_mode = ON
# GTID 복제 일관성 강제
enforce_gtid_consistency = ON
# 복제 업데이트 내역을 자신의 이진 로그에 기록
log_replica_updates = ON

Step 2. 마스터(Master) 노드 권한 설정

복제 전용 계정에 필요한 권한을 부여합니다.

-- 마스터 서버에서 실행
GRANT ALL PRIVILEGES ON *.* TO 'admin_ohy'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Step 3. 슬레이브(Slave)에서 GTID 복제 설정

이제 슬레이브 서버에서 기존 복제 정보를 초기화하고 GTID 기반으로 소스를 재설정합니다.

-- 1. 기존 복제 중지
STOP REPLICA;

-- 2. 기존 복제 정보 초기화 
RESET REPLICA ALL;

-- 3. GTID 기반으로 Source 설정 
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '172.19.0.3',
  SOURCE_USER = 'admin_ohy',
  SOURCE_PASSWORD = 'adminpassword',
  SOURCE_AUTO_POSITION = 1,  -- 파일 위치 대신 GTID를 사용하도록 설정
  SOURCE_SSL = 1,
  SOURCE_SSL_CA = '/etc/mysql/certs/ca.pem',
  SOURCE_SSL_CERT = '/etc/mysql/certs/client-cert.pem',
  SOURCE_SSL_KEY = '/etc/mysql/certs/client-key.pem';

-- 4. 복제 시작
START REPLICA;

3. 결과 확인

설정 후 아래 명령어를 통해 상태를 확인합니다.

SHOW REPLICA STATUS\G;

0개의 댓글