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

vivo 互联网服务器团队 - Shang Yongxing

MySQL Replication（主从复制）是指数据变动能够从一个 MySQL Server 被复制到另一个或多个 MySQL Server 上，通过复制的性能，能够在单点服务的根底上裁减数据库的高可用性、可扩展性等。

一、背景

MySQL 在生产环境中被宽泛地利用，大量的利用和服务都对 MySQL 服务存在重要的依赖关系，能够说如果数据层的 MySQL 实例产生故障，在不具备牢靠降级策略的背景下就会间接引发下层业务，甚至用户应用的阻碍；同时 MySQL 中存储的数据也是须要尽可能地缩小失落的危险，以防止故障时呈现数据失落引发的资产损失、客诉等影响。

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

• 实时数据变动备份
• 主库的写入数据会继续地在冗余的从库节点上被执行保留，缩小数据失落的危险
• 横向拓展节点，撑持读写拆散
• 当主库自身接受压力较大时，能够将读流量扩散到其它的从库节点上，达成读扩展性和负载平衡
• 高可用性保障
• 当主库产生故障时，能够疾速的切到其某一个从库，并将该从库晋升为主库，因为数据都一样，所以不会影响零碎的运行

具备包含但不限于以上个性的 MySQL 集群就能够笼罩绝大多数利用和故障场景，具备较高的可用性与数据可靠性，以后存储组提供的生产环境 MySQL 就是基于默认的异步主从复制的集群，向业务保障可用性 99.99%，数据可靠性 99.9999%的在线数据库服务。

本文将深入探讨 MySQL 的复制机制实现的形式，同时探讨如何具体地利用复制的能力来晋升数据库的可用性，可靠性等。

二、复制的原理

2.1 Binlog 的引入

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

• Statement：基于语句格局
• Statement 模式下，复制过程中向获取数据的从库发送的就是在主库上执行的 SQL 原句，主库会将执行的 SQL 原有发送到从库中。
• Row：基于行格局
• Row 模式下，主库会将每次 DML 操作引发的数据具体行变动记录在 Binlog 中并复制到从库上，从库依据行的变更记录来对应地批改数据，但 DDL 类型的操作仍然是以 Statement 的格局记录。
• Mixed：基于混合语句和行格局
• MySQL 会依据执行的每一条具体的 SQL 语句来辨别看待记录的日志模式，也就是在 statement 和 row 之间抉择一种。

最早的实现是基于语句格局，在 3.23 版本被引入 MySQL，从最后起就是 MySQL Server 层的能力，这一点与具体应用的存储引擎没有关联；在 5.1 版本后开始反对基于行格局的复制；在 5.1.8 版本后开始反对混合格局的复制。

这三种模式各有优劣，相对来说，基于 Row 的行格局被利用的更宽泛，尽管这种模式下对资源的开销会偏大，但数据变动的准确性以及可靠性是要强于 Statement 格局的，同时这种模式下的 Binlog 提供了残缺的数据变更信息，能够使其利用不被局限在 MySQL 集群零碎内，能够被例如 Binlogserver，DTS 数据传输等服务利用，提供灵便的跨零碎数据传输能力，目前互联网业务的在线 MySQL 集群 全部都是基于 Row 行格局的 Binlog。

2.2  Binlog 的要点

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 文件：

如上图，能够很显著地留神到三个操作，创立数据库 test，创立数据表 test，一次写入引发的行变更，可读语句 (create, alter, drop, begin, commit…..) 都能够认为是 QUERY_EVENT，而 Write_rows 就属于 ROW_EVENT 中的一种。

在复制的过程中，就是这样的 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.000001
Position: 381808617

这个概念相对来说更直观，能够间接了解为以后处在 File 对应编号的 Binlog 文件中，同时曾经产生了共计 Position bytes 的数据，如例子中所示即该实例曾经产生了 381808617 bytes 的 Binlog，这个值在对应机器间接查看文件的大小也是匹配的，所以 File Postion 就是文件序列与大小的对应值。

基于这种模式开启复制，须要显式地在复制关系中指定对应的 File 和 Position：

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

