비동기 복제
쓰기 성공은 곧바로 Replica 최신화를 뜻하지 않습니다. 아래 시간축에서 보듯이, 그 짧은 틈에 읽기가 Replica로 가면 사용자는 방금 저장한 값 대신 이전 값을 보게 됩니다.
복제 지연 구간: Master는 최신, Replica는 아직 이전 값
t0
쓰기 요청
t1
Master 커밋
t2
직후 읽기
t3
복제 완료
앱 요청
UPDATE users SET avatar='new.jpg'
쓰기 요청은 Master로만 전달됩니다.
200 OK
애플리케이션은 저장 성공 응답을 받습니다.
SELECT avatar
읽기 분산 때문에 조회는 Replica로 갈 수 있습니다.
같은 조회를 다시 하면 최신 상태를 받게 됩니다.
Master 상태
avatar='old.jpg'
avatar='new.jpg'
avatar='new.jpg'
avatar='new.jpg'
Replica 상태
avatar='old.jpg'
avatar='old.jpg'
복제 스레드가 아직 새 로그를 적용하지 않았습니다.
avatar='old.jpg'
이 시점의 읽기는 오래된 값을 반환합니다.
avatar='new.jpg'
사용자 관측
프로필 사진을 변경합니다.
"저장 완료" 메시지를 봅니다.
새로고침했는데 old.jpg
변경이 안 된 것처럼 느껴집니다.
잠시 뒤 다시 보면 new.jpg가 보입니다.
왜 문제인가
쓰기 직후 읽기 일관성(Read-after-write)이 깨질 수 있습니다.

저장은 성공했는데 화면에는 예전 값이 보여, 사용자와 운영자 모두 상태를 오해하기 쉽습니다.

실무 대응
직후 읽기는 Master로 보내거나, Replica가 따라잡을 때까지 기다립니다.

세션 기반 라우팅, read-your-writes 정책, 특정 LSN/GTID 적용 대기가 대표적인 완화 방법입니다.