MySQL 5.7并行复制实践

发布时间：2021-01-23 23:06 所属栏目：53 来源：网络整理

导读：《MySQL 5.7并行复制实践》要点：本文介绍了MySQL 5.7并行复制实践，希望对您有用。如果有疑问，可以联系我们。 MySQL 5.7并行复制原理 MySQL 从 5.6 开始引入了多库并行主从复制,但是其并行只是基于 Schema 的,也就是基于库的.如果用户的 MySQL 数据库实例

《MySQL 5.7并行复制实践》要点：
本文介绍了MySQL 5.7并行复制实践，希望对您有用。如果有疑问，可以联系我们。

MySQL 5.7并行复制原理

MySQL 从 5.6 开始引入了多库并行主从复制,但是其并行只是基于 Schema 的,也就是基于库的.如果用户的 MySQL 数据库实例中存在多个 Schema,对于从机复制的速度的确可以有比较大的帮助.MySQL 5.6 并行复制的架构如下所示：

MySQL

在上图的红色框框部分就是实现并行复制的关键所在.在 MySQL 5.6 版本之前,Slave 服务器上有两个线程 I/O 线程和 SQL 线程.I/O 线程负责接收二进制日志(更准确的说是二进制日志的 event ),SQL 线程进行回放二进制日志.如果在 MySQL 5.6 版本开启并行复制功能,那么SQL线程就变为了 Coordinator 线程,Coordinator线程主要负责以前两部分的内容：

若判断可以并行执行,那么选择 Worker 线程执行事务的二进制日志.
若判断不可以并行执行,如该操作是 DDL,亦或者是事务跨 Schema 操作,则等待所有的 Worker 线程执行完成之后,再执行当前的日志.

这意味着 Coordinator 线程并不是仅将日志发送给 Worker 线程,自己也可以回放日志,但是所有可以并行的操作交付由 Worker 线程完成.Coordinator 线程与 Worker 是典型的生产者与消费者模型.

上述机制实现的基于 Schema 的并行复制存在两个问题,首先是 Crash Safe 功能不好做,因为可能之后执行的事务由于并行复制的关系先完成执行,那么当发生 Crash 的时候,这部分的处理逻辑是比较复杂的.从代码上看,5.6 这里引入了 Low-Water-Mark 标记来解决该问题,从设计上看,其是希望借助于日志的幂等性来解决该问题,不过 5.6 的二进制日志回放还不能实现幂等性.另一个最为关键的问题是这样设计的并行复制效果并不高,如果用户实例仅有一个库,那么就无法实现并行回放,甚至性能会比原来的单线程更差.而单库多表是比多库多表更为常见的一种情形.

MySQL 5.7 才可称为真正的并行复制,这其中最为主要的原因就是 Slave 服务器的回放与主机是一致的即 Master 服务器上是怎么并行执行的 Slave 上就怎样进行并行回放.不再有库的并行复制限制,对于二进制日志格式也无特殊的要求(基于库的并行复制也没有要求).

从 MySQL 官方来看,其并行复制的原本计划是支持表级的并行复制和行级的并行复制,行级的并行复制通过解析 ROW 格式的二进制日志的方式来完成.但是最终出现的是在开发计划中称为：MTS: Prepared transactions slave parallel applier.

该并行复制的思想最早是由 MariaDB 的 Kristain 提出,并已在 MariaDB 10 中出现,MySQL 5.7 并行复制的思想简单易懂,一言以蔽之：一个组提交的事务都是可以并行回放,因为这些事务都已进入到事务的 Prepare 阶段,则说明事务之间没有任何冲突(否则就不可能提交).

为了兼容 MySQL 5.6 基于库的并行复制,5.7 引入了新的变量 slave-parallel-type,其可以配置的值有：

DATABASE：默认值,基于库的并行复制方式.
LOGICAL_CLOCK：基于组提交的并行复制方式.

如何知道事务是否在一组中,又是一个问题,因为原版的 MySQL 并没有提供这样的信息.在 MySQL 5.7版本中,其设计方式是将组提交的信息存放在 GTID 中.那么如果用户没有开启 GTID 功能,即将参数 gtid_mode 设置为 OFF 呢?故 MySQL 5.7 又引入了称之为 Anonymous_Gtid 的二进制日志 event 类型,如：

mysql> SHOW BINLOG EVENTS in 'mysql-bin.000011';

| mysql-bin.000011 | 123 | Previous_gtids | 88 | 194 | f11232f7-ff07-11e4-8fbb-00ff55e152c6:1-2 |
| mysql-bin.000011 | 194 | Anonymous_Gtid | 88 | 259 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| mysql-bin.000011 | 259 | Query | 88 | 330 | BEGIN |
| mysql-bin.000011 | 330 | Table_map | 88 | 373 | table_id: 108 (aaa.t) |
| mysql-bin.000011 | 373 | Write_rows | 88 | 413 | table_id: 108 flags: STMT_END_F |
......

这意味着在 MySQL 5.7 版本中即使不开启 GTID,每个事务开始前也是会存在一个 Anonymous_Gtid,而这 GTID 中就存在着组提交的信息.

组提交是个比较好玩的方式,我们根据 MySQL 的 binlog 可以发现较之原来的二进制日志内容多了 last_committed 和 sequence_number .

$ mysqlbinlog mysql-bin.000011 |grep last_committed
#170607 11:24:57 server id 353306 end_log_pos 876350 CRC32 0x92093332 GTID last_committed=654 sequence_number=655
#170607 11:24:58 server id 353306 end_log_pos 880406 CRC32 0x344fdf71 GTID last_committed=655 sequence_number=656
#170607 11:24:58 server id 353306 end_log_pos 888700 CRC32 0x4ba2b05b GTID last_committed=656 sequence_number=657

上面是没有开启组提交的一个日志,我们可以看得到 binlog 当中有两个参数 last_committed 和 sequence_number,我们可以看到,下一个事务在主库配置好组提交以后,last_committed 永远都和上一个事务的 sequence_number 是相等的.这也很容易理解,因为事务是顺序提交的.

下面看一下组提交模式的事务：

$ mysqlbinlog mysql-bin.000012|grep last_commit
#170609 10:11:07 server id 353306 end_log_pos 75629 CRC32 0xd54f2604 GTID last_committed=269 sequence_number=270
#170609 10:13:03 server id 353306 end_log_pos 75912 CRC32 0x43675b14 GTID last_committed=270 sequence_number=271
#170609 10:13:24 server id 353306 end_log_pos 76195 CRC32 0x4f843438 GTID last_committed=270 sequence_number=272

（编辑：ASP站长网）