[MySQL] Replication을 활용하여 Master-Slave DB 분리하기 (1)

 

🌱 들어가기 전

회사 들어가고 블로그가 너무 뜸해진 것 같아서, 이전에 쓰려다가 못 쓴 글을 작성하고자 한다 🥹 (무한의 임시 저장...) 

사내에서 Replication을 활용하고 있다는 건 알고 있는데, 구체적으로 어떤 식으로 동작하는지는 제대로 이해하지 못하고 있었던 것 같아서 간단하게 MySQL을 활용하여 Replication이 어떤 식으로 동작하는지 구축해보았다. 

구체적인 부분은 더 공부하면 좋겠지만, 학습 용도로 작성하는 글!

 

---

 

🌱 복제란 무엇일까?

복제는 기본적으로 master 노드에서 데이터가 변경되었을 때 slave 노드에도 변경된 내용을 적용시키는 것을 의미하며, MySQL에서는 기본적으로 비동기 복제 방식을 활용하여 둘 사이의 데이터 정합성을 맞추고 있다.

여기서 말하는 비동기 복제 방식이 무엇일까? 동작 방식을 흐름으로만 간단하게 이해하고 넘어가도록 하자.

 

0. 클라이언트가 커밋을 진행한다. (데이터베이스에 데이터 저장 요청)
1. Connection Thread는 스토리지 엔진에게 해당 트랜잭션에 대한 Prepare를 진행한다.
- 해당 단계는 Commit 을 실제로 진행하는 단계가 아닌, ‘준비’를 하는 단계이다. (2PC, 2 Phase Commit)
- 이 시점에 (InnoDB의 경우) Redo Log를 기록하게 된다.
- 만약 이 단계에서 서버가 다운되면, 복구할 때 해당 트랜잭션은 롤백된다.

2. Commit 을 진행하기 전, 바이너리 로그에 변경사항을 기록한다.
3. 스토리지 엔진은 변경 사항에 대해 커밋을 완료한다.
- 이 시점까지 정상적으로 완료되면, 트랜잭션은 커밋이 완료되어 바이너리 로그와 (InnoDB라면) 리두 로그까지 존재하게 된다.
4-5. Master Thread는 비동기적으로 바이너리 로그를 읽어서, Slave로 전송한다.
6. Slave의 I/O 스레드는 수신한 변경 데이터를 릴레이 로그에 기록한다.
7-8. Slave의 SQL 스레드는 릴레이 로그에 기록된 데이터를 읽어서 스토리지 엔진에 기록한다.

 

---

 

🌱 실습 준비  - 마스터 서버 구축하기

간단하게 실습을 진행하기 위해, docker를 활용하여 mySQL 서버를 띄워주었다.

가장 먼저 master 서버를 띄워주게 될 건데, mySQL의 설정 파일을 수정할 필요가 있기 때문에 my.cnf 라는 파일을 생성하여 다음과 같이 작성해두자.

[mysqld]
log-bin=mysql-bin    
server-id=1          
binlog-do-db=practice  
authentication_policy=mysql_native_password

 

- [mysqld]: MySQL 서버의 프로퍼티를 지정하기 위한 시작 prefix 값
- log-bin : 바이너리 로깅을 활성화하고, 로그 파일의 이름을 지정하는 것. 테이블에 대한 모든 변경사항을 로그 파일로 기록하게 된다. 

기본적으로 mySQL 에서 replication을 진행할 때 바이너리 로그 파일에 대한 내용을 기준으로 복제를 진행하기 때문에 로깅을 활성화하게 된다.
- server-id: MySQL 서버에 대한 고유 아이디 값으로, 추후 구축할 slave 용 서버와 꼭 다르게 설정을 해줘야 하는 값이다. 복제된 프로세스들 사이에서 각 mySQL 서버 프로세스를 구분하는데 사용하는 값이다.
- binlog-do-db: 바이너리 로깅을 특정한 데이터베이스에서만 사용할 수 있도록 지정하는 것이다. 여기에서는 추후 만들 ‘practice’ 라는 데이터베이스에 대해서만 로깅을 허용하도록 지정해주었다.
- authentication_policy : MySQL 8.0부터는 SHA-256 Hashing을 구현하기 위하여 2가지의 플러그인을 제공하고 있는데, 기본적으로 caching_sha2_password 라는 캐싱을 활용한 플러그인을 활용하고 있다. 이때 이를 사용하기 위해서 SSL 보안 연결이나 RSA 보안을 적용해야 하는데, 꽤나 번거롭기 때문에 구버전 플러그인인 mysql_native_password을 사용하도록 설정하는 것이다. (이 부분을 빼먹으면 나중에 통신이 안 된다…)

 

 

