MySQL의 마스터-레플리카 복제(replication)는 어떻게 동작하며, 읽기 확장(read scaling)에 어떻게 도움이 되는가?

Question

IT Interview Practice · Accepted Answer

복제는 변경 사항을 **소스(source, 마스터)**에서 하나 이상의 **레플리카(replica)**로 스트리밍합니다. 소스는 커밋된 모든 변경을 **바이너리 로그(binlog)**에 기록하고, 각 레플리카의 I/O 스레드가 그 로그를 복사하며 SQL/적용(applier) 스레드가 그것을 재실행하여 레플리카들이 동일한 데이터로 수렴합니다. ## 흐름 ``` writes app ---------> [ SOURCE ] --- binlog ---> [ replica 1 ] <-- reads | [ replica 2 ] <-- reads +---------- binlog ---> [ replica 3 ] <-- reads ``` - **포맷** — `ROW`(실제 행 이미지를 기록, 안전한 기본값), `STATEMENT`, `MIXED`. - **비동기(기본값)** — 소스가 레플리카를 기다리지 않고 커밋합니다: 빠르지만 레플리카가 뒤처질 수 있습니다. - **반동기(Semi-sync)** — 소스가 최소 하나의 레플리카의 확인을 기다립니다. 약간의 지연을 내주고 내구성을 얻습니다. ## 읽기 확장 쓰기는 소스로 보내고 `SELECT`는 레플리카 전반에 분산하세요. 읽기 위주 앱(대부분의 웹 앱)은 레플리카를 추가하면 읽기가 거의 선형적으로 확장되는 반면, 단일 소스는 여전히 모든 쓰기를 처리합니다. ```sql -- On a replica, watch how far behind it is: SHOW REPLICA STATUS\G -- Seconds_Behind_Source: 2 <- replication lag -- Replica_IO_Running: Yes -- Replica_SQL_Running: Yes ``` ## 함정: 복제 지연(replication lag) 비동기 레플리카는 소스보다 뒤처지므로, 쓰기를 한 뒤 곧바로 레플리카에서 읽는 사용자는 자신의 변경을 보지 못할 수 있습니다("read-your-writes" 위반). 지연에 민감하거나 방금 쓴 데이터를 읽는 경우는 소스로 라우팅하거나 반동기를 사용하세요. ## 왜 중요한가 복제는 읽기를 확장하고 장애 조치(failover)/백업을 위한 웜 스탠바이를 확보하는 표준적인 첫 단계입니다. 그 본질적 한계인 지연과 단일 쓰기 병목은 실제 설계를 좌우합니다: 왜 때때로 오래된 데이터를 읽는지, 그리고 왜 쓰기 확장에는 결국 레플리카 추가만으로는 안 되고 샤딩이 필요한지를 설명해 줍니다.

흐름

읽기 확장

함정: 복제 지연(replication lag)

왜 중요한가

관련 질문