복제를 "읽기 분산" 정도로 외워 왔는지, 아니면 로그 형식·복제 지연·장애 전환·일관성 보장 수준까지 운영 관점에서 풀 수 있는지를 가른다.
MySQL Replication은 소스(Primary)의 변경을 바이너리 로그에 적고, 레플리카가 그 로그를 받아 릴레이 로그로 복사한 뒤 자기 데이터에 적용하는 구조다. 바이너리 로그 형식은 Row(행 단위 변경), Statement(SQL 그대로), Mixed(상황에 따라 자동 선택)로 나뉘고 각각 일관성·로그 크기·복잡도가 다르다. 비동기·반동기·그룹 복제 같은 모드에 따라 "커밋이 어디까지 갔다는 보장"이 달라진다. 목적은 읽기 확장(레플리카로 읽기 분산)과 가용성(소스 장애 시 승격) 두 축인데, 둘은 서로 다른 결정과 운영 부담을 요구한다.
Seconds_Behind_Master(또는 GTID 격차)가 폭증한 사고를 추적해 본 경험이 있다면 "복제 지연 = 사용자 사고"로 풀어낼 수 있다
방금 쓴 데이터를 레플리카에서 못 읽어 "읽기 직후는 소스로" 라우팅한 경험이 있다면 일관성 보장 사례로 보여 줄 수 있다
장애 전환 후 GTID·바이너리 로그 위치를 맞춰 본 경험이 있다면 운영 책임 이야기로 일반화할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.