MySQL主从复制原理剖析与应用实践

MySQL在生产环境中被广泛地应用，大量的应用和服务都对MySQL服务存在重要的依赖关系，可以说如果数据层的MySQL实例发生故障，在不具备可靠降级策略的背景下就会直接引发上层业务，甚至用户使用的障碍；同时MySQL中存储的数据也是需要尽可能地减少丢失的风险，以避免故障时出现数据丢失引发的资产损失、客诉等影响。

在这样对服务可用性和数据可靠性需求的背景下，MySQL在Server层提供了一种可靠的基于日志的复制能力(MySQL Replication)，在这一机制的作用下，可以轻易构建一个或者多个从库，提高数据库的高可用性、可扩展性，同时实现负载均衡：

从比较宽泛的角度来探讨复制的原理，MySQL的Server之间通过二进制日志来实现实时数据变化的传输复制，这里的二进制日志是属于MySQL服务器的日志，记录了所有对MySQL所做的更改。这种复制模式也可以根据具体数据的特性分为三种：

2.2.1 Binlog事件类型

对于Binlog的定义而言，可以认为是一个个单一的Event组成的序列，这些单独的Event可以主要分为以下几类：

各类Event出现是具有显著的规律的：

• XID_EVENT标志一个事务的结尾

• 当发生了DDL类型的QUERY_EVENT，那么也是一次事务的结束提交点，且不会出现XID_EVENT

• GTID_EVENT只有开启了GTID_MODE（MySQL版本大于5.6）

• TABLE_MAP_EVENT必定出现在某个表的变更数据前，存在一对多个ROW_EVENT的情况

除了上面和数据更贴近的事件类型外，还有ROTATE_EVENT（标识Binlog文件发生了切分），FORMAT_DESCRIPTION_EVENT（定义元数据格式）等。

2.2.2 Binlog的生命周期

Binlog和Innodb Log（redolog）的存在方式是不同的，它并不会轮转重复覆写文件，Server会根据配置的单个Binlog文件大小配置不断地切分并产生新的Binlog，在一个.index文件记录当前硬盘上所有的binlog文件名，同时根据Binlog过期时间回收删除掉过期的Binlog文件，这两个在目前自建数据库的配置为单个大小1G，保留7天。

所以这种机制背景下，只能在短期内追溯历史数据的状态，而不可能完整追溯数据库的数据变化的，除非是还没有发生过日志过期回收的Server。 

2.2.3 Binlog事件示例

Binlog是对Server层生效的，即使没有从库正在复制主库，只要在配置中开启了log_bin，就会在对应的本地目录存储binlog文件，使用mysqlbinlog打开一个Row格式的示例binlog文件：

2.2.4 复制基准值

Binlog在产生时是严格有序的，但它本身只具备秒级的物理时间戳，所以依赖时间进行定位或排序是不可靠的，同一秒可能有成百上千的事件，同时对于复制节点而言，也需要有效可靠的记录值来定位Binlog中的水位，MySQL Binlog支持两种形式的复制基准值，分别是传统的Binlog File:Binlog Position模式，以及5.6版本后可用的全局事务序号GTID。

• FILE Position

只要开启了log_bin，MySQL就会具有File Position的位点记录，这一点不受GTID影响。

File: binlog.000001Position: 381808617

CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POSITION=381808617;

这个值必须要准确，因为这种模式下从库获取的数据完全取决于有效的开启点，那么如果存在偏差，就会丢失或执行重复数据导致复制中断。

• GTID

MySQL 会在开启GTID_MODE=ON的状态下，为每一个事务分配唯一的全局事务ID，格式为：server_uuid:id

Executed_Gtid_Set: e2e0a733-3478-11eb-90fe-b4055d009f6c:1-753

CHANGE MASTER TO MASTER_AUTO_POSITION=1;

从库在读取到Binlog后，会自动根据自身Executed_GTID_Set记录比对是否存在已执行或未执行的Binlog事务，并做对应的忽略和执行操作。

2.3.1 基本复制流程

• 时序关系

当集群进入运行的状态时，从库会持续地从主库接收到Binlog事件，并做对应的处理，那么这个过程中将会按照下述的数据流转方式：

1. Master将数据更改记录在Binlog中，BinlogDump Thread接到写入请求后，读取对应的Binlog

2. Binlog信息推送给Slave的I/O Thread。

3. Slave的I/O 线程将读取到的Binlog信息写入到本地Relay Log中。

4. Slave的SQL 线程读取Relay Log中内容在从库上执行。

上述过程都是异步操作，所以在某些涉及到大的变更，例如DDL改变字段，影响行数较大的写入、更新或删除操作都会导致主从间的延迟激增，针对延迟的场景，高版本的MySQL逐步引入了一些新的特性来帮助提高事务在从库重放的速度。

