轉載自公眾號：玩轉MySQL，作者：洪斌

一直以來 MySQL 複製延遲觀測是不完善的，既無法觀測到真實的主從延遲，也無法支持複雜的複製拓撲環境，常用的 second_behind_master 指標更多是判斷是否存在回放延遲，以及趨勢變化。你無法直觀的觀測到事務精確的延遲情況，因為 slave 無法獲知事務在 master 上的提交時間。

社區貢獻的基於心跳表延遲檢測方法，其流程是 master 上創建一張心跳表，心跳進程每秒更新表上的時間戳欄位，slave 同步後計算時間差。這應該是在不改動 MySQL 代碼的最好方案了，雖然也會有些不足。

• 心跳進程單點風險，心跳進程不可用則延遲檢測失效。
• 並不能反應真實的業務事務同步或回放延遲，體現的是主從複製鏈路全局的連通性和延遲。
• 觀測粒度只能達到秒級，精度不夠。
• 污染 binlog，大量心跳事件占據 binlog，更多空間占用，干擾排查和日誌恢復。

MySQL 8 複製延遲觀測的改進

WL#7319 和 WL#7374 共同完善了複製延遲觀測，WL#7319 Infrastructure for GTID based delayed replication and replication lag monitoring 在binlog 的 gtid_log_event （啟用 GTID）和 anonymous_gtid_log_event（未啟用 GTID）新增事務提交時間戳。將事務原始提交時間寫在 binlog 中，提交時間在複製鏈路上傳遞，使得 slave 可以計算事務延遲。

• original_commit_timestamp 事務在 master 提交 binlog 的時間戳（微秒），該時間戳每個節點都是一樣的。
• immediate_commit_timestamp 事務在 slave（包括中繼節點）提交 binlog 的時間戳（微秒），該時間戳在 relay log 中與 original_commit_timestamp 一樣，在 slave 的 binlog 是完成回放的時間戳。

WL#7374 Performance schema tables to monitor replication lags and queue 為 performance_schema 複製相關表新增觀測點。

• replication_connection_status 記錄事件接收線程（IO Thread）工作狀態
• replication_applier_status_by_coordinator 記錄啟用並行回放的協調線程工作狀態
• replication_applier_status_by_worker 記錄事件回放線程（SQL Thread）工作狀態

replication_connection_status

LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 已寫入 relay log 事務 ORIGINAL_COMMIT_TIMESTAMP 時間戳

LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 已寫入 relay log 事務 IMMEDIATE_COMMIT_TIMESTAMP 時間戳

LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP 已寫入 relay log 的事務開始時間戳

LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP 已寫入 relay log 的事務結束時間戳

QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 正在寫 relay log 的事務 ORIGINAL_COMMIT_TIMESTAMP 時間戳

QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 正在寫 relay log 的事務 IMMEDIATE_COMMIT_TIMESTAMP 時間戳

QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP 正在寫 relay log 的事務首個事件的時間戳

replication_applier_status_by_coordinator

LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 已調度事務的 ORIGINAL_COMMIT_TIMESTAMP 時間戳

LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 已調度事務的 IMMEDIATE_COMMIT_TIMESTAMP 時間戳

LAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMP 已調度事務到 worker 線程 buffer 的開始時間戳

LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP 已調度事務到 worker 線程 buffer 的結束時間戳

PROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 正在調度事務的 ORIGINAL_COMMIT_TIMESTAMP 時間戳

PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 正在調度事務的 IMMEDIATE_COMMIT_TIMESTAMP 時間戳

PROCESSING_TRANSACTION_START_BUFFER_TIMESTAMP 正在調度事務寫入 worker 線程 buffer 的開始時間戳

replication_applier_status_by_worker

LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 已回放事務的 ORIGINAL_COMMIT_TIMESTAMP 時間戳

LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 已回放事務的 IMMEDIATE_COMMIT_TIMESTAMP 時間戳

LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP 已回放事務的開始時間戳

LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP 已回放事務的結束時間戳

APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 正在回放事務的 ORIGINAL_COMMIT_TIMESTAMP 時間戳

APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 正在回放事務的 IMMEDIATE_COMMIT_TIMESTAMP 時間戳

APPLYING_TRANSACTION_START_APPLY_TIMESTAMP 正在回放事務的開始時間戳

如何觀測事務複製過程中在不同位置的延遲，A 是 Master 節點，C 是中繼 Slave 節點，D 是 Slave 節點。

位置 1：事務從主節點 A 到從節點 D 回放完的延遲，最常用的查看事務完整的同步延遲

SELECT LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMPFROM performance_schema.replication_applier_status_by_worker

事務從中繼節點 C 到從節點 D 回放完的延遲，與上面類似，若沒有中繼節點效果和上面一樣，也是事務完整的同步延遲

SELECT LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMPFROM performance_schema.replication_applier_status_by_worker

位置 2：當前已調度完的事務到開始回放的延遲

SELECT APPLYING_TRANSACTION_START_APPLY_TIMESTAMP - APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMPFROM performance_schema.replication_applier_status_by_worker

位置3：已調度完的事務等待回放的延遲，MTS 開啟

SELECT LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP - LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMPFROM performance_schema.replication_applier_status_by_coordinator

位置 4：當前已同步到中繼日誌的事務，等待開始調度的延遲，MTS 開啟

SELECT PROCESSING_TRANSACTION_START_BUFFER_TIMESTAMP - PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMPFROM performance_schema.replication_applier_status_by_coordinator

位置 5：事務同步到從機中繼日誌的延遲

SELECT LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP - LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMPFROM performance_schema.replication_connection_status

位置 6：當前同步事務的網絡傳輸延遲

SELECT QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP - QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMPFROM performance_schema.replication_connection_status

MySQL 8 從根源上解決了過往版本缺少事務提交時間且無法傳遞的問題，PS 視圖暴露更多觀測點簡化了觀測方式，幫助工程師更精準的診斷複製延遲問題。