[MySQL][Master-Slave] 복제소개 및 사용방법

MySQL 여러형태의 복제 솔루션과 HA, 분산기능, 그리고 클러스터링을 지원합니다. Master-Slave구조 + MHA, Multi Master for MySQL, Galera Cluster, MaxScale(MariaDB), Sharding 많은 기능들을 제공한다는 것을 있습니다. 그중에 대표적인게 Master Slave 구조입니다. Master에서는 DDL, DML 쿼리 약간의 SELECT 수행하고 Slave에서는 Select Query 지원하는 형태로 구축을 합니다. 보통 Database 쿼리 수행빈도를 분석해보면 데이터 조회가 보통 60~70% 사용한다고 합니다. 그래서 마스터 한대에 슬레이브를 여러대를 두어 부하를 분산시키는 전략을 보통 많이 사용합니다. 지금부터 가장 기본적인 복제 방법인 Master Slave구조에 대해 자세히 알아보겠습니다.

 

■ Master - Slave 구조 아키텍쳐

 

▶ MySQL Master-Slave 구조는 각각의 서버에 각각의 디스크를 가지고 있습니다. 그래서 각각의 서버에 대해 물리적인 영향을 최소화 합니다. 방식의 구조를 disk shared nothing 구조라고 합니다. 오라클 RAC같이 disk 공유하는 구조를 disk shared 라고 합니다.

 

▶ MySQL 마스터 슬레이브는 바이너리로그 기반의 복제기법입니다. 그래서 로그 관리가 굉장히 중요합니다. 먼저 복제 아키텍쳐와 마스터 슬레이브간의 동기 방법을 설명드리겠습니다.

먼저 마스터에서 수행한 DDL, DML 쿼리를 버퍼캐쉬(binlog_cache_size) 크기만큼 쌓아둡니다. 그러다 크기를 넘어서게 되면 특정 디렉토리의 바이너리 로그에 쌓게 됩니다. 보통 바이너리 로그 이름을 지정할 특별한 디렉토리가 없다면 데이타 디렉토리에 쌓이게 됩니다. 로그를 다른 DBMS에서는 아카이브 로그라고도 합니다. 슬레이브 서버는 슬레이브의 IO Thread라는 것을 통해서 마스터의 Binary Log 읽습니다. 마스터는 슬레이브에서 로그요청을 받으면 Binlog Dump Thread 통해서 슬레이브에게 로그를 전송합니다. 슬레이브는 마스터서버에서 요청한 로그를 IO Thread 슬레이브 서버의 특정 디렉토리에 쌓습니다. 슬레이브 바이너리 로그를 릴레이로그(Relay Log)라고 합니다. 슬레이브 서버는 릴레이 로그를 읽어서 SQL 수행시킵니다. 그리고 Relay Log안의 모든 SQL 수행되면 삭제됩니다.(물론 계속 존재하게 수도 있습니다.) 이런 사이클로 계속 수행하면서 마스터와 같은 서버로 동기화를 이룹니다.

 

이진로그는 쿼리나 트랜잭션이 어떠한 lock 걸려있지 않거나 commit 만나면 바로 이진로그 파일에 쓰이게 됩니다. 다른 상황으로 uncommit 트랜잭션에서 모든 변경사항(update, delete, insert) innodb 캐쉬같은 공간에 commit 수행하기 전까지 일단 모두 저장이 됩니다. 시점에서 mysqld 모든 트랜잭션을 commit 수행되기 전까지 모두 이진 로그에 저장하게 됩니다.

 

위에 대한 각각을 내용을 자세히 설명하면 다음과 같습니다.

+ Binary Log

데이터베이스를 생성하거나 변경하는 작업, 테이블을 생성하거나 제거 혹은 컬럼의 속성을 변경하는 작업등의 DDL, 데이터를 수정하고 삭제하고 변경하는 DML등의 모든 이벤트를 저장하는 로그를 Binary Log라고 합니다. 위에서도 설명했듯이 로그를 보통 아카이브 로그라고 합니다. 백업과 복구시 필수 필요 파일이며 시점 복구시에는 더욱더 필요한 파일입니다. 슬레이브 구축시 바이너리 로그 파일을 읽어서 만듭니다.

 

+ Relay log

슬레이브 서버는 I/O thread 통해서 받은 이벤트를 로컬의 data디렉토리에 로그 파일을 만들어 저장합니다. 파일을 Relay Log라고 부릅니다.

