併發複製（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事務按照以下順序
slave節點執行T1和T2相反的順序：
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中主庫提交的事務)
問題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
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功能，徹底解決了之前版本主備數據複製延遲的問題，開啓該功能參數如下：
