Monitorar o lag da réplica e os erros dos workers do applier (performance_schema)

Comando

-- 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;

O que faz

Detalha por canal e por worker o que o SHOW REPLICA STATUS resume em uma única linha: estado da receiver thread, o último erro de cada worker, o GTID aplicado / em aplicação e o lag real calculado a partir do timestamp de commit original.

Quando usar

Quando o Seconds_Behind_Source parece pouco confiável (pulando entre 0 e valores altos, NULL), para descobrir qual worker está travado em uma réplica multi-threaded e para alimentar o monitoramento com uma métrica de lag precisa.

Atenção

current_lag_sec só faz sentido enquanto uma transação está sendo aplicada; uma réplica ociosa retorna 0. Para ver se o receiver também está atrasado, compare LAST_QUEUED_TRANSACTION com o gtid_executed da source. O timestamp de commit original vem do relógio da source; diferenças de relógio entre servidores (NTP) distorcem o resultado. O Seconds_Behind_Source fica perto de zero no início de uma transação grande e salta no fim; transações longas tornam essa métrica enganosa.