복제 지연 / 중지

증상

standby/replica가 뒤처지거나 완전히 멈췄으며, 읽기 replica가 오래된 데이터를 보여 준다.

1. 지연이 얼마나 크며 증가 중인가 안정적인가

지연은 초/바이트로 얼마인가? 일정한 차이인가, 계속 증가하는가? 증가한다면 replica가 적용을 따라가지 못하는 것이고, 일정하다면 일시적인 정체가 있었던 것이다.

Oracle

SELECT name, value, unit FROM v$dataguard_stats WHERE name LIKE '%lag%';

PostgreSQL

SELECT client_addr, state, write_lag, flush_lag, replay_lag FROM pg_stat_replication;

MySQL

SHOW REPLICA STATUS\G  -- Seconds_Behind_Source

SQL Server

SELECT ar.replica_server_name, drs.redo_queue_size, drs.log_send_queue_size FROM sys.dm_hadr_database_replica_states drs JOIN sys.availability_replicas ar ON drs.replica_id=ar.replica_id;

Redis

INFO replication  # master_repl_offset vs slave offset

2. 복제가 실행 중인가, 오류가 있는가

IO/SQL 스레드 상태, apply 프로세스는 어떠하며 연결이 끊겼는가? 오류(예: 충돌 행, 누락 테이블)가 있으면 적용이 멈춘 것이므로 오류 메시지를 읽는다.

MySQL

SHOW REPLICA STATUS\G  -- Replica_IO_Running / Replica_SQL_Running / Last_Error

PostgreSQL

SELECT status, last_msg_receipt_time, latest_end_lsn FROM pg_stat_wal_receiver;  -- on the standby

Oracle

SELECT process, status, sequence#, thread# FROM v$managed_standby WHERE process LIKE 'MRP%' OR process LIKE 'RFS%';

3. 병목을 찾는다

왜 따라가지 못하는가? 단일 스레드 적용과 무거운 쓰기 부하(PG/MySQL은 대부분 직렬 적용), standby의 I/O 병목, 네트워크, 또는 적용을 막는 긴 쿼리(PG hot_standby_feedback / recovery conflict)인가?

4. 지연을 해소한다

적용을 가속한다: 병렬 적용 활성화(MySQL replica_parallel_workers — 8.0.26 이전에는 slave_parallel_workers, PG에는 없지만 recovery 설정이 있음), standby I/O 개선, 적용을 막는 쿼리 해결. 오류로 멈췄다면 오류를 수정하고(충돌 행을 수동 해결) 복제를 재개한다.

5. 깨졌다면 재구축한다

replica가 크게 뒤처졌거나 깨졌다면 재동기화가 가장 깔끔하다: 새 백업으로 standby를 재구축한다(PG pg_basebackup, MySQL clone/xtrabackup, Oracle RMAN duplicate). 중요: 재구축 전에 원인을 찾지 않으면 다시 발생한다.