• Relay Log的意义

Relay log在本质上可以认为和binlog是等同的日志文件，即使是直接在本地打开两者也只能发现很少的差异；

2.3.2 半同步复制

• 时序关系

从半同步复制的时序图来看，实际上只是在主库Commit的环节多了等待接收从库ACK的阶段，这里只需要收到一个从节点的ACK即可继续正常的处理流程，这种模式下，即使主库宕机了，也能至少保证有一个从库节点是可以用的，此外还减少了同步时的等待时间。

2.3.3 小结

在当前生产环境的在线数据库版本背景下，由MySQL官方提供的复制方式主要如上文介绍的内容，当然目前有还很多基于MySQL或兼容MySQL的衍生数据库产品，能在可用性和可靠性上做更大的提升，本文就不继续展开这部分的描述。

期望业务层限制使用是不现实的，MySQL则在5.6版本开始尝试引入可用的并行复制方案，总的来说，都是通过尝试加强在从库层面的应用速度的方式。

2.4.1 基于Schema级别的并行复制

基于库级别的并行复制是出于一个非常简易的原则，实例中不同Database/Schema内的数据以及数据变更是无关的，可以并行去处置。

MySQL Server MySQL [(none)]> show databases;+--------------------+| Database           |+--------------------+| information_schema || aksay_record       || mysql              || performance_schema || proxy_encrypt      || sys                || test               |+--------------------+7 rows in set (0.06 sec)

2.4.2 基于组提交的复制（Group Commit）

基于Schema的并行复制在大部分场景是没有效力的，例如一库多表的情况下，但改变从库的单执行线程的思路被延续了下来，在5.7版本新增加了一种基于事务组提交的并行复制方式，在具体介绍应用在复制中的组提交策略前，需要先介绍Server本身Innodb引擎提交事务的逻辑：

主库在大规模并发执行事务时，因为每个事务都触发加锁落盘，反而使得所有的Binlog串行落盘，成为性能上的瓶颈。针对这个问题，MySQL本身在5.6版本引入了事务的组提交能力（这里并不是指在从库上应用的逻辑），设计原理很容易理解，只要是能在同一个时间取得资源，开启Prepare的所有事务，都是可以同时提交的。

在主库具有这一能力的背景下，可以很容易得发现从库也可以应用相似的机制来并行地去执行事务，下面介绍MySQL具体实现经历的两个阶段：

• 基于Commit-Parents-Based

  MySQL中写入是基于锁的并发控制，所以所有在Master端同时处于Prepare阶段且未提交的事务就不会存在锁冲突，在Slave端执行时都可以并行执行。

  
  

  因此可以在所有的事务进入prepare阶段的时候标记上一个logical timestamp（实现中使用上一个提交事务的sequence_number），在Slave端同样timestamp的事务就可以并发执行。

  
  

  但这种模式会依赖上一个事务组的提交，如果本身是不受资源限制的并发事务，却会因为它的commit-parent没有提交而无法执行；

  
  

• 基于Logic-Based

  针对Commit-Parent-Based中存在的限制进行了解除，纯粹的理解就是只有当前事务的sequence_number一致就可以并发执行，只根据是否能取得锁且无冲突的情况即可以并发执行，而不是依赖上一个已提交事务的sequence_number。

当前vivo的在线MySQL数据库服务标准架构是基于一主一从一离线的异步复制集群，其中一从用于业务读请求分离，离线节点不提供读服务，提供给大数据离线和实时抽数/DB平台查询以及备份系统使用；针对这样的应用背景，存储研发组针对MySQL场景提供了两种额外的扩展服务：

虽然MySQL的主从复制可以提高系统的高可用性，但是MySQL在5.6,5.7版本是不具备类似Redis的自动故障转移的能力，如果主库宕机后不进行干预，业务实际上是无法正常写入的，故障时间较长的情况下，分离在从库上的读也会变得不可靠。

3.1.1 VSQL(原高可用2.0架构)

那么在当前这样标准一主二从架构的基础上，为系统增加HA高可用组件以及中间件组件强化MySQL服务的高可用性、读拓展性、数据可靠性：

• HA组件管理MySQL的复制拓扑，负责监控集群的健康状态，管理故障场景下的自动故障转移；

• 中间件Proxy用于管理流量，应对原有域名场景下变更解析慢或缓存不生效的问题，控制读写分离、实现IP、SQL的黑白名单等；

3.1.2 数据可靠性强化

数据本身还是依赖MySQL原生的主从复制模式在集群中同步，这样仍然存在异步复制本身的风险，发生主库宕机时，如果从库上存在还未接收到的主库数据，这部分就会丢失，针对这个场景，我们提供了三种可行的方案：

