問題：主從延遲與寫后讀不一致

在典型的 MySQL 主從架構(gòu)下，所有寫操作都會(huì)直接進(jìn)入主庫(kù)，而讀操作大多分流到從庫(kù)，從而實(shí)現(xiàn)讀寫分離，緩解主庫(kù)壓力。
然而 MySQL 的復(fù)制機(jī)制是異步的：主庫(kù)先寫入 binlog，從庫(kù) I/O 線程拉取到 relay log，再交由 SQL 線程順序回放。這個(gè)鏈路包含網(wǎng)絡(luò)傳輸與多步處理，因此天然會(huì)引入延遲。當(dāng)網(wǎng)絡(luò)抖動(dòng)、主庫(kù)寫入量過大或從庫(kù)執(zhí)行能力不足時(shí)，延遲可能進(jìn)一步加劇。
這種延遲在大多數(shù)場(chǎng)景下可以容忍，但在涉及 寫后立即讀 的業(yè)務(wù)時(shí)問題尤為突出。例如，用戶剛下單立刻查詢訂單詳情，如果讀請(qǐng)求被路由到了從庫(kù)，就可能讀到舊數(shù)據(jù)，造成一致性問題。在過去一年，公司內(nèi)部就發(fā)生過 6 起因主從延遲導(dǎo)致的線上事故，幾乎全部由這種場(chǎng)景觸發(fā)。由于問題往往跨接口、跨服務(wù)，難以在代碼評(píng)審或測(cè)試階段提前發(fā)現(xiàn)，最終只能緊急切換為“強(qiáng)制讀主”兜底，恢復(fù)過程耗時(shí)且影響業(yè)務(wù)穩(wěn)定。
為了監(jiān)控和判斷主從延遲，MySQL 提供了一個(gè)常用指標(biāo)：Seconds_Behind_Master。

Seconds_Behind_Master 的計(jì)算方式

根據(jù) MySQL 官方文檔與源碼，Seconds_Behind_Master 的計(jì)算公式如下：

Seconds_Behind_Master 
= 從庫(kù)當(dāng)前系統(tǒng)時(shí)間 (time(0)) 
- SQL 線程正在執(zhí)行的 event 時(shí)間戳 (last_master_timestamp) 
- 主從系統(tǒng)時(shí)間差 (clock_diff_with_master)

其中：

• last_master_timestamp：主庫(kù) binlog event 的時(shí)間戳，隨復(fù)制傳到從庫(kù)。
  • 如果 binlog_format=STATEMENT，則last_master_timestamp = 主庫(kù)開始執(zhí)行的時(shí)間戳 + exec_time
  • 如果 binlog_format=ROW，則last_master_timestamp = 主庫(kù)開始執(zhí)行的時(shí)間戳。
• clock_diff_with_master：主從系統(tǒng)時(shí)間差，I/O 線程啟動(dòng)時(shí)會(huì)在主庫(kù)執(zhí)行 SELECT UNIX_TIMESTAMP() 獲取，只計(jì)算一次，之后復(fù)用，直到 I/O 線程重啟。如果啟動(dòng)后手動(dòng)修改了服務(wù)器時(shí)間，這個(gè)差值不會(huì)更新，可能導(dǎo)致計(jì)算結(jié)果失真。
• time(0)：從庫(kù)當(dāng)前系統(tǒng)時(shí)間。

源碼中還定義了結(jié)果判定規(guī)則：

• SQL 與 I/O 線程均運(yùn)行且空閑 → 延遲結(jié)果為 0。此時(shí)從庫(kù)已經(jīng)把 relay log 中的事件全部回放完畢，I/O 線程又保持著和主庫(kù)的連接，因此從庫(kù)已經(jīng)與主庫(kù)保持同步，沒有新的 event 需要應(yīng)用，延遲自然為 0。
• SQL 線程未運(yùn)行 → 延遲為 NULL。如果 SQL 線程沒有運(yùn)行（例如被管理員手動(dòng) STOP SLAVE SQL_THREAD，或因錯(cuò)誤導(dǎo)致中止），那么從庫(kù)根本沒有在執(zhí)行任何 event。此時(shí)返回?cái)?shù)值型延遲沒有意義，因此直接返回 NULL 來(lái)提醒用戶“復(fù)制中斷”。
• SQL 線程空閑但 I/O 線程未運(yùn)行 → 延遲為 NULL。這種情況下，SQL 線程雖然沒有待執(zhí)行的 relay log（看起來(lái)像“追上了”），但 I/O 線程已經(jīng)停止，不再?gòu)闹鲙?kù)獲取新的 binlog。這意味著復(fù)制鏈路實(shí)際上中斷了。如果繼續(xù)返回 0，會(huì)給人錯(cuò)誤的印象，好像一切正常，所以 MySQL 設(shè)計(jì)為返回 NULL 來(lái)明確告警。
• 計(jì)算結(jié)果為負(fù)數(shù) → 強(qiáng)制歸零。按照公式Seconds_Behind_Master = time(0) - last_master_timestamp - clock_diff_with_master，如果主從時(shí)間不同步，或者事務(wù)時(shí)間戳落在未來(lái)（例如 binlog 被修改、系統(tǒng)時(shí)間漂移等），計(jì)算結(jié)果可能出現(xiàn)負(fù)數(shù)。但“延遲”為負(fù)數(shù)在邏輯上沒有意義，所以源碼中用 max(0, time_diff) 強(qiáng)制將其歸零，避免誤導(dǎo)。

