MySQL Slave DB 지연(Seconds_Behind_Master) 원인과 해결 방법

MySQL Replication 환경에서 종종 발생하는 문제 중 하나가 Slave DB 지연입니다.

SHOW SLAVE STATUS\G 명령어로 확인할 수 있는 Seconds_Behind_Master 값이 높아지는 경우, 서비스에 영향을 줄 수 있기 때문에 빠른 원인 파악과 대응이 필요합니다.

이번 글에서는 Seconds_Behind_Master 값이 커지는 원인과, InnoDB 상태 분석, 그리고 해결 방안까지 정리해보겠습니다.

1. Slave DB 지연이란?

Slave DB 지연은 마스터에서 발생한 트랜잭션(binlog 이벤트)이 슬레이브에 적용되지 못하고 밀릴 때 발생합니다.

즉, 마스터와 슬레이브 간의 데이터 동기화 시간 차이가 나는 현상입니다.

이를 확인하는 대표적인 방법은 아래와 같습니다.

• Seconds_Behind_Master : 슬레이브가 마스터 대비 몇 초 지연되어 있는지를 나타냄.

2. Slave 지연의 주요 원인

1. 마스터의 DML 과부하

   • UPDATE, DELETE, INSERT가 대량으로 발생할 경우 슬레이브가 이를 순차적으로 처리하지 못하고 밀림.

2. 슬레이브 리소스 부족

   • CPU 코어 수 부족, 디스크 I/O 속도 저하, 메모리 부족 등으로 쿼리 적용 속도가 느려짐.

3. 트랜잭션 처리 특성

   • InnoDB는 트랜잭션 단위로 처리하기 때문에, 대용량 UPDATE/DELETE는 복제 지연의 주요 원인.

4. Sync 설정

   • innodb_flush_log_at_trx_commit=1

   • sync_binlog=1
     
     → 안정성은 높지만 성능은 저하됨.

3. InnoDB 상태에서 확인할 포인트

SHOW ENGINE INNODB STATUS\G 로 확인한 내용 중 중요한 지표들입니다.

• Row operations

   

  311.63 updates/s


  슬레이브가 초당 수백 건 이상의 UPDATE를 처리 중 → 마스터 이벤트 따라가느라 지연 발생.

• Locks

   

  1 row lock(s)


  락 경합은 거의 없음 → I/O 또는 처리 속도 문제임.

• Buffer Pool

   

  Buffer pool hit rate 999 / 1000


  캐시 효율은 좋음 → 디스크 병목이 아닌 CPU/트랜잭션 처리 속도 문제.

4. Slave DB 지연 해결 방법

1) 마스터 쿼리 최적화

• 대용량 UPDATE/DELETE를 한 번에 실행하지 말고 batch 처리:

pt-online-schema-change 같은 온라인 툴 활용.

2) 슬레이브 전용 설정 적용

• 성능을 위해 슬레이브에 한정해서 아래 설정을 권장:

→ commit/flush 비용을 줄여 복제 적용 속도 개선.

3) 병렬 복제(Parallel Replication) 활성화

MySQL 5.7 이상에서는 병렬 워커 수를 늘려 처리 속도를 개선할 수 있습니다.

4) 지연 원인 쿼리 추적

Performance Schema를 이용해 시간이 오래 걸린 쿼리를 확인할 수 있습니다.

5. 결론

MySQL Replication 환경에서 Slave 지연은 흔히 발생할 수 있는 문제이지만,

대부분은 마스터의 대량 DML 이벤트와 슬레이브 적용 속도 한계에서 비롯됩니다.

• 마스터 쿼리 최적화

• 슬레이브 전용 튜닝

• 병렬 복제 활성화

이 세 가지가 핵심적인 해결책입니다.

MySQL Slave Seconds_Behind_Master 문제를 꾸준히 모니터링하고, 위의 설정을 통해 슬레이브 성능을 최적화 한다면 안정적인 복제 환경을 유지할 수 있습니다.

[함께 읽으면 좋은 글]

• MySQL 공식 문서 – Replication Monitoring

  (Seconds_Behind_Master, SHOW SLAVE STATUS 설명 포함)

• MariaDB 문서 – Replication Delay

  • (MySQL과 구조적으로 비슷해 참고 가능)