张西来 阿里云智能GTS-SRE团队 技术服务经理

曾就职于某国产数据库厂商,有10多年数据库技术支持工作经验,精通多款数据库产品,为国内多个大中银行核心数据库提供技术支持。目前就职于阿里云智能GTS-SRE团队,负责云数据库的高效运维和管理工作。

引言

通过上一节的学习,我们知道在mysql一主一从集群中,是依靠数据库的Binlog(二进制日志)来进行主从同步的,主节点执行完一个DDL、DML语句后,会将此语句记录到主库的binlog中,然后由IO线程将日志传输到从库,由SQL线程来replay binlog,从而实现主从同步。

但是,这种机制是100%可靠的么?会不会有例外情况?大家可以思考一下下面几种情况,是否会造成主备不一致:
  • 一张表上存在多个索引,在主库上执行delete from tab1limit 1语句,从库上是否会删除了同一条记录?我们知道如果表上有多个索引,在不同的节点上执行时有可能使用到不同的索引,最终引起的结果是可能会删除不同的记录。
  • 主库上执行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如何保证主从一致,下一期将会给大家介绍一下rds for mysql主从切换的知识,哪些情况下rds会自动进行主从切换、主从切换一定会成功么?