마이위키

테마

복제 ​

복제(replication)는 한 MySQL 서버(소스)에서 커밋(commit)된 변경을 다른 서버(레플리카)가 받아 똑같이 적용해, 같은 데이터를 여러 서버에 유지하는 기능이다. 읽기 분산·백업·장애 대비가 모두 이 위에서 돌아가므로, 변경이 어떻게 전달되고 어디까지 늦거나 유실될 수 있는지가 이 대주제의 핵심이다. 사실 기준은 MySQL 8.4이며, 8.4에서는 master/slave가 들어간 옛 구문이 제거되어 소스(source)/레플리카(replica) 구문만 쓴다. 이름만 바뀌었을 뿐 동작은 같다. 다만 복제 계정에 주는 REPLICATION SLAVE 권한(privilege)처럼 일부 이름에는 옛 단어가 남아 있다.

학습 순서 ​

  1. 복제 구조와 GTID — 복제가 필요한 이유, 8.4의 source/replica 용어, 바이너리 로그(binary log)에서 릴레이 로그(relay log)를 거쳐 변경이 적용되기까지의 스레드 구조 (면접 비중: 높음)
  2. 복제 구조와 GTID 2 — 복제 설정의 뼈대, 바이너리 로그의 파일 이름과 위치로 진행을 추적하는 위치 기반 복제와 GTID(Global Transaction Identifier, 전역 트랜잭션 식별자) 기반 복제의 차이, 장애 조치(failover) (면접 비중: 높음)
  3. 바이너리 로그 포맷과 동기화 방식 — 변경을 SQL 문장(STATEMENT)으로 남길지 바뀐 행(ROW)으로 남길지 섞을지(MIXED) 정하는 로그 포맷, 행 기록에 담을 칼럼을 정하는 binlog_row_image, 기본 동작인 비동기 복제(asynchronous replication) (면접 비중: 높음)
  4. 바이너리 로그 포맷과 동기화 방식 2 — 반동기 복제(semisynchronous replication)에서 레플리카의 확인을 엔진 커밋 전에 기다리는지(AFTER_SYNC) 후에 기다리는지(AFTER_COMMIT)의 차이, 방식별 유실 범위 (면접 비중: 높음)
  5. 복제 토폴로지와 고급 설정 — 싱글·멀티 레플리카·체인·듀얼 소스·멀티 소스, 지연된 복제(delayed replication), 일부 DB·테이블만 골라 적용하는 필터링된 복제(filtered replication) (면접 비중: 중간)
  6. 복제 토폴로지와 고급 설정 2 — 멀티 스레드 복제(multithreaded replication), 크래시 세이프 복제(crash-safe replication), 복제 지연(replication lag)과, 방금 쓴 값이 레플리카에서 아직 안 보이는 쓰고 바로 읽기 문제 (면접 비중: 중간)