MySQL並發複製系列二：多線程複製 2016

標籤：info   null   處理   logical   state   原理   slave   無法   思考   

並發複製（Parallel Replication） 系列二： Enhanced Multi-threaded Slaves

沃趣科技MySQL資料庫工程師  麻鵬飛

首先梳理下傳統MySQL/MariaDB主備複製基本原理：

        主從複製通過三個線程來完成，在master節點啟動並執行binlog dump的線程，I/O線程和SQL線程運行在slave 節點

•         master節點的Binlog dump線程，當slave節點與master正常串連的時候，master把更新的binlog 內容推送到slave節點。
•         slave節點的I/O 線程 ，該線程通過讀取master節點binlog日誌名稱以及位移量資訊將其拷貝到本地relay log記錄檔。
•         slave節點的SQL線程，該線程讀取relay log日誌資訊，將在master節點上提交的事務在本地回放，達到與主庫資料保持一致的目的。

問題1：

        Master節點的資料庫執行個體並發跑多個線程同時提交事務，提交的事務按照邏輯的時間（資料庫LSN號）順序地寫入binary log日誌，,slave節點通過I/O線程寫到本地的relay log日誌，但是slave節點只有SQL單線程來執行relay log中的日誌資訊重放主庫提交得事務，造成主備資料庫存在延遲（lag）

思考1：

        那麼為了減少主備資料同步延遲時間，由於備庫只有單線程補償資料的原因而造成延遲，那麼能否使slave節點同時運行多個如SQL線程一樣的功能來重放在主庫執行的事務？答案當然是：可以！但是我們需要解決以下問題：

        1、slave本地的relay log記錄的是master 的binary log日誌資訊，日誌記錄的資訊按照事務的時間先後順序記錄，那麼為了保證主備資料一致性，slave節點必須按照同樣的順序執行，如果順序不一致容易造成主備庫資料不一致的風險。

        如：

                在master節點提交T1和T2事務按照以下順序

1.  State0: x= 1, y= 1

2.  T1: { x:= Read(y);          

3.          x:= x+1;        

4.          Write(x);        

5.          Commit; }

6.  
State1: x= 2, y= 1

7.  T2: { y:= Read(x);

8.            y:=y+1;          

9.           Write(y);          

10.          Commit; }

11. 
State2: x= 2, y= 3   

            slave節點執行T1和T2相反的順序：

1.  State0: x= 1, y= 1

2.  T2: { y:= Read(x);

3.            y:= y+1;

4.            Write(y);

5.            Commit; }

6.  
State1: x= 1, y= 2

7.  T1: { x:= Read(y);

8.            x:=x+1;

9.            Write(x);

10.           Commit; }

11. 
State2: x= 3, y= 2

 

MySQL 5.6改進：

        MySQL 5.6版本引入並發複製（schema層級），基於schema層級的並發複製核心思想：“不同schema下的表並發提交時的資料不會相互影響，即slave節點可以用對relay log中不同的schema各分配一個類似SQL功能的線程，來重放relay log中主庫已經提交的事務，保持資料與主庫一致”。可見MySQL5.6版本的並發複製，一個schema分配一個類似SQL線程的功能。

實現1：      

         slave節點開啟並發複製（slave_parallel_workers＝3）如，當前的slave的SQL線程為Coordinator（協調器），執行relay log日誌的線程為worker(當前的SQL線程不僅起到協調器的作用，同時也可以重放relay log中主庫提交的事務)

1.  +-----+-------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+

2.  | Id  | User        | Host      | db   | Command | Time  | State                                                  | Info             |

3.  +-----+-------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+

4.  |   1 | system user |           | NULL | Connect | 29923 | Slave has read all relay log; waiting for more updates | NULL             |

5.  |   2 | system user |           | NULL | Connect | 29923 | Waiting for an event from Coordinator                  | NULL             |

6.  |   3 | system user |           | NULL | Connect | 29923 | Waiting for an event from Coordinator                  | NULL             |

7.  |   4 | system user |           | NULL | Connect | 29923 | Waiting for an event from Coordinator                  | NULL             |

 

問題2:

        MySQL 5.6基於schema層級的並發複製能夠解決當業務資料的表放在不同的database庫下，但是實際生產中往往大多數或者全部的業務資料表都放在同一個schema下，在這種情境即使slave_parallel_workers>0設定也無法並發執行relay log中記錄的主庫提交資料。 高並發的情況下，由於slave無法並發執行同個schema下的業務資料表，依然會造成主備延遲的情況。

 

