前言

• IO_THREAD 負責從 Source 接收 binlog 並寫入 Replica 的 relaylog

• SQL_THREAD 負責解析和重放 relaylog 中的 event

各個版本的 MTS

基於 database 級別的 MTS (5.6)

基於 Group Commit 的 MTS (5.7)

Group Commit 簡述

slave_parallel_type

• DATABASE：也就是 5.6 版本，不同 DATABASE 的才能並行回放。

• LOGICAL_CLOCK：5.7 版本基於 Group Commit 的並行回放。

LOGICAL_CLOCK - Commit Parent Based 模式

在 Source 中能夠在同一個對列一起進行 Group commit，表示這個對列中的所有 Transaction 都沒有鎖衝突，因此也可在 Replica 內並行回放。

為了讓 Replica 能基於 Group Commit 實現 MTS，在 Binlog 中為每個 Transaction 添加了 LOGICAL CLOCK 也就是以下 2 個值：

• sequence_number：每個 Transaction 的唯一序列號，具體在 Transaction 進入 flush 階段的對列之前分配。

• last_commited：紀錄上次 Group commit 時最大的 sequence_number，也就是說 last_committed 相同表示同屬一個 Group。

備註：sequence_number、last_commited 只在同一個 BinLog 文件不重複，每當換到新的 BinLog 文件時會重新從 0 開始計數。

---

不過 Commit Parent Based 有一個缺陷，讓我們看一下例子：

每一個水平線代表一個 Transaction 由左到右的時間點，其中 P 表示 prepare 階段取得上一個 Group 更新 last_committed 的時間點，C 表示 commit 前更新 last_committed 的時間點。

其中可以觀察到：

• Trx4 的 P 時間點取得的是 Trx1 commit 產生的 last_committed

• Trx5 和 Trx6 的 P 時間點取得的是 Trx2 commit 產生的 last_committed

依照 Commit Parent 模式下 Trx5、Trx6 可以一起在 Replica 回放，但是 Trx4 不可以和 Trx5、Trx6 一起在 Replica 回放。

然而，實際上依照時間線我們可以看到 Trx4 在 prepare 到 commit 的過程中，Trx5、Trx6 有在這個過程中 prepare，也就是說實際上他們並沒有鎖衝突 (如果衝突 Trx5、Trx6 會卡在 lock wait)，所以理論上他們在 Replica 是可以並行回放到。

Commit Parent Based VS Lock Based 舉例

假設有以下 binlog：

在 Commit Parent Based 下：

• sequence_number 1~7 的 Transaction 其 last_committed 都是 0，所以可在 replica 並行回放。

• sequence_number 8 的 Transaction 其 last_committed 是 1，所以不能和 sequence_number 1~7一起在 replica 並行回放。 *備註：在 Commit Parent Based 下，正確的 last_committed 應該要是 7，此處僅方便舉例使用 Lock Based 舉例。

• sequence_number 9~14 的 Transaction 其 last_committed 都是 7，不能和 sequence_number 1~8 一起在 replica 並行回放。

在 Lock Based 下：

• sequence_number 1~7 的 Transaction 其 last_committed 都是 0 表示為同一個 Group，所以 1~7 可在 replica 並行回放。

• sequence_number 8 的 last_committed = 1，表示 8 和 1~7 的鎖不衝突，因此 1~8 可在 replica 並行回放。

• sequence_number 9~14 的 Transaction 其 last_committed 都是 7 表示為同一個 Group，同時 8~14 的鎖不衝突，因次 8~14 可在 replica 並行回放

缺陷

基於 WriteSet 的 MTS (5.7.22、8.0)

• COMMIT_ORDER：使用 5.7 Group commit 的方式判斷。

• WRITESET：使用 WriteSet 的方式判斷 Transaction 是否有衝突。

• WRITESET_SESSION：WRITESET 的基礎上保證同一個 session 內的 Transaction 不可並行。

WriteSet 簡述

WriteSet 應用到 MTS 簡述