이러한 파일을 생성해주었다면, 설정 파일을 적용한 Dockerfile을 만들어 주자.

FROM mysql:8.0

COPY ./my.cnf /etc/my.cnf

 

mySQL 8.0 버전을 사용하였으며, 위에서 만들었던 my.cnf 파일을 설정 파일로 활용하도록 만들기 위해 COPY를 통해 내부 설정 파일을 덮어씌우도록 만들어주었다.

 

그리고, 만든 Dockerfile을 활용하여 도커 인스턴스를 띄울 수 있도록 docker-compose를 작성해주도록 하자.

version: '3'
services:
  mysql:
    build: .
    container_name: mysql
    environment:
      MYSQL_DATABASE: practice
      MYSQL_ROOT_PASSWORD: test
    ports:
      - 3306:3306 # HOST:CONTAINER
    volumes:
      - ./mysql/data:/var/lib/mysql
    networks:
      - practice-net

networks:
  practice-net:
    driver: bridge

 

- image 대신에 build를 활용하여 현재 디렉터리 (.)에 있는 Dockerfile을 활용하여 빌드할 수 있돌고 설정해주었다.
- 또한, slave와 동일한 네트워크를 사용하도록 만들어줘야 하기 때문에 커스텀하게 네트워크를 정의해주었다. (요것도 설정 안 해주면 나중에 통신이 안 된다… 꼭 설정해두도록 하자.)
- 참고로, 네트워크 이름은 현재 위치한 {패키지 이름_설정한 이름} 과 같이 만들어지기 때문에, 나의 경우 네트워크 이름이 master-practice-net으로 만들어졌다.

 

다 만들었다면, 컨테이너를 띄워주자. -d를 통해 백그라운드로 띄울 수 있도록 만들었다.

docker-compose -f docker-compose.yml up -d

 

정상적으로 되었는지 확인하기 위해, 컨테이너 내부로 접속하여 설정 파일이 잘 적용되었는지 확인해보자.

docker exec -it {containerID} bash

 

mySQL 버전에 따라 다를 테지만, 나의 경우 /etc 하위에 설정 파일이 기본적으로 존재하였으며, 파일 내용이 위와 같이 잘 변경되어 있는 것을 확인할 수 있었다.

 

참고로, 나의 경우 이것저것 삽질하면서 시간을 많이 보냈었는데 혹시나 설정을 잘못하여 my.cnf 파일을 수정해야 하는 일이 발생했다면, 꼭 빌드 시 no-cache 옵션을 설정해두도록 하자. 아니면 캐시로 인해서 적용이 늦게 되었는데 왜 안 되지? 라며 시간을 보내는 일이 생길 수도 있다...

docker-compose build --no-cache

 

---

 

🌱 실습 준비  - 슬레이브 서버 구축하기

- 비슷한 방법으로 슬레이브 서버도 구축하고자 한다. 설정 파일은 다음과 같다.

[mysqld]
log-bin=mysql-bin    
server-id=2  
relay_log=/var/lib/mysql/mysql-relay-bin
log_replica_updates='ON'
read_only='ON'
authentication_policy=mysql_native_password

 

- 앞서 말했던 것처럼, server-id의 값은 꼭 마스터 서버와 다르게 설정해줘야 한다.
- relay_log: 릴레이 로그의 위치를 지정한다.
- log_replica_updates: 릴레이 로그를 활용하여 자신의 데이터베이스에 적용하는 모든 변경 사항을 바이너리 로그에도 기록한다.
- read_only: 슬레이브 서버는 읽기 전용으로 설정한다. (마스터 서버에서만 쓰기 연산이 발생하도록 만들기 위해 설정해준다.)
    - 참고로, super 권한을 가진 사용자에 대해서는 적용되지 않는다!

 

다음으로 docker-compose 도 만들어주자. 포트와 컨테이너 이름은 다르게, 그리고 네트워크 정보는 꼭 동일하게 설정해주자.

version: '3'
services:
  mysql:
    build: .
    container_name: mysql-slave
    environment:
      MYSQL_DATABASE: practice
      MYSQL_ROOT_PASSWORD: test
    ports:
      - 3307:3306 # HOST:CONTAINER
    volumes:
      - ./mysql/data:/var/lib/mysql
    networks:
      - practice-net

