16.1.7.1 Checking Replication Status — MySQL 5.7

16.1.7.1 Проверка статуса репликации

Наиболее распространённой задачей при управлении процессом репликации является обеспечение того, что репликация происходит и что между репликой и источником не возникло ошибок.

Команда SHOW SLAVE STATUS, которую необходимо выполнить на каждой реплике, предоставляет информацию о конфигурации и статусе подключения между сервером реплики и сервером источника. С MySQL 5.7 схема производительности содержит таблицы репликации, которые предоставляют эту информацию в более доступной форме. См. Раздел 25.12.11, «Таблицы репликации схемы производительности».

Команда SHOW STATUS также предоставляла некоторую информацию, относящуюся конкретно к репликам. Начиная с версии MySQL 5.7.5, следующие переменные состояния, ранее отслеживаемые с помощью SHOW STATUS, были устаревшими и перенесены в таблицы репликации схемы производительности:

Информация о сердцебиении репликации, показанная в таблицах репликации схемы производительности, позволяет проверять, что подключение репликации активно, даже если источник недавно не отправлял события реплике. Источник отправляет сигнал сердцебиения реплике, если в двоичном журнале нет обновлений и нет неосланных событий в течение более длительного периода, чем интервал сердцебиения. Настройка MASTER_HEARTBEAT_PERIOD на источнике (устанавливается с помощью CHANGE MASTER TO команды) определяет частоту сердцебиения, которая по умолчанию составляет половину интервала ожидания соединения для реплики (slave_net_timeout). Таблица схемы производительности replication_connection_status показывает, когда реплика получила последний сигнал сердцебиения и сколько сигналов сердцебиения она получила.

Если вы используете команду SHOW SLAVE STATUS для проверки состояния отдельной реплики, команда предоставляет следующую информацию:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: source1
                  Master_User: root
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000004
          Read_Master_Log_Pos: 931
               Relay_Log_File: replica1-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: 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: 0

Ключевыми полями в отчёте о состоянии, которые необходимо проверить, являются:

Slave_IO_State: Текущее состояние реплики. Дополнительную информацию см. в Разделе 8.14.6, «Состояния потока I/O реплики» и Разделе 8.14.7, «Состояния потока SQL реплики».
Slave_IO_Running: Запущен ли поток I/O для чтения двоичного журнала источника. Обычно это должно быть Yes, если вы ещё не запустили репликацию или явно не остановили её с помощью команды STOP SLAVE.
Slave_SQL_Running: Запущен ли поток SQL для выполнения событий в журнале реле. Как и для потока I/O, это обычно должно быть Yes.
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 выполнил журнал реле. Эти координаты соответствуют предыдущим координатам, но выражены в координатах журнала реле реплики, а не в координатах двоичного журнала источника.

На источнике вы можете проверить состояние подключенных реплик, используя SHOW PROCESSLIST для просмотра списка работающих процессов. Подключения реплик имеют Binlog Dump в поле Command:

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

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

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

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