MySQL：如何保證雙十一的主備數據同步

作者：果凍布丁兔 2023-12-12 07:24:06

MySQL 5.7.22 的并行復制策略在通用性上還是有保證的。當然，對于“表上沒主鍵”和“外鍵約束”的場景，WRITESET 策略也是沒法并行的，也會暫時退化為單線程模型。?

之前的文章我們提到過，主備數據庫是通過binlog實現的數據同步：

主庫在接到客戶端更新請求時，執行內部事務的更新邏輯，同時寫binlog。 r
1）edo log commit后，才會回復客戶端ack；
2）binlog寫成功后就可以同步備庫，因為binlog寫盤成功后，就算后續commit失敗，數據庫也可以根據redo log+binlog重新恢復commit狀態；
備庫與主庫之間維護一個長鏈接，有專門的線程來發送或者接收請求。
果凍布丁兔，公眾號：陸隊長MySQL：為什么所有實例可以保證數據一致性

無論是主備還是主從，實際上都是為了保證MySQL集群的高可用性：

無論是主備還是主從架構，實際上就是為了系統的高可用性實現的一個策略，防止主機因為某些故障導致異常下線，這時候備份或者從實例就會通過選擇或者其他策略成為主服務實例，對外繼續提供服務。
果凍布丁兔，公眾號：陸隊長MySQL：從MySQL看主從架構高可用性實現

但是如果在一個壓力持續比較久（比如雙十一或者大促期間）的主從系統內，主服務器需要應對龐大的數據讀寫壓力，如果備庫執行日志的速度低于主庫生成日志的速度，那么主從的主備延遲時間越來越長，導致備庫可能一直無法追上主庫。這時候就需要本節引入的備庫并行復制能力。

圖片

如圖所示的兩個黑色箭頭是我們比較關注的，一個是客戶端寫入主庫，一個是備庫上sql_thread執行中轉日志（relay log）。

主庫上影響并發主要是各種鎖，在備庫上的執行，如果從sql_thread更新數據使用單線程就很大可能導致主備延遲，這也是MySQL5.6版本前在主庫并發高或者TPS高時導致嚴重主備延遲問題的原因。

圖片

上圖有些類似netty的線程模型，沒錯，如果是好的技術模型，那么在很多的技術棧中都會使用。

coordinator只負責讀取中轉日志和分發事務，真正更新日志的邏輯由各個worker線程處理，worker的線程數由參數slave_parallel_workers決定。如果是32核的服務器，這個值可以設置為8~16.

雖然文章中很多人說為了保證備庫的讀服務，線程數為核數1/4~1/2，實際上我是不認同的，應該是主要看核數和讀寫壓力，如果即使是64核的機器，并且寫壓力不大，還是可以繼續保持當前的配置；如果是讀寫比例在10:1，那么這個線程數可以超過1/2。

為了保證事務的冪等性和原子性，我們需要做如下的要求：

1.冪等性：不能造成更新覆蓋。冪等性要求同一行的兩個事務必須分發到同一個worker。這里主要是為了防止由于客戶端的重試導致的事務重復或者是兩個事務之間的上下文依賴導致的數據不一致。

2.原子性：用一個事務必須由一個worker負責。相同事務的語句必須使用一個worker處理，否則可能導致一個worker失敗，另一個worker成功引入的數據不一致問題。

1 并行復制策略介紹

注意，這部分是作者丁奇自己寫的并行復制策略，非官方實現策略。

1.1 按表分發策略

按表分發事務的基本思想是：如果兩個事務更新不同的表，他們就可以并行。因為數據是存儲在表里，所以按表分發，可以保證兩個worker不會更新同一行。

如果有跨表的事務，那么就需要把兩張表放在一起考慮。

圖片

每個worker對應一個hash表，用于保存當前正在這個worker的“執行隊列”里的事務所涉及的表。hash表的key是“庫名.表名”，value是一個數字，表示隊列中有多少事務修改這個表。

在有事務分配給 worker 時，事務里面涉及的表會被加到對應的 hash 表中。worker 執行完成后，這個表會被從 hash 表中去掉。

圖 3 中，hash_table_1 表示，現在 worker_1 的“待執行事務隊列”里，有 4 個事務涉及到 db1.t1 表，有 1 個事務涉及到 db1.t2 表；hash_table_2 表示，現在 worker_2 中有一個事務會更新到表 t3 的數據。

假設在圖中的情況下，coordinator 從中轉日志中讀入一個新事務 T，這個事務修改的行涉及到表 t1 和 t3。

現在我們用事務 T 的分配流程，來看一下分配規則：

