如果主库挂掉了
A->B A->C
A挂了只有BC了
要检查B/C是否同步完成并且检查谁更靠前
比较是否同步完成
这个时候的状态是io_thread:NO
if(master_log_file == reley_mast_log_file) and (read_master_log_post == exec_master_log_pos)
只有当这2个条件成立 我们才认为是同步完成的
b.Master_Log_File , c.Master_Log_File比较谁更大 就是同步的更完全
如果Master_Log_File都一样，那么比较 Exec_Master_Log_Pos
GTID会自动补上来 上面是传统模式
主从数据一致性怎么去校验（怎么确认主从是同步的？）
运行一段时间之后有一些不规范的操作搞成同步不一致问题
大的库分段检测 分析数据变换情况
pt-table-checksum
利用语句级复制，在主从库上对表分段进行校验，如果值不一样，说明就不同步了
pt-table-sync
利用语句复制，所有的修复都是在主库上完成的
https://www.percona.com/ Percona toolkit
下载最新版本
用yum安装 方便管理 把yum源弄进来
pt 大多是基于perl编写的
有部分的shell
同一组内的数据必须同一个端口
每组的端口号是全局唯一的
总结：
row 格式的binlog复制，有些情况下会比statement的快
原因是：sql_thread应用日志时,在有主建的情况，会利用主键更新数据
reset master 清掉Executed_Gtid_Set
gtid_purged 配置在slave上
slave只会读取gtid_purged这个GUID之后的数据之前的就不要了