MySql server master-master seconds_behind_master 跳轉
我正在執行一個 4 台伺服器的 MySql 主控集群。（2 台伺服器 5.1 版和 2 台 5.5 版）
在檢查從屬狀態時，我看到 seconds_behind_master 為 0，半秒後我看到它跳到 2000，所以是第四個。
可能是什麼？我該如何調試它？
複製拓撲：1 -> 2 -> 3 -> 4 -> 1
更新
似乎伺服器 3 的 SBM 為 0，而其他伺服器正在上下跳躍。這有幫助嗎？
更新 2 似乎問題出在伺服器 1 上。在伺服器 4 中創建測試表時，檢查伺服器 1 中的中繼日誌顯示創建語句已立即復製到伺服器 1 中的中繼日誌，但未創建表。看起來伺服器正忙於做某事，並且在伺服器獲取語句和執行語句之間存在巨大延遲。
更新 3 同樣的事情發生在伺服器 4 上。
更新 4 好的，我發現了問題。伺服器 1 2 和 4 的複制執行緒中出現“無效的查詢記憶體條目（表）”。禁用記憶體後，伺服器 4 正常，但 1&2 仍然存在此問題。
它看起來像一個常見的錯誤： http ://bugs.mysql.com/bug.php?id=60696
如果有人知道如何解決它，我會很高興聽到
問題確實出
invalidating query cache entries (table)在舊的非 Percona 伺服器上，導致複製停止，直到記憶體失效（這花了很多時間）。如此處所述：http: //bugs.mysql.com/bug.php?id= 60696
我們通過完全遷移到能夠完全禁用查詢記憶體的 Percona MySQL 伺服器 v5.5 解決了這個問題。
mysql 的 seconds_behind_master 值有一個缺陷：它只考慮相對於上游一跳的位置。使用稍微簡單的複制拓撲最容易展示：
伺服器1->伺服器2->伺服器3
如果 server2 落後，並且正在處理一些長時間執行的查詢，假設 00:00 為起點，將發生以下情況：
00:00: 大家都好
00:01: server1 將兩個 10 分鐘的查詢寫入 binlog，任何地方都沒有複製延遲
00:02: server2 開始處理查詢一個。server2 的複制延遲開始增長，server3 的複制延遲保持為零
10:02：server2 完成查詢一，開始處理查詢二。server2 複製延遲仍在增長。server3 複製延遲突然跳到10 分鐘。
20:02：server2 完成查詢 2，複製延遲再次為零。Server3 將使用查詢 3 完成，複製延遲跳回零，然後在處理下一個查詢時回到 10。
因此，跳躍行為是由於沒有使用全域時間戳來進行複制延遲，而只是複制鏈中最後一個“躍點”後面的延遲。我們發現這非常煩人，現在使用 MySQL 的事件調度程序每秒更新每個 master 上的計時器表，因此我們實際上可以看到來自全域 master 的實際延遲（在非環拓撲中）或來自環中任何對等點的延遲。