DB Master/Slave Replication 설정

Replication은 왜 필요할까?

프로젝트를 하면서 DB에 저장도 잘 되고 잘 가져오는데 굳이 DB 서버를 증설할 필요가 있을까.

너무 당연한 말이지만, 모든 서비스가 트래픽이 늘어남에 따라 DB에 많은 부하가 오게되고 병목 현상도 심해질 것이다.

따라서 복제 서버에서 쓰기/읽기만 분산해줘도 트래픽을 완하하는데 도움이되고 가용성도 확보할 수 있을것이다.

• 가용성 확보는 I/O 작업을 잘 수행하게 해준다는 의미로 적었다.

또,Master DB에 장애가 발생해서 다운된다면 Slave DB를 Master로 승격시켜서 대응할 수 있다.

하지만 MySQL Replication은 비동기 방식이기 때문에 바로 Slave로 복사가 되는것이 아니라 완벽하게 복사되지 않을 수 있다고 한다.

이것말고도 다른 방법이 많겠지만, 아직 부족하기에 할 수 있는 범위에서 고민하고자 한다.

• 샤딩, MSA(?), CQRS ..등등

읽기/쓰기 작업을 어떤 DB에 할당할까

대부분 DB는 Master/Slave 구조로 운영되며, Slave를 여러개 두는 경우가 있다고 한다.

Replication 방법은 여러가지 있곘지만, Master DB에서 실행되는 Query를 Slave에서 동일하게 수행하여 데이터를 동기화할 수 있다. 즉, Master에 변경사항이 생기면 이를 Binary Log에 저장하고 비동기적으로 Slave에게 전송한다.

Slave는 이를 받아서 Relay log에 저장하고 변경된 사항을 스토리지 엔진에 반영한다.

1. 클라이언트가 Commit 을 누르면 먼저 Master 서버에 존재하는 Binary log 에 변경사항을 모두 기록합니다.

2. Master Thread 는 비동기적 으로(복사되는 시간을 기다려주지 않습니다.) Binary log를 읽어 Slave 서버로 전송합니다.

3. Slave 의 I/O Thread 는 Master로 부터 받은 변경 데이터들을 Relay log 에 기록을 합니다.

4. Slave의 SQL Thread 는 Replay log의 기록들을 읽어 자신의 스토리지 엔진에 최종 적용합니다.

Replication 동작 원리 (MySQL 기준)

1. 트랜잭션이 Commit 되면 즉, Master 서버에서 트랜잭션이 Commit 되면 Binary Log에 변경사항을 기록한다.

2. Master Thread는 비동기로 Binary Log를 읽어서 Slave 서버로 전송한다.

   비동기 장점은 Binary Log 전송 작업을 완료하고 즉시 다음 트랜잭션을 처리하므로 Master 서버 성능 향상에 도움이 된다. 또, Slave가 여러개 있을 경우 Master 스레드는 각 Slave 서버로 동시에 전송할 수 있다.

   하지만 단점도 존재한다.

   Master 서버와 Slave 서버의 데이터 적용 순서가 다를 수 있기 때문에 네트워크 문제와 같은 장애 발생 시 데이터 일관성 문제가 생길 수 있다. (UDP 프로토콜(?)과 비슷한거 같다.)

3. Slave 서버의 I/O Thread는 Master에서 받은 변경사항들을 Relay Log에 기록한다.

4. Slave Thread는 수정된 Relay Log를 확인하고 자신의 스트로지 엔진(실제 DB)에 적용한다.

MySQL Replication이 트랜잭션 커밋 후 시작되는지는 알려면 사용하는 Replication 방식과 설정을 알아야한다. 아래와 같은 예외 사항이 있다고 하는데 이후에 알아보려고 한다.

1. Semi-Sync Replication : 서버가 트랜잭션을 Commit 하기 전에 Slave 서버에 일부 데이터를 전송하여 데이터 손실 위험을 줄이고 성능을 향상 시킬 수 있다.

2. GTID-Based Replication : 트랜잭션 ID를 사용하여 트랜잭션 순서를 보장하고, Slave 서버가 필요한 데이터만 받도록 한다.

MySQL 설정하기

MySQL의 설정 파일인 my.cnf가 존재하고 다른 위치(디렉토리)에 존재할 수 있다. 하지만 하나의 설정파일만 적용하고 디렉토리마다 우선순위를 갖는다.

1. /etc/my.cnf

2. /etc/mysql/my.cnf

3. /usr/local/etc/my.cnf

4. ~/my.cnf

my.cnf를 아래와 같이 설정한다.

Master DB

[mysqld]
# 바이너리 로그 파일 위치를 기반
server-id=1         # 서버 구분 값
log-bin=mysql-bin   # bin log 경로
expire_logs_days=1  # 로그 보관일 설정
max-biglog_size=50M # 최대 사이즈 서렂ㅇ

# GTID 기반 설정
server-id=1 
log-bin=mysql-bin
gtid-mode=ON
enforce-gtid-consistency=ON
log_slave_updates=ON

Slave DB

위 설정을 마친 후 재시작한다.

그리고 다음 순서를 진행한다.

Master DB

# 1. 먼저 Master DB와 Slave DB와 연결할 계정을 생성한다. 적용할 db에 접속 후 작업
mysql> CREATE USER '생성할 계정명'@'%' IDENTIFIED BY '비번';

# 2. 생성한 계정에 replication 권한을 부여하고 적용
mysql> GRANT REPLICATION ON SLAVE *.* to '생성한 계정명'@'%' IDENTIFIED BY '비번';
mysql> flush privileges;

# 3. 설정이 끝나면 다시시작
service mysqld restart

# 덤프 생성 전, 서버에서 Shared Lock을 걸어서 읽기/쓰기를 차단해야 한다.
mysql> FLUSH TABLES WITH READ LOCK;

# 4. 덤프 전송
bash> mysqldump -u '생성한 계정명' -p '비번' DB이름 > DB이름.sql
bash> mysqldump -uroot -p --set-gtid-purged=OFF test > test.sql (GTID)

# 5. 생성된 sql 파일을 Slave DB로 전송한다.
bash> scp DB이름.sql 'Slave 계정 이름(root)'@'Slave DB 비공인 IP 주소':/root/

# 6. 전송했으면 다시 원래값으로 돌려둔다. 
mysql> SHOW MASTER STATUS;
mysql> UNLOCK TABLES;

Slave DB

자주 발생하는 예외

대표적인 에러에 Last_IO_Error가 있는다. Slave 서버의 auto.cnf 파일에 현재 서버의 UUID가 적혀있는데, 이 파일까지 Master 서버에서 함께 가져와서 발생하는 에러라고 한다.

# 1. mysql(slave) 종료
bash> systemctl stop mysql

# 2. auto.cnf 설정파일 삭제 (경로는 알아서)
bash> rm -rf /var/lib/mysql/auto.cnf

# 3. 재시작
bash> systemctl start mysqld

다시 Slave로 넘어와서 적용한다.