복제본 손상 / 재동기화 필요
복제본/standby와 primary 간 동기화가 깨졌다. 복제가 중지되었는지, 얼마나 뒤처졌는지, 위치/GTID 체인이 깨졌는지 파악한 뒤 오류 건너뛰기, 대기, 재구축(reseed) 중 올바른 경로를 선택한다. split-brain 경고를 포함한다.
복제의 전반적인 상태는 어떠한가?
먼저 복제 상태를 확인한다: 적용 스레드가 실행 중인가, 지연은 얼마나 큰가, 오류가 있는가? 또한 두 노드가 모두 쓰기를 받고 있지 않은지(split-brain) 확인한다.
SHOW REPLICA STATUS\G
-- Check: Replica_IO_Running, Replica_SQL_Running, Seconds_Behind_Source, Last_Error, Retrieved/Executed_Gtid_Set- 복제가 중지됨 / 실패 중
- 실행 중이지만 크게 뒤처짐(큰 지연)
- GTID/위치가 깨지고 불일치 — 재구축
- 두 노드가 모두 primary로 쓰기 중(split-brain 의심)
오류를 복구할 수 있는가, 재구축이 필요한가?
적용 오류를 검토한다. 일부 오류(duplicate key, missing row)는 단일 이벤트를 안전하게 건너뛰어 해결할 수 있다. 그러나 데이터 불일치/손상이 있다면 유일하게 올바른 방법은 복제본을 재구축하는 것이다.
SHOW REPLICA STATUS\G
-- Check: Last_SQL_Errno, Last_SQL_Error, Last_IO_Errno, Last_IO_Error- 단일/소수의 적용 오류(건너뛰기 가능)
- 복구 불가능한 불일치 / 손상
지연은 일시적인가, 지속적인가?
시간에 따른 지연 추세를 확인한다. 일시적인 부하 급증 후 지연이 줄어드는가(따라잡는가), 아니면 계속 증가해 복제본이 primary를 따라잡지 못하는가?
SHOW REPLICA STATUS\G
-- Measure Seconds_Behind_Source several times: is it decreasing or increasing?- 일시적 부하 급증, 지연이 줄어드는 중
- 계속 증가, 따라잡지 못함
해결: 적용 오류를 신중하게 건너뛰기
단일 적용 오류(예: duplicate key)로 복제가 중지되었고 데이터가 실제로 일관됨을 확신한다면 해당 이벤트를 건너뛰고 스트림을 계속할 수 있다. 이는 최후 수단이며, 무작정 건너뛰면 조용한 데이터 불일치가 생긴다.
해결: 복제본 재구축(reseed / rebuild)
위치/GTID 체인이 깨졌거나, 데이터가 어긋났거나, 복구 불가능한 오류가 있다면 유일하게 신뢰할 수 있는 방법은 primary에서 새로 받은 사본으로 복제본을 재구축하는 것이다.
근본 원인: 일시적 부하 급증(지연이 줄어드는 중)
복제는 정상이다. primary의 일시적인 쓰기 폭증이나 네트워크 변동으로 지연이 생겼지만 복제본이 따라잡고 있다.
근본 원인: 복제본이 primary를 따라가지 못함
적용(apply/redo) 측이 primary가 생성하는 변경 속도를 따라가지 못해 지연이 계속 증가한다. 대개 단일 스레드 적용, 느린 복제본 하드웨어 또는 네트워크 병목이 원인이다.
경고: split-brain(두 개의 primary) — 데이터 손실 위험
두 노드가 모두 primary 역할로 쓰기를 받으면 양쪽에 충돌하는 변경이 쌓인다. 가장 위험한 상황이며 데이터 손실로 이어질 수 있다. 쓰기를 단일 노드로 줄이는 것이 최우선이다.