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

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] 복제소개 및 사용방법

 

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

MySQL은 여러형태의 복제 솔루션과 HA, 분산기능, 그리고 클러스터링을 지원합니다. Master-Slave구조 + MHA, Multi Master for MySQL, Galera Cluster, MaxScale(MariaDB), Sharding등 참 많은 기능들을 제공한다..

myinfrabox.tistory.com

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

 

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

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

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

 

Designed by JB FACTORY