参考文献：
《详解MySQL的主从同步实现方案》
作者：https://jiagou.blog.csdn.net/?type=blog
https://blog.csdn.net/zhanghuan0126/article/details/118058369
《mysql binlog日志 的三种格式》
作者：https://blog.csdn.net/u011334954?type=blog
https://blog.csdn.net/u011334954/article/details/121471967
《Mysql如何解决主从数据不一致的问题》
作者：https://blog.csdn.net/hanjinjuan?type=blog
https://blog.csdn.net/hanjinjuan/article/details/118784292?spm=1001.2014.3001.5502
一、MySQL 主从同步模式
MySQL 主从复制主要同步的是 binlog 日志，涉及三个线程。一个运行在主节点（log dump thread）,其余两个（I/O thread 和 SQL thread）运行在从节点，如下图所示：
这种异步模式，拥有了数据复制的性能和效率，但是数据一致性（主从）上表现较差，可以通过校验策略和工具，增加数据一致性的保护。
另外，基于事务（GTID）的同步方式，存在一些限制（如：主从两边存储引擎都要采用 InnoDB）。还有对 MySQL 版本的要求，如 MySQL 8.0 版本开始增加支持窗口函数等。当然还有同步模式，是否需要采用强一致性保障的半同步或全同步模式，都需要根据实际的业务场景进行挑选适配，本篇技术手册描述的是异步复制模式。
二、binlog 日志格式分类
参数 binlog_format 控制着 binlog 的格式，一种是 statement，一种是 row，还有一种是前面两种格式的混合，叫 mixed。
statement 格式记录 SQL 语句，复制过程会导致主从出现不一致的情况。row 格式的问题是会导致 binlog 占用空间（磁盘）大，同时耗费 I/O 影响整体性能，但是对于保护主从一致性上面表现好。所以，还有个 mixed 格式，它是前面两种格式的混合，MySQL 会自己判断 SQL 语句是否可能导致主从不一致，是的话就采用 row，否则就采用 statement，不过该模式对于性能的要求需要更多实践来验证，一般多见于主主架构。
三、主从数据一致性
在保证网络低延迟，主从服务器负载一致，max_allowed_packet 参数设置一致，自增键一致（从节点尽量 read-only），同步参数（sync_binlog 等）设置正确，MySQL 版本一致等的情况下，从以下两个方面进行主从一致性的保护和校验。
3.1、监控MySQL主从复制的监控项
Slave_IO_Running
该参数可作为 io_thread 的监控项，Yes 表示 io_thread 和主节点的连接正常并能完成复制工作，No 则说明与主节点通讯异常，多数情况是由主从间网络引起的问题。
Slave_SQL_Running
该参数代表 sql_thread 是否正常，具体就是语句是否执行通过，通常会遇到主键重复或某个表不存在等错误问题。
Seconds_Behind_Master
该参数经过计算得出值，该值为零的情况表示主从复制良好，延迟不存在。正值表示主从已经出现延时，数字越大表示从库落后主库越多。负值几乎很少见，该参数不支持负值，也就是不应该出现。
3.2、采用第三方工具进行主从一致性校验
工具介绍
Percona-toolkit
pt-table-checksum
负责监测MySQL主从数据一致性
pt-table-sync
负责当主从数据不一致时修复数据，让它们保存数据的一致性
pt-heartbeat
负责监控MySQL主从同步延迟