其中 e2e0a733-3478-11eb-90fe-b4055d009f6c 用于惟一地标识产生该 Binlog 事件的实例，1-753 示意曾经产生或接管了由 e2e0a733-3478-11eb-90fe-b4055d009f6c 实例产生的 753 个事务；

从库在从主库获取 Binlog Event 时，本身的执行记录会放弃和获取的主库 Binlog GTID 记录统一，还是以 e2e0a733-3478-11eb-90fe-b4055d009f6c:1-753，如果有从库对 e2e0a733-3478-11eb-90fe-b4055d009f6c 开启了复制，那么在从库本身执行 show master status 也是会看到雷同的值。

如果说从库上能够看到和复制的主库不统一的值，那么能够认为是存在 errant GTID，这个个别是因为主从切换或强制在从库上执行了写操作引发，失常状况下从库的 Binlog GTID 应该和主库的保持一致；

基于这种模式开启复制，不须要像 File Position 一样指定具体的值，只须要设置：

CHANGE MASTER TO MASTER_AUTO_POSITION=1;

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

2.3 复制的具体流程

2.3.1 根本复制流程

当主库曾经开启了 binlog(log_bin = ON)，并失常地记录 binlog，如何开启复制？

这里以 MySQL 默认的异步复制模式进行介绍：

1. 首先从库启动 I/O 线程，跟主库建设客户端连贯。
2. 主库启动 binlog dump 线程，读取主库上的 binlog event 发送给从库的 I / O 线程，I/ O 线程获取到 binlog event 之后将其写入到本人的 Relay Log 中。
3. 从库启动 SQL 线程，将期待 Relay 中的数据进行重放，实现从库的数据更新。

总结来说，主库上只会有一个线程，而从库上则会有两个线程。

• 时序关系

当集群进入运行的状态时，从库会继续地从主库接管到 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 是等同的日志文件，即便是间接在本地关上两者也只能发现很少的差别；

Binlog Version 3 (MySQL 4.0.2 – < 5.0.0)

added the relay logs and changed the meaning of the log position

在 MySQL 4.0 之前是没有 Relay Log 这部分的，整个过程中只有两个线程。然而这样也带来一个问题，那就是复制的过程须要同步的进行，很容易被影响，而且效率不高。例如主库必须要期待从库读取完了能力发送下一个 binlog 事件。这就有点相似于一个阻塞的信道和非阻塞的信道。

在流程中新增 Relay Log 中继日志后，让本来同步的获取事件、重放事件解耦了，两个步骤能够异步的进行，Relay Log 充当了缓冲区的作用。Relay Log 蕴含一个 relay-log.info 的文件，用于记录以后复制的进度，下一个事件从什么 Pos 开始写入，该文件由 SQL 线程负责更新。

对于后续逐步引入的非凡复制模式，会存在一些差别，但整体来说，是依照这个流程来实现的。

2.3.2 半同步复制

异步复制的场景下，不能确保从库实时更新到和主库统一的状态，那么如果在呈现提早的背景下产生主库故障，那么两者间的差别数据还是无奈进行保障，同时也无奈在这种状况下进行读写拆散，而如果说由异步改为齐全同步，那么性能开销上又会大幅提高，很难满足理论应用的需要。

基于这一的背景，MySQL 从 5.5 版本开始引入了半同步复制机制来升高数据失落的概率，在这种复制模式中，MySQL 让 Master 在某一个工夫点期待一个 Slave 节点的 ACK（Acknowledge Character）音讯，接管到 ACK 音讯后才进行事务提交，这样既能够缩小对性能的影响，还能够绝对异步复制取得更强的数据可靠性。

介绍半同步复制之前先疾速过一下 MySQL 事务写入碰到主从复制时的残缺过程，主库事务写入分为 4 个步骤：

1. InnoDB Redo File Write (Prepare Write)
2. Binlog File Flush & Sync to Binlog File
3. InnoDB Redo File Commit（Commit Write）
4. Send Binlog to Slave

• 当 Master 不须要关注 Slave 是否承受到 Binlog Event 时，即为异步主从复制
• 当 Master 须要在第 3 步 Commit Write 回复客户端前期待 Slave 的 ACK 时，为半同步复制（after-commit）
• 当 Master 须要在第 2 步 Flush&Sync，即 Commit 前期待 Slave 的 ACK 时，为加强半同步复制（after-sync）

