[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를 설정해 주지 않으면 로그 파일이 생성되지 않고 서버도 실행되지 않습니다. 에러는 떨어지는데 에러로그에 원인이 남지 않습니다.

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

MySQL 8.0 일때
[mysqld]
server-id=1
log-bin=master_bin
binlog_cache_size=2M
max_binlog_size=500M
log-bin-trust-function-creators=1
expire_logs_days=7
binlog_expire_logs_seconds = 691200

 

참고) expire_logs_days가 binlog_expire_logs_seconds로 바뀌고 master_info_repository은 기본값이 Table로 바뀌었습니다.

 

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

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

 

+ 추가 옵션 설정.

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

 

+ 복제 유저 생성.(5.7.x)

마스터 서버에서 복제 전용 유저를 생성합니다. 슬레이브 서버에서는 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';

 

 

- MySQL 8.0 계정 생성 관련 유의사항

 MySQL 8.0은 기본적으로 caching_sha2_password로 생성됩니다. 8.0.34부터 mysql_native_password는 Deprecated라고 명시되었기 때문에 이 암호 플러그인으로 생성하지 않으면 추후 업그레이드시 에러가 발생할 수 있습니다. 그리고 caching_sha2_password는 인증서를 통한 접속방식이기 때문에 인증서 또한 필요합니다.

mysql > select user, host, plugin from mysql.user;
+------------------+-----------+-----------------------+
| user             | host      | plugin                |
+------------------+-----------+-----------------------+
......
| repl             | %         | caching_sha2_password |
+------------------+-----------+-----------------------+

위와 같이 caching_sha2_password로 생성된것을 확인할수가 있습니다. 그리고 인증서가 준비되어야 하는데 만약 준비되어 있지 않다면 기본적으로 제공되는 키를 이용해서 접속이 가능합니다.

MySQL 데이터 디렉토리에 이동해서 확인해보면 다음과 같은 키가 있습니다.(MySQL 인증서 위치 설정에 따라 다를 수 있습니다.)

private_key.pem, public_key.pem

이 두개의 키는 caching_sha2_password_auto_generate_rsa_keys 라는 파라미터에 의해 자동으로 생성이 됩니다. 확인방법은 다음과 같습니다.

mysql> show variables like 'caching_sha2_password_private_key_path';
+----------------------------------------+-----------------+
| Variable_name                          | Value           |
+----------------------------------------+-----------------+
| caching_sha2_password_private_key_path | private_key.pem |
+----------------------------------------+-----------------+

mysql> show variables like 'caching_sha2_password_public_key_path';
+---------------------------------------+----------------+
| Variable_name                         | Value          |
+---------------------------------------+----------------+
| caching_sha2_password_public_key_path | public_key.pem |
+---------------------------------------+----------------+

 

이중에서 복제에 구성하려면 public_key.pem이 필요한데 이 키는 자동으로 다음 상태변수에 저장됩니다.

mysql> SHOW STATUS LIKE 'Caching_sha2_password_rsa_public_key'\G;
*************************** 1. row ***************************
Variable_name: Caching_sha2_password_rsa_public_key
        Value: -----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5tv10//iGJ8SvRLavbUp
fTBzqGbj9cTeeOZPINET/Be81X0ssfFfkk7e4m3ZJcZSzvSu+SYTGQ6nlsS4eKHG
wnQlCfyct5+aroATf2c36qXMjwrCR5FfffgNuT/Dhw+Oo4TOsWBxlrT1+tXj1rWN
oVkYKoh0In0o7nWz5Y8V3QmxbaWpO8S6Lw1dmSjxac9mJP2QoUJMXu8Q4ndVBj04
WdZBla1QDjKbymWzkHOkMiZds8lqFSJFbxsxxwdfVw0gR5jGBelhcmdTnBNp6NbW
Jh8oYsiB4cezUZVwq6uLcMdWr+gQZGTv0B7odbrYWjvwgHrIMkQmvJF7Q7mwHG6m
DwIDAQAB
-----END PUBLIC KEY-----

1 row in set (0.0117 sec)
ERROR: 1065 (42000): Query was empty

 

터미널에서 파일을 확인해보면 내용이 같다는 것을 확인해볼 수 있습니다.

