MYSQL 主從復制同步以及監控Seconds Behind Master 的實例分析

這期內容當中小編將會給大家帶來有關MYSQL 主從復制同步以及監控Seconds Behind Master 的實例分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

今天被老板詢問，新搭建的MYSQL 復制同步的情況怎么樣，有沒有報警或者復制時，主從不一致的情況發生，怎么報警的。我們監控了seconds_behind_master 了，沒有差異的情況發生。

看主從差異不就是看 seconds_behind_master嗎，是0 就沒差異。

那我們就看看光看 seconds_behind_master 來作為主從差異評判的標準是對的嗎？

我們先來看看SBM出現幾種值的可能性

1 出現空的可能性

當seconds_behind_master 出現空的情況，說明你的主從復制出現了問題

可能是主從復制斷了，或者停止了 SQL_THREAD,都會出現 NULL 的狀態。

2  出現大于0 的情況或等于0的情況

出現大于0 的情況，肯定的是主從庫的數據已經不一致了，有滯后的情況。

等于0 說明SQL 線程解析relay_log 到目前的從庫是沒有延遲的。

看 SBM 是不是0 就可以判斷從庫是不是落后主庫了

錯, 以下的情況會出現問題

1 由于主庫的性能問題，或者網絡問題，抓取binlog 到 從庫本身就已經出現延遲了，那通過SBM還能得到，主從之間準確的差距嗎？

2 上邊是計算SBM的源碼實現，其中深色的位置 clock_diff_with_master 是標識主從庫的時間差異，但你能保證獲得主從庫不同的時間是穩定可靠的嗎？ 如果不能保證在任何一刻主從庫的系統時間差異是準確的，你有怎么能說得到的SBM 是準確的。

準確的獲得主從差異的方式稍微靠譜的

先要查看 relay_master_log_file 和 master_log_file 是否有差異

在看Exec_master_log_pos 和 read_master_log_pos 是否一致，最后你在去看SBM是否為0 ，另外并行和串行的復制的方式，對SMB 也是有影響的。

當然目前已經上了GTID 的復制方式的MYSQL 可以有更好的方式來判斷某個時間點主從復制是否有延遲，或者使用pt工具中的 beatheart 來進行判斷也是可以的。

GTID 是怎么判斷的，還有那個什么工具來著。

（實際上判斷主從是否一致，如果通過程序來做的話可以寫一個shell 或 python程序，然在主庫產生一個庫表，通過每秒往這個表里面插入一條數據，并在從庫查詢來獲得數據，來判斷主從復制是否一致，其實這就是pt工具里面判斷主從是否一致的基本原理）

上述就是小編為大家分享的MYSQL 主從復制同步以及監控Seconds Behind Master 的實例分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。