目錄

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

備庫并行復制能力

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

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

2、備庫上sql_thread執(zhí)行中轉日志relay log

1的并行能力比2強。

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

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

現(xiàn)在MySQL使用的是多線程復制

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

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

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

MySQL5.6版本 并行復制策略

支持粒度：庫

用于決定分發(fā)策略的hash表key值：數(shù)據(jù)庫名

優(yōu)勢：

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

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

缺點：

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

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

MariaDB 并行復制策略

策略：

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

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

為了實現(xiàn)該策略，MariaDB實現(xiàn)方法為：

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

2、commit_id直接寫到binlog里

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

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

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

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

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

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

MySQL5.7版本 并行復制策略

策略思想：

1、同時處于prepare狀態(tài)的事務，在備庫執(zhí)行時是可以并行的

2、處于prepare狀態(tài)的事務，與處于commit狀態(tài)的事務之間，在備庫執(zhí)行時也是可以并行的

通過調節(jié)binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count參數(shù)

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

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

MySQL5.7.22版本 并行復制策略

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

可選值：

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

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

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

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

這個版本的好處在于：

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

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

總結

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

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

總結

以上是生活随笔為你收集整理的《MySQL——备库多线程复制策略。》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。