レプリカの遅延とアプライアワーカーのエラーを監視(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が1行に要約する内容をチャネルごと、ワーカーごとに分解する: レシーバスレッドの状態、各ワーカーの最後のエラー、適用済み/適用中のGTID、元のコミットタイムスタンプから計算した実際の遅延。

使用する場面

Seconds_Behind_Sourceが信頼できないように見えるとき(0と大きな値の間を行き来する、NULL)、マルチスレッドレプリカでどのワーカーが停止しているかを特定するため、正確な遅延メトリックを監視に取り込むために。

注意

current_lag_secはトランザクションの適用中のみ意味を持ち、アイドル状態のレプリカは0を返す。レシーバも遅れているかを確認するには、LAST_QUEUED_TRANSACTIONをソースのgtid_executedと比較する。元のコミットタイムスタンプはソースの時計に基づくため、サーバー間の時刻のずれ(NTP)は結果を歪める。Seconds_Behind_Sourceは大きなトランザクションの開始時はゼロ付近にとどまり、終了時に跳ね上がる。長いトランザクションはこのメトリックを誤解を招くものにする。