复制监控中的Seconds_behind_master并不可信

测试备库延迟

虽然SHOW SLAVE STATUS输出的Seconds_behind_master列理论上显示了备库的延时，但由于各样的原因，并不总是准确的：

1.备库Seconds_Behind_Master值是通过将服务器当前的时间戳与二进制日志中的事件时间戳相对比得到的，所以只有在执行事件时才能报告延时。

2.如果备库复制线程没有运行,就会报延迟null。

3.一些错误（例如主备的max_allowed_packet不匹配，或者网络不稳定）可能中断复制并且/或者停止复制线程，备库有时可能无法计算延时。如果发生这种情况备库会报0或者null

4.一个大事务可能会导致延迟波动，例如，有一个事务更新数据长达一个小时，最后提交。这条更新将比它实际发生时间要晚一个小时才记录到二进制日志中。当备库执行这条语句时，会临时地报告备库延迟为一个小时，然后又很快变成0

5.如果分发主库落后了，并且其本身也有已经追赶上它的备库，备库的延迟将显示为0，而事实上和源主库是有延迟的。 

解决办法是不要看这个值，最好的办法是使用heartbeat record，这是一个在主库上会每秒更新一次的时间戳。用备库当前时间减去心跳时间戳来比较。包含在Percona Toolkit里的pt-heartbeat脚本是“复制心跳”最流行的一种实现。

  

确定主备是否一致

复制延时或网络问题并总是会让主备数据不完全一致。主备一致应该是一种规范，而不是例外，也就是说，检查你的主备一致性应该是一个日常工作，特别是是当使用备库来做备份时尤为重要。

Percona Toolkit里的pt-table-checksum能够用于确认主备库数据是事一致。