從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=TABLErelay_log_info_repository=TABLErelay_log_recovery=ONslave-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的并行復制，必須首先主庫設置binlog_group_commit_sync_delay大于0，然后在從庫設置線程數和相關的方式。我們上面設置的是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 | 10.103.16.34:37263 | NULL | Query | 0 | starting | show processlist |+----+-------------+--------------------+------+---------+--------+--------------------------------------------------------+------------------+
從庫會有八個線程來等待事物處理，已經不是一個了。
? 版權聲明
文章版權歸作者所有，未經允許請勿轉載。
THE END