由于事務 T 中涉及修改表 t1，而 worker_1 隊列中有事務在修改表 t1，事務 T 和隊列中的某個事務要修改同一個表的數據，這種情況我們說事務 T 和 worker_1 是沖突的。
按照這個邏輯，順序判斷事務 T 和每個 worker 隊列的沖突關系，會發現事務 T 跟 worker_2 也沖突。
事務 T 跟多于一個 worker 沖突，coordinator 線程就進入等待。
每個 worker 繼續執行，同時修改 hash_table。假設 hash_table_2 里面涉及到修改表 t3 的事務先執行完成，就會從 hash_table_2 中把 db1.t3 這一項去掉。
這樣 coordinator 會發現跟事務 T 沖突的 worker 只有 worker_1 了，因此就把它分配給 worker_1。
coordinator 繼續讀下一個中轉日志，繼續分配事務。

也就是說，每個事務在分發的時候，跟所有 worker 的沖突關系包括以下三種情況：

如果跟所有 worker 都不沖突，coordinator 線程就會把這個事務分配給最空閑的 woker;
如果跟多于一個 worker 沖突，coordinator 線程就進入等待狀態，直到和這個事務存在沖突關系的 worker 只剩下 1 個；
如果只跟一個 worker 沖突，coordinator 線程就會把這個事務分配給這個存在沖突關系的 worker。

這個按表分發的方案，在多個表負載均勻的場景里應用效果很好。但是，如果碰到熱點表，比如所有的更新事務都會涉及到某一個表的時候，所有事務都會被分配到同一個 worker 中，就變成單線程復制了。

1.2 按行分發策略

要解決熱點表的并行復制問題，需要使用按行并行復制的方法。按行并行復制的核心思路就是：如果兩個事務沒有更新相同的行，在備庫上可以并行執行，這時候就要求binlog的格式必須是row。這時候，我們判定事務T和worker沖突的規則是“修改同一行”。

按行復制和按表復制也是為每個worker分配一個hash表，只是按行復制時，在考慮主鍵的同時還要考慮唯一索引的沖突。

CREATE TABLE `t1` (
  `id` int(11) NOT NULL,
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `a` (`a`)
) ENGINE=InnoDB;


insert into t1 values(1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5);

這兩個事務的主鍵不一致，但是如果分到不同worker，有可能出現sessionB先行，這時候id=1對應的a值還是1，就會出現唯一鍵沖突的問題。因此，基于行的策略，需要考慮唯一鍵，即key為：“庫名+表名+索引a的名字+a的值”；

因此，上表例子中，表t1執行sessionB語句，在binlog記錄了數據行修改前后各個字段的值，coordinator解析語句時，這個事務的hash表有三個項：

key=hash_func(db1+t1+"PRIMARY"+2)，value=2；這里的value=2是因為修改前后的id值不變，出現了兩次；
key=hash_func(db1+t1+"a"+2),value=1；表示會影響到表a=2的數據行；
key=hash_func(db1+t1+"a"+1),value=1；表示會影響到表a=1的數據行；

相比于按表并行分發策略，按行并行策略在決定線程分發的時候：

需要消耗更多的計算資源；
要能夠從 binlog 里面解析出表名、主鍵值和唯一索引的值。也就是說，主庫的 binlog 格式必須是 row；
表必須有主鍵；
不能有外鍵。表上如果有外鍵，級聯更新的行不會記錄在 binlog 中，這樣沖突檢測就不準確。

對比按表分發和按行分發這兩個方案的話，按行分發策略的并行度更高。不過，如果是要操作很多行的大事務的話，按行分發的策略有兩個問題：

耗費內存。比如一個語句要刪除 100 萬行數據，這時候 hash 表就要記錄 100 萬個項。
耗費 CPU。解析 binlog，然后計算 hash 值，對于大事務，這個成本還是很高的。

所以，我在實現這個策略的時候會設置一個閾值，單個事務如果超過設置的行數閾值（比如，如果單個事務更新的行數超過 10 萬行），就暫時退化為單線程模式，退化過程的邏輯大概是這樣的：

coordinator 暫時先 hold 住這個事務；
等待所有 worker 都執行完成，變成空隊列；
coordinator 直接執行這個事務；
恢復并行模式。

2 各數據庫版本并行復制策略

2.1 MySQL5.6并行復制策略

5.6版本開始支持按庫并行復制的策略，由于是按庫，自然粒度比較粗。這個策略的并行效果，取決于壓力模型，如果主庫上有多個DB，并且各個DB的壓力均衡，這個策略還好：

構建hash值只需要庫名，而且一個實例上的DB數不可能會很多，不會出現構建100萬個項這種情況；
不要求binlog格式，因為statement格式的binlog也可以很容易拿到庫名。

