읽기 트래픽이 늘어 DB 한 대로 버티기 힘들거나, 마스터가 죽으면 서비스가 통째로 멈추는 게 불안하다면 복제(replication) 가 첫 단추입니다. 소스(source) 한 대가 쓰기를 받고, 레플리카(replica)들이 그 변경을 따라 읽어 읽기 부하를 나눠 갖는 구조입니다. MySQL 8.0 기준으로 구성 과정을 정리합니다.
복제 방식 구분
복제는 변경 사항을 어떻게 전달하느냐로 나뉩니다.
| 방식 | 전달 단위 | 특징 |
|---|---|---|
| 비동기(기본) | binlog 이벤트 | 소스는 레플리카 응답을 안 기다림. 가장 빠름 |
| 반동기 | binlog + ACK 1개 | 최소 1대가 받았음을 확인. 데이터 유실 위험 감소 |
| GTID 기반 | 트랜잭션 전역 ID | 위치 추적이 쉬워 페일오버에 유리 |
요즘은 위치 좌표(binlog 파일·포지션)를 직접 다루는 대신 GTID 를 쓰는 게 표준에 가깝습니다.
구성 단계
- 소스 설정 —
my.cnf에 고유server-id와 binlog를 켭니다.
로컬 터미널
[mysqld]
server-id = 1
log_bin = mysql-bin
gtid_mode = ON
enforce_gtid_consistency = ON
- 복제 전용 계정 생성 — 레플리카가 binlog를 받아갈 권한을 가진 계정을 만듭니다.
SQL
CREATE USER 'repl'@'%' IDENTIFIED BY 'StrongPass!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
- 초기 데이터 복사 — 운영 중이라면
mysqldump로 일관된 스냅샷을 떠서 레플리카에 적재합니다. GTID 정보가 함께 들어갑니다.
DB 클라이언트
mysqldump --all-databases --single-transaction --source-data=2 \
--set-gtid-purged=ON > dump.sql
- 레플리카 연결 — 레플리카에는 다른
server-id를 주고, 소스를 가리킨 뒤 복제를 시작합니다.
SQL
CHANGE REPLICATION SOURCE TO
SOURCE_HOST='10.0.0.5',
SOURCE_USER='repl',
SOURCE_PASSWORD='StrongPass!',
SOURCE_AUTO_POSITION=1;
START REPLICA;
정상 동작 확인
복제가 붙었는지는 상태 출력에서 두 줄만 보면 됩니다.
SQL
SHOW REPLICA STATUS\G
Replica_IO_Running: Yes— 소스에서 binlog를 받아오는 스레드 정상.Replica_SQL_Running: Yes— 받은 이벤트를 적용하는 스레드 정상.Seconds_Behind_Source: 0— 지연 없음. 이 값이 계속 커지면 레플리카가 못 따라가는 것입니다.
둘 중 하나라도 No이면 Last_Error 메시지를 먼저 읽습니다. 권한 오류, 중복 키, server-id 충돌이 흔한 원인입니다.
요점 정리
- 소스는 binlog를 켜고
server-id를 부여, 레플리카는 다른server-id로 소스를 가리킨다. - 초기 데이터는
mysqldump --single-transaction으로 일관된 스냅샷을 떠 옮긴다. - GTID(
SOURCE_AUTO_POSITION=1)를 쓰면 위치 좌표를 직접 안 다뤄도 된다. - 상태 점검은
Replica_IO_Running,Replica_SQL_Running,Seconds_Behind_Source세 줄.
복제를 직접 구성하고 소스에 쓴 데이터가 레플리카에 반영되는 과정을 확인하는 실습은 데이터베이스 트랙에서 회원가입 없이 무료로 할 수 있습니다.