networks:
  practice-net:
    external: true
    name: master_practice-net

 

그리고, 컨테이너에 접속한 다음 실제로 read_only 같은 옵션이 잘 설정되었는지 확인해보자.

show global variables like '%read_only%';

 

 

 

---

 

 

🌱 연동하기 

 

✔️ 마스터 서버에 슬레이브 서버를 위한 계정 만들기

 

Replication 에서는 Slave Thread가 Master Thread 쪽으로 접속을 요청하기 때문에, Slave가 일종의 클라이언트이고, Master가 서버라고 볼 수 있다. 이때 Master에는 Slave가 로그인을 하기 위한 계정과 권한 (Replication Slave)가 필요하다. 마스터 서버에 접속하여 아래와 같이 계정을 생성하고 권한을 부여해주자.

mysql -u root -p
create user 'test-replication'@'%' identified by 'test';
grant replication slave on *.* to 'test-replication'@'%';
flush privileges;

 

권한이 정상적으로 잘 부여되었는지 한 번 확인하고 넘어가주자.

use mysql;
select user, host from user;
show grants for 'test-replication'@'%';

 

위와 같이 slave 권한이 잘 부여된 것을 확인할 수 있다.

 

본격적인 연동을 위하여 마스터 서버의 바이너리 로깅 상태를 확인해보자.

show master status;

 

- File: 현재 사용 중인 바이너리 로그 파일의 이름이다.
- Position: 바이너리 로그 파일 내의 오프셋이며, 마지막으로 복제를 완료한 지점에 대해 나타낸다.
- Binlog_Do_DB: 바이너리 로깅이 활성화된 데이터베이스이다. 우리가 앞서 마스터 서버를 구축해주었을 때 practice 데이터베이스에 대해 지정했던 것이 여기에 반영된 것이다.
- Binlog_Ignore_DB: 바이너리 로깅에서 제외된 데이터베이스이다.
- Executed_Gtid_set: GTID (Global Transaction Identifier), 해당 서버에서 실행된 모든 트렌잭션의 GTID를 의미한다. 커밋된 트랜잭션들이 가지게 되는 고유한 식별자이다. (마스터-슬레이브 모두 동일하게 사용)

-> 기본적으로 트랜잭션이 커밋되면 GTID를 할당받아 마스터의 바이너리 로그에 기록이 된다. 이때, 슬레이브가 바이너리 로그에 있던 내용을 릴레이 로그에 저장하면, GTID 정보를 토대로 해당 트랜잭션이 아직 미반영된 상태라면 반영하게 된다. 그리고 슬레이브의 바이너리 로그에도 기록하게 된다.

 

---

 

✔️ 연동하기  - 마스터 서버의 IP 주소 알아내기

 

여기까지 진행했다면 이제 두 서버에 대해 연결을 해줄 차례이다. 먼저, 마스터 서버의 컨테이너 IP 주소를 확인해야 한다.

이는, 슬레이브 서버가 마스터 서버에 접속하기 위한 정보를 얻기 위한 과정이라고 보면 된다.

 

우리는 도커를 사용하고 있기 때문에, 도커 컨테이너가 어떤 네트워크를 사용하고 있는지 확인하기 위해 아래와 같이 메시지를 입력하자.

docker inspect {container_name} | grep Network

만약 위의 캡쳐 화면처럼 마스터 서버와 슬레이브 서버의 네트워크 정보가 다르다면, 아래와 같은 방법으로 수정해줄 수 있다. (물론 재생성을 해도 괜찮다)

// mysql-slave 컨테이너에 대해 slave_default 네트워크 끊어주기
docker network disconnect slave_default mysql-slave

// 대신 master_default 네트워크를 연결해주기
docker network connect master_default mysql-slave

그럼 위와 같이 master 컨테이너와 동일한 네트워크 아이디를 할당받은 것을 볼 수 있다.    

 

위에서 확인한 네트워크 아이디를 바탕으로, 전체 docker 네트워크 목록을 확인하여 어떤 네트워크에 연결되어 있는지 체크하자.   

docker network ls

 

 

앞서 봤던 네트워크 아이디가 95dc~ 로 시작한 것을 볼 수 있으니, 현재 연결된 네트워크 이름이 ‘master_default’ 인 것을 확인할 수 있었다. 해당 네트워크의 IP 주소를 알아보기 위해 아래와 같이 다시 입력해주자.

docker inspect {network_name} | grep IPv4Address

 

---

 

✔️ 연동하기  - 슬레이브 서버에서 접속하기

 

