MYSQL 主從復(fù)制同步以及監(jiān)控Seconds Behind Master 的實(shí)例分析

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)MYSQL 主從復(fù)制同步以及監(jiān)控Seconds Behind Master 的實(shí)例分析，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

今天被老板詢問，新搭建的MYSQL 復(fù)制同步的情況怎么樣，有沒有報(bào)警或者復(fù)制時(shí)，主從不一致的情況發(fā)生，怎么報(bào)警的。我們監(jiān)控了seconds_behind_master 了，沒有差異的情況發(fā)生。

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

那我們就看看光看 seconds_behind_master 來作為主從差異評(píng)判的標(biāo)準(zhǔn)是對(duì)的嗎？

我們先來看看SBM出現(xiàn)幾種值的可能性

1 出現(xiàn)空的可能性

當(dāng)seconds_behind_master 出現(xiàn)空的情況，說明你的主從復(fù)制出現(xiàn)了問題

可能是主從復(fù)制斷了，或者停止了 SQL_THREAD,都會(huì)出現(xiàn) NULL 的狀態(tài)。

2  出現(xiàn)大于0 的情況或等于0的情況

出現(xiàn)大于0 的情況，肯定的是主從庫的數(shù)據(jù)已經(jīng)不一致了，有滯后的情況。

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

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

錯(cuò), 以下的情況會(huì)出現(xiàn)問題

1 由于主庫的性能問題，或者網(wǎng)絡(luò)問題，抓取binlog 到 從庫本身就已經(jīng)出現(xiàn)延遲了，那通過SBM還能得到，主從之間準(zhǔn)確的差距嗎？

2 上邊是計(jì)算SBM的源碼實(shí)現(xiàn)，其中深色的位置 clock_diff_with_master 是標(biāo)識(shí)主從庫的時(shí)間差異，但你能保證獲得主從庫不同的時(shí)間是穩(wěn)定可靠的嗎？ 如果不能保證在任何一刻主從庫的系統(tǒng)時(shí)間差異是準(zhǔn)確的，你有怎么能說得到的SBM 是準(zhǔn)確的。

準(zhǔn)確的獲得主從差異的方式稍微靠譜的

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

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

當(dāng)然目前已經(jīng)上了GTID 的復(fù)制方式的MYSQL 可以有更好的方式來判斷某個(gè)時(shí)間點(diǎn)主從復(fù)制是否有延遲，或者使用pt工具中的 beatheart 來進(jìn)行判斷也是可以的。

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

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

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