轉載自公眾號：玩轉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_TIMESTAMP

FROM performance_schema.replication_applier_status_by_worker

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

SELECT LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

FROM performance_schema.replication_applier_status_by_worker

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

SELECT APPLYING_TRANSACTION_START_APPLY_TIMESTAMP - APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

FROM performance_schema.replication_applier_status_by_worker

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

SELECT LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP - LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

FROM performance_schema.replication_applier_status_by_coordinator

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

SELECT PROCESSING_TRANSACTION_START_BUFFER_TIMESTAMP - PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

FROM performance_schema.replication_applier_status_by_coordinator

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

SELECT LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP - LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

FROM performance_schema.replication_connection_status

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

SELECT QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP - QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

FROM performance_schema.replication_connection_status

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

總結

以上是生活随笔為你收集整理的mysql 复制延迟诊断_新特性解读 | MySQL 8 复制延迟观测新方式，更全面更精准的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。