併發複製（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. +-----+-------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+

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

問題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併發複製系列二：多執行緒複製

相關文章