各版本MySQL并行復制的實現及優缺點

MySQL并行復制已經是老生常談，筆者從2010年開始就著手處理線上這個問題，剛開始兩三年也樂此不疲分享，現在再提這個話題本來是難免“炒冷飯”嫌疑。

最近觸發再談這個話題，是因為有些同學覺得“5.7的并行復制終于徹底解決了復制并發性問題”, 感覺還是有必要分析一下。大家都說沒有銀彈，但是又期待銀彈。。

既然要說5.7的并行復制，干脆順手把各個版本的并行復制都說明一下，也好有個對比。便是本次分享的初衷。

【背景】

一句話說完，因為這幾年太多這樣文章了， 就是MySQL一直以來的備庫復制都是單線程apply。

【解決總思路】

改成多線程復制。

備庫有兩個線程與復制相關：io_thread 負責從主庫拿binlog并寫到relaylog， sql_thread 負責讀relaylog并執行。

多線程的思路就是把sql_thread 變成分發線程，然后由一組worker_thread來負責執行。

幾乎所有的并行復制都是這個思路，有不同的，便是sql_thread 的分發策略。

而這些策略里面又分成兩類：利用傳統binlog格式、修改binlog。

使用傳統的binlog格式的幾類，由于binlog里面的信息就那些，因此只能按照粒度來分，也就是：按庫、按表、按行

另外有兩個策略是修改了binlog格式的，在binlog里面增加了別的信息，用于體現提交分組。

下面我們分別介紹幾個并行復制的實現。

【5.5】

MySQL官方5.5是不支持并行復制的。但是在阿里的業務需要并行復制的年份，還沒有官方版本支持，只好自己實現。而且從兼容性角度說，不修改binlog格式，所以采用的是利用傳統binlog格式的改造。

阿里的版本支持兩種分發策略：按表和按行。

前情說明，由于MySQLbinlog日志還有用于別的系統的要求，因此阿里的binlog格式都是row----這也給并行復制的實現減少了難度。

按表分發策略 ：row格式的binlog，每個DML前面都是有Table_map event的。因此很容易拿到庫名/表名。一個簡單的思路是，不同表的更新之間是不需要嚴格按照順序的。

因此按照表名hash，hash key是 庫名+表名，相同的表的更新放到同一個worker上。這樣就保證同一個表的更新順序，跟主庫上是一樣的。

應用場景：對于多表更新的場景效果特別好。缺點是反之的，若是熱點表更新，則本策略無效。而且由于hash表的維護，性能反而下降。

按行分發策略 ：row格式的binlog中，也不難拿到主鍵ID.  有同學說如果沒有主鍵怎么辦，答案是"起開，現在誰還沒主鍵:)"。好吧，正經答案是沒有主鍵就不支持這個策略。

同樣的，我們認為不同行的更新，可以無序并發的。只要保證同一行的數據更新，在備庫上的順序與主庫上的相同即可。

因此按照主鍵id hash，所以這個hash key更長，必須是 庫名+表名+主鍵id。相同行的更新放到同一個worker上。

需要注意的是，上面的描述看上去都是對單個event的操作，實際上 并不能 ！因為備庫可能接受讀，因此事務的原子性是要保證的，也就是說，對于涉及多個更新操作的事務，每次用于決策的不是一個hash key，而是一組。

應用場景：熱點表更新。缺點，hash key計算沖突的代價大。尤其是大事務，計算hash key的cpu消耗大，而且耗內存。這需要業務DBA做判斷得失。

【5.6】

官方的5.6支持的是按庫分發。有了上面的背景，大家就知道，這個feature出來以后，在中國并沒有什么反響。

但是這個策略也要說也是有優點的：

1、對于可以按表分發的場景，可以通過將表遷到不同的庫，來應用此策略，有可操作性

2、速度更快，因為hash key就一個庫名

3、不要求binlog格式，大家知道不論是row還是statement格式，都是能夠輕松獲取庫名的。

所以并不是完全沒有用的。還是習慣問題。

【MariaDB】

