Monitorear el lag de la réplica y los errores de los workers del applier (performance_schema)
MySQLReplicaciónComando
-- 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;Qué hace
Desglosa por canal y por worker lo que SHOW REPLICA STATUS resume en una sola fila: el estado del receiver thread, el último error de cada worker, el GTID aplicado / en aplicación y el lag real calculado a partir del timestamp de commit original.
Cuándo usarlo
Cuando Seconds_Behind_Source parece poco fiable (salta entre 0 y valores grandes, NULL), para encontrar qué worker está atascado en una réplica multi-threaded, y para alimentar el monitoreo con una métrica de lag precisa.
Precaución
current_lag_sec solo tiene sentido mientras se está aplicando una transacción; una réplica inactiva devuelve 0. Para ver si el receiver también va retrasado, compare LAST_QUEUED_TRANSACTION con el gtid_executed del origen. El timestamp de commit original procede del reloj del origen; el desfase de reloj entre servidores (NTP) distorsiona el resultado. Seconds_Behind_Source se mantiene cerca de cero al principio de una transacción grande y salta al final; las transacciones largas hacen que esa métrica sea engañosa.