mysql主备延迟测试,高性能MySQL：测量备库延迟

一个比较普遍的问题是如何监控备库落后主库的延迟有多大。虽然SHOW SLAVE STATUS输出的Seconds_ behind master 列理论上显示了备库的延时，但由于各种各样的原因，并不总是准确的:

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

(2)如果备库复制线程没有运行，就会报延迟为NULL。

(3)一些错误 (例如主备的max allowed packet 不匹配，或者网络不稳定)可能中断复制并且/或者停止复制线程，但Seconds_ behind master 将显示为0而不是显示错误。

(4)即使备库线程正在运行，备库有时候可能无法计算延时。如果发生这种情况，备库会报0或者NULL。

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

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

解决这些问题的办法是忽略Seconds_ behind_master 的值，并使用一些可以直接观察和衡量的方式来监控备库延迟。最好的解决办法是使用hearbeat_record,这是一个在主库上会每秒更新一次的时间戳。为了计算延时，可以直接用备库当前的时间戳减去心跳记录的值。这个方法能够解决刚刚我们提到的所有问题，另外个额外的好处是我们还可以通过时间戳知道备库当前的复制状况。包含在Percona_Toolkit 里的pl-heartbeat脚本是“复制心跳"最流行的一种实现。

心跳还有其他好处，记录在二进制日志中的心跳记录拥有许多用途，例如在一些很难解决的场景下可以用于灾难恢复。

我们刚刚所描述的几种延迟指标都不能表明备库需要多长时间才能赶上主库。这依赖于许多因素，例如备库的写人能力以及主库持续写人的次数。关于这个话题，详细参阅前面介绍的“何时备库开始延迟”。