MySQL 슬레이브 구성 및 SSL 복제 설정

개요

이 가이드는 마스터(MySQL 서버1)에서 제공한 SHOW MASTER STATUS의 값을 사용해 슬레이브(MySQL 서버2)를 구성하는 방법을 설명합니다. SSL을 사용한 복제 설정 예제를 포함합니다. 주요 단계는 다음과 같습니다: 설정파일 수정, MySQL 재시작, 빈 데이터베이스 생성, 스냅샷 임포트, CHANGE MASTER TO로 복제 설정, 슬레이브 시작 및 상태 확인.

Important: server-id 값은 마스터와 달라야 합니다. 중복되면 복제가 동작하지 않습니다.

사전 요구사항

마스터에서 복제용 사용자(slave_user)를 생성하고 REPLICATION 권한을 부여했을 것.
마스터에서 SHOW MASTER STATUS; 명령으로 반환된 파일명과 포지션을 기록해 두었을 것.
슬레이브가 마스터에 접근 가능한 네트워크 환경이어야 함(포트 3306 등).
SSL을 사용하려면 CA 및 클라이언트 인증서/키 파일이 슬레이브에 준비되어 있어야 함.

1. /etc/my.cnf 편집 (슬레이브)

서버2에서 /etc/my.cnf를 열어 [mysqld] 섹션에 다음 옵션들이 있는지 확인합니다.

server2:

vi /etc/my.cnf