• slave_preserve_commit_order = ON

• binlog_transaction_dependency_tracking = WRITESET_SESSION

實現方式

WriteSet 是什麼？

WriteSet 是一個 hash 數組，大小由 binlog_transaction_dependency_history_size 來決定。

在 InooDB 修改數據後，會將修改的 row 數據以下內容進行 hash 後寫入 WriteSet：

WriteSet 產出細節

💡

產生的 Hash 值的方式可以參考 sql/rpl_write_set_handler.cc 中的 add_pke function mysql-server/rpl_write_set_handler.cc at 8.0 · mysql/mysql-server · GitHub

範例：

偽代碼如下：

基於 WriteSet 的 MTS 怎麼實現？

該模式下 Replica 同樣是基於 Source 產生的 binlog 中的 last_commited 和 sequenct_number 來決定是否可以並行回放，也就是說如果要進一步增加並行回放的效率，就需要盡可能為每個 Transaction 找出更小的 last_commited。

基於 WriteSet 的 MTS 能找出更小的 last_commited 的方式就是維護一個先前 Transaction 所組成的 WriteSet 的歷史紀錄，之後新進來的 Transaction 計算 WriteSet 後和這個歷史紀錄進行衝突比對，以此來嘗試找出更小的 last_commited。

binlog_transaction_dependency_tracking 不同對 last_commit 的處理

基於 WriteSet 的 MTS 實際上是基於 ORDER_COMMIT (Group Commit) 進一步處理而已。

根據 binlog_transaction_dependency_tracking 的設定不同，在 Source code 有如下內容：

可以看到從 COMMIT_ORDER 到 WRITESET 再到 WRITESET_SESSION 其實都是以上一個設定的為基礎進一步透過一個新的 function 進行修改而已，這些 function 修改的是 last_commited 值。

WriteSet 歷史紀錄詳解

WriteSet 的歷史紀錄包含了 2 個元素：

• WriteSet 的 Hash 值

• 最後一次修改該行的 Transaction 其 sequence_number

另外 binlog_transaction_dependency_history_size 決定了可以儲存幾組紀錄，內部會依照 WriteSet Hash 值進行排序。

如果 WriteSet 的歷史紀錄達到 binlog_transaction_dependency_history_size 設定的值就會將歷史紀錄清空，並且本次的 Transaction 會成為清空後歷史紀錄的第一筆紀錄。

另外除了歷史紀錄還有有一個 m_writeset_history_start 的值，用來儲存這個歷史紀錄中的最小 sequence_number。

WriteSet MTS 對 last_commit 的處理流程

這裡透過一個例子解釋，假設如下：

• 當前的 Transaction 基於 ORDER_COMMIT (Group Commit) 的方式產生了結果：
• last_commit = 125
• sequence_number = 130

• 該 Transaction 修改的表只有 PK 沒有 UK。

• 該 Transaction 修改了 4 行資料，分別為 ROW1、ROW7、ROW6、ROW10。

下圖展示了該 Transaction 和 WriteSet 歷史紀錄：

接下來就會透過 WriteSet 方式找到更小的 last_commit：

1. 將 last_commit 由 125 調整為 100 (歷史紀錄中最小的 sequence_number m_writeset_history_start)。
備註：因為該 Transaction 比歷史紀錄中的 Transaction 晚執行，因此 last_commit 一定都比他們的 sequence_number 大。

2. 將 ROW1 的 Hash 值在 WriteSet 歷史紀錄中確認，發現有修改相同紀錄的 Transaction：
• 將歷史紀錄中該行的 sequence_number 由 120 (歷史紀錄值) 調整為 130(該 Transaction)。
• 將該 Transaction 的 last_commit 由 100 調整為 120。

3. 將 ROW7 的 Hash 值在 WriteSet 歷史紀錄中確認，發現有修改相同紀錄的 Transaction：
• 將歷史紀錄中該行的 sequence_number 由 114 (歷史紀錄值) 調整為 130(該 Transaction)。
• 當前 Transaction 當前 last_commit 為 120 比歷史紀錄中的 114 大，因為在 120 就衝突了，所以不能改成更小的 114，因此 last_commit 不變依舊是 120。

