MySQL中slave監控的延遲情況分析
在MySQL複製環境中,我們通常只根據 Seconds_Behind_Master 的值來判斷SLAVE的延遲。這麼做大部分情況下尚可接受,但並不夠準確,而應該考慮更多因素。
首先,我們先看下SLAVE的狀態:
複製程式碼 程式碼如下:yejr@imysql.com [(none)]> show slave statusG
*************************** 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程式狀態:
複製程式碼 程式碼如下:yejr@imysql.com [(none)]> show full processlistG
*************************** 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值異常,比如變成負數,或者非常大。
來看下面幾個狀態:
?
12345678910111213141516171819202122232425262728293031323334 |
#設定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 statusG | 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 statusG | 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 statusG | 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 statusG | 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 STATUSG的請求,最後判斷二者binlog的差異,以及 Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差異。
例如:
在MASTER上執行SHOW BINARY LOGS 的結果是:
?
123456 |
+ ------------------+--------------+ | Log_name | File_size | + ------------------+--------------+ | mysql-bin.000009 | 1073742063 | | mysql-bin.000010 | 107374193 | + ------------------+--------------+
|
而在SLAVE上執行SHOW SLAVE STATUSG 的結果是:
?
1234567891011 |
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
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/758/viewspace-2811091/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Mysql 建立心跳錶來監控Replication的Slave是否延遲MySql
- 從Mysql slave system lock延遲說開去MySql
- 【MySQL】六、常見slave 延遲原因以及解決方法MySql
- metricbeat 監控 nginx 情況Nginx
- mysql同步問題之Slave延遲很大最佳化方法MySql
- Oracle11g 密碼延遲認證導致library cache lock的情況分析Oracle密碼
- zabbix應用-監控mysql slave 主從狀態MySql
- MySQL:slave 延遲一列 外來鍵檢查和自增加鎖MySql
- MySQL 中讀寫分離資料延遲MySql
- HBase工具之監控Region的可用和讀寫延時狀況
- 從庫延遲案例分析
- 級聯slave的延遲計算和query event exe time獲取方法
- mysql主從延遲複製MySql
- MySQL 延遲從庫介紹MySql
- Mysql 主從延時監控(pt-heartbeat)詳解MySql
- PostgreSQL中的複製延遲SQL
- 分析伺服器延遲的問題伺服器
- 使用C#如何監控選定資料夾中檔案的變動情況?C#
- mysql索引失效的情況MySql索引
- 故障分析 | MySQL 異地從庫複製延遲案例一則MySql
- Redis資料操作長延遲分析Redis
- Sql Server實時監控釋出訂閱複製Replication、subscription有多少延遲的方法SQLServer
- 在Linux中,mysql 如何減少主從複製延遲?LinuxMySql
- RabbitMQ延遲訊息的延遲極限是多少?MQ
- Java程式碼中,如何監控Mysql的binlog?JavaMySql
- EF中延遲載入的那些事
- Spring Boot 2.2 中的延遲載入Spring Boot
- 批次查詢並設定中通快遞延誤情況的方法
- mysql同步(複製)延遲的原因及解決方案MySql
- MySQL監控工具MySql
- MySQL之 從複製延遲問題排查MySql
- MySQL主從複製延遲解決方案MySql
- mysql索引不會命中的情況MySql索引
- 監控 SQL Server 的執行狀況SQLServer
- Spring Boot 2.2中的延遲初始化Spring Boot
- JavaScript 中的延遲載入屬性模式JavaScript模式
- 影片監控推流助手/極低延遲/支援N路批次多執行緒推流/264和265推流/監控轉網頁執行緒網頁
- Mysql 非同步複製延遲的原因及解決方案MySql非同步