• 时序关系

从半同步复制的时序图来看，实际上只是在主库 Commit 的环节多了期待接管从库 ACK 的阶段，这里只须要收到一个从节点的 ACK 即可持续失常的解决流程，这种模式下，即便主库宕机了，也能至多保障有一个从库节点是能够用的，此外还缩小了同步时的等待时间。

2.3.3 小结

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

2.4 复制的个性

目前曾经提及的复制形式，存在一个显著的个性：无奈回避数据提早的场景，异步复制会使得从库的数据落后，而半同步复制则会阻塞主库的写入，影响性能。

MySQL 晚期的复制模式中，从库的 IO 线程和 SQL 线程实质上都是串行获取事件并读取重放的，只有一个线程负责执行 Relaylog，但主库自身接管申请是能够并发地，性能下限只取决于机器资源瓶颈和 MySQL 解决能力的下限，主库的执行和从库的执行（SQL 线程利用事件）是很难对齐的，这里援用一组测试数据：

• 机器：64 核 256G，MySQL 5.7.29
• 测试场景：惯例的 INSERT，UPDATE 压测场景
• 后果：MySQL Server 的 IO 线程速度以网络上的数据量评估，每秒超过 100MB，失常是能够笼罩业务应用的，然而 SQL 线程的预估速度只有 21~23MB/s，如果是波及 UPDATE 场景，性能还会缩小；
• 须要留神的是，以上后果是在高版本的 MySQL 具备并行复制能力的前提下获得，如果是不具备该个性的版本，性能会更差。

冀望业务层限度应用是不事实的，MySQL 则在 5.6 版本开始尝试引入可用的并行复制计划，总的来说，都是通过尝试增强在从库层面的利用速度的形式。

2.4.1 基于 Schema 级别的并行复制

基于库级别的并行复制是出于一个十分繁难的准则，实例中不同 Database/Schema 内的数据以及数据变更是无关的，能够并行去处理。

在这种模式中，MySQL 的从节点会启动多个 WorkThread，而原来负责回放的 SQLThread 会转变成 Coordinator 角色，负责判断事务是否并行执行并分发给 WorkThread。

如果事务别离属于不同的 Schema，并且不是 DDL 语句，同时没有跨 Schema 操作，那么就能够并行回放，否则须要等所有 Worker 线程执行实现后再执行以后日志中的内容。

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)

对于从库而言，如果接管到了来自主库的 aksay_record 以及 proxy_encrypt 内的数据变更，那么它是能够同时去解决这两局部 Schema 的数据的。

然而这种形式也存在显著缺点和有余，首先只有多个 Schema 流量平衡的状况下才会有较大的性能改善，但如果存在热点表或实例上只有一个 Schema 有数据变更，那么这种并行模式和晚期的串行复制也不存在差别；同样，尽管不同 Schema 的数据是没有关联，这样并行执行也会影响事务的执行程序，某种程度来说，整个 Server 的因果一致性被毁坏了。

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

基于 Schema 的并行复制在大部分场景是没有效劳的，例如一库多表的状况下，但扭转从库的单执行线程的思路被连续了下来，在 5.7 版本新减少了一种基于事务组提交的并行复制形式，在具体介绍利用在复制中的组提交策略前，须要先介绍 Server 自身 Innodb 引擎提交事务的逻辑：

Binlog 的落盘是基于 sync_binlog 的配置来的，失常状况都是取 sync_binlog=1，即每次事务提交就发动 fsync 刷盘。

主库在大规模并发执行事务时，因为每个事务都触发加锁落盘，反而使得所有的 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 场景提供了两种额定的扩大服务：

3.1 利用高可用零碎 + 中间件

尽管 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 数据并在候选主上重放。

劣势

• 与 1.0 的 MHA 计划保持一致，能够间接应用旧的机制
• 机制革新后能够混合在高可用的能力内，不须要机器间的免密互信，升高权限需要和平安危险

劣势

• 不肯定可用，须要故障节点所在机器可访达且硬盘失常，无奈应答硬件或网络异样的状况
• 网络上链路较长，可能无法控制两头重放日志的耗时，导致服务较长时间不可用

• 日志集中存储

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