局限性

雖然 Seconds_Behind_Master 在多數(shù)場(chǎng)景下能反映延遲情況，但在生產(chǎn)環(huán)境中，它仍存在明顯的局限。下面結(jié)合實(shí)際場(chǎng)景進(jìn)行說(shuō)明。

延遲為 0 并不代表沒有延遲

• 場(chǎng)景：在主從架構(gòu)中，I/O 線程負(fù)責(zé)從主庫(kù)拉取 binlog 并寫入 relay log，SQL 線程再?gòu)?relay log 中讀取并回放。如果主從之間網(wǎng)絡(luò)較慢，I/O 線程就可能長(zhǎng)期落后主庫(kù)，積壓大量尚未傳輸?shù)?binlog。
• 表現(xiàn)：當(dāng) SQL 線程把 relay log 消費(fèi)完時(shí)，SHOW SLAVE STATUS 會(huì)顯示 Seconds_Behind_Master = 0，似乎表示“沒有延遲”。
• 實(shí)際情況：從庫(kù)雖然追上了 I/O 線程，但 I/O 線程本身離主庫(kù)最新的 binlog 可能還有幾十 MB，甚至幾分鐘的差距。換句話說(shuō)，從庫(kù)與主庫(kù)之間仍存在顯著延遲，只是指標(biāo)無(wú)法體現(xiàn)。
• 風(fēng)險(xiǎn)：業(yè)務(wù)層可能基于延遲值為 0 做出“主從一致”的判斷，結(jié)果讀到的數(shù)據(jù)卻仍是舊的，造成寫后讀不一致。

系統(tǒng)時(shí)間修改會(huì)導(dǎo)致失真

• 場(chǎng)景：在運(yùn)維過程中，DBA 可能會(huì)因?yàn)闀r(shí)區(qū)調(diào)整、NTP 時(shí)間同步異常、手工校準(zhǔn)等原因修改主庫(kù)或從庫(kù)的系統(tǒng)時(shí)間。
• 表現(xiàn)：Seconds_Behind_Master 的計(jì)算依賴于 binlog 事件的時(shí)間戳（來(lái)自主庫(kù)）和從庫(kù)當(dāng)前的系統(tǒng)時(shí)間。一旦系統(tǒng)時(shí)間被修改，這兩者的對(duì)應(yīng)關(guān)系就會(huì)被破壞，延遲值可能出現(xiàn)異常，甚至出現(xiàn)負(fù)數(shù)。
• 源碼處理：MySQL 為避免出現(xiàn)“負(fù)延遲”，源碼中使用 max(0, time_diff) 強(qiáng)制將負(fù)數(shù)歸零。
• 結(jié)果：這會(huì)導(dǎo)致監(jiān)控曲線突然出現(xiàn)“不合理的斷層”，讓運(yùn)維人員無(wú)法正確評(píng)估延遲情況。
• 例子：主庫(kù)時(shí)間向前撥快 5 分鐘 → 從庫(kù)計(jì)算出的延遲會(huì)瞬間飆升；主庫(kù)時(shí)間向后撥慢 5 分鐘 → 從庫(kù)計(jì)算出的延遲可能變成負(fù)數(shù)，最后被歸零，看起來(lái)好像“沒有延遲”。

長(zhǎng)事務(wù)導(dǎo)致延遲值波動(dòng)

