bitsCN.com
在mysql的主从环境中，我们可以通过在slave上执行show slave status来查看slave的一些状态信息，其中有一个比较重要的参数seconds_behind_master。那么你是否明白它的真正含义以及它是怎么计算的呢？
在之前我一直误以为Seconds_Behind_Master是表示slave比master落后多少，如果这个值为0的表示主从已经处于一致了（在非同步模式下，现在官方最多也只在5.5中增加了半同步复制）。但是最近我终于认识到之前的错误理解。首先我们需要明白的一点：Seconds_Behind_Master表示slave上SQL thread与IO thread之间的延迟，我们都知道在MySQL的复制环境中，slave先从master上将binlog拉取到本地（通过IO thread），然后通过SQL thread将binlog重放，而Seconds_Behind_Master表示本地relaylog中未被执行完的那部分的差值。
手册上的定义：
In essence, this field measures the time difference in seconds between the slave SQL thread and the slave I/O thread.
所以如果slave拉取到本地的relaylog（实际上就是binlog，只是在slave上习惯称呼relaylog而已）都执行完，此时通过show slave status看到的会是0，那么Seconds_Behind_Master的值为0是否表示主从已经处于一致了呢?答案几乎是否定的！为什么几乎是否定的？因为绝大部分的情况下复制都是异步的，异步就意味着master上的binlog不是实时的发送到slave上，所以即使Seconds_Behind_Master的值为0依然不能肯定主从处于一致，这也是我之前强调非同步复制的原因（现在已经有公司在做同步复制了，比如网易自己实现了VSR，VirtualSynchronized Replication，由于同步复制性能较差，所以网易再实现同步复制的同时还打了group commit的补丁）。所以如果我们要以这个参数来估计主从延迟多久的话至少得在一个比较好的网络环境中，这样才能保证几乎master上的binlog都已经发送到slave上。
上面解释了Seconds_Behind_Master这个值的真正含义，那么它的值到底是怎么计算出来的呢？实际上在binlog中每个binlog events都会附上执行时的timestamp，所以在在确定Seconds_Behind_Master的值时MySQL是通过比较当前系统的时间戳与当前SQL thread正在执行的binlog event的上的时间戳做比较，这个差值就是Seconds_Behind_Master的值。也许你会有疑问那要是两台服务器之间的时钟不一致怎么办？确实会存在这种情况，那么此时这个值的可靠性就不大了，手册上对此也进行了说明：
This time difference computation works even if the master and slave do not have identical clock times, provided that the difference,
computed when the slave I/O thread starts, remains constant from then on. Any changes—including NTP updates—can lead to clock
skews that can make calculation of Seconds_Behind_Master less reliable
Seconds_Behind_Master的值除了是非负数之外还可能是NULL，它是由如下几种情况导致的：SQL thread没运行/IO thread没运行/slave没有连接到master。
接下来再简单介绍一下异步复制/半同步复制之间的区别。
异步复制，master上的操作记录binlog的同时不关心binlog是否已经被slave接收。
半同步复制，master上的操作记录binlog的同时会关心binlog是否被slave接受。但是由于它的处理逻辑问题可能丢一个事务，如下图所示：
这样的处理流程存在一个问题，当存储引擎提交（storage commit）后，此时如果master挂了那么会存在主从不一致，对于这个问题orczhou好像自己对源码进行了修改更改storage commit的顺序来达到一个增强的半同步复制。
对Seconds_Behind_Master就解释到这里，希望对你也能有点帮助。
