Mysql Seconds_Behind_Master 解析

原文地址：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进行比较得出复制是否能跟上主的状态。