MySQL5.7的组提交与并行复制

468次阅读

共计 3486 个字符，预计需要花费 9 分钟才能阅读完成。

从 MySQL5.5 版本以后，开始引入并行复制的机制，是 MySQL 的一个非常重要的特性。MySQL5.6 开始支持以 schema 为维度的并行复制，即如果 binlog row event 操作的是不同的 schema 的对象，在确定没有 DDL 和 foreign key 依赖的情况下，就可以实现并行复制。

社区也有引入以表为维度或者以记录为维度的并行复制的版本，不管是 schema，table 或者 record，都是建立在备库 slave 实时解析 row 格式的 event 进行判断，保证没有冲突的情况下，进行分发来实现并行。

MySQL5.7 的并行复制，multi-threaded slave 即 MTS，期望最大化还原主库的并行度，实现方式是在 binlog event 中增加必要的信息，以便 slave 节点根据这些信息实现并行复制。

MySQL 5.7 的并行复制建立在 group commit 的基础上，所有在主库上能够完成 prepared 的语句表示没有数据冲突，就可以在 slave 节点并行复制。

关于 MySQL5.7 的组提交，我们要看下以下的参数：

mysql> show global variables like '%group_commit%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.00 sec)

binlog_group_commit_sync_delay 这个参数控制着日志在刷盘前日志提交要等待的时间，默认是 0 也就是说提交后立即刷盘，当设置为 0 以上的时候，就允许多个事物的日志同事一起提交刷盘，也就是我们说的组提交。组提交是并行复制的基础，我们设置这个值的大于 0 就代表打开了组提交的功能。最大值只能设置为 1000000 微妙。

组提交是个比较好玩的方式，我们根据 MySQL 的 binlog 就可以看得到组提交到底是怎么回事：

[root@mxqmongodb2 log]# mysqlbinlog mysql-bin.000005 |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
#170607 11:24:58 server id 353306 end_log_pos 890675 CRC32 0xf8a8ad64 GTID last_committed=657 sequence_number=658
#170607 11:24:58 server id 353306 end_log_pos 892770 CRC32 0x127f9cdd GTID last_committed=658 sequence_number=659
#170607 11:24:58 server id 353306 end_log_pos 894757 CRC32 0x518abd93 GTID last_committed=659 sequence_number=660
#170607 11:37:46 server id 353306 end_log_pos 895620 CRC32 0x99174f95 GTID last_committed=660 sequence_number=661
#170607 11:37:51 server id 353306 end_log_pos 895897 CRC32 0xb4ffc341 GTID last_committed=661 sequence_number=662
#170607 11:38:00 server id 353306 end_log_pos 896174 CRC32 0x6bcbc492 GTID last_committed=662 sequence_number=663
#170607 11:39:40 server id 353306 end_log_pos 896365 CRC32 0x1fe16c7c GTID last_committed=663 sequence_number=664

上面是没有开启组提交的一个日志，我们可以看得到 binlog 当中有两个参数 last_committed 和 sequence_number，我们可以看到，下一个事物的

在主库配置好组提交以后，从库我们要加上如下的参数：last_committed 永远都和上一个事物的 sequence_number 是相等的。这也很容易理解，因为事物是顺序提交的，这么理解起来并不奇怪。

下面看一下组提��模式的事物：

[root@mxqmongodb2 log]# mysqlbinlog mysql-bin.000008|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

我们可以看到最后两个事物的 last_committed 是相同的，这意味什么呢，意味着两个事物是作为一个组提交的，两个事物在 perpare 截断获取相同的 last_committed 而且相互不影响，最终是会作为一个组进行提交。这就是所谓的组提交。

#MTS
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=8 #太多的线程会增加线程间同步的开销，建议 4 - 8 个 slave 线程
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
slave-parallel-type 有两个之，DATABASE 和 LOGICAL_CLOCK，DATABASE：默认值，兼容 5.6 以 schema 维度的并行复制，LOGICAL_CLOCK：MySQL 5.7 基于组提交的并行复制机制。

综合来说，MySQL5.7 的并行复制是基于主库的 group commit 和从库以下参数的配置：mysql> show variables like ‘%slave_para%’;

+------------------------+---------------+
| Variable_name | Value |
+------------------------+---------------+
| slave_parallel_type | LOGICAL_CLOCK |
| slave_parallel_workers | 8 |
+------------------------+---------------+
2 rows in set (0.01 sec)