MySQL5.6 Replication 구현에 대한 자세한 내용

17.2.1 Replication 구현에 대한 자세한 내용

MySQL 복제 기능은 3 개의 스레드 (마스터 서버에서 하나 슬레이브에서 두)를 사용하여 구현됩니다.

Binlog 덤프 스레드 마스터는 슬레이브가 연결되었을 때 바이너리 로그 내용을 슬레이브에 전송하는 스레드를 만듭니다. 이 스레드는 마스터에서 SHOW PROCESSLIST 의 출력에서 Binlog Dump 스레드로 확인할 수 있습니다.

바이너리 로그 덤프 스레드가 슬레이브에 전송되는 각 이벤트를 읽기 위해 마스터의 바이너리 로그에서 잠금을 획득합니다. 이벤트를 읽 자마자 잠금이 해제됩니다 (이벤트가 슬레이브에 전송되기 전에라도).
슬레이브 I / O 스레드 START SLAVE 명령문이 슬레이브 서버에서 실행되면 슬레이브는 I / O 스레드를 만들고 이것이 마스터에 연결되어 그 바이너리 로그에 기록 된 업데이트를 보낼 것을 요청합니다 .

슬레이브 I / O 쓰레드는 마스터의 Binlog Dump 스레드가 보내는 업데이트를 읽고 (이전 항목 참조) 그들을 슬레이브 릴레이 로그로 구성된 로컬 파일에 복사합니다.

이 스레드의 상태는 SHOW SLAVE STATUS 의 출력은 Slave_IO_running 으로 SHOW STATUS 출력은 Slave_running 로 표시됩니다.
슬레이브 SQL 쓰레드 슬레이브는 슬레이브 I / O thread에 의해 기록 된 릴레이 로그를 읽고 그에 포함 된 이벤트를 실행하는 SQL 스레드를 만듭니다.

마스터 / 슬레이브 연결마다 3 개의 슬레이브가 있다는 것을 이미 설명했습니다. 복수의 슬레이브를 가진 마스터는 현재 접속되어있는 슬레이브 당 하나의 바이너리 로그 덤프 스레드를 생성하고 슬레이브마다 고유의 I / O 및 SQL 스레드가 있습니다.

슬레이브는 2 개의 스레드를 사용하여 마스터에서 업데이트를 읽을 수와 그들을 수행하는 것이 독립 작업으로 분류합니다. 이렇게해도 문 실행이 느린 경우에도 문을 읽을 작업이 느려질 수는 없습니다. 예를 들어, 슬레이브 서버가 잠시 동안 실행되지 않은 경우 I / O 스레드가 슬레이브 시작할 때 마스터에서 모든 바이너리 로그 내용을 빠르게 가져올 수 있습니다 (SQL thread가 꽤 늦어 있어도). SQL 쓰레드가 모든 가져 오기 명령문의 실행을 완료하기 전에 슬레이브가 정지 한 경우에도 I / O 스레드는 적어도 모든 것을 가져옵니다 때문에 문의 안전한 복사본을 슬레이브 릴레이 로그에 로컬로 저장되어 있고, 다음 슬레이브가 시작할 때 실행할 수있는 상태입니다. 따라서 마스터 서버는 바이너리 로그를 즉시 제거 할 수 있습니다 (슬레이브가 그 내용을 가져 오는 것을 더 이상 기다릴 필요가 없기 때문에).

SHOW PROCESSLIST 명령문은 복제에 대해 마스터 및 슬레이브에서 무슨 일이 일어나고 있는지를 전하는 정보를 제공합니다. 마스터 상태 내용은 섹션 8.12.5.5 「복제 마스터 스레드 상태 " 를 참조하십시오. 노예 상태에 대해서는 섹션 8.12.5.6 "리플리케이션 슬레이브 I / O 쓰레드 상태" 및 섹션 8.12.5.7 "리플리케이션 슬레이브 SQL 쓰레드 상태" 를 참조하십시오.

다음 예에서는 3 개의 스레드가 SHOW PROCESSLIST 의 출력에 어떻게 나타나는지를 보여줍니다.

마스터 서버에서 SHOW PROCESSLIST 의 출력은 다음과 같이됩니다.

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
     Id: 2
   User: root
   Host: localhost:32931
     db: NULL
Command: Binlog Dump
   Time: 94
  State: Has sent all binlog to slave; waiting for binlog to
         be updated
   Info: NULL

여기서 스레드 2는 연결된 슬레이브에 서비스를 제공하는 Binlog Dump 복제 스레드입니다. State 정보는 모든 처리되지 않은 업데이트가 슬레이브에 전송되며 마스터는 후속 업데이트의 발생을 대기하고있는 것을 보여줍니다. 마스터 서버에서 Binlog Dump 쓰레드가 보이지 않을 경우, 이것은 복제가 실행되고 있지 않은, 즉 현재 슬레이브가 연결되어 있지 않다는 것을 의미합니다.

슬레이브 서버에서 SHOW PROCESSLIST 의 출력은 다음과 같이됩니다.

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
     Id: 10
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 11
  State: Waiting for master to send event
   Info: NULL
*************************** 2. row ***************************
     Id: 11
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 11
  State: Has read all relay log; waiting for the slave I/O
         thread to update it
   Info: NULL

State 정보는 스레드 10이 마스터 서버와 통신하는 I / O 스레드, 11가 릴레이 로그에 포함 된 업데이트를 처리하는 SQL 스레드임을 보여줍니다. SHOW PROCESSLIST 가 실행 된 시점에서 두 스레드는 유휴 후속 업데이트를 대기 중이었습니다.

Time 컬럼의 값은 마스터와 비교하여 슬레이브가 얼마나 뒤쳐 졌는지를 나타낼 수 있습니다. 섹션 A.13 "MySQL 5.6 FAQ : 복제" 를 참조하십시오. 마스터 측에서 Binlog Dump 스레드의 활동이없는 상태에서 충분한 시간이 경과 한 경우 마스터는 슬레이브가 이미 연결되어 있지 않다고 판단합니다. 다른 클라이언트 연결에 대해이 시간 제한은 net_write_timeout 및 net_retry_count 의 값에 따라 다릅니다. 이러한 자세한 내용은 섹션 5.1.4 "서버 시스템 변수" 를 참조하십시오.

SHOW SLAVE STATUS 문은 슬레이브 서버에서 복제 작업에 대한 추가 정보를 제공합니다. 섹션 17.1.5.1 "복제 상태 확인" 을 참조하십시오.