如何監控mysql主從之間的延遲
來自： http://my.oschina.net/kkrgwbj/blog/614446
前言：
日常工作中，對于MYSQL主從復制的檢查有兩方面
保證復制的整體結構是否完整；
需要檢查數據是否一致；
對于前者我們可以通過監控復制線程是否工作正常以及主從延時是否在容忍范圍內，對于后者則可以通過分別校驗主從表中數據的md5碼是否一致，來保證數據一致，可以使用Maatkit工具包中的mk-table-checksum工具去檢查。
本文檔介紹下關于如何檢查主從延遲的問題。
主從延遲判斷的方法，通常有兩種方法：Seconds_Behind_Master和mk-heartbeat
方法1. 通過監控show slave status\G命令輸出的Seconds_Behind_Master參數的值來判斷，是否有發生主從延時。
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host:
Master_User:
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000022
Read_Master_Log_Pos: 879720441
Relay_Log_File: ***-relay-bin.000011
Relay_Log_Pos: 250520472
Relay_Master_Log_File: mysql-bin.000022
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: retail
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 879720441
Relay_Log_Space: 565133487
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2
1 row in set (0.00 sec)
以上是show slave status\G的輸出結果，這些結構給我們的監控提供了很多有意義的參數。
Slave_IO_Running：該參數可作為io_thread的監控項，Yes表示io_thread的和主庫連接正常并能實施復制工作，No則說明與主庫通訊異常，多數情況是由主從間網絡引起的問題；
Slave_SQL_Running：該參數代表sql_thread是否正常，具體就是語句是否執行通過，常會遇到主鍵重復或是某個表不存在。
Seconds_Behind_Master：是通過比較sql_thread執行的event的timestamp和io_thread復制好的event的timestamp(簡寫為ts)進行比較，而得到的這么一個差值；
NULL—表示io_thread或是sql_thread有任何一個發生故障，也就是該線程的Running狀態是No，而非Yes。
0 — 該值為零，是我們極為渴望看到的情況，表示主從復制良好，可以認為lag不存在。
正值 — 表示主從已經出現延時，數字越大表示從庫落后主庫越多。
負值 — 幾乎很少見，我只是聽一些資深的DBA說見過，其實，這是一個BUG值，該參數是不支持負值的，也就是不應該出現。
備注Seconds_Behind_Master的計算方式可能帶來的問題：我們都知道的relay-log和主庫的bin-log里面的內容完全一樣，在記錄sql語句的同時會被記錄上當時的ts，所以比較參考的值來自于binlog，其實主從沒有必要與NTP進行同步，也就是說無需保證主從時鐘的一致。你也會發現，其實比較真正是發生在io_thread與sql_thread之間，而io_thread才真正與主庫有關聯，于是，問題就出來了，當主庫I/O負載很大或是網絡阻塞，io_thread不能及時復制binlog（沒有中斷，也在復制），而sql_thread一直都能跟上io_thread的腳本，這時Seconds_Behind_Master的值是0，也就是我們認為的無延時，但是，實際上不是，你懂得。這也就是為什么大家要批判用這個參數來監控數據庫是否發生延時不準的原因，但是這個值并不是總是不準，如果當io_thread與master網絡很好的情況下，那么該值也是很有價值的。之前，提到Seconds_Behind_Master這個參數會有負值出現，我們已經知道該值是io_thread的最近跟新的ts與sql_thread執行到的ts差值，前者始終是大于后者的，唯一的肯能就是某個event的ts發生了錯誤，比之前的小了，那么當這種情況發生時，負值出現就成為可能。
方法2. mk-heartbeat：Maatkit萬能工具包中的一個工具，被認為可以準確判斷復制延時的方法。
mk-heartbeat的實現也是借助timestmp的比較實現的，它首先需要保證主從服務器必須要保持一致，通過與相同的一個NTP server同步時鐘。它需要在主庫上創建一個heartbeat的表，里面至少有id與ts兩個字段，id為server_id，ts就是當前的時間戳now()，該結構也會被復制到從庫上，表建好以后，會在主庫上以后臺進程的模式去執行一行更新操作的命令，定期去向表中的插入數據，這個周期默認為1秒，同時從庫也會在后臺執行一個監控命令，與主庫保持一致的周期去比較，復制過來記錄的ts值與主庫上的同一條ts值，差值為0表示無延時，差值越大表示延時的秒數越多。我們都知道復制是異步的ts不肯完全一致，所以該工具允許半秒的差距，在這之內的差異都可忽略認為無延時。這個工具就是通過實打實的復制，巧妙的借用timestamp來檢查延時；