MySQL GTID(Global Transaction ID) 기반 복제 환경에서 Slave 서버의 복제가 중단되었을 때, 원인을 확인하고 상황에 맞게 복구하는 방법을 정리한다.

장애 원인 확인

복제가 중단된 경우 가장 먼저 Slave 서버에서 현재 상태를 확인한다.

SHOW SLAVE STATUS \G;

주요 확인 항목은 다음과 같다.

항목	설명
Last_IO_Error	Master와의 통신 과정에서 발생한 오류
Last_SQL_Error	Relay Log 실행 중 발생한 SQL 오류
Slave_IO_Running	IO Thread 실행 여부
Slave_SQL_Running	SQL Thread 실행 여부
Seconds_Behind_Master	Master와의 복제 지연 시간

특히 Last_IO_Error 와 Last_SQL_Error 값을 통해 다음과 같은 문제를 확인할 수 있다.

네트워크 단절
디스크 공간 부족
권한 문제
테이블 구조 불일치
데이터 충돌
설정 오류

단순 장애인 경우 복제 재개

일시적인 네트워크 장애나 순간적인 오류로 인해 복제가 중단된 경우에는 복제를 재시작하는 것만으로 해결될 수 있다.

STOP SLAVE;
START SLAVE;

재시작 후 상태를 다시 확인한다.

SHOW SLAVE STATUS \G;

정상이라면 다음과 같이 표시된다.

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

특정 GTID를 건너뛰고 복제 재개

복제 중 특정 트랜잭션에서 오류가 발생했지만 해당 트랜잭션을 적용하지 않아도 서비스에 큰 영향이 없는 경우에는 해당 GTID를 건너뛰고 복제를 진행할 수 있다.

오류 발생 GTID 확인

SHOW SLAVE STATUS \G;

다음 항목을 확인한다.

Retrieved_Gtid_Set
Executed_Gtid_Set

예시

Retrieved_Gtid_Set : UUID:1-265410
Executed_Gtid_Set  : UUID:1-265409

위 상태는 다음을 의미한다.

Master에서 265410번 트랜잭션까지 전달됨
Slave는 265409번까지 실행 완료
265410번 트랜잭션 실행 중 오류 발생

즉, 오류가 발생한 GTID는 UUID:265410 이다.

GTID 건너뛰기

STOP SLAVE SQL_THREAD;

SET SESSION GTID_NEXT='{GTID}';

BEGIN;
COMMIT;

SET SESSION GTID_NEXT='AUTOMATIC';

START SLAVE SQL_THREAD;

예시

SET SESSION GTID_NEXT='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:265410';

주의사항

해당 트랜잭션이 실제로 누락되어도 괜찮은 데이터인지 반드시 확인해야 한다.

예를 들어:

이미 삭제된 데이터를 다시 삭제하는 쿼리
중복 INSERT
운영에 영향이 없는 로그성 데이터

등의 경우에만 사용을 고려한다.

Master와 Slave 데이터 재동기화

Slave 데이터가 크게 틀어졌거나 다수의 GTID 오류가 발생한 경우에는 전체 재동기화를 수행하는 것이 안전하다.

GTID 기반 복제에서는 이미 수행된 트랜잭션을 자동으로 인식하므로, 누락된 트랜잭션만 재전송 받을 수 있다.

Master에서 데이터 덤프 생성

mysqldump -u root -p \
--databases {DB명} \
--single-transaction \
--master-data=2 \
--triggers \
--routines \
--events \
> {덤프파일명}.sql

옵션	설명
--single-transaction	일관된 스냅샷 생성
--master-data=2	Binlog 위치 정보를 주석으로 포함
--triggers	Trigger 포함
--routines	Procedure / Function 포함
--events	Event 포함

Slave에서 데이터 복원

mysql -u root -p {DB명} < {덤프파일명}.sql

Slave 복제 정보 초기화

STOP SLAVE;

RESET SLAVE ALL;

Master 정보 재설정

CHANGE MASTER TO
MASTER_HOST='{서버_IP}',
MASTER_USER='{복제계정}',
MASTER_PASSWORD='{비밀번호}',
MASTER_AUTO_POSITION=1;

GTID 기반 복제에서는 MASTER_AUTO_POSITION=1 옵션을 사용하여 자동 위치 기반 동기화를 수행한다.

복제 시작

START SLAVE;

복제 정상 여부 확인

SHOW SLAVE STATUS \G;

다음 항목이 정상인지 확인한다.

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

설명:

Slave_IO_Running = Yes
- Master와 정상 통신 중
Slave_SQL_Running = Yes
- Relay Log 정상 적용 중
Seconds_Behind_Master = 0
- Master와 동기화 완료

정리

GTID 기반 복제 장애 발생 시 대응 순서는 다음과 같다.

SHOW SLAVE STATUS \G 로 원인 확인
단순 장애라면 STOP SLAVE → START SLAVE
특정 트랜잭션 문제라면 GTID Skip 수행
데이터 불일치가 크다면 재동기화 진행
Slave_IO_Running, Slave_SQL_Running, Seconds_Behind_Master 상태 확인

무조건 GTID를 Skip 하기보다는 오류 원인을 먼저 분석하고, 데이터 정합성에 문제가 없는 경우에만 Skip 하는 것이 중요하다.

연관 포스트

MySQL Replication 구성기

Sep 2, 2024

MySQL Replication 장애 복구 절차