MySQL 主從複制延遲監測

主從複制延遲的監測，我以前的做法是通過比較show slave status\G中的兩個變量的內插補點（Read_Master_Log_Pos，Exec_Master_Log_Pos），将內插補點設定為一個自己認為合理的範圍，Seconds_Behind_Master 沒有适用過，今天做一次解析:

    Seconds_Behind_Master 是通過比較 SQL THREAD 接受 events事件的時間戳（timestamp） 與IO THREAD  執行事件 events時間戳的內插補點--秒數來确定slave 落後于master多少。如果主從機器的時間不同，該時間的計算也是不會受影響的（如果時間發生異常，則這個秒數的就不怎麼可靠啦）

    如果slave SQL thread 或者 slave I/O thread 或者沒有連接配接到master，那麼該變量的值為NULL.

        0：表示master slave 複制沒有延遲（大部分情況下是這個樣子）。

    正值：表示slave落後于master的秒數。

    在網絡很快的情況下，I/O thread 能夠很快的從master上擷取binlog到slave的 relay-log。這種情況下， seconds_behind_master的值能真正代表slave落後于master的秒數。在網絡很差的情況下，I/O thread 同步很慢，slave收到的二進制日志資訊，SQL THREAD能夠很快的執行。這個時候 seconds_behind_master 是0，這種情況下 slave落後于master很多。

     為了排除網絡的幹擾，我們可以參考percona 的工具 pt-heartbeat.

     該工具可以計算出MySQL複制或者是PostgreSQL,它可以更新master或者監控複制。它還可以從my.cnf 讀取配置。它借助timestmp的比較實作的，首先需要保證主從伺服器時間必須要保持一緻，通過與相同的一個NTP server同步時鐘。它需要在主庫上建立一個heartbeat的表，裡面的時間戳ts就是目前的時間戳 now()，該結構也會被複制到從庫上。表建好以後，會在主庫上以背景程序的模式去執行一行更新操作的指令，定期去向表中的插入資料，這 個周期預設為1 秒，同時從庫也會在背景執行一個監控指令，與主庫保持一緻的周期+0.5S（預設0.5S延遲檢查）去比較，複制過來記錄的ts值與主庫上的同一條ts值，內插補點為0表示無延時，內插補點越大表示 延時的秒數越多。

    文法：

    舉例：

    在master上以守護程序的方式更新test.heartbeat表。

    在slave上監控複制延遲：

    隻檢查一次slave複制延遲：

    它由兩部分組成：第一部分 是--update 執行個體，它連接配接到master每--interval秒更新一張表的時間記錄。第二部分是--monitor或者--check執行個體 連接配接到slave。它會檢查新記錄中的時間戳來确定兩者之間的延遲。

    可以使用—create-table選項進行表的建立，或者手動建立。

    存儲引擎推薦使用memory存儲引擎。pt-heartbeat時間精确到0.01秒，master和slave的始終速率必須經過NTP服務進行同步。隻要檢查的時間差小于0.5秒，那麼pt-heartbeat will report zero seconds of delay。

本文轉自 位鵬飛 51CTO部落格，原文連結：http://blog.51cto.com/weipengfei/977998，如需轉載請自行聯系原作者