16.2.1. Детали Реализации репликации

Возможности репликации MySQL реализуются, используя три потока, один на главном сервере и два на ведомом устройстве:

Binlog выводят поток. Ведущее устройство создает поток, чтобы отправить двоичное содержание журнала ведомому устройству, когда ведомое устройство соединяется. Этот поток может быть идентифицирован в выводе SHOW PROCESSLIST на ведущем устройстве как Binlog Dump поток.

Поток дампа binlog получает блокировку на двоичном журнале ведущего устройства для того, чтобы считать каждое событие, которое должно быть отправлено ведомому устройству. Как только событие было считано, блокировка выпускается, даже прежде, чем событие отправляется ведомому устройству.
Ведомый поток ввода-вывода. Когда a START SLAVE заявление делается на ведомом сервере, ведомое устройство создает поток ввода-вывода, который соединяется с ведущим устройством и просит, чтобы это отправило обновления, записанные в его двоичных журналах.

Ведомый поток ввода-вывода читает обновления что ведущее устройство Binlog Dump поток передается (см. предыдущий элемент), и копирует их в локальные файлы, которые включают релейный журнал ведомого устройства.

Состояние этого потока показывают как Slave_IO_running в выводе SHOW SLAVE STATUS или как Slave_running в выводе SHOW STATUS.
Ведомый поток SQL. Ведомое устройство создает поток SQL, чтобы считать релейный журнал, который пишется ведомым вводом-выводом, распараллеливают и выполняют события, содержавшие там.

В предыдущем описании есть три потока на основное/ведомое соединение. Ведущее устройство, у которого есть многократные ведомые устройства, создает один поток дампа binlog для каждого в настоящий момент соединенного ведомого устройства, и у каждого ведомого устройства есть свой собственный ввод-вывод и потоки SQL.

Ведомое устройство использует два потока, чтобы разделить обновления чтения от ведущего устройства и выполнение их в независимые задачи. Таким образом задача чтения операторов не замедляется, если выполнение оператора медленное. Например, если ведомый сервер не работал некоторое время, его поток ввода-вывода может быстро выбрать все двоичное содержание журнала от ведущего устройства, когда ведомое устройство запускается, даже если поток SQL отстает далеко позади. Если ведомое устройство останавливается прежде, чем поток SQL выполнил все выбранные операторы, поток ввода-вывода, по крайней мере, выбрал все так, чтобы безопасная копия операторов была сохранена локально в релейных журналах ведомого устройства, готовых к выполнению в следующий раз, когда ведомое устройство запускается. Это позволяет главному серверу произвести чистку своих двоичных журналов скорее, потому что он больше не должен ожидать ведомого устройства, чтобы выбрать их содержание.

SHOW PROCESSLIST оператор предоставляет информацию, которая говорит Вам, что происходит на ведущем устройстве и на ведомом устройстве относительно репликации. Для получения информации об основных состояниях см. Раздел 8.12.5.4, "Ведущие государства Потока Репликации". Для рабовладельческих штатов см. Раздел 8.12.5.5, "Ведомые государства Потока ввода-вывода Репликации", и Раздел 8.12.5.6, "Ведомые государства Потока SQL Репликации".

Следующий пример иллюстрирует, как три потока обнаруживаются в выводе от SHOW PROCESSLIST.

На главном сервере, выводе от SHOW PROCESSLIST похож на это:

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

Здесь, распараллельте 2, a Binlog Dump поток репликации, который обслуживает соединенное ведомое устройство. State информация указывает, что все выдающиеся обновления были отправлены ведомому устройству и что ведущее устройство ожидает большего количества обновлений, чтобы произойти. Если Вы видите нет Binlog Dump потоки на главном сервере, это означает, что репликация не работает; то есть, никакие ведомые устройства в настоящий момент не соединяются.

На ведомом сервере, выводе от SHOW PROCESSLIST похож на это:

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

State информация указывает, что распараллеливают 10, поток ввода-вывода, который связывается с главным сервером, и поток 11 является потоком SQL, который обрабатывает обновления, сохраненные в релейных журналах. В то время, когда SHOW PROCESSLIST был выполнен, оба потока были неактивны, ожидая дальнейших обновлений.

Значение в Time столбец может показать, как поздно ведомое устройство по сравнению с ведущим устройством. См. Раздел B.13, "FAQ MySQL 5.7: Репликация". Если достаточное количество времени протекает на основной стороне без действия на Binlog Dump поток, ведущее устройство решает, что ведомое устройство больше не соединяется. Что касается любого другого клиентского соединения, тайм-ауты для этого зависят от значений net_write_timeout и net_retry_count; для получения дополнительной информации о них, см. Раздел 5.1.4, "Системные Переменные Сервера".

SHOW SLAVE STATUS оператор обеспечивает дополнительную информацию об обработке репликации на ведомом сервере. См. Раздел 16.1.5.1, "Проверяя Состояние Репликации".