MariaDB的并行復制策略看上去有好幾個選項，然而生產上可用的也就是默認值的 CONSERVATIVE。

由于maraiaDB支持多主復制，一個domain_id字段是用來標示事務來源的。如果來自于不同的主，自然可以并行（這個其實也是通用概念，還得業務DBA自己判斷）。

對于同一個主庫來的binlog，用commit_id 來決定分組。

想法是這樣的：在主庫上同時提交的事務設置成相同的commit_id。在備庫上apply時，相同的commit_id可以并行執行，因為這意味著這些事務之間是沒有行沖突的（否則不可能同時提交）。

這個思路跟最初從單線程改成多線程一樣，個人認為是劃時代的。

但是也并沒有解決了所有的問題。這個策略最怕的是，拖后腿事務。

設想一下這個場景，假設某個DB里面正在作大量小更新事務（比如每個事務更新一行），這樣在備庫就并行得很歡樂。

然后突然，在同一個實例，另外一個庫下，或者同一個庫的另外一個跟目前的更新無關的表，突然有一個delte操作刪除了10w行。

delete事務在提交的時候，跟當時一起提交的事務都算同一個commit_id。假設為N.

之后的小事務更新提交組commit_id為N+1。

到備庫apply時，就會發現N這個組里面，其他小事務都執行完了，線程進入空閑狀態，但是不能繼續執行N+1這個commit_id的事務，因為N里面還有一個大事務沒有執行完成，這個我們認為是拖后腿的。

而基于傳統binlog格式的上面三個策略，反而沒有這個問題。只要是策略上能夠判斷不沖突，大事務自己有個線程跑，其他事務繼續并行。

【5.7】

MySQL官方5.7版本也是及時跟進，先引入了上述MariaDB的策略。當然從版權安全上，oracle是不會允許直接port代碼的。

實際上按組直接分段這個策略略顯粗暴。實際上事務提交并不是一個點，而是一個階段。至少我們可以分成：準備提交、提交中、提交完成。

這三個階段都是在事務已經完成了主要操作邏輯，進入commit狀態了。

同時進入“提交中”狀態的算同一個commit_id. 但是實際上，在任意時刻，處于”準備提交”的事務，與“提交中”的事務，也是可以并行的。但是明顯他們會被分成兩個不同的commit_id。

這意味著這個策略還有提升并發度的空間。

我們來看一下兩種策略的對比差別。

假設主庫有如下面示意圖的事務序列。每個事務提交過程看成兩個階段，prepare ... commit. 分別給不同的編號。其中commit對應的數字是自然數遞增，sequence_no。而prepare是對應的數字是X+1，這個X表示的是當前已經提交完成的sequence_no。

分析：

在MariaDB的策略里面，并發執行序列如下：

trx1, trx2, trx3 ----group 1

trx4 -----group 2

trx 5, trx6 ----group 3

trx 7 ----group 4

每個group 執行完成后，下一個group 才可以開始。

完全執行完成的時間是每個group的最大事務時間之和，即 trx3 + trx4+trx6+trx7。

因此，如果某個group里面有一個很大的事務，則整個序列的執行時間就會被拖久。

再來看5.7的改進策略：

雖然也是group1先啟動，但是在trx1完成后， trx4就可以開始執行；

同樣的，trx7可以在trx4執行完成后就開始執行，與trx5和trx6并發。

因此可以說上面這個例子中，備庫apply過程完全達到了主庫執行的并發度。

但是對于大事務，比如trx2 commit 非常久的情況，仍然存在拖后腿的問題。

【小結】

按粒度區分的三個策略，粒度從粗到細是按庫、按表、按行。

這三個的對比中，并行度越來越大，額外損耗也是。無關大事務不會影響并發度。

按照commit_id 的兩個策略，適用范圍更廣，額外消耗也低。

5.7的改進策略并發性更優。但出現大事務會拖后腿。

實際上策略的選擇取決于應用場景，這是架構師的工作之一。

PS：具體5.7的實現原理可參考我們團隊的@印風 同學的博客  http://mysqllover.com/?p=1370 (最后一個例子的case也從此摘錄）