Surveiller le retard de la réplique et les erreurs des workers d'apply (performance_schema)
MySQLRéplicationCommande
-- 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;Ce que fait la commande
Détaille par canal et par worker ce que SHOW REPLICA STATUS résume en une ligne : état du thread receiver, dernière erreur de chaque worker, GTID appliqué / en cours d'application et retard réel calculé à partir de l'horodatage de commit d'origine.
Quand l'utiliser
Lorsque Seconds_Behind_Source semble peu fiable (oscille entre 0 et de grandes valeurs, NULL), pour trouver quel worker est bloqué sur une réplique multi-thread, et pour alimenter la supervision avec une métrique de retard exacte.
Attention
current_lag_sec n'a de sens que pendant l'application d'une transaction ; une réplique inactive renvoie 0. Pour savoir si le receiver est aussi en retard, comparez LAST_QUEUED_TRANSACTION avec le gtid_executed de la source. L'horodatage de commit d'origine provient de l'horloge de la source ; un décalage d'horloge entre serveurs (NTP) fausse le résultat. Seconds_Behind_Source reste proche de zéro au début d'une grosse transaction et bondit à la fin ; les transactions longues rendent cette métrique trompeuse.