MySQL複製中slave延遲監控

標籤：style   http   color   os   io   strong   ar   for   2014   

 MySQL複製中slave延遲監控

http://imysql.com/2014/08/30/mysql-faq-howto-monitor-slave-lag.shtml

在MySQL複製環境中，我們通常只根據 Seconds_Behind_Master 的值來判斷SLAVE的延遲。這麼做大部分情況下尚可接受，但並不夠準確，而應該考慮更多因素。

首先，我們先看下SLAVE的狀態：

[email protected] [(none)]> show slave status\G*************************** 1. row ***************************Slave_IO_State: Waiting for master to send event***Master_Log_File: mysql-bin.000327Read_Master_Log_Pos: 668711237Relay_Log_File: mysql-relay-bin.002999Relay_Log_Pos: 214736858Relay_Master_Log_File: mysql-bin.000327Slave_IO_Running: YesSlave_SQL_Running: Yes***Skip_Counter: 0Exec_Master_Log_Pos: 654409041Relay_Log_Space: 229039311***Seconds_Behind_Master: 3296***

可以看到 Seconds_Behind_Master 的值是 3296，也就是SLAVE至少延遲了 3296 秒。

我們再來看下SLAVE上的2個REPLICATION進程狀態：

[email protected] [(none)]> show full processlist\G*************************** 1. row ***************************Id: 6User: system userHost:db: NULLCommand: ConnectTime: 22005006State: Waiting for master to send eventInfo: NULL*************************** 2. row ***************************Id: 7User: system userHost:db: NULLCommand: ConnectTime: 3293State: UpdatingInfo: UPDATE ** SET ** WHERE **

可以看到SQL線程一直在執行UPDATE操作，注意到 Time 的值是 3293，看起來像是這個UPDATE操作執行了3293秒，一個普通的SQL而已，肯定不至於需要這麼久。 實際上，在REPLICATION進程中，Time 這列的值可能有幾種情況： 1、SQL線程當前執行的binlog（實際上是relay log）中的timestamp和IO線程最新的timestamp的差值，這就是通常大家認為的 Seconds_Behind_Master 值，並不是某個SQL的實際執行耗時； 2、SQL線程當前如果沒有活躍SQL在執行的話，Time值就是SQL線程的idle time；

而IO線程的Time值則是該線程自從啟動以來的總時間長度（多少秒），如果系統時間在IO線程啟動後發生修改的話，可能會導致該Time值異常，比如變成負數，或者非常大。

來看下面幾個狀態：

#設定pager，只查看關注的幾個status值[email protected] [(none)]> pager cat | egrep -i ‘system user|Exec_Master_Log_Pos|Seconds_Behind_Master|Read_Master_Log_Pos‘#這是沒有活躍SQL的情況，Time值是idle time，並且 Seconds_Behind_Master 為 0[email protected] [(none)]> show processlist; show slave status\G| 6 | system user | | NULL | Connect | 22004245 | Waiting for master to send event | NULL || 7 | system user | | NULL | Connect | 13 | Has read all relay log;**Read_Master_Log_Pos: 445167889Exec_Master_Log_Pos: 445167889Seconds_Behind_Master: 0#和上面一樣[email protected] [(none)]> show processlist; show slave status\G| 6 | system user | | NULL | Connect | 22004248 | Waiting for master to send event | NULL || 7 | system user | | NULL | Connect | 16 | Has read all relay log;**Read_Master_Log_Pos: 445167889Exec_Master_Log_Pos: 445167889Seconds_Behind_Master: 0#這時有活躍SQL了，Time值是和 Seconds_Behind_Master 一樣，即SQL線程比IO線程“慢”了1秒[email protected] [(none)]> show processlist; show slave status\G| 6 | system user | | NULL | Connect | 22004252 | Waiting for master to send event | NULL || 7 | system user | | floweradmin | Connect | 1 | Updating | update **Read_Master_Log_Pos: 445182239Exec_Master_Log_Pos: 445175263Seconds_Behind_Master: 1#和上面一樣[email protected] [(none)]> show processlist; show slave status\G| 6 | system user | | NULL | Connect | 22004254 | Waiting for master to send event | NULL || 7 | system user | | floweradmin | Connect | 1 | Updating | update **Read_Master_Log_Pos: 445207174Exec_Master_Log_Pos: 445196837Seconds_Behind_Master: 1

好了，最後我們說下如何正確判斷SLAVE的延遲情況： 1、首先看 Relay_Master_Log_File 和 Master_Log_File 是否有差異； 2、如果Relay_Master_Log_File 和 Master_Log_File 是一樣的話，再來看Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差異，對比SQL線程比IO線程慢了多少個binlog事件； 3、如果Relay_Master_Log_File 和 Master_Log_File 不一樣，那說明延遲可能較大，需要從MASTER上取得binlog status，判斷當前的binlog和MASTER上的差距；

因此，相對更加嚴謹的做法是： 在第三方監控節點上，對MASTER和SLAVE同時發起SHOW BINARY LOGS和SHOW SLAVE STATUS\G的請求，最後判斷二者binlog的差異，以及 Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差異。

例如： 在MASTER上執行SHOW BINARY LOGS 的結果是：

+------------------+--------------+| Log_name | File_size |+------------------+--------------+| mysql-bin.000009 | 1073742063 || mysql-bin.000010 | 107374193 |+------------------+--------------+

而在SLAVE上執行SHOW SLAVE STATUS\G 的結果是：

Master_Log_File: mysql-bin.000009 Read_Master_Log_Pos: 668711237Relay_Master_Log_File: mysql-bin.000009Slave_IO_Running: YesSlave_SQL_Running: Yes***Exec_Master_Log_Pos: 654409041***Seconds_Behind_Master: 3296***

這時候，SLAVE實際的延遲應該是： mysql-bin.000009 這個binlog中的binlog position 1073742063 和 SLAVE上讀取到的binlog position之間的差異延遲，即：

1073742063 - 668711237 = 405030826 個binlog event

並且還要加上 mysql-bin.000010這個binlog已經產生的107374193個binlog event，共

107374193 + 405030826 = 512405019 個binlog event

後記更新：

可以在MASTER上維護一個監控表，它只有一個欄位，儲存這最新最新時間戳記（高版本可以採用event_scheduler來更新，低版本可以用cron結合自動迴圈指令碼來更新），在SLAVE上讀取該欄位的時間，只要MASTER和SLAVE的系統時間一致，即可快速知道SLAVE和MASTER延遲差了多少。不過，在高並發的系統下，這個時間戳記可以細化到毫秒，否則哪怕時間一致，也是有可能會延遲數千個binlog event的。

MySQL複製中slave延遲監控