MySQL从库Seconds_Behind_Master瞬间飙升又很快恢复

缘由

---

收到系统告警如下：

告警一次，Seconds_Behind_Master的值到了11083795，很快就恢复。

---

原因

---

网上查找相似问题发下如下文章：
https://www.jianshu.com/p/d01190078cf5
看后觉得不错。但是本人并未测试出相同的结果。可能是数据量的问题。

于是我开始查找官方文档，与Seconds_Behind_Master相关内容如下：

Seconds_Behind_Master: The number of seconds that the slave SQL thread is behind processing the master binary log. A high number (or an increasing one) can indicate that the slave is unable to handle events from the master in a timely fashion.

A value of 0 for Seconds_Behind_Master can usually be interpreted as meaning that the slave has caught up with the master, but there are some cases where this is not strictly true. For example, this can occur if the network connection between master and slave is broken but the slave I/O thread has not yet noticed this—that is, slave_net_timeout has not yet elapsed.

It is also possible that transient values for Seconds_Behind_Master may not reflect the situation accurately. When the slave SQL thread has caught up on I/O, Seconds_Behind_Master displays 0; but when the slave I/O thread is still queuing up a new event, Seconds_Behind_Master may show a large value until the SQL thread finishes executing the new event. This is especially likely when the events have old timestamps; in such cases, if you execute SHOW SLAVE STATUS several times in a relatively short period, you may see this value change back and forth repeatedly between 0 and a relatively large value.

大体意思是说，Seconds_Behind_Master这个值代表从库SQL线程处理主库binlog时落后的时间(关于这个时间是怎么计算的下面单独说一下)，值比较大时，代表从库不能及时的处理

当值为0时，基本上可以认为是同步的，但是特殊的情况下是不正确的，比如，如果主服务器和从服务器之间的网络连接出问题，但从服务器I/O线程还没有意识到（在slave_net_timeout时间内），那么就会发生值为0但是并未同步的情况。

也有可能瞬间的值对于Seconds_Behind_Master可能不能准确反映情况。当从库SQL线程赶上I/O线程时，Seconds_Behind_Master显示为0;但是，当从库I/O线程仍在排队等待一个新事件时，Seconds_Behind_Master可能会显示一个很大的值，直到SQL线程完成这个新事件的执行完成为止。尤其当事件有旧的时间戳时，这是很有可能的;在这种情况下，如果您在相对较短的时间内多次执行show slave status，您可能会看到这个值在0和相对较大的值之间反复地来回转换。

---

结论

---

看完官方文档的内容可以认为瞬间飙升又很快恢复的这种情况其实算是正常的。并非同步有特别大的延迟。

而且通过官方文档这个说明，又发现了个问题就是我们并不能单纯的依靠Seconds_Behind_Master的值来确定主从之间的延迟。因为在网络问题的情况下，很有可能Seconds_Behind_Master的值为0，但是并不同步的情况。这个问题的解决办法可以参考：请不要用SECONDS_BEHIND_MASTER来衡量MYSQL主备的延迟时间【转】和seconds_behind_master的陷阱和pt-heartbeat两篇文章。

还有一个结论是关于Seconds_Behind_Master的值是如何计算的。
我看网上的各种文章说的计算方式大概有这么几种：

1. 从服务器系统时间和SQL线程正在执行事件的时间戳差值
2. 从服务器SQL线程和从服务器I/O线程之间的时间差值
3. I/O线程拉取的最后一个事件的时间戳和SQL线程正在应用的事件的时间戳的差值

个人愚见，认为这几种说的都有道理，第一种在同步复制的情况下完全正确，因为此时IO线程正在源源不断的拉取binlog并且最新事件时间戳和系统时间一致。第二种在同步复制的情况下，一致。第三种说的比较完善，就是IO线程拉取的最后一个事件的时间戳和SQL线程正应用事件的时间戳的差值。在同步情况下和前两种结果一致，在IO线程有延迟的时候，所得的值相比前两种而言我认为更准确。

所以认为是IO线程获得的最新事件的时间戳和SQL线程正在应用事件的时间戳的差值。

补充：
对如何计算Seconds_Behind_Master的认知可以参考：
参考此篇文章http://blog.csdn.net/huyi91/article/details/77529838
计算中也会参考系统时间，源码计算貌似很复杂，不是简单的某个时间减某个时间。。。