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