前言
本文主要介紹 MySQL 備庫的并行復制策略，
為什么備庫需要并行復制
如果主庫有大量更新操作，因為主庫可以并發寫入，而備庫只能單執行緒執行的話，那么備庫的同步延遲會不斷累加，即備庫越來越追不上主庫，所以，后面有了備庫的并行復制，
備庫的并行復制模型：
coordinator 職責是分發 binlog 給作業執行緒，真正執行同步的是 worker，
按表分發策略
每個 worker 作業執行緒都對應一個表，coordinator 根據 binlog 內容將事務分發到不沖突的 worker 中并行執行，如果發生沖突，則等到不沖突的情況再分發到 worker 中執行，
以“資料庫名 + 表名”為鍵，判斷是否沖突：
-
如果待分發事務的鍵和 worker 存在鍵沖突數等于0，則選擇空閑的 worker 執行；
-
如果待分發事務的鍵和 worker 存在鍵沖突數等于1，則選擇沖突的 worker 執行；
-
如果待分發事務的鍵和 worker 存在鍵沖突數大于1，則等待直到前兩個條件符合；
按行分發策略
和按表分發策略同理，不過是以“資料庫名 + 表名 + 主鍵名 + 主鍵值”或者“資料庫名 + 表名 + 唯一鍵名 + 唯一鍵值”為鍵來判斷沖突，需要計算更多的鍵，
為什么還需要判斷唯一鍵是否沖突？
因為并發執行時，執行時序不與原先相同，原先后執行的事務可能現在先執行，有可能會導致不符合唯一性約束，造成資料不一致，
組提交并行策略
MariaDB 提出的并行復制策略
MySQL 組提交的前提是組里面的事務是不沖突的，或者說并行執行不影響資料一致性的，組提交時，在 binlog 中記錄 commit_id，那么在備庫分發時，將同一個 commit_id 的事務分到不同的 worker 并行執行，
不過，這個方法存在一個缺陷，備庫每次執行分發同一個 commit_id 下的事務到 worker 中執行，等都執行完之后，才可以分發下一個 commit_id 對應的事務，這樣的話，備庫并不是真正地在并行復制，并且，如果一個 commit_id 下的某個事務是大事務，那么將導致下一組執行的時間延后，即存在“短板效應”，
組提交優化策略
MySQL5.7 提出的并行復制策略，在 MariaDB 并行復制策略上進行了優化，
根據 MySQL 兩階段提交，只要處于 prepare 階段的事務就可以并行執行，所以，下面情況下的事務都可以并行執行：
-
同時處于 prepare 的事務
-
處于 prepare 和 commit 之間的事務
write_set策略
在主庫寫入 binlog 之前，計算事務涉及的每一行的 hash 值，寫入 binlog，這樣在備庫分發的時候就不需要決議 binlog 來判斷，只需要判斷兩個事務是否有交集來判斷是否可以并行，提交運行效率，
因為不需要決議 binlog 來獲取資訊，所以該方法下， binlog 采用 statement 和 row 格式都可以，
此外，還有 write_set_session 策略，它在 write_set 策略上加了一個約束，同一個執行緒先后執行的兩個事務，在備庫復制時不能并行，
參考
- [1] 備庫為什么會延遲好幾個小時
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/308619.html
標籤：其他