劣势

• 能够自定义日志的存储模式：文件系统或其它共享存储模式
• 不波及机器可用和权限的问题
• 间接进步 binlog 的保留安全性（备份）

劣势

• 额定的资源应用，如果须要保留较长时间的日志，资源使用量较大
• 如果不开启半同步，也不能保障所有的 binlog 日志都能被采集到，即便采集（相当于 IO 线程）速度远超 relay 速度，极限约 110MB/s
• 零碎复杂度晋升，须要接受引入额定链路的危险

• 扭转为半同步复制

MySQL 集群开启半同步复制，通过配置避免进化（危险较大），Agent 自身反对半同步集群的相干监控，能够缩小故障切换时日志失落的量（相比异步复制）

劣势

• MySQL 原生的机制，不须要引入额定的危险
• 实质上就是在强化高可用的能力（MySQL 集群自身）
• HA 组件能够无缝接入开启半同步的集群，不须要任何革新

劣势

• 存在不兼容的版本，不肯定能够开启
• 业务可能无奈承受性能降落的结果
• 半同步不能保障齐全不丢数据，Agent 自身机制实际上是优先选择“执行最多”的从节点而不是“日志最多”的从节点

orchestrator will promote the replica which has executed more events rather than the replica which has more data in the relay logs.

目前来说，咱们采纳的是日志近程复制的计划，同时往年在布局集中存储的 BinlogServer 计划来强化数据安全性；不过值得一提的是，半同步也是一种无效可行的形式，对于读多写少的业务实际上是能够思考降级集群的能力，这样实质上也能够保障拆散读流量的准确性。

3.2 数据传输服务

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)

1. 第 0 - 3 位为 0，无意义
2. 第 4 位是 MySQL 协定中的 Command_Register_Slave，byte 值为 21
3. 第 5 - 8 位是以后实例预设的 server_id（非 uuid，是一个数值）应用小端编码成的 4 个字节
4. 接下来的若干位是把以后实例的 hostname，user，password
5. 接下来的 2 位是小端编码的 port 端口值
6. 最初 8 位个别都置为 0，其中最初 4 位指 master_id，假装 slave 设置为 0 即可

（3）发动复制指令

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

1. 第 0 - 3 位同样置为 0，无非凡意义
2. 第 4 位是 MySQL 协定的 Command_Binlog_Dump，byte 值为 18
3. 第 5 - 8 位是 Binlog Position 值的小端序编码产生的 4 位字节
4. 第 9 -10 位是 MySQL Dump 的类别，默认是 0，指 Binlog_Dump_Never_Stop，即编码成 2 个 0 值
5. 第 11-14 位是实例的 server_id（非 uuid）基于小端编码的四个字节值
6. 最初若干位即间接追加 Binlog File 名称

以上两个命令通过客户端连贯执行后，就能够在主库上察看到一个无效的复制连贯。

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

以上两个命令通过客户端连贯执行后，就能够在主库上察看到一个无效的复制连贯。

依据晚期的性能测试后果，不做任何优化，间接单连贯重放源集群数据，在网络上的均匀传输速度在 7.3MB/ s 左右，即便是和 MySQL 的 SQL Relay 速度相比也是相差很远，在低压场景下很难满足需要。

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

1. MySQL 5.7 版本以前，会利用事务的 Schema 属性，使不同 db 下的 DML 操作能够在备库并发回放。在优化后，能够做到不同表 table 下并发。然而如果业务在 Master 端高并发写入一个库（或者优化后的表），那么 slave 端就会呈现较大的提早。基于 schema 的并行复制，Slave 作为只读实例提供读取性能时候能够保障同 schema 下事务的因果序（Causal Consistency，本文探讨 Consistency 的时候均假如 Slave 端为只读），而无奈保障不同 schema 间的。例如当业务关注事务执行先后顺序时候，在 Master 端 db1 写入 T1，收到 T1 返回后，才在 db2 执行 T2。但在 Slave 端可能先读取到 T2 的数据，才读取到 T1 的数据。
2. MySQL 5.7 的 LOGICAL CLOCK 并行复制，解除了 schema 的限度，使得在主库对一个 db 或一张表并发执行的事务到 slave 端也能够并行执行。Logical Clock 并行复制的实现，最后是 Commit-Parent-Based 形式，同一个 commit parent 的事务能够并发执行。但这种形式会存在能够保障没有抵触的事务不能够并发，事务肯定要等到前一个 commit parent group 的事务全副回放完能力执行。前面优化为 Lock-Based 形式，做到只有事务和以后执行事务的 Lock Interval 都存在重叠，即保障了 Master 端没有锁抵触，就能够在 Slave 端并发执行。LOGICAL CLOCK 能够保障非并发执行事务，即当一个事务 T1 执行完后另一个事务 T2 再开始执行场景下的 Causal Consistency。

