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

从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微妙。

binlog_group_commit_sync_no_delay_count ，这个参数表示咱们在binlog_group_commit_sync_delay等待时间内，若是事物数达到binlog_group_commit_sync_no_delay_count 设置的参数，就会触动一次组提交，若是这个值设为为0的话就不会有任何的影响。若是到达时间可是事物数并无达到的话，也是会进行一次组提交操做的。

组提交是个比较好玩的方式，咱们根据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)

要想使用MySQL5.7的并行复制，必须首先主库必须标记某几个事物是同时提交，也就是last_commited的值是相同的擦灰在从库上并行回放，而后在从库设置线程数和相关的方式。咱们上面设置的是8，再从库就能看到

mysql> show processlist;
+----+-------------+--------------------+------+---------+--------+--------------------------------------------------------+------------------+
| Id | User        | Host               | db   | Command | Time   | State                                                  | Info             |
+----+-------------+--------------------+------+---------+--------+--------------------------------------------------------+------------------+
|  1 | system user |                    | NULL | Connect | 373198 | Waiting for master to send event                       | NULL             |
|  2 | system user |                    | NULL | Connect |   1197 | Slave has read all relay log; waiting for more updates | NULL             |
|  4 | system user |                    | NULL | Connect |   4292 | Waiting for an event from Coordinator                  | NULL             |
|  5 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             |
|  6 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             |
|  7 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             |
|  8 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             |
|  9 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             |
| 10 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             |
| 11 | system user |                    | NULL | Connect | 373198 | Waiting for an event from Coordinator                  | NULL             |
| 16 | root        | 172.16.16.34:37263 | NULL | Query   |      0 | starting                                               | show processlist |
+----+-------------+--------------------+------+---------+--------+--------------------------------------------------------+------------------+

从库会有八个线程来等待事物处理，已经不是一个了。

最近好友看到个人文章，指出了一些错误的理解。感谢，我大概又测试了一下。首先咱们的环境仍是不变的，咱们有一主两从的一套MySQL高可用结构，A(主)，B（MTS从），C（普通从库）三个MySQL数据库，版本5.7

咱们的设置

mysql> show variables like 'binlog_group_commit_sync_delay';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| binlog_group_commit_sync_delay | 0     |
+--------------------------------+-------+
1 row in set (0.00 sec)

下面先在主库进行压测，主库A上进行压力测试。而后观看三个数据库的日志。

[root@mxqmongodb2 tpcc-mysql]#  ./tpcc_start -h127.0.0.1 -P3306 -d tpcc -u root -p123456  -w 10 -c 50 -r 30 -l 300 

压测结束开始看日志信息：

[root@localhost log]# mysqlbinlog /home/mysql/db3306/log/mysql-bin.000013 |grep last_commit

首先上A主库的：

而后看B，开启多线程复制的从库的日志信息

接下来看C普通复制从库的日志信息：

经过对比发现，主库因为并无开启组提交，可是也是并行执行的，也就是说在MySQL5.7当中，组提交是默认开启的，而binlog_group_commit_sync_delay参数相对来讲是由于考虑到从库的性能，可以更多的一次性提交多个事物提交来减小IO，因此开启了组提交的B从库，事物是分组提交的，这也就是说明，MTS自己就是基于组提交来实现的。