监控副本延迟和 applier worker 错误（performance_schema）

命令

-- 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 汇总在一行中的信息按通道和 worker 细分：receiver 线程状态、每个 worker 的最后错误、已应用/正在应用的 GTID，以及根据原始提交时间戳计算的真实延迟。

适用场景

当 Seconds_Behind_Source 看起来不可靠（在 0 和很大的值之间跳动、为 NULL）时，用于找出多线程副本上哪个 worker 卡住，以及为监控提供准确的延迟指标。

注意

current_lag_sec 只有在正在应用事务时才有意义；空闲副本返回 0。要查看 receiver 是否也落后，请将 LAST_QUEUED_TRANSACTION 与源的 gtid_executed 进行比较。原始提交时间戳来自源的时钟；服务器之间的时钟偏差（NTP）会扭曲结果。在大事务开始时 Seconds_Behind_Source 保持接近零，结束时才跳升；长事务会使该指标产生误导。