한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

복제 지연 Replication lag

원인 ID db-replica-lag · 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발

그림과 실험이 있는 원본 카드로 열기 →

쓰기는 주 DB에, 읽기는 복제본에서 하는데 복제본이 늦게 따라오면 방금 쓴 내용이 안 보입니다.

왜 주 DB에 쓰기가 몰려 복제본이 수 초 뒤처짐 → 그러면 방금 저장한 내용을 복제본에서 읽으면 아직 없음 → 화면에서는 방금 산 아이템이 안 보임, 거래소 가격이 옛날 값, 중복 지급 버그

증상: 씹힘·롤백
요인: 지연
누가 겪나: 특정 기능만
언제: 사람이 몰릴 때, 저녁 피크 시간
담당: 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 방금 쓴 데이터는 주 DB에서 읽기, 지급 여부 확인과 지급은 주 DB에서 한 트랜잭션으로(유니크 키나 조건부 UPDATE로 중복 차단).
인프라팀 할 일: 복제 지연 경보, 복제본 사양을 주 DB 이상으로 두고 병렬 복제 적용, 대량 삭제는 잘게 나눠 실행, 복제본에서 오래 도는 집계 쿼리 관리.
그래프에서는: 인원·부하를 따라 오름 · 복제 지연(초)
확인할 곳: MySQL은 복제본에서 SHOW REPLICA STATUS의 Seconds_Behind_Source(8.0.22 이전 버전은 SHOW SLAVE STATUS)를 봄. PostgreSQL은 주 서버 pg_stat_replication의 write_lag·flush_lag·replay_lag, RDS는 ReplicaLag를 봄
이러면 맞음: “안 보인다”는 제보 시각에 지연이 수 초 이상이고 지연이 풀린 뒤 다시 보면 정상. 쓰기 폭주나 대량 삭제, 복제본의 긴 집계 쿼리 시각에 지연이 커짐
이러면 아님: 지연이 0 근처인데도 안 보이면 게임 서버의 캐시나 동기화 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 쓰기가 많지 않아도 뒤처질 수 있습니다. 주 DB에서 10분 걸린 대량 삭제 하나는 복제본에서도 다시 실행되므로 복제본이 그만큼 뒤처집니다. 복제본에서 오래 도는 집계 쿼리도 따라가기를 늦춥니다.

출처

SHOW REPLICA STATUS Statement MySQL
Seconds_Behind_Source: 복제본이 지금 적용 중인 이벤트가 주 DB에서 기록된 시각과의 차이(복제 지연)
Replica Server Options and Variables MySQL
replica_parallel_workers로 여러 스레드가 트랜잭션을 병렬 적용(기본 4, 0이면 한 스레드가 순서대로)
Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
스트리밍 복제는 기본 비동기라 커밋과 복제본 반영 사이에 지연이 있음(복제본이 따라갈 수 있으면 보통 1초 미만)
MySQL 8.0 Reference Manual: SHOW REPLICA STATUS Statement MySQL
8.0.22부터 SHOW SLAVE STATUS 대신 SHOW REPLICA STATUS, 그 이전 버전은 SHOW SLAVE STATUS
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_replication의 write_lag·flush_lag·replay_lag: 주 서버가 WAL을 기록한 뒤 복제본이 쓰고·디스크에 내리고·적용했다고 알릴 때까지 걸린 시간
Amazon CloudWatch metrics for Amazon RDS AWS
ReplicaLag: 읽기 복제본이 원본보다 뒤처진 시간(초)

복제 지연 Replication lag

출처

함께 보면 좋은 원인

같은 층: L12 데이터베이스

같은 증상(씹힘·롤백)의 다른 층 원인