• 場(chǎng)景：主庫(kù)執(zhí)行一個(gè)耗時(shí)數(shù)分鐘的大事務(wù)，例如大批量的 INSERT 或 UPDATE。
• 表現(xiàn)：在事務(wù)執(zhí)行期間，binlog 中多個(gè) event 的時(shí)間戳可能相同（通常是事務(wù)開始時(shí)的時(shí)間戳）。SQL 線程在從庫(kù)上回放這些 event 時(shí)，Seconds_Behind_Master 會(huì)不斷增大，因?yàn)閺膸?kù)當(dāng)前時(shí)間與事務(wù)開始時(shí)間的差值在拉大。一旦事務(wù)提交，從庫(kù)應(yīng)用完成，延遲值瞬間歸零。
• 結(jié)果：監(jiān)控曲線會(huì)出現(xiàn)典型的“逐漸升高 → 瞬間清零”的模式，容易被誤判為網(wǎng)絡(luò)抖動(dòng)或系統(tǒng)故障。
• 例子：某個(gè)大事務(wù)從 10:00:00 開始，主庫(kù)執(zhí)行 5 分鐘才提交。從庫(kù)在 10:04:59 時(shí)仍在執(zhí)行該事務(wù)，延遲值可能顯示接近 300 秒；但到 10:05:00 一提交，延遲值直接歸零，看似“延遲消失”，實(shí)際卻只是事務(wù)執(zhí)行完畢。

STATEMENT 與 ROW 格式差異

MySQL 的 binlog 格式有 STATEMENT 和 ROW，兩種模式下 Seconds_Behind_Master 的計(jì)算邏輯不同。
STATEMENT 格式：記錄的是 SQL 語(yǔ)句本身，例如：DELETE FROM t WHERE id=1。binlog 中會(huì)包含 exec_time 字段，表示該語(yǔ)句在主庫(kù)執(zhí)行所花的時(shí)間。從庫(kù)計(jì)算 last_master_timestamp 時(shí)，會(huì)在主庫(kù)開始執(zhí)行的時(shí)間戳上加上 exec_time。

• 結(jié)果：延遲值被“平滑”掉，實(shí)際延遲被低估。
• 例子：某條 DELETE 在主庫(kù)執(zhí)行耗時(shí) 9 秒，從庫(kù)在 18 秒后才執(zhí)行到這一 event。按理應(yīng)該顯示 18 秒延遲，但由于公式減去了 9 秒，最終只顯示 9 秒。

ROW 格式：記錄的是行級(jí)變更數(shù)據(jù)，例如：Delete_rows event，而不是 SQL 語(yǔ)句。binlog 不包含 exec_time，所以從庫(kù)的延遲計(jì)算直接基于事務(wù)開始時(shí)間戳。

• 結(jié)果：延遲值更接近真實(shí)情況。
• 例子：同樣的事務(wù)，從庫(kù)在 24 秒后執(zhí)行，延遲顯示 24 秒，與實(shí)際差距一致。
• 對(duì)比總結(jié)：在短事務(wù)場(chǎng)景下，兩種格式差異不大；在長(zhǎng)事務(wù)或復(fù)雜 SQL 場(chǎng)景下，STATEMENT 模式會(huì)嚴(yán)重低估延遲值，ROW 模式更準(zhǔn)確。

在 MySQL 的 binlog 里，不管是 STATEMENT 模式還是 ROW 模式，數(shù)據(jù)變更都會(huì)被寫成一條條 event。
event 就是 binlog 里的“記錄單元”，包含 header（時(shí)間戳、server_id、位置等）和 body（具體內(nèi)容）。

在 ROW 格式 下，binlog 記錄的是行級(jí)變更事件（如 Delete_rows event），這些事件不包含 exec_time 字段，所以 Seconds_Behind_Master 的計(jì)算完全依賴于事件 header 中的 timestamp。對(duì)于一個(gè)事務(wù)來(lái)說(shuō)，絕大多數(shù) row events 的時(shí)間戳等于事務(wù)開始時(shí)刻，只有最后的 XID_EVENT 才標(biāo)記提交時(shí)間。因此，在長(zhǎng)事務(wù)場(chǎng)景下，延遲值會(huì)隨著事務(wù)執(zhí)行逐漸升高，而在提交時(shí)瞬間歸零。

例子

STATEMENT 格式大事務(wù)案例

主庫(kù)執(zhí)行語(yǔ)句

BEGIN;
INSERT INTO t_user (name, age)
VALUES ('Alice', 20), ('Bob', 25), ('Cathy', 30), ... 共 100 萬(wàn)行;
COMMIT;

binlog 內(nèi)容（STATEMENT 模式）

# at 100
# 250914 10:00:00 server id 1 end_log_pos 200 CRC32 0xaaaa
BEGIN
# at 200
# 250914 10:00:00 server id 1 end_log_pos 300 CRC32 0xbbbb
# Query   thread_id=11   exec_time=300   error_code=0
SET TIMESTAMP=1726298400/*!*/;   -- 事務(wù)開始時(shí)間 (10:00:00)
INSERT INTO t_user (name, age)
VALUES ('Alice',20),('Bob',25),('Cathy',30), ... 共 100萬(wàn)行
/*!*/;
# at 5000
# 250914 10:05:00 server id 1 end_log_pos 5100 CRC32 0xcccc
Xid = 12345
COMMIT;