보통 Relay Log SQL Thread 이벤트를 읽고 나면 지웁니다. 따라서 어느 정도 이상의 크기가 되지 않습니다. 하지만 SQL Thread 멈추어 있으면 Relay Log 계속해서 크기가 커지게 됩니다. 그렇게 되면 I/O Thread 자동으로 Relay Log 파일을 만들어, 파일이 너무 커지는 것을 막습니다.

 

보통 MySQL 데이터를 백업하여 아카이브를 만드는 것은 mysqldump라는 백업 프로그램을 이용합니다. 하지만 mysqldump MySQL 쿼리를 실행하고 있을 실행되면 데이터의 일관성이 깨지거나 병행성 문제가 발생할 있습니다. 그러나 Replication 이용하면, 슬레이브의 SQL Thread 정지시키면 되기 때문에 안전하게 백업을 만들 있습니다.

 

+ Binlog dump thread

복제를 위해서는 마스터 서버에 저장된 바이너리 로그를 읽어서 슬레이브로 전송해야 합니다. 이를 위해서 MySQL서버에서 쓰레드를 하나 생성해서 바이너리 로그를 전송하는데 역활을 하는게 Binary Log Dump Thread입니다. 쓰레드의 역활은 슬레이가 로그를 요청하면 바이너리 로그에 먼저 Lock 겁니다. 그리고 슬레이브 서버에서 요청하는 특정 위치의 이벤트를 찾습니다. 그리고 해당 이벤트를 슬레이브로 전송합니다. 바이너리 로그에 Lock 거는 시간은 순간적입니다. 마스터에서도 로그를 작성해야 하는데 오랜시간 Lock 걸면 성능과 복제에 문제가 발생하기 때문입니다.

 

또한 마스터 서버는 슬레이브에 대한 정보를 전혀 필요가 없습니다. 슬레이브가 몇개인지 어디까지 복제를 했는지등 슬레이브 서버에 대한 정보는 전혀 저장하지 않습니다. 그저 슬레이브에서 요청하는 이벤트가 있다면 이벤트만을 보낼 뿐입니다. 그래서 마스터 서버는 그리 부하없이 운영할 있습니다. 마스터는 

DDL, DML, SELECT 모든 쿼리를 처리해야 하기 때문에 가능한 부하를 줄여주어야 합니다. 혹은 복제서버들 중에서 가능하면 네트워크 성능과 하드웨어 성능이 좋아야 합니다.

 

참고로 Binary Log Dump Thread 슬레이브가 마스터에 이벤트를 요청할 생성되지만 여러개의 슬레이브가 붙어도 하나의 쓰레드에서 모두 처리됩니다.

 

+ I/O thread

슬레이브는 마스터에 없는 2개의 스레드가 있습니다. 그중 하나가 I/O thread입니다. 슬레이브는 자신이 어디까지 데이터를 복사했는지 기억하고 있습니다. I/O thread 슬레이브가 마지막으로 읽었던 이벤트를 기억하고 있다가 마스터에게 다음 이벤트를 전송해 달라고 요청합니다. 마스터의 binlog dump thread 이벤트를 보내주면 이것을 슬레이브 서버의 Relay log 저장합니다. 따라서 I/O thread 정지된 상황에서 마스터의 binary log 지워지면, 슬레이브는 마스터의 데이터를 복제할 없게 됩니다. 복제 상태에서 마스터의 바이너리 로그를 함부로 지우면 안되는 이유입니다. 또한 스레드의 상태는 SHOW SLAVE STATUS 출력에서 ​​Slave_IO_running 또는 SHOW STATUS 출력에서 ​​Slave_running으로 표시됩니다.

 

+ SQL thread

SQL thread I/O thread 만든 relay log 읽어 실행을 시키고, relay log 지웁니다. SQL 실행시키는 스레드와 마스터로부터 값을 복사해오는 스레드가 분리되어 있다는 것은 매우 중요한 특징입니다.

 

구성방법

Master-Slave 서버의 아키텍쳐와 특징을 알아보았습니다. 이제는 Master - Slave구조를 설정해보겠습니다.

서버 환경

  Master Slave
IP 192.168.0.101 192.168.0.102
복제 USER/암호 repl/replpass -
Binary Log master_bin relay_bin

 

 

▶ Master 서버 설정 구성

위에서 설명했듯이 Replication 바이너리 로그를 사용하여 복제를 진행하게 됩니다. 그러나 특이하게 MySQL 바이너리 로그가 하나의 형식을 가지는게 아니라 Statement, ROW, Mixed라는 3가지 방식의 로깅을 지원합니다. 그래서 바이너리 로그의 특징을 이해하는게 중요하며 한번 일독을 권장드립니다. 아래 다시 한번 말씀드리긴 할테지만 소개 정도로만 나와 있어 다음 페이지를 읽어보시기를 권장드립니다.

