메인 콘텐츠로 건너뛰기

VillageSQL is a drop-in replacement for MySQL with extensions.

All examples on this page work on VillageSQL. Install Now →
MySQL 복제는 한 서버(소스)의 변경을 하나 이상의 서버(복제본)로 복사합니다. 소스는 모든 변경을 바이너리 로그에 쓰고, 각 복제본은 그 로그를 읽어 변경을 재생합니다. 복제는 읽기 확장, 고가용성, 지리적 분산의 기반입니다.

복제의 동작 방식

  1. 소스가 트랜잭션을 커밋하고 바이너리 로그에 씁니다.
  2. 복제본의 I/O 스레드가 소스에 연결해 새 binlog 이벤트를 읽고 로컬 릴레이 로그에 씁니다.
  3. 복제본의 SQL 스레드가 릴레이 로그에서 읽어 각 이벤트를 실행합니다.
이것은 기본적으로 비동기입니다 — 소스는 복제본이 수신을 확인하기를 기다리지 않습니다. 복제본은 소스보다 뒤처질 수 있습니다.

복제본 구성하기

소스에서 — my.cnf에서 바이너리 로깅을 활성화하고 고유한 서버 ID를 설정합니다:
복제 사용자를 만듭니다:
--source-data와 함께 mysqldump로 일관된 스냅샷을 찍습니다:
복제본에서 — 다른 서버 ID를 설정합니다:
스냅샷을 복원하고 복제를 시작합니다:
SOURCE_AUTO_POSITION = 1은 GTID 기반 복제를 활성화합니다. GTID를 사용하지 않는다면 대신 SOURCE_LOG_FILE과 SOURCE_LOG_POS를 지정하세요(값은 스냅샷 파일 헤더에 있습니다).

GTID 복제

전역 트랜잭션 식별자(GTID)는 커밋된 모든 트랜잭션에 고유한 ID를 부여합니다. 장애 조치와 복제본 구성을 더 단순하게 만듭니다 — binlog 파일 이름과 위치를 추적하는 대신, MySQL은 각 서버가 어떤 트랜잭션을 적용했는지 추적합니다. 소스와 복제본 양쪽에서 GTID를 활성화합니다:
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로 감쌉니다.
참고: 그룹 복제는 모든 테이블이 InnoDB를 사용하고 기본 키를 가져야 합니다. group_replication 플러그인으로 활성화합니다; 설정은 이 가이드의 범위를 벗어납니다.

복제본으로 읽기 확장

소스의 부하를 줄이기 위해 읽기가 많은 쿼리를 복제본으로 보내세요:
애플리케이션은 복제 지연을 견뎌야 합니다. 복제본에는 몇 밀리초 전에 소스에 삽입된 행이 아직 없을 수 있습니다. 최신 쓰기를 반영해야 하는 읽기는 소스에 연결하세요.

복제 대 대안

복제는 특정 문제를 잘 해결하고 다른 문제에는 잘못된 도구입니다. 복제를 도입하기 전에 실제로 맞는지 확인하세요. 짧은 버전: 한 서버가 모든 쓰기를 처리하고 읽기 확장, HA, 또는 웜 스탠바이(warm standby)가 필요할 때 복제가 올바른 선택입니다. 쓰기 처리량이 병목이라면 복제는 문제를 모든 복제본에 복사합니다 — 샤딩이나 분산 데이터베이스가 근원에서 그것을 해결합니다.

복제 중지와 시작

실패하는 이벤트 하나를 건너뛰려면(신중하게 사용하세요 — 이벤트를 건너뛰면 복제본이 소스와 달라집니다):

자주 묻는 질문

복제는 MySQL 메이저 버전 간에 동작하나요?

MySQL은 오래된 소스에서 새로운 복제본으로의 복제를 지원하지만, 그 반대는 지원하지 않습니다. 항상 소스를 업그레이드하기 전에 복제본을 업그레이드하세요.

반동기 복제와 비동기 복제의 차이는 무엇인가요?

비동기 복제(기본값)에서는 소스가 어떤 복제본의 수신 확인도 기다리지 않고 커밋합니다. 반동기 복제에서는 소스가 클라이언트에 반환하기 전에 최소 한 복제본이 이벤트를 받았다고 확인하기를 기다립니다. 반동기는 약간 더 높은 쓰기 지연을 대가로 소스 장애 시 데이터 손실 위험을 줄입니다.

문제 해결

함께 보기