主从延时（二）

对于Seconds_Behind_Master，很多人误以为是从库落后主库多少秒，从Seconds_Behind_Master单词的字面上看也是如此。

但是看看Seconds_Behind_Master的原理就明白了，其延迟是通过备库当前的时间戳减去SQL线程正在执行的SQL语句的时间戳计算出来的。

Seconds_Behind_Master描述延时是不太准确的，比如IO线程挂起了，主从有明显的延时，你会发现Seconds_Behind_Master可能还是0.

可以进行下面两个测试：

测试一：把备库当前时间进行调整。

测试二：断开备库的网络连接，你会发现Seconds_Behind_Master仍旧为0，备库过来slave-net-timeout秒还没有收到主库来的数据，它就会开始第一次重试。然后每过master-connect-retry秒，备库会再次尝试重连主库。直到重试了master-retry-count次，它才会放弃重试。如果重试的过程中，脸上了主库，那么它认为当前主库是好的，又会开始slave-net-timeout秒的等待。

slave-net-timeout的默认值是3600秒，master-connect-retry默认值是60秒，master-retry-count默认值为86400次。

slave-net-timeout的3600秒的默认值有些大，建议可以设置小一点，比如30秒。

可以使用percona的pt-heartbeat工具计算延时：

原理是在主库生成一张表，把这个表同步