https://myinfrabox.tistory.com/20?category=784582

 

+ Binary Log 활성 서버ID 설정

마스터 서버의 my.cnf 다음 항목을 입력합니다. [mysqld] 섹션에 입력합니다. 참고로 log-bin 설정할 server-id 설정해 주지 않으면 로그 파일이 생성되지 않고 서버도 실행되지 않습니다. 에러는 떨어지는데 에러로그에 원인이 남지 않습니다.

[mysqld]
server-id=1
log-bin=master_bin
binlog_cache_size=2M
max_binlog_size=500M
expire_logs_days=7
log-bin-trust-function-creators=1
master_info_repository = TABLE

 

마스터 서버에서 skip_networking 시스템 변수가 활성화되어 있지 않은지 확인해 보아야 합니다. 바이너리 로그 전송은 네트워크로 이루어지기 때문에 네트워크 활성화가 필수입니다. 네트워킹이 비활성화 경우 슬레이브는 마스터와 통신 없으며 복제가 실패합니다.

복제에 참가되는 모든 서버 ID(server-id) 모두 달라야 합니다. 유일해야 합니다. 같은 ID 되어 있으면 복제가 되지 않습니다.

 

+ 추가 옵션 설정.

트랜잭션과 함께 InnoDB 사용하는 복제 설정에서 최대한의 내구성과 일관성을 유지하려면 마스터의 my.cnf 파일에서 innodb_flush_log_at_trx_commit=1 sync_binlog=1 사용해야합니다. 

 

+ 복제 유저 생성.

마스터 서버에서 복제 전용 유저를 생성합니다. 슬레이브 서버에서는 change master to 라는 옵션을 이용해서 마스터 서버에 접속합니다. 이때 마스터 서버에 생되어 있는 복제 계정을 이용해서 접속하게 됩니다. 그리고 복제 계정은 replication slave라는 권한을 가지고 있어야 합니다. 아래 명령을 마스터에서 실행합니다.

mysql> CREATE USER 'repl'@'192.168.0.101' IDENTIFIED BY 'replpass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.0.101';

 

+ 준비사항 데이터 덤프.

복제를 구성하려면 마스터 서버의 데이터 디렉토리를 똑같이 슬레이브 서버에도 구성해야 합니다. 이때 구성할 있는 방법은 간단하게 2가지 방법이 있습니다.

 

- 파일시스템 데이터 디렉토리 복사 방법.

아마 Master-slave 내리고 구성한다면 방법이 가장 좋을 있습니다. 마스터의 데이터 디렉토리를 아예 통채로 압축하고 slave 서버로 복사하는 방법입니다.

대신 마스터 서버를 내리고 복사를 해야 합니다. 보통 기존 서버를 이용해서 신규 복제를 구성할 사용되며 다운타임(서버를 셧다운 시키는 시간) 반드시 필요합니다. 절대 서버가 실행중인 상태에서 복사하시면 안됩니다.!

 

- Master 서버 데이터 덤프 이동.

mysqldump 방법으로 덤프를 생성한 이걸 이용해서 Slave서버를 구성하는 방식입니다. Master 서버를 내릴 없을 이용하는 방식입니다. 가능하면 트랜잭션이 거의 없는 상황에서 작업진행을 추천드립니다.

아래 예제예서는 DB덤프 방법으로 수행합니다.

 

1. 데이터 덤프(일관성 있는 백업)

테이블에 Lock 걸지 않고(엄밀하게 말하면 아주 잠깐 read lock 걸고 해제합니다.) 백업을 수행하는 작업방법입니다. --single-transaction이란 옵션을 사용하여 덤프를 받습니다.

shell> mysqldump -uroot -p --single-transaction --master-data=2 --hex-blob --master-data=2 --routines --triggers --all-databases | gzip > dbdump.sql.gz

--master-data 옵션은 덤프파일 안에 change master 옵션을 넣을지 말지를 결정하는 옵션입니다. 옵션을 붙이게 되면 change master 명령문이 들어가게 됩니다.

2가지가 있는데 1은 change master 명령문을 수행하는 옵션입니다. 서버에 덤프파일을 넣을때 change master 명령문까지 자동으로 실행되게 하는 명령문입니다. 2도 마찬가지로 change master 명령문은 포함되지만 주석으로 되어 있습니다.

즉 덤프파일을 서버에 넣어도 change master 명령어는 추후 실행해 주어야 합니다.

덤프를 받은 슬레이브로 넘깁니다.

 

 

슬레이브 서버 설정

+ 설정방법