이제 IP 주소도 알게 되었으니, 슬레이브 서버에 접속하여 아래와 같은 명령어를 입력해주자.

CHANGE MASTER TO MASTER_HOST='172.29.0.2', MASTER_PORT=3306, MASTER_USER='test-replication', MASTER_PASSWORD='test', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=880, GET_MASTER_PUBLIC_KEY=1;

 

 

 - MASTER_HOST / MASTER_PORT: 마스터 서버의 IP 주소 / Port로, 슬레이브 서버가 마스터 서버에 접속하기 위해 알아야 하는 IP 정보와 포트 정보이다.

- MASTER_USER / MASTER_PASSWORD: 이전에 마스터 서버에서 생성했던 슬레이브 서버용 계정 정보이다.

- MASTER_LOG_FILE / MASTER_LOG_POST: 앞서 마스터 서버의 바이너리 로그 파일 정보에서 봤던 파일 이름과 오프셋 정보이다. (어디서부터 읽어올 것인지 정하는 것)
- GET_MASTER_PUBLIC_KEY=1 : 슬레이브가 마스터 서버에 연결할 때 마스터의 공개키를 자동으로 요청하게 된다.

 

 

연동을 시작해주기 위해 start slave를 입력해주자.

재구성하고 싶을 때는 stop replica > reset slave;를 활용해주면 된다.    

start slave;

마지막으로 연동을 확인하기 위해 아래의 명령어를 입력해보자.

 show slave status\G

여기에서 Slave_IO_Running, Slave_SQL_Running의 값이 모두 Yes로 표시가 되어야 한다.

만약 Slave_IO_Running가 Connecting으로 뜬다면, 아래로 내려 Last_IO_Error 항목을 보자.

나 같은 경우는 초기에 network 설정을 제대로 안 해줘서 이렇게 통신이 실패했었다.

 

혹은, 이런 식으로 Authentication 오류가 발생했다면, 초기에 mysql 설정 파일에서 default_authentication_plugin 값을 지정해주지 않았을 확률이 높다… 왜 안 되는지 나도 알고 싶지 않았지만 이 2가지 오류 때문에 시간을 많이 썼다.

슬레이브 서버에서 마스터 서버 연동 시 GET_MASTER_PUBLIC_KEY 이 옵션을 빼먹었을 확률도 있다…! 잘 확인해보자.
    
최종적으로 제대로 되었다면 아래와 같이 둘 다 Yes로 뜰 것이다.
호스트 주소가 이전과 다른 이유는 오류가 꽤 여러 번 떴었어서 다시 만드느라 바뀌었다.

    
마스터에서도 슬레이브의 접속 정보를 확인할 수 있는데, 아래와 같이 입력해보자.

show processlist\G

가장 아래에 우리가 연동했던 test-replication 이라는 친구에 대해 State로 ‘source가 모든 binlog를 replication을 보냈다’ 라는 문구를 확인할 수 있다!

 

---

🌱 복제 테스트 해보기

마스터 서버에 접속하여 더미 데이터를 집어 넣고 한 번 확인해보자.

use practice;

create table test(
    id bigint not null primary key,
    name varchar(100)
) engine = 'INNODB';

insert into test (id, name) values (1, 'test');

 

insert 후 마스터 서버의 모습이다. 

그리고, 슬레이브 서버에 접속하여 해당 데이터가 잘 복제되었는지 확인해보자.

 

위와 같이 잘 복제가 된 것을 확인할 수 있다! 

(데이터 값이 똑같아서 아닌 것처럼 보이지만, 실제로 슬레이브 서버에 접속했을 때 나온 결과이다!

---

 

🌱 마무리

이번 포스팅에서는 mySQL을 활용하여 간단하게 master <-> slave 간 replication 을 만들어보았다.

실무에서는 고려해야 하는 점들이 훨씬 더 많겠지만, master의 내용이 알아서 slave로 복제되는 모습을 직접 보니까 굉장히 신기했다. 

이렇게 간단하게 만드는 것도 엄청 시간이 오래 걸렸는데, 실제로는 훨씬 복잡하게 동작할 것 같다는 고민도 들엇다.

실제로 일을 하면서 이런 것까지 제대로 고찰해보지 못했었는데, 앞으로는 이런 식으로 간단하게 만들어 볼 수 있는 것들은 실습해보는 식으로 공부해봐야겠다는 생각이 들었다.

 

다음 포스팅이 언제가 될지 모르겠지만... 시간 내서 2편도 작성해봐야겠다. 끝!