19.1.7.1 Checking Replication Status — MySQL 8.4

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

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

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

Информация о тактировании репликации, отображаемая в таблицах репликации Performance Schema, позволяет проверить, что подключение репликации активно, даже если источник недавно не отправлял события реплике. Источник отправляет сигнал тактирования реплике, если в двоичном журнале нет обновлений и нет неопубликованных событий в течение периода, превышающего интервал тактирования. Параметр SOURCE_HEARTBEAT_PERIOD на источнике (устанавливается с помощью CHANGE REPLICATION SOURCE TO) определяет частоту тактирования, которая по умолчанию составляет половину интервала таймаута подключения для реплики (указанного системной переменной replica_net_timeout). Таблица Performance Schema replication_connection_status показывает, когда была получена последняя метка тактирования репликой и сколько сигналов тактирования она получила.

Вы можете использовать SHOW REPLICA STATUS для проверки статуса отдельной реплики; это выражение предоставляет информацию, показанную здесь:

mysql> SHOW REPLICA STATUS\G
*************************** 1. row ***************************
             Replica_IO_State: Waiting for source to send event
                  Source_Host: 127.0.0.1
                  Source_User: root
                  Source_Port: 13000
                Connect_Retry: 1
              Source_Log_File: master-bin.000001
          Read_Source_Log_Pos: 927
               Relay_Log_File: slave-relay-bin.000002
                Relay_Log_Pos: 1145
        Relay_Source_Log_File: master-bin.000001
           Replica_IO_Running: Yes
          Replica_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_Source_Log_Pos: 927
              Relay_Log_Space: 1355
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Source_SSL_Allowed: No
           Source_SSL_CA_File:
           Source_SSL_CA_Path:
              Source_SSL_Cert:
            Source_SSL_Cipher:
               Source_SSL_Key:
        Seconds_Behind_Source: 0
Source_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Source_Server_Id: 1
                  Source_UUID: 73f86016-978b-11ee-ade5-8d2a2a562feb
             Source_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
    Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
           Source_Retry_Count: 10
                  Source_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Source_SSL_Crl:
           Source_SSL_Crlpath:
           Retrieved_Gtid_Set: 73f86016-978b-11ee-ade5-8d2a2a562feb:1-3
            Executed_Gtid_Set: 73f86016-978b-11ee-ade5-8d2a2a562feb:1-3
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Source_TLS_Version:
       Source_public_key_path:
        Get_Source_public_key: 0
            Network_Namespace:

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

Replica_IO_State: Текущий статус реплики. Подробнее см. Раздел 10.14.5, «Состояния потока I/O репликации (приёмник)» и Раздел 10.14.6, «Состояния потока SQL репликации».
Replica_IO_Running: Работает ли поток I/O (приёмник) для чтения двоичного журнала источника. Обычно это должно быть Yes, если вы ещё не запустили репликацию или явным образом не остановили её с помощью STOP REPLICA.
Replica_SQL_Running: Работает ли поток SQL для выполнения событий в журнале репликации. Как и в случае с потоком I/O, это обычно должно быть Yes.
Last_IO_Error, Last_SQL_Error: Последние ошибки, зарегистрированные потоками I/O (приёмник) и SQL (применитель), при обработке журнала репликации. В идеале они должны быть пустыми, что указывает на отсутствие ошибок.
Seconds_Behind_Source: Количество секунд, в течение которых поток репликации SQL (применитель) отстаёт от обработки двоичного журнала источника. Большое значение (или увеличивающееся) может указывать на то, что реплика не может обрабатывать события из источника своевременно.

Значение 0 для Seconds_Behind_Source обычно можно интерпретировать как то, что реплика догнала источник, но в некоторых случаях это не совсем верно. Например, это может произойти, если сетевое соединение между источником и репликой прервано, но поток репликации I/O (приёмник) ещё не заметил этого; то есть период времени, установленный replica_net_timeout, ещё не истек.

Также возможно, что временные значения для Seconds_Behind_Source могут не отражать ситуацию точно. Когда поток репликации SQL (применитель) догнал I/O, Seconds_Behind_Source отображает 0; но когда поток репликации I/O (приёмник) по-прежнему добавляет новое событие в очередь, Seconds_Behind_Source может показывать большое значение до тех пор, пока поток репликации-применителя не завершит выполнение нового события. Это особенно вероятно, когда у событий есть старые метки времени; в таких случаях, если вы несколько раз выполняете SHOW REPLICA 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 REPLICAS на источнике показывает основную информацию о репликах. Вывод включает идентификатор сервера реплики, значение параметра --report-host, порт подключения и идентификатор источника:

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