슬레이브 서버의 my.cnf 다음 항목을 입력합니다. [mysqld] 섹션에 입력합니다.

[mysqld]
server-id=2
relay-log=relay-bin
log_slave_updates=ON
relay_log_purge=true
read_only
relay_log_info_repository = TABLE

 

server-id master 서버, 혹은 설정된 슬레이브가 있다면 슬레이브번호와 중복되지 않는 값으로 설정합니다. 복제에 참가하는 모든 서버의 servier-id 달라야 합니다.

 

마스터에서 복사해온 덤프 파일을 압축을 해재하고 준비합니다.

# tar -zxvf dbdump.sql.gz

 

압축이 해제된 덤프 파일에서 다음 구문을 찾습니다. 보통 맨위에서 몇십줄 아래에 있습니다. 아래의 명령어를 입력합니다.

# head -100 dbdump.sql

혹은

# more dbdump.sql

이렇게 하면 아래와 같은 구문이 중간에 보입니다.

......
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=619
......

 

그리고 위의 내용을 별도로 다른곳에 복사해 둡니다.

 

신규 슬레이브 서버에 덤프를 임포트합니다.

# mysql -uroot -p < mysqldumpfile.sql

 

 

마스터와 슬레이브 연결

위에서 알아낸 복제 정보를 이용해서 슬레이브 서버에 다음의 명령어를 입력합니다. 속성들은 자신의 환경에 맞게 입력해야 합니다.(IP 패스워드, 바이너리 로그 이름등)

mysql> CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='replpass', MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=619;

 

복제 설정 상태 확인.

mysql> SHOW SLAVE STATUS\G;

여러 데이터가 나옵는데 이중에서 다음의 내용을 확인해야 합니다.

....
Slave_IO_Running: NO
Slave_SQL_Running: NO
....

두개가 YES 되어 있어야 합니다.

만약 YES 되어 있지 않다면 다음의 명령을 수행합니다.

mysql> start slave;

 

다시한번 확인해봅니다.

mysql > show slave status\G;

......
Slave_IO_Running: YES
Slave_SQL_Running: YES
......

만약 YES 변경되어 있지 않다면 복제구성이 제대로 이루어지지 않은 것입니다. error로그를 확인해서 이유를 찾아야 하고 mysql 클라이언트에서 show warning 명령을 이용해서 나오는 경고문이 있는지 확인합니다.

 

 

마스터에서 테이블을 생성하거나 Database를 생성하여 슬레이브에 잘 넘어오고 적용되는지 확인합니다.

mysql > use mydb;
mysql > show tables;
mysql > select * from mytable;

반드시 테이블의 데이터까지 확인해 봅니다.

 

 

로그파일 정보에 대한 정보 저장 방법.

슬레이브는 마스터 정보 저장소에 구성한 마스터에 대한 정보를 저장합니다. 위의 마스터, 슬레이브 서버 설정중 master_info_repository, relay_log_info_repository = TABLE 파라미터에 해당합니다.

파라미터 변수에 설정된 값에 따라 파일 또는 테이블 형식 있습니다. 슬레이브가 master_info_repository = FILE 실행되면 master.info relay-log.info라는 개의 파일이 데이터 디렉토리에 저장됩니다. 기본값입니다. 만약 master_info_repository = TABLE 되어 있다면 정보는 mysql 데이터베이스의 master_slave_info 테이블에 저장됩니다. 두개 모두 파일이나 테이블로 정보를 저장하고 표기하게 되는데 이때 임의로 편집하거나 제거하거나 하지 마세요. 복제 매개 변수를 변경하려면 항상 CHANGE MASTER TO 문을 사용하셔야 합니다. 슬레이브는 명령문에 지정된 값을 사용하여 상태 파일을 자동으로 업데이트 있습니다.

 

슬레이브 복제 중지

STOP SLAVE START SLAVE 문을 사용하여 슬레이브에서 복제를 중지하고 시작할 있습니다.

마스터서버로부터 바이너리 로그의 처리를 중지하려면 다음과 같이 입력합니다.

mysql> STOP SLAVE;

 

복제가 중지되면 슬레이브 I/O 스레드는 마스터 이진 로그에서 이벤트 읽기 릴레이 로그에 기록을 중지하고 SQL 스레드는 릴레이 로그에서 이벤트 읽기 실행을 중지합니다. 스레드 유형을 지정하여 I/O 또는 SQL 스레드를 개별적으로 일시 정지 있습니다.

mysql> STOP SLAVE IO_THREAD;

mysql> STOP SLAVE SQL_THREAD;

 

Slave 다시 기동하려면 Start slave 입력합니다.

