原文地址：http://blog.itpub.net/23721637/viewspace-1050178/

通過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.001291Position: 896711460Binlog_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 eventMaster_Host: 10.69.6.163Master_User: replicaMaster_Port: 3801Connect_Retry: 60Master_Log_File: *****-bin.001211Read_Master_Log_Pos: 278633662Relay_Log_File: *****-relay-bin.002323Relay_Log_Pos: 161735853Relay_Master_Log_File: *******-bin.001211Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0Last_Error: Skip_Counter: 0Exec_Master_Log_Pos: 278633662Relay_Log_Space: 161735853Until_Condition: NoneUntil_Log_File: Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 01 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線程。

PS：

別人對于seconds_behind_master的解釋：

Read_Master_Log_Pos和Exec_Master_Log_Pos位置之間的時間差值吧.這個值只能在一定程度上說明復制良好，但是經常 不準確，比如主從之間網絡環境很差的時候，可能主和從的數據差異很大，但是復制過來的日志都能被slave的sql線程執行完 成，seconds_behind_master此時為0。可以通過在主上show master status/G的Position,和從執行show slave status/G的 Read_Master_Log_Pos和Exec_Master_Log_Pos進行比較得出復制是否能跟上主的狀態。