Apr 3, 2026

MySQL replication lag 가이드: 복제 지연은 왜 생길까

MySQL을 읽기 분산 구조로 운영하다 보면 replication lag 문제를 자주 만나게 됩니다. 쓰기는 primary에서 했는데 replica에서는 아직 반영되지 않아, 방금 저장한 데이터가 안 보이거나 화면 상태가 어긋나는 식의 문제가 생길 수 있습니다.

이 글에서는 아래 내용을 정리합니다.

replication lag가 무엇인지
왜 생기는지
어떤 사용자 문제로 이어지는지
어떤 순서로 점검하면 좋은지

핵심은 replication lag는 단순한 DB 내부 지연이 아니라, 읽기/쓰기 일관성과 사용자 경험에 직접 영향을 주는 운영 문제라는 점입니다.

replication lag란 무엇인가

primary에 기록된 변경 사항이 replica에 반영되기까지 시간이 벌어지는 상태를 말합니다.

즉:

쓰기는 이미 완료됨
하지만 읽기 replica는 아직 과거 상태

이런 차이가 생기는 것입니다.

왜 문제가 될까

lag가 크면 사용자는 다음 같은 경험을 할 수 있습니다.

방금 수정한 데이터가 안 보임
목록과 상세 화면이 서로 다름
같은 요청 흐름 안에서 읽기 결과가 어긋남

즉, 단순히 “조금 느리다”가 아니라 제품 신뢰 문제로 이어질 수 있습니다.

replication lag는 왜 생길까

대표적인 원인은 아래와 같습니다.

replica가 적용해야 할 작업량이 너무 많음
긴 트랜잭션이나 큰 배치 작업
느린 쿼리로 replica 리소스가 부족함
I/O 또는 네트워크 병목
replica 스펙 부족

즉, lag는 복제 자체만의 문제가 아니라 전체 워크로드와 리소스 문제와 연결되어 있습니다.

무엇부터 확인할까

실무에서는 보통 아래 순서가 좋습니다.

lag가 언제 커지는지 확인
그 시점의 쓰기 부하와 배치 작업 확인
replica에서 느린 쿼리 여부 확인
CPU, 디스크, 네트워크 병목 확인
읽기 라우팅 전략 점검

중요한 점은 “DB가 느린가”만 볼 게 아니라 “왜 replica가 따라가지 못하는가”를 봐야 한다는 것입니다.

애플리케이션에서는 어떻게 대응할까

모든 읽기를 무조건 replica로 보내면 일관성 문제가 커질 수 있습니다. 그래서 일부 흐름에서는:

write 직후는 primary 읽기
중요한 조회는 strong read 유지
나머지는 replica 활용

같은 전략을 씁니다.

즉, replication lag는 DB 운영 문제이면서 동시에 읽기 라우팅 설계 문제이기도 합니다.

자주 하는 오해

1. replica를 늘리면 lag가 자동으로 해결된다

복제 처리 병목이 그대로면 수만 늘어도 해결되지 않을 수 있습니다.

2. lag는 DB 팀만의 문제다

읽기 라우팅과 일관성 요구사항은 애플리케이션 설계와 깊게 연결됩니다.

3. lag가 조금 있으면 무조건 괜찮다

기능에 따라 작은 지연도 사용자에게 크게 보일 수 있습니다.

FAQ

Q. replication lag는 어떤 서비스에서 특히 민감한가

방금 저장한 데이터가 바로 보여야 하는 서비스에서 특히 민감합니다.

Q. 먼저 DB를 볼까, 앱을 볼까

둘 다 봐야 합니다. lag 원인은 DB 쪽이고, 영향도는 앱 라우팅에서 크게 드러납니다.

Q. lag를 완전히 없앨 수 있나

구조적으로 완전 0을 항상 보장하기는 어렵고, 운영 전략과 읽기 정책으로 영향을 줄이는 경우가 많습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.