[MySQL][Master-Slave] 복제 환경 모니터링
- Databases/MySQL
- 2020. 3. 20.
Replication 상태에서 모니터링을 하는 방법에 대해 알아봅니다. 모니터링에서 표시해주는 상태에 따라 그에 맞는 대처를 해서 복제가 지속적으로 이루어 지도록 합니다.
■ Slave 상태 확인
mysql 클라이언트에서 다음의 명령을 입력합니다.
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.30.224.100
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 619
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 619
Relay_Log_Space: 528
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 68e4c109-5b08-11ea-8016-001c423121a9
Master_Info_File: /usr/local/mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
출력되는 주요필드의 의미는 다음과 같습니다.
▶ Slave_IO_State: 슬레이브의 현재 상태입니다. 만약 문제가 생기면 에러가 표시됩니다.
▶ Slave_IO_Running: 마스터 바이너리 로그를 읽기위한 I / O 스레드가 실행 중인지 여부를 나타냅니다. 일반적으로 Yes로 표시되며 아직 복제를 시작하지 않았거나로 명시 적으로 복제를 중지(STOP SLAVE)한경우 NO로 표시됩니다.
▶ Slave_SQL_Running: 릴레이 로그에서 이벤트를 실행하기위한 SQL 스레드가 실행 중인지 여부를 나타냅니다. I/O 스레드와 마찬가지로 이것은 보통이어야 Yes로 표시됩니다. NO로 표시될 경우 로그상태나 복제 상태를 확인해봐야 합니다.
▶ Last_IO_Error, Last_SQL_Error: 릴레이 로그를 처리 할 때 I/O 및 SQL 스레드에 의해 등록 된 마지막 오류를 표시합니다. 가장 좋은건 오류가 표시되지 않는 것이지만 만약 자주 같은 오류가 반복된다면 버그나 데이터 중복 복제등 이유를 분석해봐야 합니다.
▶ Seconds_Behind_Master: 슬레이브 SQL 스레드가 마스터 바이너리 로그를 처리하는 시간 (초)입니다. 높은 숫자 (또는 증가하는 숫자)는 마스터가 이벤트를 잘 처리하지 못함을 나타내며 그 이유를 분석해봐야 합니다. 순간적인 데이터 로드가 많거나 아니면 성능상에 문제는 없는지 확인해 보아야 합니다.
또한 값 0에 대한 Seconds_Behind_Master 은 일반적으로 슬레이브가 마스터를 따라 잡았다는 의미로 해석 될 수 있지만, 이것이 사실이 아닌 경우가 있습니다. 예를 들어, 마스터와 슬레이브 간의 네트워크 연결이 끊어졌지만 슬레이브 I/O 스레드가 아직 이를 인식하지 못했거나 slave_net_timeout 값이 아직 경과하지 않은 경우에 발생할 수 있습니다 .
Seconds_Behind_Master에 대한 과도한 값이 상황을 정확하게 반영하지 않을 수도 있습니다. 슬레이브 SQL 스레드가 I/O에 걸리면 Seconds_Behind_Master는 0을 표시합니다. 그러나 슬레이브 I/O 스레드가 여전히 새 이벤트를 대기중인 경우, Seconds_Behind_Master는 SQL 스레드가 새 이벤트 실행을 완료 할 때까지 큰 값을 표시 할 수 있습니다. 이벤트에 오래된 타임 스탬프가있는 경우 특히 그렇습니다. 이러한 경우 SHOW SLAVE STATUS명령을 비교적 짧은 기간에 여러 번 실행 하면, 이 값이 0과 비교적 큰 값 사이에서 반복해서 앞뒤로 변경되는 것을 볼 수 있습니다.
▶ Master_Log_file, Read_Master_Log_Pos : 슬레이브 I / O 스레드가 해당 로그에서 이벤트를 읽은 포지션(위치)을 나타내는 마스터 바이너리 로그의 좌표입니다.
▶ Relay_Master_Log_File, Exec_Master_Log_Pos : 마스터 바이너리 로그의 좌표로 슬레이브 SQL 스레드가 해당 로그에서받은 이벤트를 얼마나 멀리 실행했는지 나타냅니다.
▶ Relay_Log_File, Relay_Log_Pos) : 슬레이브 SQL 스레드가 릴레이 로그를 실행 한 거리를 나타내는 슬레이브 릴레이 로그의 좌표입니다. 이들은 이전 좌표에 해당하지만 마스터 바이너리 로그 좌표가 아닌 슬레이브 릴레이 로그 좌표로 표시됩니다.
■ 서버 상태 확인
▶ master 서버 상태 확인
마스터에서 SHOW PROCESSLIST명령어로 실행중인 프로세스 목록을 검사하는데 이때 연결된 슬레이브의 상태를 확인할 수 있습니다. 슬레이브 연결은 Command 필드란의 Binlog Dump입니다.
mysql> SHOW PROCESSLIST \G;
*************************** 2. row ***************************
Id: 7
User: repl
Host: slave_server:37496
db: NULL
Command: Binlog Dump
Time: 534
State: Master has sent all binlog to slave; waiting for more updates
Info: NULL
복제 프로세스를 주도하는 것은 슬레이브입니다. 그래서 마스터 서버에서 볼 수 있는 정보는 거의 없다고 보시면 됩니다.
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 | 619 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
사용중인 로그 파일 이름과 로그 포지션만 표시가 됩니다. 복제에 참여하는 정보는 없습니다.
--report-host옵션 으로 시작 하여 마스터에 연결된 슬레이브의 경우 마스터의 SHOW SLAVE HOSTS명령문에 슬레이브에 대한 기본 정보가 표시됩니다. 출력에는 슬레이브 서버의 ID, --report-host옵션 값 , 연결 포트 및 마스터 ID가 포함됩니다.
mysql> SHOW SLAVE HOSTS;
+-----------+------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID |
+-----------+------+------+-----------+--------------------------------------+
| 2 | | 3306 | 1 | 269e1843-3551-11ea-be70-001c426db796 |
+-----------+------+------+-----------+--------------------------------------+
1 row in set (0.00 sec)
▶ Slave 서버 상태 확인
mysql> SHOW PROCESSLIST\G;
*************************** 2. row ***************************
Id: 11
User: system user
Host:
db: NULL
Command: Connect
Time: 296
State: Waiting for master to send event
Info: NULL
*************************** 3. row ***************************
Id: 12
User: system user
Host:
db: NULL
Command: Connect
Time: 0
State: Reading event from the relay log
Info: NULL
3 rows in set (0.01 sec)
위에서는 쓰레드 10이 마스터 서버와 통신을 하는 I/O 쓰레드이고, 쓰레드 11은 릴레이 로그에 저장되어 있는 업데이트 사항을 실행하는 SQL 쓰레드라는 것을 알려 줍니다. SHOW PROCESSLIST 가 실행 되었을 때에는 양쪽 쓰레드 모두 아이들 (idle) 상태였으며, 또 다른 업데이트를 기다리고 있는 중입니다. Time 컬럼에 있는 값은 슬레이브가 마스터와 비교해서 얼마나 늦는지를 알려주는 것입니다.
▶ 바이너리 로그 모니터링
data 디렉토리에 보면 로그파일이름.index 라는 파일이 있습니다. 이 블로그의 매뉴얼대로 설정했다면 mysql-bin.index일 것입니다. 슬레이브는 relay-bin.index입니다. 이 파일을 확인해 마스터에서는 어떤 로그들을 작성하고 있는지 확인이 되고 슬레이브에서는 어떤 릴레이 로그가 현제 서버에 적용중인지 확인할 수 있습니다. 이 파일을 통해서 어느정도 복제가 지연되고 있는지 혹은 어디까지 복제가 되고 있는지 확인할 수 있습니다.
■ 서버 쓰레드 상태 확인
아래의 리스트는 마스터 서버의 Binlog Dump 쓰레드에 대해 State 컬럼에서 자주 볼 수 있는 상태들입니다. 마스터 서버에서 Binlog Dump 쓰레드를 볼 수 없다면, 리플리케이션이 구동 되지 않은 것이며 이말은 어떠한 슬레이브도 연결되어 있지 않다는 얘기가 됩니다. 복제 구성 상태를 확인해봐야 할수 있습니다.
▶ 마스터 스레드 상태
+ Sending binlog event to slave
바이너리 로그는 이벤트 (events)로 구성이 되며, 일반적으로 하나의 이벤트는 여러 개의 정보를 가지고 있는 하나의 업데이트 항목이 됩니다. 쓰레드는 바이너리 로그에서 이벤트를 읽었으며 이제 이것을 슬레이브에 전달합니다.
+ Finished reading one binlog; switching to next binlog
쓰레드는 바이너리 로그를 읽는 것을 마쳤으며, 슬레이브에 보낼 바로 다음 이벤트를 열고 있습니다.
+ Has sent all binlog to slave; waiting for binlog to be updated
쓰레드는 모든 업데이트 항목을 바이너리 로그에서 읽었으며 그것들을 슬레이브에 전달했음을 나타냅니다. 쓰레드는 현재 아이들 (idle)상태이며, 마스터에서 새로운 업데이트가 발생해서 바이너리 로그에 새로운 이벤트가 나타나기를 기다리고 있는 상태입니다.
+ Waiting to finalize termination
쓰레드가 종료했을 때 매우 짧게 나타나는 상태입니다.
▶ 슬레이브 I/O 쓰레드 상태
아래의 리스트는 슬레이브 서버의 I/O 쓰레드에 대해 State 컬럼에서 볼 수 있는 가장 일반적인 상태를 설명하는 것입니다. 이 상태는 SHOW SLAVE STATUS를 통해서 볼 수 있는 Slave_IO_State 컬럼에서도 나타날 수 있습니다. 따라서 이 명령문을 사용하면, 슬레이브에 어떤 일이 일어났는지에 대해서 정보를 얻게 됩니다.
+ Connecting to master
쓰레드는 마스터에 접속을 시도하고 있습니다.
+ Checking master version
마스터에 접속이 된 후에 매우 짧게 나타나는 상태입니다.
+ Registering slave on master
마스터에 접속이 된 후에 매우 짧게 나타나는 상태입니다.
+ Requesting binlog dump
마스터에 접속이 된 후에 매우 짧게 나타나는 상태. 쓰레드는 바이너리 로그 파일 이름과 위치를 가지고, 바이너리 로그 내용에 대한 요청을 마스터에 보냅니다.
+ Waiting to reconnect after a failed binlog dump request
바이너리 로그 덤프가 실패할 경우 (접속 불가로 인해), 쓰레드는 곧장 이 상태가 되며, 그 다음에는 주기적으로 재 접속을 시도하게 됩니다. 재시도 간격은 --master-connect-retry 옵션을 가지고 지정할 수가 있습니다.
+ Reconnecting after a failed binlog dump request
쓰레드는 마스터에 재 접속을 시도합니다.
+ Waiting for master to send event
쓰레드는 마스터에 접속이 되었고 바이너리 로그 이벤트가 도착 하기를 기다리고 있습니다. 마스터가ave_read_timeout 시간 동안 대기를 하게 되면, 시간 초과 (timeout)가 발생합니다. 이렇게 되면, 쓰레드는 마스터와의 연결이 단절되었다고 생각을 하고 재 접속을 시도합니다.
+ Queueing master event to the relay log
쓰레드는 이벤트를 읽었고 이것을 릴레이 로그에 복사를 해서 SQL 쓰레드가 이 이벤트를 처리하게끔 합니다.
+ Waiting to reconnect after a failed master event read
이벤트를 읽는 도중에 에러(접속 단절로 인해)가 발생했다는 에러문입니다. 쓰레드는 재 접속을 시도하기 전에 master-connect-retry 시간 동안 대기(sleeping)를 해야 합니다.
+ Reconnecting after a failed master event read
쓰레드는 마스터에 재 접속을 시도합니다. 접속이 다시 이루어지면, 상태는 Waiting for master to send event가 됩니다.
+ Waiting for the slave SQL thread to free enough relay log space
0(zero)이 아닌 relay_log_space_limit 값을 사용하는 중이며, 릴레이 로그의 크기는 이 값을 초과할 만큼 충분이 커져 있는것을 나타냅니다. I/O 쓰레드는 SQL 쓰레드가 릴레이 로그 파일 중에 일부를 삭제해서 충분한 공간을 확보하지 않으면 계속 대기를 합니다.
+ Waiting for slave mutex on exit
쓰레드가 멈추었을 때 매우 짧게 발생하는 상태입니다.
▶ 리플리케이션 슬레이브 SQL 쓰레드 상태
아래의 리스트는 State 컬럼에서 가장 일반적으로 볼 수 있는 슬레이브 서버 SQL 쓰레드 상태를 나타낸 것입니다:
+ Reading event from the relay log
쓰레드는 릴레이 로그에서 이벤트를 하나 읽었으며 이것을 처리할 수가 있습니다.
+ Has read all relay log; waiting for the slave I/O thread to update it
쓰레드는 릴레이 로그 파일에 있는 모든 이벤트를 처리하였고, I/O쓰레드가 새로운 이벤트를 릴레이 로그에 작성하기를 기다리고 있습니다.
+ Waiting for slave mutex on exit
쓰레드가 멈추었을 때 매우 짧게 나타나는 상태입니다.
I/O 쓰레드용 State 컬럼은 명령문 문장도 함께 보여 준다. 이것은 쓰레드가 릴레이 로그로부터 하나의 이벤트를 읽었으며, 거기에서 명령문을 추출했고, 추출한 명령문을 실행했다는 것을 가리킨다.
▶ 리플리케이션 릴레이 및 상태 파일-진행중
릴레이 로그 파일 이름은 host_name-relay-bin.nnnnnn형식을 디폴트로 가지며, 여기에서 host_name 는 슬레이브 서버 이름이 되고, nnnnnn 은 시퀀스 번호가 됩니다. 000001으로 시작하는 연속적인 시퀀스 번호를 사용해서 연속적인 릴레이 로그 파일들이 생성됩니다. 슬레이브는 현재 사용 중에 있는 릴레이 로그 파일을 추적하기 위해 하나의 인덱스를 사용합니다. 디폴트 릴레이 로그 인덱스 파일 이름은 host_name-relay-bin.index입니다. 디폴트로는, 슬레이브 서버는 자신의 데이터 디렉토리에 릴레이 파일을 생성하게 됩니다. 디폴트 파일 이름은 --relay-log 와 --relay-log-index 서버 옵션을 가지고 덮어 쓸 수가 있습니다.
릴레이 로그는 바이너리 로그와 동일한 포맷을 사용하기 때문에 mysqlbinlog를 사용해서 읽을 수가 있습니다. SQL 쓰레드는 릴레이 로그 파일 안에 있는 모든 이벤트들이 처리가 되고 더 이상 그 파일이 필요가 없게 되면 자동으로 즉시 각 릴레이 로그 파일을 삭제합니다. SQL 쓰레드는 이러한 삭제 동작을 매우 조심스럽게 진행하는데 반해, 릴레이 로그 파일을 삭제하는 데에는 명백한 메커니즘이 존재하지 않습니다. 하지만, FLUSH LOGS 는 릴레이 로그를 로테이트 (rotate) 시키며, 이것은 SQL 쓰레드가 이 파일들을 삭제하는 시기에 영향을 미치게 됩니다.
슬레이브 서버는 아래의 조건 아래에서 새로운 릴레이 로그 파일을 생성합니다.
- I/O 쓰레드가 매번 시작될 때.
- 로그가 플러시 될 때; 예를 들면, FLUSH LOGS 또는 mysqladmin flush-logs가 실행될 때.
현재 로그 파일의 크기가 너무 커질 때. “너무 크다 (too large)” 의 의미는 아래와 같이 판됩니다.
- 만일 max_relay_log_size의 값이 0보다 크면, 그 값이 릴레이 로그 파일의 최대 크기가 됩니다.
- 만일 max_relay_log_size의 값이 0이면, max_binlog_size가 릴레이 로그 파일의 최대 크기가 됩니다.
슬레이브 리플리케이션 서버는 데이터 디렉토리에 두 개의 작은 파일을 추가로 생성을 합니다. 이 상태 파일들은 디폴트로 master.info 및 relay-log.info라는 이름으로 생성됩니다. 이 파일들의 이름은 --master-info-file와 --relay-log-info-file 옵션으로 바꿀 수가 있습니다.
두 상태 파일들은 SHOW SLAVE STATUS 명령문 결과에서 볼 수 있는 정보를 가지고 있습니다. 상태 파일들은 디스크에 저장이 되기 때문에, 슬레이브 서버가 셧 다운 되더라도 계속 존재를 하게 됩니다. 슬레이브가 시작되는 다음 시점에, 슬레이브 서버는 마스터에서 바이너리 로그를 어디까지 읽었는지 그리고 자신의 릴레이 로그가 어디까지 진행 되었는지를 알아보기 위해 이 파일들을 읽게 됩니다.
슬레이브 I / O 스레드는 마스터 정보 로그를 업데이트합니다. 다음 표는 master.info 파일의 행, mysql.slave_master_info 테이블의 열 및 SHOW SLAVE STATUS에 의해 표시되는 열 간의 대응 관계를 보여줍니다.
master.info File Line |
slave_master_info Table Column | SHOW SLAVE STATUS Column | Description |
1 | Number_of_lines | [None] | 파일의 행 수 또는 테이블의 열 |
2 | Master_log_name | Master_Log_File | 현재 마스터에서 읽은 마스터 바이너리 로그의 이름 |
3 | Master_log_pos | Read_Master_Log_Pos | 마스터 바이너리 로그 내에서 마스터에서 읽은 현재 위치 |
4 | Host | Master_Host | 마스터의 호스트 이름 |
5 | User_name | Master_User | 마스터에 연결하는 데 사용되는 사용자 이름 |
6 | User_password | Password (not shown by SHOW SLAVE STATUS) |
마스터에 연결하는 데 사용되는 비밀번호 |
7 | Port | Master_Port | 마스터에 연결하는 데 사용되는 네트워크 포트 |
8 | Connect_retry | Connect_Retry | 슬레이브가 마스터에 다시 연결하기 전에 대기하는 시간(초) |
9 | Enabled_ssl | Master_SSL_Allowed | 서버가 SSL 연결을 지원하는지 여부를 나타냅니다. |
10 | Ssl_ca | Master_SSL_CA_File | 인증 기관 (CA) 인증서에 사용되는 파일 |
11 | Ssl_capath | Master_SSL_CA_Path | 인증 기관 (CA) 인증서의 경로 |
12 | Ssl_cert | Master_SSL_Cert | SSL 인증서 파일의 이름 |
13 | Ssl_cipher | Master_SSL_Cipher | SSL 연결을위한 핸드 셰이크에 사용 가능한 암호 목록 |
14 | Ssl_key | Master_SSL_Key | SSL key파일의 이름 |
15 | Ssl_verify_server_cert | Master_SSL_Verify_Server_Cert | 서버 인증서를 확인할지 여부 |
16 | Heartbeat | [None] | 복제 하트 비트 간격 (초) |
17 | Bind | Master_Bind | 마스터에 연결하기 위해 사용해야하는 슬레이브의 네트워크 인터페이스 |
18 | Ignored_server_ids | Replicate_Ignore_Server_Ids | 무시할 서버 ID 목록입니다. "Ignored_server_ids"의 경우 서버 ID 목록 앞에는 무시할 총 서버 ID 수가 있습니다. |
19 | Uuid | Master_UUID | 마스터의 unique ID |
20 | Retry_count | Master_Retry_Count | 허용되는 최대 재 연결 시도 횟수 |
21 | Ssl_crl | [None] | SSL 인증서 해지 목록 파일의 경로 |
22 | Ssl_crlpath | [None] | SSL 인증서 해지 목록 파일이 포함 된 디렉토리의 경로 |
23 | Enabled_auto_position | Auto_position | 자동 위치 조정이 사용 중인지 여부 |
24 | Channel_name | Channel_name | 복제 채널의 이름 |
25 | Tls_version | Master_TLS_Version | 마스터 TLS 버전 |
슬레이브 SQL 스레드는 릴레이 로그 정보 로그를 업데이트합니다. relay-log.info 파일에는 줄 수 및 복제 지연 값이 포함됩니다. 다음 표는 relay-log.info 파일의 행, mysql.slave_relay_log_info 테이블의 열 및 SHOW SLAVE STATUS에 의해 표시되는 열 간의 대응 관계를 보여줍니다.
Line in relay-log.info | slave_relay_log_info Table Column |
SHOW SLAVE STATUS Column | Description |
1 | Number_of_lines | [None] | 파일의 행 수 또는 테이블의 열 |
2 | Relay_log_name | Relay_Log_File | 현재 릴레이 로그 파일의 이름 |
3 | Relay_log_pos | Relay_Log_Pos | 릴레이 로그 파일 내의 현재 위치. 이 위치까지의 이벤트가 슬레이브 데이터베이스에서 실행되었습니다 |
4 | Master_log_name | Relay_Master_Log_File | 릴레이 로그 파일의 이벤트를 읽은 마스터 바이너리 로그 파일의 이름 |
5 | Master_log_pos | Exec_Master_Log_Pos | 이미 실행 된 이벤트의 마스터 바이너리 로그 파일 내에서 동등한 위치 |
6 | Sql_delay | SQL_Delay | 슬레이브가 마스터를 지연시켜야하는 시간 (초) |
7 | Number_of_workers | [None] | 병렬로 복제 이벤트 (트랜잭션)를 실행하기위한 슬레이브 작업자 스레드 수 |
8 | Id | [None] | 내부 목적으로 사용되는 ID. 현재 이것은 항상 1입니다 |
9 | Channel_name | Channel_name | 복제 채널의 이름 |
MySQL 5.6 이전의 MySQL 버전에서는 relay-log.info 파일에 줄 수 또는 지연 값이 포함되어 있지 않으며 slave_relay_log_info 테이블을 사용할 수 없습니다.
Line | Status Column | Description |
1 | Relay_Log_File | 현재 릴레이 로그 파일의 이름 |
2 | Relay_Log_Pos | 릴레이 로그 파일 내의 현재 위치. 이 위치까지의 이벤트가 슬레이브 데이터베이스에서 실행되었습니다 |
3 | Relay_Master_Log_File | 릴레이 로그 파일의 이벤트를 읽은 마스터 바이너리 로그 파일의 이름 |
4 | Exec_Master_Log_Pos | 이미 실행 된 이벤트의 마스터 바이너리 로그 파일 내에서 동등한 위치 |
relay-log.info 파일이 디스크로 플러시되지 않은 경우 relay-log.info 파일의 내용과 SHOW SLAVE STATUS 문으로 표시되는 상태가 일치하지 않을 수 있습니다. 이상적으로는 오프라인 상태인(즉, mysqld가 실행되고 있지 않은)슬레이브에서만 relay-log.info를 보아야합니다. 실행중인 시스템의 경우 SHOW SLAVE STATUS를 사용하거나 상태 로그를 테이블에 쓰는 경우 slave_master_info 및 slave_relay_log_info 테이블을 쿼리 할 수 있습니다.
슬레이브 데이터를 백업 할 때는 릴레이 로그 파일과 함께이 두 가지 상태 로그를 백업해야 합니다. 슬레이브에서 데이터를 복원 한 후 복제를 재개하려면 상태 로그가 필요합니다. 릴레이 로그를 잃게되도 여전히 릴레이 로그 정보 로그가 있는 경우 마스터 바이너리 로그에서 SQL 스레드가 얼마나 많이 실행되었는지 확인할 수 있습니다. 그런 다음 MASTER_LOG_FILE 및 MASTER_LOG_POS 옵션과 함께 CHANGE MASTER TO를 사용하여 슬레이브가 해당 지점에서 바이너리 로그를 다시 읽도록 할 수 있습니다. 물론 바이너리 로그가 여전히 마스터에 있어야합니다.
■ Master-Slave 복제 환경 관련 참고글
[Master-Slave] 복제소개 및 사용방법
[Master-Slave] 복제환경에서의 바이너리 로그 특징
[Master-Slave] 복제 필터링 - 복제평가방법
[Master-Slave] 복제 필터링 - 명령문 및 적용방법
[Master-Slave] GTID를 이용한 복제 - 이론
[Master-Slave] GTID를 이용한 복제 - 구성방법
'Databases > MySQL' 카테고리의 다른 글
[MySQL][Master-Slave] 복제 필터링 - 명령문 및 적용방법 (0) | 2020.03.28 |
---|---|
[MySQL][Master-Slave] 복제 필터링 - 복제평가방법 (0) | 2020.03.28 |
[MySQL][Master-Slave] 복제 환경에서 Binary Log 특징 (0) | 2020.03.14 |
[MySQL][Master-Slave] 복제소개 및 사용방법 (1) | 2020.03.08 |
[MySQL][Admin] Binary 로그 소개 및 특징 (0) | 2020.03.01 |