VillageSQL is a drop-in replacement for MySQL with extensions.
All examples on this page work on VillageSQL. Install Now →
복제의 동작 방식
- 소스가 트랜잭션을 커밋하고 바이너리 로그에 씁니다.
- 복제본의 I/O 스레드가 소스에 연결해 새 binlog 이벤트를 읽고 로컬 릴레이 로그에 씁니다.
- 복제본의 SQL 스레드가 릴레이 로그에서 읽어 각 이벤트를 실행합니다.
복제본 구성하기
소스에서 —my.cnf에서 바이너리 로깅을 활성화하고 고유한 서버 ID를 설정합니다:
--source-data와 함께 mysqldump로 일관된 스냅샷을 찍습니다:
SOURCE_AUTO_POSITION = 1은 GTID 기반 복제를 활성화합니다. GTID를 사용하지 않는다면 대신 SOURCE_LOG_FILE과 SOURCE_LOG_POS를 지정하세요(값은 스냅샷 파일 헤더에 있습니다).
GTID 복제
전역 트랜잭션 식별자(GTID)는 커밋된 모든 트랜잭션에 고유한 ID를 부여합니다. 장애 조치와 복제본 구성을 더 단순하게 만듭니다 — binlog 파일 이름과 위치를 추적하는 대신, MySQL은 각 서버가 어떤 트랜잭션을 적용했는지 추적합니다. 소스와 복제본 양쪽에서 GTID를 활성화합니다:SOURCE_AUTO_POSITION = 1만 있으면 됩니다 — MySQL이 복제본에 빠진 트랜잭션을 알아내 자동으로 재생합니다.
복제 모니터링
복제가 동작하려면
Replica_IO_Running과 Replica_SQL_Running 둘 다 Yes여야 합니다.
복제 지연
복제 지연은 복제본의 SQL 스레드가 소스의 쓰기 속도를 따라가지 못할 때 발생합니다. 흔한 원인:- 적용기 병렬성: MySQL 8.4는 이미 기본적으로 이벤트를 병렬로 적용합니다 —
replica_parallel_workers는 4이고replica_parallel_type은LOGICAL_CLOCK입니다. 복제본이 여전히 뒤처지면 워커 수를 올리세요:
- 복제본에서 오래 실행되는 쿼리: 행을 잠그는 쿼리가 SQL 스레드를 막습니다.
- 네트워크 지연: 느린 I/O 스레드 때문에 SQL 스레드가 할 일이 없어집니다.
- 복제본의 디스크 I/O: 릴레이 로그나 데이터 파일 동기화가 병목입니다.
복제 아키텍처
기본 구성 — 소스 하나와 하나 이상의 비동기 복제본 — 이 유일한 선택지는 아닙니다. MySQL은 일관성과 가용성의 트레이드오프가 서로 다른 여러 복제 아키텍처를 제공합니다.
각각을 사용할 때:
- 비동기 복제 — 약간의 지연이 허용되는 읽기 확장과 재해 복구 복제본에 올바른 기본값입니다.
- 반동기 — 소스 장애에 대한 내구성 보험이 필요하지만 그룹 복제의 운영 복잡도를 감당할 수 없을 때. 쓰기 커밋마다 네트워크 왕복 ~1회를 더합니다.
- 그룹 복제 / InnoDB Cluster — 자동 장애 조치가 필요하고 쓰기 지연 증가를 감당할 수 있을 때. InnoDB Cluster는 더 쉬운 관리를 위해 그룹 복제를 MySQL Router와 MySQL Shell로 감쌉니다.
group_replication 플러그인으로 활성화합니다; 설정은 이 가이드의 범위를 벗어납니다.
복제본으로 읽기 확장
소스의 부하를 줄이기 위해 읽기가 많은 쿼리를 복제본으로 보내세요:복제 대 대안
복제는 특정 문제를 잘 해결하고 다른 문제에는 잘못된 도구입니다. 복제를 도입하기 전에 실제로 맞는지 확인하세요.
짧은 버전: 한 서버가 모든 쓰기를 처리하고 읽기 확장, HA, 또는 웜 스탠바이(warm standby)가 필요할 때 복제가 올바른 선택입니다. 쓰기 처리량이 병목이라면 복제는 문제를 모든 복제본에 복사합니다 — 샤딩이나 분산 데이터베이스가 근원에서 그것을 해결합니다.
복제 중지와 시작
자주 묻는 질문
복제는 MySQL 메이저 버전 간에 동작하나요?
MySQL은 오래된 소스에서 새로운 복제본으로의 복제를 지원하지만, 그 반대는 지원하지 않습니다. 항상 소스를 업그레이드하기 전에 복제본을 업그레이드하세요.반동기 복제와 비동기 복제의 차이는 무엇인가요?
비동기 복제(기본값)에서는 소스가 어떤 복제본의 수신 확인도 기다리지 않고 커밋합니다. 반동기 복제에서는 소스가 클라이언트에 반환하기 전에 최소 한 복제본이 이벤트를 받았다고 확인하기를 기다립니다. 반동기는 약간 더 높은 쓰기 지연을 대가로 소스 장애 시 데이터 손실 위험을 줄입니다.문제 해결
함께 보기
- MySQL 바이너리 로깅 — 복제가 소스에서 복제본으로 스트리밍하는 바이너리 로그
- MySQL 백업 전략 — 내구성을 위해 복제를 보완하는 전략
- MySQL의 읽기 복제본 — 이 가이드가 구성하는 복제본 사용하기