（1）连接池革新

旧版的 DTS 的每一个生产工作只有一条维持的 MySQL 长连贯，该生产链路的所有的事务都在这条长连贯上串行执行，产生了极大的性能瓶颈，那么思考到并发执行事务的需要，不可能对连贯进行并发复用，所以须要革新本来的单连贯对象，晋升到近似连接池的机制。

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

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

（2）并发抉择连贯

• 利用逻辑时钟

开启 GTID 复制的模式下，binlog 中的 GTID_EVENT 的注释内会蕴含两个值：

LastCommitted  int64
SequenceNumber int64

lastCommitted 是咱们并发的根据，原则上，LastCommitted 相等事务能够并发执行，联合本来事务并发解析实现后会产生并发度（配置值）数量的事务汇合，那么对这个列表进行分析判断，进行事务到连接池的调配，实现一种近似负载平衡的机制。

• 非并发项互斥

对于并发执行的场景，能够比较简单地应用相似负载平衡的机制，从连接池中遍历 mysql connection 执行对应的事务；但须要留神到的是，源的事务自身是具备程序的，在 logical-clock 的场景下，存在局部并发 prepare 的事务是能够被并发执行的，但依然有相当一部分的事务是不可并发执行，它们显然是扩散于整个事务队列中，能够认为并发事务（起码 2 个）是被不可并发事务突围的：

假设存在一个事务队列有 6 个元素，其中只有 t1、t2 和 t5、t6 能够并发执行，那么执行 t3 时，须要 t1、t2 曾经执行结束，执行 t5 时须要 t3,t4 都执行结束。

（3）校验点更新

在并发的事务执行场景下，存在水位低的事务后执行完，而水位高的事务先执行完，那么按照本来的机制，更低的水位会笼罩掉更高的水位，存在肯定的危险：

1. Write_Event 的结构 SQL 调整为 replace into，能够回避抵触反复的写事件；Update 和 Delete 能够基于逻辑时钟的并发保障，不会呈现。
2. 水位只会向上晋升，不会向下升高。

但不论怎样进行优化，并发执行事务必然会引入更多的危险，例如并发事务的回滚无法控制，指标实例和源实例的因果一致性被毁坏等，业务能够依据本身的须要进行衡量，是否开启并发的执行。

基于逻辑时钟并发执行事务革新后，生产端的执行性能在等同的测试场景下，能够从 7.3MB/ s 晋升到 13.4MB/ s 左右。

（4）小结

基于生产工作自身的库、表过滤，能够实现另一种模式下的并发执行，能够启动复数的生产工作别离反对不同的库、表，这也是利用了 kafka 的多消费者组反对，能够横向扩大以进步并发性能，实用于数据迁徙场景，这一部分能够专门提供反对。

而基于逻辑时钟的形式，对于目前现网大规模存在的未开启 GTID 的集群是有效的，所以这一部分咱们也始终在寻找更优的解决方案，例如更高版本的个性 Write Set 的合并等，持续做性能优化。

四、总结

最初，对于 MySQL 的复制能力不仅对于 MySQL 数据库服务自身的可用性、可靠性有微小的晋升，也提供了 Binlog 这一非常灵活的开放式的数据接口用于扩大数据的利用范畴，通过利用这个“接口”，很容易就能够达成数据在多个不同存储构造、环境的实时同步，将来存储组也将会聚焦于 BinlogServer 这一扩大服务来强化 MySQL 的架构，包含但不限于数据安全性保障以及对上游数据链路的凋谢等。

参考资料：

• MySQL 官网文档
• 数据库内核月报