思考2：

        那麼如果slave同時可以用多線程的方式，同時執行一個schema下的所有業務資料表，將能大大提高slave節點執行ralay log中記錄的主庫提交事務達到與主庫資料同步的目的，實現該功能我們需要解決什麼問題？

• 1、前面提到過為了保證主庫資料一致性，master節點寫入的binary log日誌按照資料庫邏輯時間先後的順序並且slave節點執行relay log中主庫提交的事務必須按照一致的順序否則會造成主備資料不一致的情況。
• 2、既然要實現scehma下所有的業務資料表能夠並發執行，那麼slave必須得知道並發執行relay log中主庫提交的事務不能相互影響而且結果必須和主庫保持一致。

 

實現2:

        MySQL 5.7 引入Enhanced Muti-threaded slaves,當slave配置slave_parallel_workers>0並且global.slave_parallel_type＝‘LOGICAL_CLOCK’,可支援一個schema下，slave_parallel_workers個的worker線程並發執行relay log中主庫提交的事務。但是要實現以上功能，需要在master機器標記binary log中的提交的事務哪些是可以並發執行，雖然MySQL 5.6已經引入了binary log group commit，但是沒有將可以並發執行的事務標記出來。

 

我們用命令 mysqlbinlog -vvv mysqlbinlog.0000003 | grep -i last_committed    在MySQL 5.7的master機器上可以看到last_committed 和sequence_number

1.  #151223 15:11:28 server id 15102  end_log_pos 14623 CRC32 0x767a33fa GTID      last_committed=18         sequence_number=26

2.   

3.  #151223 15:11:28 server id 15102  end_log_pos 15199 CRC32 0x7dd1bf05 GTID     last_committed=26         sequence_number=27

4.   

5.  #151223 15:11:28 server id 15102  end_log_pos 15773 CRC32 0xb01dc76e GTID     last_committed=26         sequence_number=28

6.   

7.  #151223 15:11:28 server id 15102  end_log_pos 16347 CRC32 0x7a8e0ee8 GTID     last_committed=26         sequence_number=29

8.   

9.  #151223 15:11:28 server id 15102  end_log_pos 16921 CRC32 0x92516d17 GTID     last_committed=26         sequence_number=30

10.  

11. #151223 15:11:28 server id 15102  end_log_pos 17495 CRC32 0xeb14a51e GTID     last_committed=26         sequence_number=31

12.  

13. #151223 15:11:28 server id 15102  end_log_pos 18071 CRC32 0x750667d0 GTID     last_committed=26         sequence_number=32

14.  

15. #151223 15:11:28 server id 15102  end_log_pos 18645 CRC32 0xcaed6159 GTID     last_committed=26         sequence_number=33

16.  

17. #151223 15:11:28 server id 15102  end_log_pos 19219 CRC32 0x62408408 GTID     last_committed=26         sequence_number=34

18.  

19. #151223 15:11:28 server id 15102  end_log_pos 19793 CRC32 0x5cf46239 GTID     last_committed=33         sequence_number=35

slave機器的relay log中 last_committed相同的事務（sequence_num不同）可以並發執行。從上面截取的資訊可以看出last_committed=26的事務一共有8個：從sequence_number=27~24。假設當slave_parallel_workers=7時，Coordinator線程（SQL線程）分配這一組事務到worker中排隊去執行。這裡可以看出增加master庫binary log group commit組中事務的數量可以提高slave機器並發處理事務的數量，MySQL5.7引入 binlog_group_commit_sync_delay和 binlog_group_commit_sync_no_delay_count參數即提高binary log組提交並發數量。MySQL等待binlog_group_commit_sync_delay毫秒的時間直到binlog_group_commit_sync_no_delay_count個事務數時，將進行一次組提交。

總結:

       MySQL 5.7 GA版本推出的 Enhanced Multi-threaded Slaves功能，徹底解決了之前版本主備資料複寫延遲的問題，開啟該功能參數如下：

1.  # slave機器

2.  slave-parallel-type=LOGICAL_CLOCK

3.  ＃slave-parallel-type=DATABASE #相容MySQL 5.6基於schema層級的並發複製

4.  slave-parallel-workers=16 ＃開啟多線程複製

5.  master_info_repository=TABLE

6.  relay_log_info_repository=TABLE

7.  relay_log_recovery=ON

MySQL並發複製系列二：多線程複製 2016