《MySQL——備庫多線程複制政策。》

目錄

• ​​備庫并行複制能力​​
• ​​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政策也沒有辦法并行，會暫時退化為單線程模型。 是以，表是否有主鍵，也是影響主備同步延遲原因之一。

總結