特點(diǎn)

• exec_time=300 秒，binlog 記錄了主庫(kù)執(zhí)行這條 SQL 的耗時(shí)。
• 從庫(kù)在計(jì)算 last_master_timestamp 時(shí)：

last_master_timestamp = 10:00:00 + 300s = 10:05:00

• 所以在從庫(kù)回放時(shí)，不管過程多長(zhǎng)，最終 SBM 顯示偏小（會(huì)被 exec_time 矯正）。
• 結(jié)果：真實(shí)延遲可能幾百秒，但 SBM 看起來(lái)更“溫和”。

ROW 格式大事務(wù)案例

主庫(kù)執(zhí)行語(yǔ)句

BEGIN;
INSERT INTO t_user (name, age) VALUES ('Alice', 20);
INSERT INTO t_user (name, age) VALUES ('Bob', 25);
...
INSERT INTO t_user (name, age) VALUES ('User1000000', 99);
COMMIT;

binlog 內(nèi)容（ROW 模式）

# at 100
# 250914 10:00:00 server id 1 end_log_pos 200 CRC32 0xaaaa
BEGIN
# at 200
# 250914 10:00:00 server id 1 end_log_pos 250 CRC32 0xbbbb
### INSERT INTO `test`.`t_user`
### SET
###   @1=1, @2='Alice', @3=20
# at 250
# 250914 10:00:00 server id 1 end_log_pos 300 CRC32 0xcccc
### INSERT INTO `test`.`t_user`
### SET
###   @1=2, @2='Bob', @3=25
-- ... 中間還有 999,998 條 Write_rows_event ...
-- 注意：所有 row event 的時(shí)間戳都是 10:00:00
# at 5000000
# 250914 10:05:00 server id 1 end_log_pos 5000100 CRC32 0xdddd
Xid = 12345
COMMIT;

特點(diǎn)

• 所有 row events 的時(shí)間戳都是事務(wù) 開始時(shí)的 10:00:00。
  • 從庫(kù) SQL 線程回放這些 row event 時(shí)：
  • 在 10:04:59 還在執(zhí)行 → SBM = 10:04:59 - 10:00:00 = 299 秒
  • 一旦遇到 XID_EVENT（10:05:00） → SBM = 10:05:00 - 10:05:00 = 0
  • 結(jié)果：延遲曲線先逐漸升高，再在提交瞬間清零。

對(duì)比總結(jié)：

• STATEMENT：有 exec_time，SBM 往往被低估，延遲曲線更“平滑”。
• ROW：事件時(shí)間戳基本等于事務(wù)開始時(shí)間，延遲曲線會(huì)拉高再瞬間歸零，更容易表現(xiàn)出“抖動(dòng)”。

總結(jié)

Seconds_Behind_Master 是 MySQL 提供的一個(gè)延遲指標(biāo)，但其計(jì)算方式?jīng)Q定了它并不能完全反映真實(shí)延遲。在網(wǎng)絡(luò)抖動(dòng)、系統(tǒng)時(shí)間漂移或長(zhǎng)事務(wù)場(chǎng)景下，它可能顯示為 0 或出現(xiàn)異常波動(dòng)；在 STATEMENT 格式下可能被低估，在 ROW 格式下更接近真實(shí)；

因此，在數(shù)據(jù)庫(kù)架構(gòu)和業(yè)務(wù)邏輯設(shè)計(jì)中，不能單純依賴這一指標(biāo)。線上常見做法是：借助 pt-heartbeat 或 MySQL 8.0 performance_schema 原生方案進(jìn)行更可靠的延遲監(jiān)控；或在業(yè)務(wù)層結(jié)合 插件化攔截、配置化強(qiáng)制讀主、長(zhǎng)事務(wù)拆分 等措施，主動(dòng)規(guī)避寫后讀不一致風(fēng)險(xiǎn)。

盡管 Seconds_Behind_Master 存在一定的局限性，但在大多數(shù)場(chǎng)景下，它依然能夠較為準(zhǔn)確地反映主從復(fù)制的延遲情況。

參考

[1] MySQL自治平臺(tái)建設(shè)的內(nèi)核原理及實(shí)踐

[2] Seconds_Behind_Master 的局限性及如何監(jiān)控主從延遲

[3] MySQL 復(fù)制延遲 Seconds_Behind_Master 究竟是如何計(jì)算的

到此這篇關(guān)于深入理解MySQL主從架構(gòu)中的Seconds_Behind_Master指標(biāo)的文章就介紹到這了,更多相關(guān)mysql Seconds_Behind_Master指標(biāo)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論