Seconds_Behind_Master不準(zhǔn)確問(wèn)題     Seconds_Behind_Mas析ter解

Seconds_Behind_Master不準(zhǔn)確問(wèn)題

      Seconds_Behind_Mas析ter解

1. Seconds_Behind_Master說(shuō)明：

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

在mysql官網(wǎng)中中，對(duì)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是通過(guò)比較sql_thread執(zhí)行的event的timestamp和io_thread復(fù)制好的 event的timestamp(簡(jiǎn)寫(xiě)為ts)進(jìn)行比較，而得到的這么一個(gè)差值。我們都知道的relay-log和主庫(kù)的bin-log里面的內(nèi)容完全一 樣，在記錄sql語(yǔ)句的同時(shí)會(huì)被記錄上當(dāng)時(shí)的ts，所以比較參考的值來(lái)自于binlog。

3. 導(dǎo)致Seconds_Behind_Master不準(zhǔn)確的因素‘

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

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

其實(shí)這個(gè)時(shí)候，我們看下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． 有很長(zhǎng)一段時(shí)間沒(méi)有數(shù)據(jù)提交，slave I/O thread time和slave SQL thread time都保持在舊值，比如A(但事實(shí)上master上的時(shí)間已經(jīng)到A+I了)，這個(gè)時(shí)候主庫(kù)出現(xiàn)提交，slave I/O開(kāi)始去和master同步binlog，slave I/O thread time更新到A+I，但是slave SQL thread time保持在A值，這時(shí)的seconds_behind_master=I，出現(xiàn)較大延遲，但其實(shí)是否出現(xiàn)延遲是不確定的

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

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

4. 對(duì)于second_behind_master不準(zhǔn)確的解決方案

mk-heartbeat，Maatkit萬(wàn)能工具包中的一個(gè)工具，被認(rèn)為可以準(zhǔn)確判斷復(fù)制延時(shí)的方法。

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