| [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 ssl server-id=2 master-connect-retry=60 replicate-do-db=exampledb [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid |

위 예제에서 server-id는 고유해야 하며 마스터의 server-id와 달라야 합니다. replicate-do-db는 슬레이브에서 복제하려는 데이터베이스 이름(exampledb)을 지정합니다. 필요에 따라 replicate-ignore-db, replicate-do-table 등으로 더 세밀한 복제를 설정할 수 있습니다.

2. MySQL 재시작

설정을 저장한 뒤 MySQL을 재시작합니다:

/etc/init.d/mysqld restart

시스템이 systemd 기반이면 아래처럼 실행할 수 있습니다:

systemctl restart mysqld

(환경에 맞는 명령을 사용하세요.)

3. 빈 데이터베이스 생성 및 스냅샷 임포트

슬레이브에서 먼저 대상 데이터베이스를 빈 상태로 생성합니다.

mysql -u root -p

mysql> CREATE DATABASE exampledb; mysql> quit;

그다음 master에서 추출한 snapshot.sql을 슬레이브에 가져와 임포트합니다. 먼저 슬레이브의 복제 스레드를 중지합니다(이미 시작된 경우 대비).

/usr/bin/mysqladmin --user=root --password=yourrootsqlpassword stop-slave
cd /tmp
mysql -u root -pyourrootsqlpassword exampledb < snapshot.sql

스냅샷 임포트가 완료되면 MySQL 쉘에 다시 접속합니다.

mysql -u root -p

4. CHANGE MASTER TO로 마스터 지정 (중요)

마스터에서 얻은 값을 사용해 슬레이브에 마스터 정보를 등록합니다. 반드시 SHOW MASTER STATUS;에서 얻은 MASTER_LOG_FILE과 MASTER_LOG_POS 값을 대체하여 사용하세요.

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=3096416, MASTER_SSL=1, MASTER_SSL_CA = '/etc/mysql/newcerts/ca-cert.pem', MASTER_SSL_CERT = '/etc/mysql/newcerts/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/newcerts/client-key.pem';

옵션 설명:

MASTER_HOST: 마스터의 IP 또는 호스트명 (예: 192.168.0.100)
MASTER_USER: 마스터에서 부여한 복제 전용 사용자
MASTER_PASSWORD: 해당 사용자의 비밀번호
MASTER_LOG_FILE: SHOW MASTER STATUS가 반환한 바이너리 로그 파일
MASTER_LOG_POS: SHOW MASTER STATUS가 반환한 로그 포지션
MASTER_SSL: SSL 연결 사용 여부(1 = 사용)
MASTER_SSL_CA: 슬레이브에 있는 CA 인증서 경로
MASTER_SSL_CERT: 슬레이브에 있는 클라이언트 인증서 경로
MASTER_SSL_KEY: 슬레이브에 있는 클라이언트 키 경로

5. 슬레이브 시작 및 상태 확인

슬레이브를 시작합니다:

START SLAVE;

상태를 확인합니다:

SHOW SLAVE STATUS \G

정상적이라면 출력에서 반드시 다음 두 필드가 Yes여야 합니다:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

SSL을 사용한 경우에는 아래와 같은 필드들이 채워져 있어야 합니다: Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_Cert, Master_SSL_Key

예시 출력 일부(참고용):

mysql> SHOW SLAVE STATUS \G * 1. row * Slave_IO_State: Waiting for master to send event Master_Host: 192.168.0.100 Master_User: slave_user Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 3096416 Relay_Log_File: mysqld-relay-bin.000002 Relay_Log_Pos: 235 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: exampledb Master_SSL_Allowed: Yes Master_SSL_CA_File: /etc/mysql/newcerts/ca-cert.pem Master_SSL_Cert: /etc/mysql/newcerts/client-cert.pem Master_SSL_Key: /etc/mysql/newcerts/client-key.pem Seconds_Behind_Master: 0 1 row in set (0.00 sec)

시작 후 MySQL 쉘을 종료합니다:

quit;

이제 마스터의 exampledb에 변경이 발생하면 슬레이브의 exampledb에도 동일하게 복제됩니다. 간단한 테스트 쿼리로 확인하세요.

점검 및 검증 체크리스트 (운영자/엔지니어 역할별)

운영자(Ops): 네트워크(포트 3306) 연결 확인, 방화벽 규칙 점검, 시스템 로그(/var/log/syslog 또는 /var/log/mysqld.log) 확인
DBA: SHOW MASTER STATUS, SHOW SLAVE STATUS 결과 비교 및 확인, 바이너리 로그와 포지션 일치 여부 확인
보안 담당자: SSL 인증서 유효성, 권한 최소화(복제 전용 사용자), 인증서 파일 권한 검사

실패 사례와 원인(언제 동작하지 않는가)

server-id가 마스터와 중복된 경우: 복제가 시작되지 않음. 서로 다른 고유 ID를 설정하세요.
MASTER_LOG_FILE/MASTER_LOG_POS가 잘못된 경우: 슬레이브가 로그 위치를 찾지 못하고 에러 발생. 마스터에서 값을 재확인하세요.
네트워크 또는 포트 차단: Slave_IO_Running이 No가 될 수 있음. 네트워크 경로와 방화벽을 점검하세요.
SSL 인증서 문제: 인증서 경로가 잘못되거나 권한이 잘못된 경우 SSL 연결 실패.

대안 접근 방법

비동기 복제 대신 GTID 기반 복제를 고려(환경에 따라 복제 관리가 쉬워짐).
비동기 복제 대신 연속 백업/스트리밍 방식(예: Percona XtraBackup + 복원)을 사용해 초기 동기화를 수행.
프라이머리-리플리카 패턴 대신 멀티-마스터(예: Galera) 등 고가용성 솔루션 고려(애플리케이션 특성에 따라).

트러블슈팅 플레이북 (간단)

SHOW SLAVE STATUS \G 실행. Slave_IO_Running/Slave_SQL_Running 확인.
Slave_IO_Running = No → ERROR 메시지(Last_Error) 확인 → 네트워크/인증 확인.
Slave_SQL_Running = No → SQL 에러(Last_SQL_Error) 확인 → 해당 쿼리 수동 실행 및 원인 분석.
로그(/var/log/mysqld.log, /var/log/syslog) 확인.
필요한 경우 STOP SLAVE; CHANGE MASTER TO …; START SLAVE; 로 재설정.

보안 권장사항

복제 전용 계정에 최소 권한만 부여합니다.
가능한 경우 SSL을 사용하여 트래픽을 암호화합니다.
인증서(private key 포함) 파일 권한을 600 등으로 제한하세요.
마스터와 슬레이브 간 네트워크를 전용 네트워크 또는 VPN으로 구성해 노출을 줄이세요.

검증 기준 (수락 조건)

SHOW SLAVE STATUS 출력에서 Slave_IO_Running 및 Slave_SQL_Running이 모두 Yes.
Seconds_Behind_Master 값이 0 또는 수용 가능한 지연 범위 내에 있음.
MasterSSL* 필드가 SSL 사용 시 올바른 경로를 표시함.
간단한 INSERT/UPDATE/DELETE 테스트가 마스터에서 실행되면 슬레이브에 반영됨.

명령어 스니펫(참고)

master에서 바이너리 로그 확인: SHOW MASTER STATUS;
슬레이브 재시작(시스템별): systemctl restart mysqld 또는 /etc/init.d/mysqld restart
슬레이브 상태 확인: SHOW SLAVE STATUS \G
슬레이브 일시 중지: STOP SLAVE;
슬레이브 시작: START SLAVE;

간단한 의사결정 흐름(머메이드)

flowchart TD
  A[복제 설정 시작] --> B{server-id 중복?}
  B -- 예 --> C[server-id 변경 및 재시작]
  B -- 아니오 --> D{스냅샷 임포트 완료?}
  D -- 아니오 --> E[스냅샷 임포트]
  D -- 예 --> F[CHANGE MASTER TO 실행]
  F --> G[START SLAVE]
  G --> H{Slave_IO_Running && Slave_SQL_Running == Yes}
  H -- 예 --> I[복제 정상]
  H -- 아니오 --> J[로그 및 Last_Error 확인]

5 Links

MySQL: http://www.mysql.com/
CentOS: http://www.centos.org/

요약: /etc/my.cnf에서 server-id와 replicate 관련 설정을 하고 MySQL을 재시작한 뒤 빈 데이터베이스를 생성하고 스냅샷을 임포트합니다. 마스터의 바이너리 로그 파일명과 포지션을 사용해 CHANGE MASTER TO를 설정하고 START SLAVE로 시작한 뒤 SHOW SLAVE STATUS로 Slave_IO_Running과 Slave_SQL_Running이 Yes인지 확인하면 됩니다. 문제 발생 시 제공한 트러블슈팅 절차를 따르세요.