MySQL / MariaDB Replication 구성 방법 (mysqldump)

해당 페이지에서는 mysqldump 를 사용한 MySQL / MariaDB 의 replication 구성방법을 다룬다.

 

해당 페이지를 읽기 전, 아래의 replication 작동 원리를 참조하고 오면 좋다.

 

2021.03.04 - [MySQL/Replication] - Replication 작동구조

 

 

 

 

먼저, Replication 을 구성하기 전에 일부 설정 확인이 필요하다.

 

- Replication 은 binlog 파일을 읽어들여 동기화를 하는 구조 이므로 binlog 설정이 되어 있어야한다.

아래의 log_bin 이 on 인지 확인한다.

 

 

- 상이 버전 간의 replication 설정시에는 slave 서버의 버전이 더 높아야 한다.

(필자는 해당 테스트를 할때 동일하게 5.7 버전으로 맞췄다.)

 

- 또한 replication 을 사용할 유저를 생성한다. 물론 root 를 써도 문제 없다면 root 로 걸수도 있다.

 

 

 

 

 

설정을 확인 했다면 Master 서버에서 Slave 서버로 데이터베이스 형상 및 데이터를 백업 받아 옮겨 놔야 한다. 옮길 분량이 적다면 mysqldump 로 빠르게 파일로 만들 수 있다. (용량이 크다면 mysqldump 는 매우 오래 걸리므로 xtrabackup 을 사용해야한다.)

 

또한 운영서버에서 아무 옵션 없이 dump 를 받을 시에는 Table Lock 을 걸어서 데이터 인입을 막으므로 서비스 사용 불가 까지 갈 수 있는 상황이 올수 있기 때문에 --skip-lock-tables 나 --single-tracsaction 옵션을 반드시 넣어서 lock을 방지하도록 한다.

 

 

 

 

 

백업이 완료되면 완료된 파일을 slave 서버로 옮긴 후, 해당 DB에 적용시키도록 한다. 

(물론 mysql 은 설치되어 있어야한다.)

 

 

 

백업파일을 Slave 에 적용시키면 이제 어느정도 형상을 맞춘 상태다. 이제 DB 내에서 아래의 현재 DB 기록 중인 번호를 파악 해서 replication 시작 지점을 설정 할 수 있는데 두가지 방법 중 하나를 택 할 수 있다.

 

 

-  Master 서버에서 현재 기록중인 binlog 파일과 Position 번호 사용

 

mysqldump 는 백업시점의 형상만 받고 백업을 받는동안 수행된 데이터 변경이력은 binlog 로 추가 적용 시켜야한다.

이 방법을 사용시에는 백업과 replication 적용 시점 사이의 데이터 변경이력을 무시해도 될 때 사용한다.

 

-  Slave 서버에서 현재 기록 된 binlog 파일과 Position 번호 사용

 

백업시점 이후에 변경된 내역을 전부 동기화 하고 싶을때 사용한다. 단, 이를 위해서 동기화가 진행되는 동안 순간적인 table lock 이 발생하여 지연이 있을 수 있다.

 

 

 

설정이 끝나면 아래와 같은 명령어로 설정하여 replication 연결 정보를 설정한다.

master_logfile 은 위에서 선택한 번호 시점으로 설정하면 된다.

 

 

그 후, slave 통신을 시작하여 동기화를 시작한다. (나중에 반대로 중지시킬때는 stop slave 사용)

 

 

설정이 정상적으로 되면 아래의 show slave status 명령어로 동기화 상태를 볼 수 있다.

 

 

여기서 replication 이 정상적으로 작동하는지는 Slave_IO_Running 과 Slave_SQL_Running 을 확인한다.

해당 요소가 무엇을 뜻하는지는 위의 replication 작동구조 링크에서 확인하면 된다.

 

 

 

 

이제 정상적으로 replication 이 작동하는지 테스트를 해보자. 필자는 아래와 같이 repl_test DB 및 테이블을 만들어서 테스트로 데이터를 넣었다.

 

 

 

이제 Slave 서버에서도 위의 DB와 테이블이 조회되는지 확인해보면 정상적으로 조회가 됨을 확인 할 수 있다.