引言
通过上一节的学习，我们知道在mysql一主一从集群中，是依靠数据库的Binlog（二进制日志）来进行主从同步的，主节点执行完一个DDL、DML语句后，会将此语句记录到主库的binlog中，然后由IO线程将日志传输到从库，由SQL线程来replay binlog，从而实现主从同步。但是，这种机制是100%可靠的么？会不会有例外情况？大家可以思考一下下面几种情况，是否会造成主备不一致：
（1）一张表上存在多个索引，在主库上执行delete from tab1 limit 1语句，从库上是否会删除了同一条记录？我们知道如果表上有多个索引，在不同的节点上执行时有可能使用到不同的索引，最终引起的结果是可能会删除不同的记录。
（2）主库上执行insert into t1 values(now())语句，从库在1分钟后才执行此条记录，从库上插入的时间与主库是一致的么？
binlog深入了解
在回答上面两个问题之前，我们首先深入了解一下数据库的binlog，到底binlog里记录了哪些信息呢。
delete的binlog解析
首先，我们创建了一张测试表，表结构如下图：
图1：测试表tab1的表结构
接着，向表内插入4条记录：
图2：测试表tab1内的4条记录
执行语句delete from tab1 limit 1，然后使用mysqlbinlog工具来解析一下binlog：
图3：delete的binlog解析结果
我们可以看到，虽然我们执行时没有where条件，但是在binlog里自动加上了where条件@1=1 @2=’abc’，这样当这条记录传到从机上时，便可以保证删除了同一条记录。
insert的binlog解析
另外，我们再新建一张表，然后执行insert into tab2(1,now())，然后再用mysqlbinlog来看下binlog里的内容：
图4：insert的binlog解析结果
原来binlog在记录sql语句的同时，多记录了一条SET TIMESTAMP=1586956197的语句，用SET TIMESTAMP命令约定了接下来的now()函数的返回时间。因此，不论这个binlog是1分钟之后被备库执行，还是3天后用来恢复这个库的备份，这个insert语句插入的行，值都是固定的。也就是说，通过这条SET TIMESTAMP命令，MySQL就确保了主备数据的一致性。
binlog小结
通过上面的分析，我们了解了binlog里不光记录了sql执行语句，同时，也记录了一些上下文信息。因此，我们在使用binlog做数据恢复时，不能只执行里面的sql语句，要连同上下文的信息一起执行。正确用binlog来恢复数据的标准做法是，用mysqlbinlog工具解析出来，然后把解析结果整个发给MySQL执行。
总结
此文只是给大家简单介绍了一下mysql binlog的原理，实际上binlog还有许多本文未讲到的东西，若感兴趣可以查看相关的资料进行学习。
本文用两节的内容给大家介绍了mysql的主从实现原理、mysql如何保证主从一致。
相关内容
云数据库高可用——Series1：MySQL主从复制原理背景
作者：张西来阿里云智能GTS-SRE团队技术服务经理
曾就职于某国产数据库厂商，有10多年数据库技术支持工作经验，精通多款数据库产品，为国内多个大中银行核心数据库提供技术支持。目前就职于阿里云智能GTS-SRE团队，负责云数据库的高效运维和管理工作。
我们是阿里云智能全球技术服务-SRE团队，我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队；提供专业、体系化的SRE服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术，您可用钉钉扫描下方二维码，加入阿里云SRE技术学院钉钉圈子，和更多云上人交流关于云平台的那些事。
