mysql-主从模式-分析从库延迟

查看主库当前有哪些binlog文件在磁盘上

show master logs;

查看从库同步情况

show slave status;

虽然show slave status输出的seconds_behind_master列理论上显示备库的延时，但由于各种各样的原因，并不是很准确：

备库seconds_behind_master值是通过将服务器当前的时间戳与二进制中的事件的事件戳相对比得到的，所以只有在执行事件时才能报告延时。
如果备库复制线程没有运行，就会报延迟为null
一些错误（例如主备的max_allowed_packet（mysql服务器端和客户端在一次传送数据包的过程当中最大允许的数据包大小）不匹配，或者网络不稳定）可能中断复制并且/或停止复制线程，但seconds_behind_master将显示为0而不是显示错误。
即使备库线程正在运行，备库有时候可能无法计算延时。如果发生这种情况。备库会报0或者null
一个大事务可能会导致延迟波动，例如一个事务更新数据长达一个小时，最后提交。这条更新将比它实际发生时间要晚一个小时才记录到二进制日志中。当备库执行这条语句时，会临时地报告备库延迟为一个小时，然后又很快变成0.
如果分发主库落后了，并且其本身也有已经追赶上它的备库，备库的延迟将显示为0，而事实上和源主库之间是有延迟的

解决办法时忽略seconds_behind_master的值，使用heartbeat record,具体如何实现后面再查资料。

确定主备是否一致

方法1：checksum table ：是mysql内部组件为表和数据生成校验值，但复制进行时此方法不可行。

方法2：pt-table-checksum：下面是组件概述，具体也没试过，先记录。

用于检测 MySQL 主、从库的数据是否一致。其原理是在主库执行基于 statement 的 SQL 语句来生成主库数据块的checksum，把相同的 SQL 语句传递到从库执行，并在从库上计算相同数据块的 checksum，最后，比较主从库上相同数据块的 checksum 值，由此判断主从数据是否一致。它能在非常大的表上工作的一个原因是，它把每个表分成行块，并检查每个块与单个替换。选择查询。它改变块的大小，使校验和查询在所需的时间内运行。分块表的目的是确保校验和不受干扰，并且不会在服务器上造成太多复制延迟或负载，而不是使用单个大查询处理每个表。这就是为什么默认情况下每个块的目标时间是 0.5 秒。