shell> cat public_key.pem
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5tv10//iGJ8SvRLavbUp
fTBzqGbj9cTeeOZPINET/Be81X0ssfFfkk7e4m3ZJcZSzvSu+SYTGQ6nlsS4eKHG
wnQlCfyct5+aroATf2c36qXMjwrCR5FfffgNuT/Dhw+Oo4TOsWBxlrT1+tXj1rWN
oVkYKoh0In0o7nWz5Y8V3QmxbaWpO8S6Lw1dmSjxac9mJP2QoUJMXu8Q4ndVBj04
WdZBla1QDjKbymWzkHOkMiZds8lqFSJFbxsxxwdfVw0gR5jGBelhcmdTnBNp6NbW
Jh8oYsiB4cezUZVwq6uLcMdWr+gQZGTv0B7odbrYWjvwgHrIMkQmvJF7Q7mwHG6m
DwIDAQAB
-----END PUBLIC KEY-----

 

만약

SHOW STATUS LIKE 'Caching_sha2_password_rsa_public_key'\G;

명령어로 내용 확인 시 아무것도 보이지 않는다면 public_key.pem와 private_key.pem에 대한 OS 소유권을 확인해봅니다. 보통 mysql로 되어 있는데 root나 다른 권한으로 되어 있다면 mysql로 변경합니다. 이 내용이 보이지 않는다면 CHANGE REPLICATION SOURCE 명령시 해당 소스 서버에 접속할 수 없다는 에러 메세지를 출력합니다. 반드시 내용이 출력되어야 합니다.

 

+ 준비사항 및 데이터 덤프.

복제를 구성하려면 마스터 서버의 데이터 디렉토리를 똑같이 슬레이브 서버에도 구성해야 합니다. 이때 구성할 수 있는 방법은 간단하게 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

이렇게 하면 아래와 비슷한 구문이 중간에 보입니다.

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

MySQL 8.0
......
-- CHANGE REPLICATION SOURCE TO MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=619
......

 

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

 

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

# mysql -uroot -p < mysqldumpfile.sql

 

 

▶ 마스터와 슬레이브 연결

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

mysql 5.7
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 8.0
GET_SOURCE_PUBLIC_KEY파라미터를 이용해서 소스 서버에 있는 공개키를 이용, 복제를 구성합니다.
CHANGE REPLICATION SOURCE TO SOURCE_HOST = '192.168.0.100', SOURCE_PORT = 3306, SOURCE_USER = 'repl', SOURCE_PASSWORD = 'replpass', SOURCE_LOG_FILE='mysql-bin.000002', SOURCE_LOG_POS=619, GET_SOURCE_PUBLIC_KEY=1;

 

 

복제 설정 상태 확인.

mysql> SHOW SLAVE STATUS\G;

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

MySQL 5.7
mysql> SHOW SLAVE STATUS\G;
Slave_IO_Running: NO
Slave_SQL_Running: NO

MySQL 8.0
mysql> SHOW REPLICA STATUS\G;
Replica_IO_Running: NO
Replica_SQL_Running: NO

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

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

MySQL 5.7
mysql> start slave;

MySQL 8.0
mysql> start replica;

 

다시한번 확인해봅니다.

 

MySQL 5.7
mysql > show slave status\G;
......
Slave_IO_Running: YES
Slave_SQL_Running: YES
......

MySQL 8.0
mysql > show replica status\G;
......
Replica_IO_Running: Yes
Replica_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 5.7
mysql> STOP SLAVE;

MySQL 8.0
mysql> STOP REPLICA;

 

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

MySQL 5.7
mysql> STOP SLAVE IO_THREAD;
mysql> STOP SLAVE SQL_THREAD;

MySQL 8.0
mysql> STOP REPLICA IO_THREAD;
mysql> STOP REPLICA SQL_THREAD;

 

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

MySQL 5.7
mysql> START SLAVE;

MySQL 8.0
mysql> START REPLICA;

 

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

MySQL 5.7
mysql> START SLAVE IO_THREAD;
mysql> START SLAVE SQL_THREAD;

MySQL 8.0
mysql> STOP REPLICA IO_THREAD;
mysql> STOP REPLICA 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 특징

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

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

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

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

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

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

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

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

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

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

 

 

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