4. 將 ROW6 的 Hash 值在 WriteSet 歷史紀錄中確認，發現有修改相同紀錄的 Transaction：
• 將歷史紀錄中該行的 sequence_number 由 105 (歷史紀錄值) 調整為 130(該 Transaction)。
• 當前 Transaction 當前 last_commit 為 120 比歷史紀錄中的 105 大，因為在 120 就衝突了，所以不能改成更小的 105，因此 last_commit 不變依舊是 120。

5. 將 ROW10 的 Hash 值在 WriteSet 歷史紀錄中確認，發現並沒有修改相同紀錄的 Transaction：
• 因為沒有找到相同的 WriteSet，因此需要把該 Transaction ROW10 的 Hast 值和 sequence_number 寫入 WriteSet 歷史紀錄。
• 如果歷史紀錄大小超過 binlog_transaction_dependency_history_size，則清空當前歷史紀錄，隨後將 Transaction ROW10 的 Hast 值和 sequence_number(130) 寫入 WriteSet 新的歷史紀錄，並將 m_writeset_history_start 改為 130。
• 如果歷史紀錄大小沒有超過 binlog_transaction_dependency_history_size，將 Transaction ROW10 的 Hast 值和 sequence_number(130) 寫入 WriteSet 當前歷史紀錄。

整個過程結束，該 Transaction 的 last_commit 由原本的 125 降低為 120，最後結果如下圖：

該過程在 Function Writeset_trx_dependency_tracker::get_dependency 中：

 

 

WRITESET_SESSION 怎麼做?

前面有提到過 WRITESET_SESSION 是基於 WRITESET 的基礎上繼續處理的，WRITESET_SESSION 要做到的是同一個 session 的 Transaction 不能在 Replica 並行回放，要實現非常簡單：

關於 binlog_transaction_dependency_history_size 參數說明

• 5.7 版本：binlog_transaction_dependency_history_size = 修改的行數 * ( 1 + UK 數量 ) * 2

• 8.0 版本：binlog_transaction_dependency_history_size = 修改的行數 * ( 1 + UK 數量 )

WriteSet 不適用情境

1. 沒有 PK 也沒有 UK

2. DDL

3. session 的 hash 算法換 history 不同

4. Transaction 更新了有 Forign key 關聯的欄位

slave_preserve_commit_order 介紹

GAP

相關參數

• slave_parallel_workers (5.6~8.0.25)、replica_parallel_workers (8.0.26~)



設定要在 replica 並行的 thread 數量。
如果 slave 有多個 channel，則每個 channel 都會有此數量的 thread。
設置此參數後必須重新 START REPLICA 才會生效。

• slave_parallel_type (5.7~8.0.25)、replica_parallel_type (8.0.26~8.0.29)



設定在 replica 上允許哪些 Transaction 並行回放
• DATABASE：Transaction 必須作用於不同 Database 才能並行。
• LOGICAL_CLOCK：基於 Source 寫入 binlog 的 timestamp 來決定 Transaction 的並行，也就是基於 Group Commit。
建議將 binlog_transaction_dependency_tracking 設置為 WRITESET 或 WRITESET_SESSION ，這樣在合適的情況下會走 WriteSet 來提高並行度。
預計 8.0.29 之後棄用此參數，總是以 LOGICAL_CLOCK 的方式運行。

• binlog_group_commit_sync_delay



