MySQL中slave監控的延遲情形剖析。本站提示廣大學習愛好者：（MySQL中slave監控的延遲情形剖析）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL中slave監控的延遲情形剖析正文
在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.000327
Read_Master_Log_Pos: 668711237
Relay_Log_File: mysql-relay-bin.002999
Relay_Log_Pos: 214736858
Relay_Master_Log_File: mysql-bin.000327
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
***
Skip_Counter: 0
Exec_Master_Log_Pos: 654409041
Relay_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: 6
User: system user
Host:
db: NULL
Command: Connect
Time: 22005006
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 7
User: system user
Host:
db: NULL
Command: Connect
Time: 3293
State: Updating
Info: 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: 445167889 Exec_Master_Log_Pos: 445167889 Seconds_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: 445167889 Exec_Master_Log_Pos: 445167889 Seconds_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: 445182239 Exec_Master_Log_Pos: 445175263 Seconds_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: 445207174 Exec_Master_Log_Pos: 445196837 Seconds_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: 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 ***
這時候候，SLAVE現實的延遲應當是：
mysql-bin.000009 這個binlog中的binlog position 1073742063 和 SLAVE上讀取到的binlog position之間的差別延遲，即：
1073742063 - 654409041 = 419333022 個binlog event
而且還要加上 mysql-bin.000010這個binlog曾經發生的107374193個binlog event，共
107374193 + 419333022 = 526707215 個binlog event
