16.1.5.1. Проверка Состояния Репликации

Наиболее распространенная задача, управляя процессом репликации состоит в том, чтобы гарантировать, что репликация имеет место и что не было никаких ошибок между ведомым устройством и ведущим устройством. Основной оператор для этого SHOW SLAVE STATUS, который следует выполнить на каждом ведомом устройстве:

mysql> SHOW SLAVE STATUS\G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: master1                  Master_User: root                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: mysql-bin.000004          Read_Master_Log_Pos: 931               Relay_Log_File: slave1-relay-bin.000056                Relay_Log_Pos: 950        Relay_Master_Log_File: mysql-bin.000004             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: 931              Relay_Log_Space: 1365              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: 0Master_SSL_Verify_Server_Cert: No                Last_IO_Errno: 0                Last_IO_Error:               Last_SQL_Errno: 0               Last_SQL_Error:  Replicate_Ignore_Server_Ids: 0

Поля ключа из отчета о состоянии исследовать:

Slave_IO_State: Текущий статус ведомого устройства. См. Раздел 8.12.5.5, "Ведомые государства Потока ввода-вывода Репликации", и Раздел 8.12.5.6, "Ведомые государства Потока SQL Репликации", для получения дополнительной информации.
Slave_IO_Running: Работает ли поток ввода-вывода для того, чтобы считать двоичный журнал ведущего устройства. Обычно, Вы хотите, чтобы это было Yes если Вы еще не запустили репликацию или явно остановили ее с STOP SLAVE.
Slave_SQL_Running: Работает ли поток SQL для того, чтобы выполнить события в релейном журнале. Как с потоком ввода-вывода, это должно обычно быть Yes.
Last_IO_Error, Last_SQL_Error: Последние ошибки, зарегистрированные вводом-выводом и SQL, распараллеливают, обрабатывая релейный журнал. Идеально они должны быть пробелом, не указывая ни на какие ошибки.
Seconds_Behind_Master: Число секунд, что ведомый поток SQL находится позади обработки основного двоичного журнала. Высокое число (или увеличивающийся) может указать, что ведомое устройство неспособно обработать события от ведущего устройства своевременно.

Значение 0 для Seconds_Behind_Master может обычно интерпретироваться как то, чтобы подразумевать, что ведомое устройство догнало ведущее устройство, но есть некоторые случаи, где это не строго истинно. Например, это может произойти, если сетевое соединение между ведущим устройством и ведомым устройством повреждается, но ведомый поток ввода-вывода еще не заметил это — то есть, slave_net_timeout еще не протек.

Это также возможно тот переходный процесс значения для Seconds_Behind_Master возможно, не отражает ситуацию точно. Когда ведомый поток SQL нагнал во вводе-выводе, Seconds_Behind_Master дисплеи 0; но когда ведомый поток ввода-вывода все еще стоит в очереди новое событие, Seconds_Behind_Master может показать большое значение, пока поток SQL не заканчивает выполнять новое событие. Это особенно вероятно, когда у событий есть старые метки времени; в таких случаях, если Вы выполняетесь SHOW SLAVE STATUS несколько раз за относительно короткий период, можно видеть, что это значение изменяется назад и вперед неоднократно между 0 и относительно большое значение.

Несколько пар полей предоставляют информацию о продвижении ведомого устройства в чтении событий от основного двоичного журнала и обработки их в релейном журнале:

(Master_Log_file, Read_Master_Log_Pos): Координаты в основном двоичном журнале, указывающем, как далеко ведомый поток ввода-вывода считал события из того журнала.
(Relay_Master_Log_File, Exec_Master_Log_Pos): Координаты в основном двоичном журнале, указывающем, как далеко ведомый поток SQL выполнил события, полученные от того журнала.
(Relay_Log_File, Relay_Log_Pos): Координаты в ведомом релейном журнале, указывающем, как далеко ведомый поток SQL выполнил релейный журнал. Они соответствуют предыдущим координатам, но выражаются в ведомых релейных координатах журнала, а не основных двоичных координатах журнала.

На ведущем устройстве можно проверить состояние соединенного ведомого использования SHOW PROCESSLIST исследовать список выполнения процессов. Ведомые соединения имеют Binlog Dump в Command поле:

mysql> SHOW PROCESSLIST \G;*************************** 4. row ***************************     Id: 10   User: root   Host: slave1:58371     db: NULLCommand: Binlog Dump   Time: 777  State: Has sent all binlog to slave; waiting for binlog to be updated   Info: NULL

Поскольку это - ведомое устройство, которое управляет процессом репликации, очень небольшая информация доступна в этом отчете.

Для ведомых устройств, которые были запущены с --report-host опция и соединяется с ведущим устройством, SHOW SLAVE HOSTS оператор на ведущем устройстве показывает основную информацию о ведомых устройствах. Вывод включает ID ведомого сервера, значение --report-host опция, соединяющийся порт, и основной ID:

mysql> SHOW SLAVE HOSTS;+-----------+--------+------+-------------------+-----------+| Server_id | Host   | Port | Rpl_recovery_rank | Master_id |+-----------+--------+------+-------------------+-----------+|        10 | slave1 | 3306 |                 0 |         1 |+-----------+--------+------+-------------------+-----------+1 row in set (0.00 sec)