Мониторинг отставания реплики и ошибок рабочих процессов applier (performance_schema)
MySQLРепликацияКоманда
-- Receiver (I/O) thread: connection state and last error
SELECT CHANNEL_NAME, SERVICE_STATE, LAST_ERROR_NUMBER,
LEFT(LAST_ERROR_MESSAGE, 100) AS last_error,
LAST_QUEUED_TRANSACTION, LAST_HEARTBEAT_TIMESTAMP
FROM performance_schema.replication_connection_status;
-- Applier workers: error, applied GTID and real lag
SELECT CHANNEL_NAME, WORKER_ID, SERVICE_STATE, LAST_ERROR_NUMBER,
LEFT(LAST_ERROR_MESSAGE, 120) AS last_error,
LAST_APPLIED_TRANSACTION,
APPLYING_TRANSACTION,
IF(APPLYING_TRANSACTION = '', 0,
TIMESTAMPDIFF(SECOND, APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP, NOW(6))) AS current_lag_sec,
TIMESTAMPDIFF(MICROSECOND, LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP,
LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP) / 1000000 AS last_trx_lag_sec
FROM performance_schema.replication_applier_status_by_worker
ORDER BY CHANNEL_NAME, WORKER_ID;Что делает
Раскладывает то, что SHOW REPLICA STATUS сводит в одну строку, по каналам и рабочим процессам: состояние потока-получателя, последняя ошибка каждого рабочего процесса, применённый / применяемый GTID и реальное отставание, вычисленное по исходной метке времени commit.
Когда использовать
Когда Seconds_Behind_Source выглядит недостоверно (скачет между 0 и большими значениями, NULL), чтобы найти, какой рабочий процесс завис на многопоточной реплике, и чтобы передавать в мониторинг точную метрику отставания.
Внимание
current_lag_sec имеет смысл только во время применения транзакции; простаивающая реплика возвращает 0. Чтобы увидеть, отстаёт ли и получатель, сравните LAST_QUEUED_TRANSACTION с gtid_executed источника. Исходная метка времени commit берётся по часам источника; расхождение часов между серверами (NTP) искажает результат. Seconds_Behind_Source остаётся около нуля в начале большой транзакции и скачет в конце; долгие транзакции делают эту метрику вводящей в заблуждение.