Seconds_Behind_Master不準確問題

創(chuàng)新互聯(lián)建站專注于輝南網(wǎng)站建設服務及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供輝南營銷型網(wǎng)站建設，輝南網(wǎng)站制作、輝南網(wǎng)頁設計、輝南網(wǎng)站官網(wǎng)定制、重慶小程序開發(fā)服務，打造輝南網(wǎng)絡公司原創(chuàng)品牌,更為您提供輝南網(wǎng)站排名全網(wǎng)營銷落地服務。

      Seconds_Behind_Mas析ter解

 

1. Seconds_Behind_Master說明：

通過show slave status查看到的Seconds_Behind_Master，從字面上來看，他是slave落后master的秒數(shù)，一般情況下，也確實這樣，我們可以通過Seconds_Behind_Master數(shù)字查看slave是否落后于master，但是在一些環(huán)境中，他確會讓我們產(chǎn)生幻覺。

在MySQL官網(wǎng)中中，對Seconds_Behind_Master的有一句話闡述如下：

In essence, this field measures the time difference in seconds between the slave SQL thread and the slave I/O thread.          

很清晰的表明，該值是SQL thread I/O thread.之間的差值。

 

2. Seconds_Behind_Master原理

Seconds_Behind_Master是通過比較sql_thread執(zhí)行的event的timestamp和io_thread復制好的event的timestamp(簡寫為ts)進行比較，而得到的這么一個差值。我們都知道的relay-log和主庫的bin-log里面的內容完全一 樣，在記錄sql語句的同時會被記錄上當時的ts，所以比較參考的值來自于binlog。

 

3.導致Seconds_Behind_Master不準確的因素‘

a.當在很快的網(wǎng)絡連接情況下，I/O thread. 能很快的從master的binlog中同步sql到slave的relay-log里，這樣，這個值就能基本確定的slave落后master的秒數(shù)

當網(wǎng)絡環(huán)境特別糟糕的情況下，這個值確會讓我們產(chǎn)生幻覺，I/O thread同步很慢，每次同步過來，SQL thread就能立即執(zhí)行，這樣，我們看到的Seconds_Behind_Master是0，而真正的，slave已經(jīng)落后master很多很多。這時業(yè)務部門的同志們就會抱怨slave與master數(shù)據(jù)不對，而你看到的Seconds_Behind_Master確實為0，你就會非常的郁悶了。

其實這個時候，我們看下master，與slave就能很好的確定這期間的原因。

mysql> show master status\G

*************************** 1. row ***************************

File: ******-bin.001291

Position: 896711460

Binlog_Do_DB: 

Binlog_Ignore_DB: 

1 row in set (0.00 sec)

 

mysql> show slave status\G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 10.69.6.163

Master_User: replica

Master_Port: 3801

Connect_Retry: 60

Master_Log_File: *****-bin.001211

Read_Master_Log_Pos: 278633662

Relay_Log_File: *****-relay-bin.002323

Relay_Log_Pos: 161735853

Relay_Master_Log_File: *******-bin.001211

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB: 

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: 278633662

Relay_Log_Space: 161735853

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

1 row in set (0.00 sec)

 

b． 有很長一段時間沒有數(shù)據(jù)提交，slave I/O thread time和slave SQL thread time都保持在舊值，比如A(但事實上master上的時間已經(jīng)到A+I了)，這個時候主庫出現(xiàn)提交，slave I/O開始去和master同步binlog，slave I/O thread time更新到A+I，但是slave SQL thread time保持在A值，這時的seconds_behind_master=I，出現(xiàn)較大延遲，但其實是否出現(xiàn)延遲是不確定的

 

c．Mysql主從同步延遲受到多種因素影響， 比如大事務， 從庫查詢壓力， 網(wǎng)路延遲等； 這些比較常見； 但還受到主從機器系統(tǒng)時鐘差的影響，這一點可能容易被忽視。

 

d．總結：由此看來 我們分析Seconds_Behind_Master這個參數(shù)的時候應該結合主從之間binlog日志的文件名和具體的網(wǎng)絡環(huán)境來看。當然在網(wǎng)絡暢通的情況下我們可以直接通過這個參數(shù)來看出主從之間的延遲。不過總的來說seconds_behind_master受影響的因素很多不能保持準確。

 

4.對于second_behind_master不準確的解決方案

mk-heartbeat，Maatkit萬能工具包中的一個工具，被認為可以準確判斷復制延時的方法。

mk-heartbeat的實現(xiàn)也是借助timestmp的比較實現(xiàn)的，它首先需要保證主從服務器必須要保持一致，通過與相同的一個NTP server同步時鐘。它需要在主庫上創(chuàng)建一個heartbeat的表，里面至少有id與ts兩個字段，id為server_id，ts就是當前的時間戳now()，該結構也會被復制到從庫上，表建好以后，會在主庫上以后臺進程的模式去執(zhí)行一行更新操作的命令，定期去向表中的插入數(shù)據(jù)，這個周期默認為1秒，同時從庫也會在后臺執(zhí)行一個監(jiān)控命令，與主庫保持一致的周期去比較，復制過來記錄的ts值與主庫上的同一條ts值，差值為0表示無延時，差值越大表示 延時的秒數(shù)越多。我們都知道復制是異步的ts不肯完全一致，所以該工具允許半秒的差距，在這之內的差異都可忽略認為無延時。這個工具就是通過實打實的復 制，巧妙的借用timestamp來檢查延時

 

文章題目：Seconds_Behind_Master不準確問題  Seconds_Behind_Mas析ter解
網(wǎng)頁路徑：http://aaarwkj.com/article40/peeceo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供用戶體驗、Google、建站公司、網(wǎng)站營銷、網(wǎng)站建設、網(wǎng)頁設計公司

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)