目錄

• • 備庫并行復制能力
  • MySQL5.6版本 并行復制策略
  • MariaDB 并行復制策略
  • MySQL5.7版本 并行復制策略
  • MySQL5.7.22版本 并行復制策略
  • 總結

備庫并行復制能力

主要涉及兩個方面的并行度：

1、客戶端寫入主庫的能力

2、備庫上sql_thread執行中轉日志relay log

1的并行能力比2強。

主庫上由于InnoDB支持行鎖，對業務并行度的支持比較友好。

備庫上如果用單線程，會導致備庫應用日志不夠快，造成主備延遲。

現在MySQL使用的是多線程復制

coordinator 就是原來的sql_thread，不過現在它不再直接更新數據了，只負責讀取中轉日志和分發事務。真正更新日志的，是worker線程。線程個數由slave_parallel_workers決定，一般設置為8~16。

coordinator在分發事務的時候，要遵循兩個要求：

• 不能造成更新覆蓋。也就是說更新同一行的兩個事務必須被分發到同一個worker中。
• 同一個事務不能被拆開，必須放到同一個worker中。

MySQL5.6版本 并行復制策略

支持粒度：庫

用于決定分發策略的hash表key值：數據庫名

優勢：

1、構造hash值快；一個實例上的DB數目不會很多。

2、不要求binlog格式。row和statement格式的binlog都可以拿到庫名。

缺點：

1、主庫表在同一個DB中，策略失效

2、不同DB熱點不同，起不到并行效果

MariaDB 并行復制策略

策略：

1、能夠在同一組里提交的事務，一定不會修改同一行

2、主庫上可以并行執行的事務，備庫上一定是可以并行執行的

為了實現該策略，MariaDB實現方法為：

1、在一組里面一起提交的事務，有一個相同的commit_id，下一組就是commit_id+1

2、commit_id直接寫到binlog里

3、傳到備庫應用的時候，相同commit_id的事務分發到多個worker執行

4、一組全部執行完后，coordinator再去取下一批

這個策略目標就是備庫模擬主庫的并行模式。

不過主庫再一組事務commit的時候，下一組事務實際上是處于"執行中"狀態的。

而按照MariaDB策略，在備庫上執行的時候，要等一組事務完全執行完，下一組事務才能開始執行，這樣系統的吞吐量就不夠。

這個策略，對于長事務來說不友好。如果一組里有一個超大事務線程，該組其他線程執行完后要等待這個線程執行完，之后才能切換到下一組。這段時間，只有一個線程進行工作，浪費了資源。

MySQL5.7版本 并行復制策略

策略思想：

1、同時處于prepare狀態的事務，在備庫執行時是可以并行的

2、處于prepare狀態的事務，與處于commit狀態的事務之間，在備庫執行時也是可以并行的

通過調節binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count參數

來來拉長binlog從write到fsync的時間，以此減少binlog’的寫盤次數。同時在并行復制策略里，可以用來制造更多“同時處于prepare階段的事務”。這樣就能增加備庫復制的并行度。

通俗來講，這兩個參數，既可以讓主庫提交慢一點，又可以讓備庫執行快一點。在MySQL5.7處理備庫延遲時，可以調節這兩個參數，達到提升備庫復制并行度的目的。

MySQL5.7.22版本 并行復制策略

新增了一個參數binlog-transaction-dependency-tracking，用來控制是否啟用這個新策略。

可選值：

1、COMMIT_ORDER，表示根據同時進入prepare和commit來判斷是否可以并行

2、WRITESET,表示對于事務涉及更新的每一行，計算出這一行的hash值，組成集合writeset。如果兩個事務沒有操作相同的行，即writeset沒有交集，就可以并行。

3、WRITESET_SESSION，在WRITESET基礎上多了一個約束：在主庫上同一線程先后執行的兩個事務，在備庫執行的時候，要保證相同的先后順序

為了唯一標識，hash通過"庫名+表名+索引名+值"計算。如果表上除了主鍵索引外，還有其他唯一索引，那么對于每個唯一索引，insert語句對應的writeset就要多增加一個hash值。

這個版本的好處在于：

--1、writeset是在主庫生成后直接寫入到binlog里的，在備庫執行的時候，不需要解析binlog內容，節省了備庫計算量
--2、不需要把整個事務的binlog都掃一邊才能決定分發到哪個worker，更加節省內存
--3、備庫的分發策略不依賴于binlog內容，所以binlog是statement格式也是可以的

對于表上沒有主鍵和外鍵約束的場景，WRITSET策略也沒有辦法并行，會暫時退化為單線程模型。 所以，表是否有主鍵，也是影響主備同步延遲原因之一。

總結

單線程復制能力低于多線程復制，對于更新壓力較大的主庫，備庫可能一直追不上主庫。

MySQL備庫并行策略，修改了binlog的內容，也就是說不是向上兼容的，所以需要注意。