從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本身就是基於組提交來實現的。