Replica-Lag und Fehler der Applier-Worker überwachen (performance_schema)
MySQLReplikationBefehl
-- 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;Was es tut
Schlüsselt auf, was SHOW REPLICA STATUS in einer Zeile zusammenfasst, je Kanal und je Worker: Zustand des Receiver-Threads, letzter Fehler jedes Workers, angewendete / gerade angewendete GTID und die echte Verzögerung, berechnet aus dem ursprünglichen Commit-Zeitstempel.
Wann einsetzen
Wenn Seconds_Behind_Source unzuverlässig wirkt (springt zwischen 0 und großen Werten, NULL), um herauszufinden, welcher Worker auf einer Multi-Threaded Replica hängt, und um eine genaue Lag-Metrik ins Monitoring einzuspeisen.
Vorsicht
current_lag_sec ist nur aussagekräftig, während eine Transaktion angewendet wird; eine inaktive Replica liefert 0. Um zu sehen, ob auch der Receiver zurückliegt, LAST_QUEUED_TRANSACTION mit gtid_executed der Quelle vergleichen. Der ursprüngliche Commit-Zeitstempel stammt von der Uhr der Quelle; Uhrenabweichungen zwischen Servern (NTP) verfälschen das Ergebnis. Seconds_Behind_Source bleibt zu Beginn einer großen Transaktion nahe null und springt am Ende; lange Transaktionen machen diese Metrik irreführend.