《Mysql實例MySQL中slave監控的延遲情況分析》要點：
本文介紹了Mysql實例MySQL中slave監控的延遲情況分析，希望對您有用。如果有疑問，可以聯系我們。
MYSQL入門在MySQL復制環境中,我們通常只根據 Seconds_Behind_Master 的值來判斷SLAVE的延遲.這么做大部分情況下尚可接受,但并不夠準確,而應該考慮更多因素.
MYSQL入門首先,我們先看下SLAVE的狀態：
MYSQL入門可以看到 Seconds_Behind_Master 的值是 3296,也就是SLAVE至少延遲了 3296 秒.
MYSQL入門我們再來看下SLAVE上的2個REPLICATION進程狀態：
MYSQL入門可以看到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；
MYSQL入門而IO線程的Time值則是該線程自從啟動以來的總時長(多少秒),如果系統時間在IO線程啟動后發生修改的話,可能會導致該Time值異常,比如變成負數,或者非常大.
MYSQL入門來看下面幾個狀態：
MYSQL入門
#設置pager,只查看關注的幾個status值
yejr@imysql.com [(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
yejr@imysql.com [(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: 445167889
Exec_Master_Log_Pos: 445167889
Seconds_Behind_Master: 0
#和上面一樣
yejr@imysql.com [(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: 445167889
Exec_Master_Log_Pos: 445167889
Seconds_Behind_Master: 0
#這時有活躍SQL了,Time值是和 Seconds_Behind_Master 一樣,即SQL線程比IO線程“慢”了1秒
yejr@imysql.com [(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: 445182239
Exec_Master_Log_Pos: 445175263
Seconds_Behind_Master: 1
#和上面一樣
yejr@imysql.com [(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: 445207174
Exec_Master_Log_Pos: 445196837
Seconds_Behind_Master: 1
MYSQL入門好了,最后我們說下如何正確判斷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上的差距；
MYSQL入門因此,相對更加嚴謹的做法是：
在第三方監控節點上,對MASTER和SLAVE同時發起SHOW BINARY LOGS和SHOW SLAVE STATUS\G的請求,最后判斷二者binlog的差異,以及 Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差異.
MYSQL入門例如：
在MASTER上執行SHOW BINARY LOGS 的結果是：
MYSQL入門
+------------------+--------------+
| Log_name | File_size |
+------------------+--------------+
| mysql-bin.000009 | 1073742063 |
| mysql-bin.000010 | 107374193 |
+------------------+--------------+
MYSQL入門而在SLAVE上執行SHOW SLAVE STATUS\G 的結果是：
MYSQL入門
Master_Log_File: mysql-bin.000009
Read_Master_Log_Pos: 668711237
Relay_Master_Log_File: mysql-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
***
Exec_Master_Log_Pos: 654409041
***
Seconds_Behind_Master: 3296
***
MYSQL入門這時候,SLAVE實際的延遲應該是：
mysql-bin.000009 這個binlog中的binlog position 1073742063 和 SLAVE上讀取到的binlog position之間的差異延遲,即：
MYSQL入門1073742063 - 654409041 = 419333022 個binlog event
MYSQL入門并且還要加上 mysql-bin.000010這個binlog已經產生的107374193個binlog event,共
MYSQL入門107374193 + 419333022 = 526707215 個binlog event
《Mysql實例MySQL中slave監控的延遲情況分析》是否對您有啟發，歡迎查看更多與《Mysql實例MySQL中slave監控的延遲情況分析》相關教程，學精學透。維易PHP學院為您提供精彩教程。
