MySQL 並行複製方案演進歷史及原理分析
有過線上 MySQL 維護經驗的童鞋都知道，主從延遲往往是一個讓人頭疼不已的問題。
不僅僅是其造成的潛在問題比較嚴重，而且主從延遲原因的定位尤其考量 DBA 的綜合能力：既要熟悉複製的內部原理，又能解讀主機層面的資源使用情況，甚至還要會分析 binlog。
導致主從延遲的一個常見原因是，對於 binlog 中的事務，從庫上只有一個 SQL 執行緒進行重放，而這些事務在主庫中是併發寫入的。
就好比你多個人（多執行緒）挖坑，我一個人（單執行緒）來填，本來就雙拳難敵四手，在你挖坑速度不快的情況下，我尚能應付。一旦你稍微加速，我則力有不逮，只能眼睜睜地看著你挖的坑越來越深。
具體在 MySQL 中，則意味著 Seconds_Behind_Master 的值越來越大。
本文主要包括以下幾部分：
1、主從延遲的危害。
2、並行複製方案簡介。
3、MySQL 5.7 基於組提交的並行複製方案，包括 Commit-Parent-Based 方案和 Lock-Based 方案。
4、MySQL 8.0 基於 WRITESET 的並行複製方案。
5、對 COMMIT_ORDER，WRITESET_SESSION，WRITESET 這三種方案的壓測結果。
6、如何開啟並行複製。
一、主從延遲的危害
主從延遲帶來的問題，主要體現在以下兩個方面：
1、對於讀寫分離的業務，主從延遲意味著業務會讀到舊資料。
2、主從延遲過大，會影響資料庫的高可用切換。這一點尤其需要注意。
如果等待從庫應用完差異的 binlog 才做高可用切換，無疑會影響資料庫服務的可用性。
如果不等待，直接切換，則意味著沒應用完的這部分 binlog 的資料會丟失，業務不一定能接受這種情況。
二、並行複製方案簡介
MySQL官方先後提出了多個不同的並行複製方案，具體如下。
1、MySQL 5.6 基於庫級別的並行複製方案。
2、MySQL 5.7 基於組提交的並行複製方案。
3、MySQL 8.0 基於 WRITESET 的並行複製方案。
因為線上大部分環境都是單庫多表的，所以基於庫級別的並行複製實際上用得並不多。
下面，重點看看後兩個方案的實現原理。
三、基於組提交的並行複製方案
MySQL 5.7 基於組提交的並行複製方案，先後經歷了兩個版本的迭代：Commit-Parent-Based 方案和 Lock-Based 方案。
3.1 Commit-Parent-Based 方案
MySQL 會將一個事務拆分為兩個階段進行處理：Prepare 階段和 Commit 階段。
另外，InnoDB 使用的鎖機制是悲觀鎖。在悲觀鎖中，事務是在操作之初執行加鎖操作，如果鎖資源被其它事務佔用了，則該事務會被阻塞。
基於這兩點，我們不難推斷出，兩個事務如果都進入了 Prepare 階段，則意味著它們之間是沒有鎖衝突的，在從庫重放時可並行執行。這就是 Commit-Parent-Based 方案的核心思想。
具體實現上：
1、主庫有個全域性計數器（global counter），每次在事務儲存引擎層提交之前，都會增加這個計數器。
2、在事務進入 Prepare 階段之前，會將全域性計數器的當前值記錄在事務中，這個值稱為事務的 commit-parent。
3、這個 commit-parent 會寫入 binlog，記錄在事務的頭部。
4、從庫重放時，如果發現兩個事務的 commit-parent 相同，會並行執行這兩個事務。
以下面這 7 個事務為例，看看這 7 個事務在從庫的並行執行情況。
Trx1 ------------P----------C-------------------------------->
|
Trx2 ----------------P------+---C---------------------------->
| |
Trx3 -------------------P---+---+-----C---------------------->
| | |
Trx4 -----------------------+-P-+-----+----C----------------->
| | | |
Trx5 -----------------------+---+-P---+----+---C------------->
| | | | |
Trx6 -----------------------+---+---P-+----+---+---C---------->
| | | | | |
Trx7 -----------------------+---+-----+----+---+-P-+--C------->
| | | | | | |
示例中的 Trx 指的是事務，P 指的是事務在進行 Prepare 階段之前，讀取 commit-parent 的時間點。C 指的是事務在進行 Commit 階段之前，增加全域性計數器的時間點。
下面看看這 7 個事務的並行執行情況。
Trx1、Trx2、Trx3 並行執行。
Trx4 序列執行。
Trx5、Trx6 並行執行。
Trx7 序列執行。
這在很大程度上實現了並行，但還不夠完美。
實際上，Trx4、Trx5、Trx6 可並行執行，因為它們同時進入了 Prepare 階段。同理，Trx6、Trx7 也可並行執行。
基於此，官方迭代了並行複製方案，推出了新的 Lock-Based 方案。
3.2 Lock-Based 方案
該方案引入了鎖區間（locking interval）的概念，鎖區間定義了一個事務持有鎖的時間範圍。具體來說，
1、將 Prepare 階段，最後一個 DML 語句獲取鎖的時間點，定義為鎖區間的開始點。
2、將儲存引擎層提交之前，鎖釋放的時間點，定義為鎖區間的結束點。
如果兩個事務的鎖區間存在交集，則意味著這兩個事務沒有鎖衝突，可並行重放。例如，
Trx1 -----L---------C------------>
Trx2 ----------L---------C------->
反之，則不可並行重放，例如，
Trx1 -----L----C----------------->
Trx2 ---------------L----C------->
這裡的 L 代表鎖區間的開始點，C 代表鎖區間的結束點。
在具體實現上，主庫引入了以下 4 個變數：
1、global.transaction_counter：事務計數器。
2、transaction.sequence_number：事務序列號。
在事務進入 Prepare 階段之前，會將 global.transaction_counter 自增加 1 並賦值給 transaction.sequence_number。
transaction.sequence_number = ++global.transaction_counter
序列號不是一直遞增的，每切換一個 binlog，都會將 transaction.sequence_number 重置為 1。
3、global.max_committed_transaction：當前已提交事務的最大序列號。
在事務進行儲存引擎層提交之前，會取 global.max_committed_transaction 和當前事務的 sequence_number 的最大值，賦值給 global.max_committed_transaction。
global.max_committed_transaction = max(global.max_committed_transaction,
transaction.sequence_number)
4、transaction.last_committed：在事務進入 Prepare 階段之前，已提交事務的最大序列號。
transaction.last_committed = global.max_committed_transaction
在這 4 個變數中，transaction.sequence_number 和 transaction.last_committed 會寫入 binlog。
具體來說，對於 GTID 複製，它們會寫入 GTID_LOG_EVENT；對於非 GTID 複製，則寫入 ANONYMOUS_GTID_LOG_EVENT 。
對於示例中的 7 個事務，記錄在 binlog 中的 last_committed、sequence_number 如下所示：
Trx1: last_committed=0 sequence_number=1
Trx2: last_committed=0 sequence_number=2
Trx3: last_committed=0 sequence_number=3
Trx4: last_committed=1 sequence_number=4
Trx5: last_committed=2 sequence_number=5
Trx6: last_committed=2 sequence_number=6
Trx7: last_committed=5 sequence_number=7
3.3 從庫並行重放的邏輯
下面說說從庫並行重放的邏輯。
從庫引入了一個事務佇列（ transaction_sequence ），包含了當前正在執行的事務。
該佇列是有序的，按照事務的 sequence_number 從小到大排列。這個佇列中的事務可並行執行。
一個新的事務能否插入這個佇列，唯一的判斷標準是，事務的 last_committed 是否小於佇列中第一個事務的 sequence_number。只有小於才允許插入。
transaction.last_committed < transaction_sequence[0].sequence_number
最後，回到示例中的 7 個事務，結合 binlog 中的 last_committed 和 sequence_number，我們看看這 7 個事務的並行執行情況。
Trx1、Trx2、Trx3 並行執行。
Trx1 執行完畢後，Trx4 可加入佇列。
Trx2 執行完畢後，Trx5、Trx6 可加入佇列。
Trx5 執行完畢後，Trx7 可加入佇列。
不難發現，相對於 Commit-Parent-Based 方案，Lock-Based 方案的並行度確實大大提高了。
3.4 組提交方案小結
無論是 Commit-Parent-Based 方案，還是 Lock-Based 方案，依賴的都是組提交（Group Commit）。
組提交方案有以下兩個特點：
1、適用於高併發場景。因為只有在高併發場景下，才會有更多的事務放到一個組（Group）中提交。
2、在級聯複製中，層級越深，並行度越低。
針對低併發場景，如果要提升從庫的並行效率，可調整以下兩個引數：
binlog_group_commit_sync_delay
binlog 刷盤（fsync）之前等待的時間。單位微秒，預設為 0，不等待。
該值越大，一個組內的事務就越多，相應地，從庫的並行度也就越高。但該值越大，客戶端的響應時間也會越長。
binlog_group_commit_sync_no_delay_count
在 binlog_group_commit_sync_delay 時間內，允許等待的最大事務數。
如果 binlog_group_commit_sync_delay 設定為 0，則此引數無效。
四、WRITESET 方案
MySQL 8.0 推出了 WRITESET 方案。該方案推出的初衷實際上是為 Group Replication 服務的，主要是用於認證階段（Certification）的衝突檢測。
WRITESET 方案的核心思想是，兩個來自不同節點的併發事務，只要沒修改同一行，就不存在衝突。對於沒有衝突的併發事務，在寫入relay log 中時，可以共享一個 last_committed。
這裡的衝突檢測，實際上比較的是兩個事務之間的寫集合（writeset）。
注意，writeset 和 WRITESET 兩者的區別，前者指的是事務的寫集合，後者則特指 WRITESET 方案。
4.1 事務寫集合的生成過程
下面來看看事務 writeset 的生成過程。具體步驟如下：
1、首先提取被修改行的主鍵、唯一索引、外來鍵資訊。一張表，如果有主鍵和一個唯一索引，則每修改一行，會提取兩條約束資訊：一條針對主鍵，另一條針對唯一索引。針對主鍵的，提取的資訊包括主鍵名、庫名、表名、主鍵值，這些資訊會拼湊為一個字串。
2、計算該字串的雜湊值，具體的雜湊演算法由 transaction_write_set_extraction 引數指定。
3、將計算後的雜湊值插入當前事務的寫集合。
4.2 WRITESET 方案的實現原理
接下來，結合原始碼看看 WRITESET 方案的實現原理。
void Writeset_trx_dependency_tracker::get_dependency(THD *thd,
int64 &sequence_number,
int64 &commit_parent) {
Rpl_transaction_write_set_ctx *write_set_ctx =
thd->get_transaction()->get_transaction_write_set_ctx();
std::vector<uint64> *writeset = write_set_ctx->get_write_set();
#ifndef NDEBUG
/* 空事務的寫集合必須為空 */
if (is_empty_transaction_in_binlog_cache(thd)) assert(writeset->size() == 0);
#endif
/*
判斷一個事務能否使用 WRITESET 方案
*/
bool can_use_writesets =
// 事務寫集合的大小不為 0 或者事務為空事務
(writeset->size() != 0 || write_set_ctx->get_has_missing_keys() ||
is_empty_transaction_in_binlog_cache(thd)) &&
// 事務的 transaction_write_set_extraction 必須與全域性設定一致
(global_system_variables.transaction_write_set_extraction ==
thd->variables.transaction_write_set_extraction) &&
// 不能被其它表外來鍵關聯
!write_set_ctx->get_has_related_foreign_keys() &&
// 事務寫集合的大小不能超過 binlog_transaction_dependency_history_size
!write_set_ctx->was_write_set_limit_reached();
bool exceeds_capacity = false;
if (can_use_writesets) {
/*
檢查 m_writeset_history 加上事務寫集合的大小是否超過 m_writeset_history 的上限，
m_writeset_history 的上限由引數 binlog_transaction_dependency_history_size 決定
*/
exceeds_capacity =
m_writeset_history.size() + writeset->size() > m_opt_max_history_size;
/*
計算所有衝突行中最大的 sequence_number，並將被修改行的雜湊值插入 m_writeset_history
*/
int64 last_parent = m_writeset_history_start;
for (std::vector<uint64>::iterator it = writeset->begin();
it != writeset->end(); ++it) {
Writeset_history::iterator hst = m_writeset_history.find(*it);
if (hst != m_writeset_history.end()) {
if (hst->second > last_parent && hst->second < sequence_number)
last_parent = hst->second;
hst->second = sequence_number;
} else {
if (!exceeds_capacity)
m_writeset_history.insert(
std::pair<uint64, int64>(*it, sequence_number));
}
}
// 如果表上都存在主鍵，則會取 last_parent 和 commit_parent 的較小值作為事務的 commit_parent。
if (!write_set_ctx->get_has_missing_keys()) {
commit_parent = std::min(last_parent, commit_parent);
}
}
if (exceeds_capacity || !can_use_writesets) {
m_writeset_history_start = sequence_number;
m_writeset_history.clear();
}
}
該函式的處理流程如下：
1、呼叫函式時，會傳入事務的 sequence_number，commit_parent（last_committed），這兩個值是基於 Lock-Based 方案生成的。
2、獲取事務的寫集合。可以看到，事務的寫集合是陣列型別。
3、判斷一個事務能否使用 WRITESET 方案。
以下場景不能使用 WRITESET 方案，此時，只能使用 Lock-Based 方案生成的 last_committed。
事務沒有寫集合。常見的原因是表上沒有主鍵。 當前事務 transaction_write_set_extraction 的設定與全域性不一致。 表被其它表外來鍵關聯。 事務寫集合的大小超過 binlog_transaction_dependency_history_size。
4、如果能使用 WRITESET 方案。
4.1、首先判斷 m_writeset_history 的容量是否超標。
具體來說，m_writeset_history + writeset 的大小是否超過 binlog_transaction_dependency_history_size 的設定。
4.2、將 m_writeset_history_start 賦值給變數 last_parent。
m_writeset_history_start 代表不在 m_writeset_history 中最後一個事務的 sequence_number，其初始值為 0。
當引數 binlog_transaction_dependency_tracking 發生變化或清空 m_writeset_history 時，會更新 m_writeset_history_start。
4.3、迴圈遍歷事務的寫集合，判斷被修改行對應的雜湊值是否在 m_writeset_history 存在。
若存在，則意味著 m_writeset_history 存在同一行的操作。既然是同一行的不同操作，自然就不能並行重放。這個時候，會將 m_writeset_history 中該行的 sequence_number 賦值給 last_parent。
需要注意的是，這裡會迴圈遍歷完事務的寫集合，畢竟這個事務中可能有多條記錄在 m_writeset_history 中存在。
在遍歷的過程中，會判斷 m_writeset_history 中衝突行的 sequence_number 是否大於 last_parent，只有大於才會賦值。換言之，這裡會取所有衝突行中最大的 sequence_number，賦值給 last_parent。
若不存在，則判斷 m_writeset_history 的容量是否超標，若不超標，則會將被修改行的雜湊值插入 m_writeset_history。
可以看到，m_writeset_history 是個字典型別。其中 key 儲存的是被修改行的雜湊值，value 儲存的是事務的 sequence_number。
5、判斷被操作的表上是否都存在主鍵。
若存在，才會取 last_parent 和 commit_parent 的較小值作為事務的 commit_parent。否則，使用的還是 Lock-Based 方案生成的commit_parent。
6、如果 m_writeset_history 容量超標或者事務不能使用 WRITESET 方案，則會將當前事務的 sequence_number 賦值給m_writeset_history_start，同時清空 m_writeset_history。
4.3 WRITESET 方案的相關引數
下面看看 WRITESET 方案的三個引數。
binlog_transaction_dependency_tracking
指定基於何種方案決定事務的依賴關係。對於同一個事務，不同的方案可生成不同的 last_committed。
該引數有以下取值：
COMMIT_ORDER：基於 Lock-Based 方案決定事務的依賴關係。預設值。
WRITESET：基於 WRITESET 方案決定事務的依賴關係。
WRITESET_SESSION：同 WRITESET 類似，只不過同一個會話中的事務不能並行執行。
transaction_write_set_extraction
指定事務寫集合的雜湊演算法，可設定的值有：OFF，MURMUR32，XXHASH64（預設值）。
對於 Group Replication，該引數必須設定為 XXHASH64。
注意，若要將 binlog_transaction_dependency_tracking 設定為 WRITESET 或 WRITESET_SESSION，則該引數不能設定為 OFF。
binlog_transaction_dependency_history_size
m_writeset_history 的上限，預設 25000。
一般來說，binlog_transaction_dependency_history_size 越大，m_writeset_history 能儲存的行的資訊就越多。在不出現行衝突的情況下，m_writeset_history_start 也會越小。相應地，新事務的 last_committed 也會越小，在從庫重放的併發度也會越高。
五、壓測結果
接下來，看看 MySQL 官方對於 COMMIT_ORDER，WRITESET_SESSION，WRITESET 這三種方案的壓測結果。
主庫環境：16 核，SSD，1個資料庫，16 張表，共 800w 條資料。
壓測場景：OLTP Read/Write, Update Indexed Column 和 Write-only。
壓測方案：在關閉複製的情況下，在不同的執行緒數下，注入 100w 個事務。開啟複製，觀察不同執行緒數下，不同方案的從庫重放速度。
三個場景下的壓測結果如圖所示。
分析壓測結果，我們可以得出以下結論。
1、對於 COMMIT_ORDER 方案，主庫併發度越高，從庫的重放速度越快。
2、對於 WRITESET 方案，主庫的併發執行緒數對其幾乎沒有影響。甚至，單執行緒下 WRITESET 的重放速度都超過了 256 執行緒下的COMMIT_ORDER。
3、與 COMMIT_ORDER 一樣，WRITESET_SESSION 也依賴於主庫併發。只不過，在主庫併發執行緒數較低（4 執行緒、8 執行緒）的情況下，WRITESET_SESSION 也能實現較高的吞吐量。
六、如何開啟並行複製
在從庫上設定以下三個引數。
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 16
slave_preserve_commit_order = ON
下面看看這三個引數的的具體含義。
slave_parallel_type
設定從庫並行複製的型別。該引數有以下取值：
DATABASE：基於庫級別的並行複製。MySQL 8.0.27 之前的預設值。 LOGICAL_CLOCK：基於組提交的並行複製。
slave_parallel_workers
設定 Worker 執行緒的數量。開啟了多執行緒複製，原來的 SQL 執行緒將演變為 1 個 Coordinator 執行緒和多個 Worker 執行緒。
slave_preserve_commit_order
事務在從庫上的提交順序是否與主庫保持一致，建議開啟。
需要注意的是，調整這三個引數，需要重啟複製才能生效。
從 MySQL 5.7.22、MySQL 8.0 開始，可使用 WRITESET 方案進一步提升並行複製的效率，此時，需在主庫上設定以下引數。
binlog_transaction_dependency_tracking = WRITESET_SESSION
transaction_write_set_extraction = XXHASH64
binlog_transaction_dependency_history_size = 25000
binlog_format = ROW
注意，基於 WRITESET 的並行複製方案，只在 binlog 格式為 ROW 的情況下才生效。
七、參考資料
1、WL#6314: MTS: Prepared transactions slave parallel applier：https://dev.mysql.com/worklog/task/?id=6314
2、WL#6813: MTS: ordered commits (sequential consistency)：https://dev.mysql.com/worklog/task/?id=6813
3、WL#7165: MTS: Optimizing MTS scheduling by increasing the parallelization window on master：https://dev.mysql.com/worklog/task/?id=7165
4、WL#8440: Group Replication: Parallel applier support：https://dev.mysql.com/worklog/task/?id=8440
5、WL#9556: Writeset-based MTS dependency tracking on master：https://dev.mysql.com/worklog/task/?id=9556
6、WriteSet並行複製：
7、Improving the Parallel Applier with Writeset-based Dependency Tracking：
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024420/viewspace-2938244/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- mysql 並行複製原理MySql並行
- MySQL並行複製(MTS)原理（完整版）MySql並行
- MySQL 5.7並行複製MySql並行
- MySQL 5.7 並行複製MySql並行
- MySQL · 功能分析 · 5.6 並行複製實現分析MySql並行
- [Mysql]Mysql5.7並行複製MySql並行
- Angular Universal 的演進歷史Angular
- Mysql主從複製原理及搭建MySql
- mysql主從複製原理及配置MySql
- mysql 5.7開啟並行複製MySql並行
- mysql 5.7 主從複製搭建及原理MySql
- 【Mysql】mysql5.7新特性之-並行複製實現原理與調優MySql並行
- 長篇分析：從歷史演進角度談研發成本和製作傾向調整
- 各版本 MySQL 並行複製的實現及優缺點MySql並行
- 網易影片雲：MySQL 5.7 並行複製實現原理與調優MySql並行
- MYSQL並行複製（parallel replication部署篇）MySql並行Parallel
- MySQL 傳統複製與 GTID 複製原理及操作詳解MySql
- mysql複製原理圖MySql
- MySQL 同步複製及高可用方案總結MySql
- redis系列--主從複製以及redis複製演進Redis
- MySQL並行複製-原始碼理解記錄MySql並行原始碼
- MySQL 5.6並行複製的架構圖MySql並行架構
- MySQL Case-MySQL5.7無效的並行複製MySql並行
- MySQL Case-MySQL8.0真正的並行複製writesetMySql並行
- MySQL主從複製歷程MySql
- MySQL主從複製原理MySql
- MySQL（13）---MYSQL主從複製原理MySql
- mysql replication /mysql 主從複製原理MySql
- MySQL Cluster 與 MongoDB 複製群集分片設計及原理MySqlMongoDB
- 我經歷過的監控系統演進史
- Android開發之道（3）系統演進歷史Android
- mysql同步(複製)延遲的原因及解決方案MySql
- Mysql歷史MySql
- MySQL並行複製延時時間不準確MySql並行
- mysql 複製原理與實踐MySql
- MySQL5.6複製原理圖MySql
- Mysql的複製原理以及流程MySql
- MySQL 8 複製（七）——組複製基本原理MySql