主从延迟监控工具percona-toolkit里面的pt-heartbeat
监控原理：在主库创建一张heartbeat表，里面记录了server-id和定时更新的时间戳，从库上的pt-heartbeat的monitor线程会复查该记录和当前系统时间进行对比
主要参数介绍：
–daemonize：后台执行
–create-table：在主库上创建心跳监控表
–database：-D连接数据库名称
–monitor：持续监控从库的延迟情况
–master-server-id：指定主库的server_id，不指定则从主库配置文件查找
–update：更新主库的心跳表
监控步骤：（主库56.11，从库56.12）
(1)首先在主库创建heartbeat心跳表，并执行更新时间戳操作，心跳表建立在zs库
./pt-heartbeat -uroot -proot123 --database zs --update --create-table --daemonize
(2)然后从库进行监控操作
./pt-heartbeat --master-server-id=3 --monitor --database zs --uroot -proot123
处理方法：
(1)5.7开启并行复制
(2)使用PXC架构，可以实现多节点写入和实时同步
(3)业务初期规划时采用合适的分库、分表策略，避免单表或单库过大，适当调整buffer pool的大小
(4)避免一些无用的I/O消耗，可以增加高转速的磁盘、SSD或PCIE-SSD设备，I/O调度选择deadline模式
(5)阵列级别选择RAID10，raid cache策略要使用WB，坚决不要使用WT
(6)避免让数据进行各种大量运算，让应用端承担压力或通过缓存完成
主从复制数据校验：
使用pt-table-checksum检查主从数据库一致性，再通过pt-table-sync工具修复不一致数据信息
pt-table-checksum参数：
–[no]check-replication-filters：是否检查复制的过滤器，默认是yes，建议不检查
–databases：指定需要被检查的数据库，多个库间可以用逗号分隔
–[no]check-binlog-format：是否检查binlog格式，默认为yes，建议不开启。因为在默认的row格式下会出错
–replicate：把checksum的信息写入到指定表中
–replicate-check-only：只显示不同步信息
–tables：指定需要被检查的表，多个表用逗号分隔
–where：大表校验使用where过滤条件
主库执行：pt-table-checksum --no-check-binlog-format --replicate=zs.checksums --databases=zs --table=tt -usz -p123456 -h 192.168.56.11
结果分析：
TS：完成检查的时间
ERRORS：检查时发生错误和警告的数量
DIFFS：0表示没有不一致发生，1表示出现不一致，当指定–no-replicate-check时会一直为0，当指定–replicate-check-only时会显示不同的信息
ROWS：表的行数
CHUNKS：被划分到表中的块的数目
SKIPPED：由于错误或警告过大跳过块的数目
原理：生成一张统计表，主库和从库都会针对被对比数据的表上所有字段进行hash函数运算并将结果记录在生成的统计表中。
pt-table-sync修复主从数据不一致：
参数：
–replicate：指定通过pt-table-checksum工具得到的表
–print：打印但不执行命令
–execute：执行命令
示例：主库执行：./pt-table-sync --replicate=zs.checksums -h=192.168.56.11,u=zs,p=123456 --print查看要执行的sql
./pt-table-sync --replicate=zs.checksums -h=192.168.56.11,u=zs,p=123456 --execute执行sql