• 日志远程复制

配置HA的中心节点和全网MySQL机器的登录机器后，按照经典的MHA日志文件复制补偿方案来保障故障时的数据不丢失，操作上即HA节点会访问故障节点的本地文件目录读取候选主节点缺失的Binlog数据并在候选主上重放。

优势

劣势

• 日志集中存储

依赖数据传输服务中的BinlogServer模块，提供Binlog日志的集中存储能力，HA组件同时管理MySQL集群以及BinlogServer，强化MySQL架构的健壮性，真实从库的复制关系全部建立在BinlogServer上，不直接连接主库。

优势

劣势

• 改变为半同步复制

MySQL集群开启半同步复制，通过配置防止退化（风险较大），Agent本身支持半同步集群的相关监控，可以减少故障切换时日志丢失的量（相比异步复制）

优势

劣势

目前来说，我们采用的是日志远程复制的方案，同时今年在规划集中存储的BinlogServer方案来强化数据安全性；不过值得一提的是，半同步也是一种有效可行的方式，对于读多写少的业务实际上是可以考虑升级集群的能力，这样本质上也可以保证分离读流量的准确性。

3.2.1 基于Binlog的跨系统数据流转

通过利用Binlog，实时地将MySQL的数据流转到其它系统，包括MySQL，ElasticSearch，Kafka等MQ已经是一种非常经典的应用场景了，MySQL原生提供的这种变化数据同步的能力使其可以有效地在各个系统间实时联动，DTS（数据传输服务）针对MySQL的采集也是基于和前文介绍的复制原理一致的方法，这里介绍我们是如何利用和MySQL 从节点相同的机制去获取数据的，也是对于完整开启复制的拓展介绍：

（1）如何获取Binlog

比较常规的方式有两种：

• 监听Binlog文件，类似日志采集系统的操作

• MySQL Slave的机制，采集者伪装成Slave来实现

本文只介绍第二种，Fake Slave的实现方式

（2）注册Slave身份

这里以GO SDK为例，GO的byte范围是0~255，其它语言做对应转换即可。

data := make([]byte, 4+1+4+1+len(hostname)+1+len(b.cfg.User)+1+len(b.cfg.Password)+2+4+4)

（3）发起复制指令

data := make([]byte, 4+1+4+2+4+len(p.Name))

以上两个命令通过客户端连接执行后，就可以在主库上观察到一个有效的复制连接。

3.2.2 利用并行复制模式提升性能

以上两个命令通过客户端连接执行后，就可以在主库上观察到一个有效的复制连接。

DTS消费单元实现了对消费自kafka的事件的事务重组以及并发的事务解析工作，但实际最终执行还是串行单线程地向MySQL回放，这一过程使得性能瓶颈完全集中在了串行执行这一步骤。

（1）连接池改造

旧版的DTS的每一个消费任务只有一条维持的MySQL长连接，该消费链路的所有的事务都在这条长连接上串行执行，产生了极大的性能瓶颈，那么考虑到并发执行事务的需求，不可能对连接进行并发复用，所以需要改造原本的单连接对象，提升到近似连接池的机制。

go-mysql/client包本身不包含连接池模式，这里基于事务并发解析的并发度在启动时，扩展存活连接的数量。

// 初始化客户端连接数se.conn = make([]*Connection, meta.MaxConcurrenceTransaction)

（2）并发选择连接

• 利用逻辑时钟

开启GTID复制的模式下，binlog中的GTID_EVENT的正文内会包含两个值：

LastCommitted  int64SequenceNumber int64

lastCommitted是我们并发的依据，原则上，LastCommitted相等事务可以并发执行，结合原本事务并发解析完成后会产生并发度（配置值）数量的事务集合，那么对这个列表进行分析判断，进行事务到连接池的分配，实现一种近似负载均衡的机制。

• 非并发项互斥

（3）校验点更新

但不论怎样进行优化，并发执行事务必然会引入更多的风险，例如并发事务的回滚无法控制，目标实例和源实例的因果一致性被破坏等，业务可以根据自身的需要进行权衡，是否开启并发的执行。

（4）小结

最后，关于MySQL的复制能力不仅对于MySQL数据库服务本身的可用性、可靠性有巨大的提升，也提供了Binlog这一非常灵活的开放式的数据接口用于扩展数据的应用范围，通过利用这个“接口”，很容易就可以达成数据在多个不同存储结构、环境的实时同步，未来存储组也将会聚焦于BinlogServer这一扩展服务来强化MySQL的架构，包括但不限于数据安全性保障以及对下游数据链路的开放等。

• MySQL官方文档

• 数据库内核月报