MariaDB Replication 구성 해보기

MariaDB Replication은 primary 서버의 binary log를 replica 서버가 읽어 같은 변경을 재생하는 구조입니다. 예전 문서에서는 master/slave라는 용어를 많이 쓰지만, MariaDB 문서는 primary/replica 용어를 함께 사용하고 있습니다. 아래 절차는 단일 primary와 단일 replica를 구성하는 기본 흐름입니다.

구성 전 확인

두 서버의 MariaDB 버전, 네트워크, 시간 동기화, 방화벽을 먼저 확인합니다. replica가 primary의 3306/TCP에 도달해야 합니다.

# primary와 replica 양쪽
mariadb --version
timedatectl
hostname -f

# replica에서 primary 접근 확인
nc -vz -w 3 primary-db.example.com 3306

운영 DB에 붙이는 경우에는 신규 replica를 기존 데이터와 같은 시점으로 맞춘 뒤 replication을 시작해야 합니다. 빈 replica에 바로 CHANGE MASTER TO만 넣으면 기존 데이터는 복제되지 않습니다.

primary 설정

primary에서는 binary log와 고유한 server_id가 필요합니다. MariaDB 공식 문서는 replication log 이름을 안정적으로 유지하기 위해 log-basename도 지정하라고 안내합니다.

# /etc/mysql/mariadb.conf.d/60-replication.cnf 또는 배포판에 맞는 conf.d 파일
[mariadb]
server_id=1
log-bin
log-basename=primary1
binlog-format=mixed
bind-address=0.0.0.0

설정 후 재시작합니다.

sudo systemctl restart mariadb
sudo systemctl status mariadb --no-pager

bind-address가 127.0.0.1로만 잡혀 있으면 원격 replica가 접속할 수 없습니다. 보안상 전체 대역을 열기보다 DB 방화벽과 계정 host 제한을 함께 적용하세요.

replication 계정 생성

primary에서 replica 전용 계정을 만듭니다. 비밀번호는 문서나 쉘 히스토리에 실제 값으로 남기지 말고, 운영 secret 관리 경로에서 주입하는 방식이 좋습니다.

CREATE USER 'replication_user'@'replica-db.example.com' IDENTIFIED BY 'REPLACE_WITH_STRONG_PASSWORD';
GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'replica-db.example.com';
FLUSH PRIVILEGES;

MariaDB 버전에 따라 REPLICATION REPLICA 권한 표현을 지원할 수 있지만, REPLICATION SLAVE는 호환성 때문에 여전히 많이 쓰입니다. 실제 운영 버전에 맞춰 확인하세요.

replica 설정

replica에도 primary와 다른 고유 server_id를 설정합니다.

# replica: /etc/mysql/mariadb.conf.d/60-replication.cnf
[mariadb]
server_id=2
relay-log=replica1-relay-bin
read_only=ON

sudo systemctl restart mariadb
sudo systemctl status mariadb --no-pager

read_only=ON은 일반 사용자가 replica에 직접 쓰는 실수를 줄이는 장치입니다. 관리자 권한 사용자는 여전히 쓸 수 있으므로 운영 정책으로도 분리해야 합니다.

기존 데이터 기준점 잡기

운영 DB라면 primary에서 일관된 백업과 binary log 좌표를 확보합니다. 가장 단순한 전통 방식은 테이블을 잠그고 좌표를 기록한 뒤 덤프를 뜨는 것입니다. 데이터가 큰 환경에서는 mariadb-backup 같은 물리 백업 방식을 검토합니다.

-- primary 세션 1: 잠금 유지
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

SHOW MASTER STATUS의 File과 Position 값을 기록합니다. 잠금 세션을 닫으면 lock이 풀리므로 주의하세요.

# primary 세션 2: 예시 덤프
mariadb-dump --single-transaction --routines --triggers --events --all-databases \
  | gzip -9 > mariadb-primary-full.sql.gz

스토리지 엔진과 쓰기 패턴에 따라 lock/backup 전략은 달라질 수 있습니다. 트랜잭션 테이블 중심이면 --single-transaction이 유용하지만, 모든 상황의 만능은 아닙니다.

-- primary 세션 1: 덤프 기준점 확보 후 잠금 해제
UNLOCK TABLES;

replica에 데이터 적재

scp mariadb-primary-full.sql.gz replica-db.example.com:/tmp/
ssh replica-db.example.com
gzip -dc /tmp/mariadb-primary-full.sql.gz | mariadb

데이터 적재가 끝난 뒤 replication 연결 정보를 설정합니다.

CHANGE MASTER TO
  MASTER_HOST='primary-db.example.com',
  MASTER_USER='replication_user',
  MASTER_PASSWORD='REPLACE_WITH_STRONG_PASSWORD',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='primary1-bin.000001',
  MASTER_LOG_POS=12345,
  MASTER_CONNECT_RETRY=10;

GTID 기반으로 운영할 계획이라면 MASTER_USE_GTID=slave_pos를 검토합니다. 새 환경에서는 GTID가 장애 조치와 재구성에 더 유리한 경우가 많지만, 기존 환경과 섞을 때는 현재 GTID 상태를 먼저 이해해야 합니다.

CHANGE MASTER TO MASTER_USE_GTID=slave_pos;

복제 시작과 상태 확인

최근 MariaDB 문서는 START REPLICA, SHOW REPLICA STATUS를 사용합니다. 기존 START SLAVE, SHOW SLAVE STATUS도 호환 목적으로 남아 있는 환경이 많습니다.

START REPLICA;
SHOW REPLICA STATUS\G

최소한 다음 항목을 확인합니다.

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
Last_IO_Error:
Last_SQL_Error:

Slave_IO_Running이 No면 primary 접속, 계정 권한, 방화벽, binary log 좌표를 봅니다. Slave_SQL_Running이 No면 replica에서 SQL 적용 중 충돌이나 중복 키, 누락 테이블 같은 데이터 불일치를 봐야 합니다.

운영 중 기본 점검

SHOW MASTER STATUS;
SHOW REPLICA STATUS\G
SHOW VARIABLES LIKE 'server_id';
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'read_only';

replication은 백업을 대체하지 않습니다. primary에서 잘못 삭제한 데이터도 replica로 복제될 수 있기 때문입니다. 별도의 시점 백업, binlog 보관, 복구 리허설을 함께 운영해야 합니다.

공식 문서

MariaDB 버전별 용어와 옵션은 계속 정리되고 있으므로 실제 운영 전에는 공식 문서를 확인하세요.

• MariaDB Setting Up Replication
• MariaDB CHANGE MASTER TO
• MariaDB replication and binary log variables