Seconds_Behind_Master不準確問題     Seconds_Behind_Mas析ter解

Seconds_Behind_Master不準確問題

      Seconds_Behind_Mas析ter解

1. Seconds_Behind_Master說明：

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

在mysql官網中中，對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執行的event的timestamp和io_thread復制好的 event的timestamp(簡寫為ts)進行比較，而得到的這么一個差值。我們都知道的relay-log和主庫的bin-log里面的內容完全一 樣，在記錄sql語句的同時會被記錄上當時的ts，所以比較參考的值來自于binlog。

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

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

當網絡環境特別糟糕的情況下，這個值確會讓我們產生幻覺，I/O thread同步很慢，每次同步過來，SQL thread就能立即執行，這樣，我們看到的Seconds_Behind_Master是0，而真正的，slave已經落后master很多很多。這時業務部門的同志們就會抱怨slave與master數據不對，而你看到的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． 有很長一段時間沒有數據提交，slave I/O thread time和slave SQL thread time都保持在舊值，比如A(但事實上master上的時間已經到A+I了)，這個時候主庫出現提交，slave I/O開始去和master同步binlog，slave I/O thread time更新到A+I，但是slave SQL thread time保持在A值，這時的seconds_behind_master=I，出現較大延遲，但其實是否出現延遲是不確定的

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

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

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

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

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