透過show slave status檢視到的Seconds_Behind_Master，從字面上來看，他是slave落後master的秒數，一般情況下，也確實這樣，我們可以透過Seconds_Behind_Master數字檢視slave是否落後於master，但是在一些環境中，他確會讓我們產生幻覺。
在http://dev.mysql.com/doc/refman/5.5/en/show-slave-status.html中，對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.之間的差值。
當在很快的網路連線情況下，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 statusG
*************************** 1. row ***************************
File: ******-bin.001291
Position: 896711460
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

mysql> show slave statusG
*************************** 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)

很明顯，slave已經落後master 好多了。

暫停複製

你可以在從機上用STOP SLAVE語句來停止複製，用START SLAVE來開始複製。用STOP SLAVE來停止從機執行二進位制日誌：

slave> STOP SLAVE;

當停止執行時，從機不再透過IO執行緒從主機讀取二進位制日誌並且不再透過SQL執行緒處理中繼日誌中還沒執行的事件。你可以指定執行緒的型別來獨立地停止IO或者SQL執行緒。

例如： slave> STOP SLAVE IO_THREAD;

如果你想在從機上執行備份或者其他任務，僅僅只處理來自主機的事件，停止SQL執行緒會是有效的。

IO執行緒會繼續從主機讀取變化，但這些變化不會馬上被應用，這樣當你再次開始從機操作的時候從機就能輕易地趕上進度。停止IO執行緒會讓中繼日誌裡的語句執行到中繼日誌停止接收新事件的那個點為止。

當你想要讓從機趕上從主機來的事件時，當你想在從機上做管理但要確保你已經在指定的點有最新的更新時，可用停止IO執行緒的選項。這種方法同樣也能用來停止從機上的事件執行，同時你在主機上做管理確保複製再次啟動的時候不會有大量積壓的事件要執行。

要再次開始執行復制，用START SLAVE語句：

slave> START SLAVE;

如果必要，你可以分別獨立啟動IO執行緒和SQL執行緒。

[@more@]

[MySQL管理] Seconds_Behind_Master 解析

相關文章