복제 지연 원인과 대처 — Seconds_Behind_Source 읽기

읽기를 복제본(replica)으로 분산했는데 "방금 쓴 데이터가 안 보인다"는 문의가 들어오면 십중팔구 복제 지연입니다. 소스(source)에 쓴 변경이 복제본에 반영되기까지 시간이 벌어진 상태라, 그 사이 복제본을 읽으면 옛 데이터가 나옵니다.

먼저 지연 폭을 본다

SQL

SHOW REPLICA STATUS\G

세 줄을 봅니다.

OUTPUT

Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 312

Seconds_Behind_Source가 지연 초입니다. IO/SQL 스레드가 둘 다 Yes인데 이 값만 크면 복제는 살아 있지만 따라잡지 못하는 상황입니다. 둘 중 하나가 No면 지연이 아니라 복제 중단이므로 Last_Error를 먼저 봐야 합니다.

원인별 대처

복제본의 단일 스레드 적용 — 소스는 여러 커넥션이 동시에 쓰지만 복제본은 기본적으로 순차 적용합니다. 쓰기가 몰리면 밀립니다. → 병렬 복제를 켭니다.
SQL
```
SET GLOBAL replica_parallel_workers = 4;
SET GLOBAL replica_parallel_type = 'LOGICAL_CLOCK';
```
긴 단일 트랜잭션/대량 DML — DELETE로 수백만 행을 한 번에 지우면 복제본이 그 한 덩어리를 적용하는 동안 통째로 밀립니다. → 배치를 잘게 쪼갭니다.
복제본 하드웨어가 약함 — 소스보다 디스크 IOPS가 낮으면 못 따라갑니다. → 사양을 맞춥니다.
복제본에서 무거운 읽기 쿼리 — 분석 쿼리가 SQL 스레드와 자원을 다툽니다. → 분석은 별도 복제본으로 분리합니다.

점검 체크리스트

SQL

SHOW REPLICA STATUS\G                    -- Seconds_Behind_Source, IO/SQL 상태
SHOW PROCESSLIST;                        -- 복제본에 무거운 쿼리가 도는지
SELECT * FROM performance_schema.replication_applier_status_by_worker;  -- 워커별 적용 상태
SHOW VARIABLES LIKE 'replica_parallel_workers';  -- 병렬 복제 설정값

애플리케이션 차원에서는, 방금 쓴 직후의 읽기는 소스로 보내거나(read-your-writes), 일정 지연을 허용할 수 있는 화면만 복제본을 쓰도록 라우팅하는 것이 근본 대책입니다.

복제 토폴로지와 읽기 분산을 직접 구성하고 지연을 관찰하는 실습은 데이터베이스 트랙에서 회원가입 없이 무료로 할 수 있습니다.