控制 binlog commit 之後等待 N 微秒後才 fsync 到 Disk，設置越大單個 Group 可以有更多時間等到更多的 Transaction 一起 fsync Disk，減少 fsync 的次數及減少每個 Transaction commit 的單位時間。
此外適度的增加對於以下設置的 MTS 也能增加在 Slave 的並行度：
注意：會增加 server 上 transaction 的延遲，也就是 client 端收到 transaction commit 的時間會變晚，另外相應的會增加資源的競爭，因此需評估最好的設置。
補充：在有 Group Commit 之後，sync_binlog 的單位指的是 Group 而不是 Transaction，例如：sync_binlog = 1000，表示的不是每 1000 個 Transaction 就 sync binlog，而是每 1000 個 Group 才 sync binlog。

• binlog_group_commit_sync_no_delay_count



在 Group commit 中等待的 N 個 Transaction 後就不等待 binlog_group_commit_sync_delay 設置的時間直接開始 sync binlog。
當 binlog_group_commit_sync_delay = 0 ，此參數無效。

• slave_preserve_commit_order (5.7~8.0.25)、replica_preserve_commit_order (8.0.26~)



只有當 slave_parallel_type = LOGICAL_CLOCK 且 log-slave-updates 開啟時才能設置。
當設置為 0 或 OFF 時，在 Replica 上的讀取操作無法滿足 Causal Consistency ，在 Source 和 Replica 上 Transaction 在 binlog 中可能有不同的寫入順序，另外在檢查 Replica 上最近執行的 Transaction 無法保證對應到 Source 上該 Transaction 位置之前的 Transaction 都已經執行完畢。
設置為 1 或 ON 確保 Transaction 在執行時按照在 relay log 中的順序，這可以讓 Master 和 Replica 有相同的 Transaction history log，也就是符合 Causal Consistency。

• binlog_transaction_dependency_tracking (5.7.22~)



指定 Source 依據什麼方式來生成 Transaction 之間的依賴關係寫入 binlog，協助 Replica 確定那些 Transaction 能夠並行執行。
必須設置 replica_parallel_type 為 LOGICAL_CLOCK。
有以下三種值：
• COMMIT_ORDER：使用 5.7 Group commit 的方式判斷。
• WRITESET：使用 WriteSet 的方式判斷 Transaction 是否有衝突。
• WRITESET_SESSION：WRITESET 的基礎上保證同一個 session 內的 Transaction 不可並行。

• binlog_transaction_dependency_history_size (8.0~)



WriteSet 會判斷 Transaction 之間是否衝突，因此需要將 commit 的 Transaction 修改的行 hash 後暫時保存在內存。
此參數用來設定儲存的 hash 上限，超過此上限會清除先前的歷史紀錄。
若 Source 性能有餘裕可以考慮提升此參數，進一步提高 Replica 的並行度。

• transaction_write_set_extraction



設定 WriteSet 使用的 Hash 演算法。
MySQL 5.7 預設為 OFF，MySQL 8.0.26 後棄用，一般不用特別調整。

官方測試數據

• 在 Source 低並行率的情況，WRITESET 的機制下 Replica 仍舊能夠有良好的並行率。

• 當 Source 並行率越高，COMMIT_ORDER 和 WriteSet 差距會縮小。

親自測試

環境：Mysql 8.0.12，測試前stop slave，待sysbench跑完後在start slave

確認在performance_schema中，MTS相關的統計ENABLED皆有開啟(YES)

(*啟用或禁用transaction event的收集)

(分別為當前的transaction event，每個線程最近的transaction event，global(跨線程)最近的transaction event)

查詢MTS並行度的語法

首次壓測以Threads 1 進行10分鐘壓測

在commit_order下測試(即MySQL 5.7使用)

在WriteSet下測試(MySQL 8.0新方案)

接著試試看Threads 128進行10分鐘壓測

在commit_order下測試(即MySQL 5.7使用)

在WriteSet下測試(MySQL 8.0新方案)

測試結果基本上和官方提供的差不多，主要是解決在Master低並行度的情況下，提高MTS的效率。

LOG

懶人包

MySQL 5.7~5.7.21 參數設定

• Source (Master)

• Replica (Slave)

MySQL 5.7.22~8.0.XX 參數設定

• Source (Master)

• Replica (Slave)

MTS 效率確認

參考