但是問題也比較明顯，比如大促項目的數據庫和運營后臺的數據庫一定不是均衡的，因此，策略的應用性有些差。

2.2 MariaDB并行復制策略

MariaDB是基于redo log的組提交（group commit）特性實現：

能夠在一個組內提交的事務，一定不會修改同一行；原因在于說：事務在執行數據更新或者DDL時一定會加鎖，只有事務提交后才會釋放鎖，所以，借助于鎖的互斥性，保證了事務的原子性；
主庫上可以并行執行的事務，備庫上也一定是可以并行執行的；

在實現上：

在一組里面一起提交的事務，有一個相同的commit_id，下一組就是commit_id+1；
commit_id直接寫入binlog中；
傳到備庫應用時，相同commit_id事務分發到多個worker執行；
這一組全部執行完成后，coordinator再去取下一批；

MariaDB的目標就是“模擬主庫的并行執行”，但是在具體實現上有些差距，畢竟主庫在一組事務commit時，下一組事務同時處于“執行中”狀態。如圖所示：

圖片

MariaDB的執行過程為：

圖片

在備庫上執行的時候，要等第一組事務完全執行完成后，第二組事務才能開始執行，這樣系統的吞吐量就不夠。

另外，這個方案很容易被大事務拖后腿。假設 trx2 是一個超大事務，那么在備庫應用的時候，trx1 和 trx3 執行完成后，就只能等 trx2 完全執行完成，下一組才能開始執行。這段時間，只有一個 worker 線程在工作，是對資源的浪費。

2.3 MySQL5.7版本并行復制策略

5.7版本提供了類似于MariaDB策略，并增加參數slave-parallel-type控制并行策略：

配置為 DATABASE，表示使用 MySQL 5.6 版本的按庫并行策略；
配置為 LOGICAL_CLOCK，表示的就是類似 MariaDB 的策略。不過，MySQL 5.7 這個策略，針對并行度做了優化。

優化點在于，把階段進行了提前，執行中的事務可能會存在沖突，commit狀態的事務可能又有些延遲，MySQL5.7允許同時處于prepare狀態的事務執行并行操作，因為已經prepare狀態的事務一定也已經通過鎖沖突的檢測：

同時處于prepare狀態的事務在備庫執行時可以并行；
處于prepare狀態的事務與commit狀態的事務之間，可以并行；

binlog 的組提交的時候，介紹過兩個參數：

binlog_group_commit_sync_delay 參數，表示延遲多少微秒后才調用 fsync;
binlog_group_commit_sync_no_delay_count 參數，表示累積多少次以后才調用 fsync。

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

也就是說，這兩個參數，既可以“故意”讓主庫提交得慢些，又可以讓備庫執行得快些。在 MySQL 5.7 處理備庫延遲的時候，可以考慮調整這兩個參數值，來達到提升備庫復制并發度的目的。

2.4 MySQL5.7.22版本的并行復制策略

MySQL 5.7.22 版本里，MySQL 增加了一個新的并行復制策略，基于 WRITESET 的并行復制，新增了一個參數 binlog-transaction-dependency-tracking，用來控制是否啟用這個新策略。這個參數的可選值有以下三種。

COMMIT_ORDER，根據同時進入 prepare 和 commit 來判斷是否可以并行的策略。
WRITESET，表示的是對于事務涉及更新的每一行，計算出這一行的 hash 值，組成集合 writeset。如果兩個事務沒有操作相同的行，也就是說它們的 writeset 沒有交集，就可以并行。
WRITESET_SESSION，是在 WRITESET 的基礎上多了一個約束，即在主庫上同一個線程先后執行的兩個事務，在備庫執行的時候，要保證相同的先后順序。

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

這跟前面介紹的基于 MySQL 5.5 版本的按行分發的策略是差不多的。不過，MySQL 官方的這個實現還是有很大的優勢：

writeset 是在主庫生成后直接寫入到 binlog 里面的，這樣在備庫執行的時候，不需要解析 binlog 內容（event 里的行數據），節省了很多計算量；
不需要把整個事務的 binlog 都掃一遍才能決定分發到哪個 worker，更省內存；
由于備庫的分發策略不依賴于 binlog 內容，所以 binlog 是 statement 格式也是可以的。

因此，MySQL 5.7.22 的并行復制策略在通用性上還是有保證的。當然，對于“表上沒主鍵”和“外鍵約束”的場景，WRITESET 策略也是沒法并行的，也會暫時退化為單線程模型。

責任編輯：武曉燕來源：陸隊長

MySQL 策略主服務器