MySQL45講之備庫並行複製策略
前言
本文主要介紹 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] 備庫為什麼會延遲好幾個小時