mysql> START SLAVE;

 

위에서 스레드를 개별로 중지시킬 있듯이 시작도 스레드 개별로 수행시킬 있습니다.

mysql> START SLAVE IO_THREAD;

mysql> START SLAVE SQL_THREAD;

 

■ I/O Thread SQL Thread 시작 중지 활용 방법

마스터의 이벤트를 처리하여 업데이트만 수행하는 슬레이브의 경우, 백업 또는 다른 작업을 수행하려는 경우, SQL 스레드만 중지하는 것이 유용 있습니다. I/O 스레드는 마스터에서 계속 이벤트를 읽지만 실행되지는 않습니다. 이렇게하면 SQL 스레드를 다시 시작할 슬레이브가 쉽게 따라 잡을 있습니다.

 

I/O 스레드만 중지하면 릴레이 로그의 이벤트가 릴레이 로그가 끝나는 지점까지 SQL 스레드에 의해 실행될 있습니다. 이는 슬레이브에서 관리를 수행하려고 하지만 특정 지점으로 모든 업데이트를 처리했는지 확인할 마스터에서 이미 수신 이벤트를 따라 잡기 위해 실행을 일시 중지하려는 경우 유용 있습니다. 방법을 사용하면 마스터에서 관리를 수행하는 동안 슬레이브에서 이벤트 수신을 일시 중지 수도 있습니다. I/O 스레드를 중지하고 SQL 스레드가 실행되도록 허용하면 복제가 다시 시작될 실행될 이벤트의 로그가 없도록하는 도움이됩니다.

 

 Master-Slave 복제 환경 관련 참고글

[Master-Slave] 복제환경에서의 바이너리 로그 특징

 

[MySQL][Master-Slave] 복제 환경에서 Binary Log 특징

복제를 사용할 때 이진 로그에 대해 어떤 타입을 선택할지 정해야 하는데 이때 아래 내용들을 참고해서 설정하시면 도움이 됩니다. 복제를 할 때 safe(안전한), unsafe(안전하지 않은) 쿼리가 있는데 이것을 알면..

myinfrabox.tistory.com

[Master-Slave] 복제환경 모니터링

 

[MySQL][Master-Slave] 복제 환경 모니터링

Replication 상태에서 모니터링을 하는 방법에 대해 알아봅니다. 모니터링에서 표시해주는 상태에 따라 그에 맞는 대처를 해서 복제가 지속적으로 이루어 지도록 합니다. ■ Slave 상태 확인 mysql 클라이언트에서..

myinfrabox.tistory.com

[Master-Slave] 복제 필터링 - 복제평가방법

 

[MySQL][Master-Slave] 복제 필터링 - 복제평가방법

■ 서버가 복제 필터링 규칙을 평가하는 방법 복제를 구성할때 전체 데이터베이스를 대상으로 하는 방법도 있지만 원하는 데이터베이스만을 선택해서 복제할 수도 있습니다. 반대로 원하는 데이터베이스만을 복제..

myinfrabox.tistory.com

[Master-Slave] 복제 필터링 - 명령문 및 적용방법

 

[MySQL][Master-Slave] 복제 필터링 - 명령문 및 적용방법

■ Replication Filtering Rule 사용 및 적용방법 이전 챕터에서 복제 룰에 대해서 평가하는 방법을 배웠습니다. 이번엔 실제 복제필터링을 적용하는 명령과 환경설정 옵션에서 어떻게 적용하는지에 대해 알아봅니..

myinfrabox.tistory.com

[Master-Slave] GTID를 이용한 복제 - 이론

 

[MySQL][Master-Slave] GTID를 이용한 복제 - 이론

이 섹션에서는 GTID (Global Transaction Identifier)를 사용한 트랜잭션 기반 복제에 대해 설명합니다. GTID를 사용할 때 각 트랜잭션은 원래 서버에서 커밋되고 슬레이브에 의해 적용될 때 식별되고 추적 될 수..

myinfrabox.tistory.com

[Master-Slave] GTID를 이용한 복제 - 구성방법

 

[MySQL][Master-Slave] GTID를 이용한 복제 - 구성방법

■ GTID를 이용한 복제 설정. 이 섹션에서는 MySQL 5.7에서 GTID 기반 복제를 구성하고 시작하는 프로세스에 대해 설명합니다. 이는 처음으로 복제 마스터를 시작하거나 중지 할 수 있다고 가정하는 "콜드 스타트"..

myinfrabox.tistory.com

 

 

도움이 되셨다면 광고클릭 한번 부탁드립니다.※

댓글(0)

Designed by JB FACTORY