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.000001Position: 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  int64SequenceNumber 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官网文档
  • 数据库内核月报