01 並行複製的概念

在MySQL的主從複製架構中，主庫上經常會併發的執行很多SQL，只要這些SQL沒有產生鎖等待，那麼同一時間併發好幾個SQL執行緒是沒有問題的。

我們知道，MySQL的從庫是要通過IO_thread去拉取主庫上的binlog的，然後存入本地，落盤成relay-log，通過sql_thread來應用這些relay-log。

在MySQL5.6之前的版本中，當主庫上有多個執行緒併發執行SQL時，sql_thread只有一個，在某些TPS比較高的場景下，會出現主庫嚴重延遲的問題。MySQL為了解決這個問題，將sql_thread演化了多個worker的形式，在slave端並行應用relay log中的事務，從而提高relay log的應用速度，減少複製延遲。這就是並行複製的由來。

在MySQL中，複製執行緒是由引數slave_parallel_workers來控制的，通常情況下，在8G記憶體、8核CPU的機器上，將該值設定為8比較合適，如果你的CPU核數比較高，那麼可以適當調整為8~16之間的數字。

mysql> show variables like 'slave_parallel_workers';
+------------------------+-------+
| Variable_name     | Value |
+------------------------+-------+
| slave_parallel_workers | 8   |
+------------------------+-------+
1 row in set,1 warning (0.00 sec)

02 並行複製的演進

並行複製的本質是同時執行的SQL不存在鎖爭用。

在MySQL5.6版本，MySQL支援的粒度是按照資料庫進行並行執行relay log，這種方式能夠解決一部分問題，因為不同資料庫上的SQL，肯定不會修改表中的同一行內容。這樣也就不會產生鎖爭用。在一些資料庫均勻分佈，每個資料庫使用頻率都差不多的場景下，這種並行複製的方法比較好。如果你的業務的資料都集中在一個熱點表，這種情況下，並行複製會退化為單執行緒複製。

隨後，在MariaDB中對並行複製做了一定的改進，它的做法是：

1、主庫上能夠並行提交的事務，也就是已經進入到了redo log commit階段的事務，在從庫上也一定能夠並行提交，所以在主庫上並行提交的事務，它用一個commit_id對這組事務來進行標識，下一組並行事務的commit_id為本組的commit_id+1

2、將所有的事務的commit_id寫入binlog中

3、在從庫上應用binlog的時候，將所有的binlog按照commit_id進行劃分到不同的worker上

4、本組commit_id的事務全部在從庫上提交完成之後，再去拿下一批事務。

這種方法大大增加了從庫應用relay log的速度，但是問題是從庫在應用前一組事務的時候，後一組事務是處於等待中的，即使前一組的worker有些已經空閒。而在主庫上，可能無時無刻不在寫入，這樣，系統的吞吐量上主從節點就不匹配，主庫的吞吐量嚴重高於從庫。

MySQL5.7的並行複製在MariaDB的基礎上做了改進，我們知道，事務進入到redo log prepare階段的時候，由於WAL技術，說明此時事務已經經過了所衝突檢測階段了。MySQL5.7的並行複製時將所有在主庫上處於redo log prepare階段的事務，和該階段之後的事務，也就是處於redo log commit階段的事務，在從庫並行執行，從而減少worker執行緒不必要的等待。

這裡，有必要再說兩個引數，

• binnlog_group_commit_sync_delay引數，表示redo log prepare階段完成之後，延遲多少微秒後才呼叫fsync;
• binlog_group_commit_sync_no_delay_count引數，表示累積多少次redo log prepare：write的操作以後才呼叫fsync

這兩個引數是用於故意拉長binlog從write到fsync的時間，以此減少binlog的寫盤次數。在MySQL 5.7的並行複製策略裡，它們可以用來製造更多的“同時處於prepare階段的事務”。這樣就增加了備庫複製的並行度。

它們既可以“故意”讓主庫提交得慢些，又可以讓備庫執行得快些。在MySQL 5.7處理備庫延遲的時候，可以考慮調整這兩個引數值，來達到提升備庫複製併發度的目的。

以上就是淺析MySQL並行複製的詳細內容，更多關於MySQL並行複製的資料請關注我們其它相關文章！