技術分享 | 從庫 MTS 多執行緒並行回放（一）

2020 年 3 月 13 日
筆記

作者：高鵬 文章末尾有他著作的《深入理解 MySQL 主從原理 32 講》，深入透徹理解 MySQL 主從，GTID 相關技術知識。

本節包含分發調用流程請參考鏈接：

https://www.jianshu.com/p/8706d7422d89

一、綜述

與單 SQL 執行緒的回放不同，MTS 包含多個工作執行緒，原有的 SQL 執行緒蛻變為協調執行緒。SQL 協調執行緒同時還承擔了檢查點的工作。我們知道並行回放的方式有兩種，包含 LOGICAL_CLOCK 和 DATABASE，體現在判定哪些事物能夠並行回放的規則不同。實際上源碼對應兩個不同的類：

Mts_submode_logical_clock
Mts_submode_database

這裡只準備討論基於 LOGICAL_CLOCK 的並發方式，而不會討論老的基於 DATABASE 的方式，下面是我設置的參數：

slave_parallel_type：LOGICAL_CLOCK
slave_parallel_workers ：4

注意 slave_parallel_workers 設置的是工作執行緒的個數，且不包協調執行緒，因此如果不想使用 MTS 應該將這個參數設置為 0，然後『stop slave;start slave』才能生效。因為工作執行緒在啟動的時候已經初始化完畢了。

因為我們知道在 5.7 中即便不開啟 GTID 也包含的匿名的 GTID Event，它攜帶了 last commit 和 seq number，因此即便關閉 GTID 也可以使用 MTS，但是不建議後面第 26 節可以找到原因。

在前面我們討論了 MySQL 層事務提交的流程和基於 WRITESET 的並行複製方式，我們總共提到了三種生成 last commit 和 seq number 的方式：

ORDER_COMMIT
WRITESET
WRITESET_SESSION

它們控制的是生成 last commit 和 seq number 的規則。而從庫只要將參數 slave_parallel_type 設置為 LOGICAL_CLOCK，其能否並行的依據就是 last commit 和 seq number。

我們下面的描述還是以一個正常的『Delete』語句刪除一行數據的 Event 來描述，那麼這個事物 Event 的順序如下：

同時在此之前我們先來明確一下 MySQL 中持久化 MTS 資訊的三個場所，因為和傳統的單 SQL 執行緒的主從不同，MTS 需要存儲更多的資訊。注意我們只討論 master_info_repository 和 relay_log_info_repository 為 TABLE 的情況，如下：

slave_master_info 表：由 IO 執行緒進行更新，超過 sync_master_info 設置更新，單位 Event 個數。
relay_log_info_repository 表：由 SQL 協調執行緒執行檢查點的時候進行更新。
slave_worker_info 表：由工作執行緒每次提交事務的時候更新。

更加詳細的解釋參考第 25 節，同時會解釋為什麼只考慮 master_info_repository 和 relay_log_info_repository 為 TABLE 的原因。

二、協調執行緒的分發機制

協調執行緒在 Event 的分發中主要完成下面兩個工作：

判定事務是否可以並行回放。
判定事務由哪一個工作執行緒進行回放。

和單 SQL 執行緒執行的流程不同，主要體現在函數 apply_event_and_update_pos 下面，對於單執行緒而言會完成 Event 的應用，而對用 MTS 而言就是只會完成 Event 的分發，具體的應用將會由工作執行緒完成。這裡說一下簡化的流程，具體函數調用參考筆記。下面是一張流程圖：

三、步驟解析

下面對每一步進行解析如下：

（1）如果是 GTID_LOG_EVENT 代表事物開始，將本事物加入到 GAQ 隊列中（下一節會詳細描述 GAQ）。可參考函數 Log_event::get_slave_worker。

（2）將 GTID_LOG_EVENT 加入到 curr_group_da 隊列中暫存。可參考函數 Log_event::get_slave_worker。

（3）獲取 GTID_LOG_EVENT 中的 last commit 和 seq number 值。可參考函數 Mts_submode_logical_clock::schedule_next_event。

（4）獲取 current_lwm 值，這個值代表的是所有在 GAQ 隊列上還沒有提交完成事務中最早的那個事務的前一個已經提交事務的 seq number，可能後面的事務已經提交完成了，聽起來可能比較拗口但很重要，如果都提交完成了那麼就是取最新提交的事務的 seq number，下面的圖表達的就是這個意思，這個圖是源碼中的。這個值的獲取可參考函數Mts_submode_logical_clock::get_lwm_timestamp。

the last time index containg lwm                 +------+                 | LWM  |                 |  |   |                 V  V   V  GAQ:x  xoooooxxxxxXXXXX...X               ^   ^               |   | LWM+1（LWM代表的是檢查點指向的位置）               |               + new current_lwm（這裡就是current_lwm）          <---- logical (commit) time ----    here `x' stands for committed, `X' for committed and discarded from  the running range of the queue, `o' for not committed.

我們可以先不看 LWM 部分，對於檢查點的 LWM 後面在討論。seq number 從右向左遞增，在 GAQ 中實際上有三種值：

X：已經做了檢查點，在 GAQ 中出隊的事物。
x：已經提交完成的事物。
o：沒有提交完成的事物。

我們可以看到我們需要獲取的 current_lwm 並不是最新一次提交事物的 seq number 的值，而是最早未提交事物的前一個已經提交事物的 seq number。這一點很重要，因為理解後就會知道大事務是如何影響 MTS 的並行回放的，同時中間的 5 個『o』實際上就是所謂的『gap』，關於『gap』下一節還會詳細描述。

（5）將 GTID_LOG_EVENT 中的 last commit 和當前 current_lwm 進行比較。可以參考函數 Mts_submode_logical_clock::schedule_next_event。下面是大概的規則：

如果 last commit 小於等於 current_lwm 表示可以進行並行回放，繼續。
如果 last commit 大於 current_lwm 則表示不能進行並行回放。這個時候協調執行緒就需要等待了，直到小於等於的條件成立。成立後協調執行緒會被工作執行緒喚醒。等待期間狀態被置為「Waiting for dependent transaction to commit」。

源碼處也比較簡單如下：

longlong lwm_estimate= estimate_lwm_timestamp();  //這個值 只有在 出現 下面等待的時候 才會設置 min_waited_timestamp ，  //設置了min_waited_timestamp才會更新lwm_estimate      if (!clock_leq(last_committed, lwm_estimate) &&  //  @return   true  when a "<=" b,false otherwise  last_committed<=lwm_estimate          rli->gaq->assigned_group_index != rli->gaq->entry)      {        if (wait_for_last_committed_trx(rli, last_committed, lwm_estimate))  //等待上一次 組提交的完成 Waiting for dependent transaction to commit

（6）如果是 QUERY_EVENT 則加入到 curr_group_da 隊列中暫存。

（7）如果是 MAP_EVENT 進行工作執行緒的分配。參考函數 Mts_submode_logical_clock::get_least_occupied_worker，分配工作執行緒如下：

如果有空閑的工作執行緒則分配完成，繼續。
如果沒有空閑的工作執行緒則等待空閑的工作執行緒。這種情況下狀態會置為「Waiting for slave workers to process their queues」。

下面是分配的標準，其實也很簡單：

for (Slave_worker **it= rli->workers.begin(); it != rli->workers.end(); ++it)    {      Slave_worker *w_i= *it;      if (w_i->jobs.len == 0)  //任務隊列為0表示本Worker執行緒空閑可以分配        return w_i;    }    return 0;

（8）將 GTID_LOG_EVENT 和 QUERY_EVENT 分配給工作執行緒。可參考 append_item_to_jobs 函數。

前面工作執行緒已經分配了，這裡就可以開始將 Event 分配給這個工作執行緒了。分配的時候需要檢查工作執行緒的任務隊列是否已滿，如果滿了需要等待，狀態置為「Waiting for Slave Worker queue」。因為分配的單位是 Event，對於一個事務而言可能包含很多 Event，如果工作執行緒應用的速度趕不上協調執行緒入隊的速度，可能導致任務隊列的積壓，因此任務隊列被佔滿是可能的。任務隊列的大小為 16384 如下：

mts_slave_worker_queue_len_max= 16384;

下面是入隊的部分程式碼：

while (worker->running_status == Slave_worker::RUNNING && !thd->killed &&           (ret= en_queue(&worker->jobs, job_item)) == -1)  //如果已經滿了    {      thd->ENTER_COND(&worker->jobs_cond, &worker->jobs_lock,                      &stage_slave_waiting_worker_queue, &old_stage);  //標記等待狀態      worker->jobs.overfill= TRUE;      worker->jobs.waited_overfill++;      rli->mts_wq_overfill_cnt++; //標記隊列滿的次數      mysql_cond_wait(&worker->jobs_cond, &worker->jobs_lock);  //等待喚醒      mysql_mutex_unlock(&worker->jobs_lock);      thd->EXIT_COND(&old_stage);      mysql_mutex_lock(&worker->jobs_lock);    }

（9）MAP_EVENT 分配給工作執行緒，同上。

（10）DELETE_EVENT 分配給工作執行緒，同上。

（11）XID_EVENT 分配給工作執行緒，但是這裡還需要額外的處理，主要處理一些和檢查點相關的資訊，這裡關注一點如下：

ptr_group->checkpoint_log_name= my_strdup(key_memory_log_event,  rli->get_group_master_log_name(), MYF(MY_WME));  ptr_group->checkpoint_log_pos= rli->get_group_master_log_pos();  ptr_group->checkpoint_relay_log_name=my_strdup(key_memory_log_event,  rli->get_group_relay_log_name(), MYF(MY_WME));  ptr_group->checkpoint_relay_log_pos= rli->get_group_relay_log_pos();  ptr_group->ts= common_header->when.tv_sec + (time_t) exec_time;  //Seconds_behind_master related .checkpoint  //的時候會將這個值再次傳遞 mts_checkpoint_routine()  ptr_group->checkpoint_seqno= rli->checkpoint_seqno;  //獲取seqno 這個值會在chkpt後減去偏移量

如果檢查點處於這個事務上，那麼這些資訊會出現在表 slave_worker_info 中，並且會出現在 show slave status 中。也就是說，show slave status 中很多資訊是來自 MTS 的檢查點。下一節將詳細描述檢查點。

（12）如果上面 Event 的分配過程大於 2 分鐘（120 秒），可能會出現一個日誌如下：

這個截圖也是一個朋友問的問題。實際上這個日誌可以算一個警告。實際上對應的源碼為：

sql_print_information("Multi-threaded slave statistics%s: "                  "seconds elapsed = %lu; "                  "events assigned = %llu; "                  "worker queues filled over overrun level = %lu; "                  "waited due a Worker queue full = %lu; "                  "waited due the total size = %lu; "                  "waited at clock conflicts = %llu "                  "waited (count) when Workers occupied = %lu "                  "waited when Workers occupied = %llu",                  rli->get_for_channel_str(),                  static_cast<unsignedlong>                  (my_now - rli->mts_last_online_stat),  //消耗總時間 單位秒                  rli->mts_events_assigned,  //總的event分配的個數                  rli->mts_wq_overrun_cnt,  // worker執行緒分配隊列大於 90%的次數 當前硬編碼  14746                  rli->mts_wq_overfill_cnt,  //由於work 分配隊列已滿造成的等待次數 當前硬編碼 16384                  rli->wq_size_waits_cnt,  //大Event的個數 一般不會存在                  rli->mts_total_wait_overlap,  //由於上一組並行有大事物沒有提交導致不能分配worker執行緒的等待時間 單位納秒                  rli->mts_wq_no_underrun_cnt,  //work執行緒由於沒有空閑的而等待的次數                  rli->mts_total_wait_worker_avail);  //work執行緒由於沒有空閑的而等待的時間   單位納秒

因為經常看到朋友問這裡詳細說明一下它們的含義，從前面的分析中我們一共看到三個等待點：

「Waiting for dependent transaction to commit」由於協調執行緒判定本事務由於 last commit 大於 current_lwm 因此不能並行回放，協調執行緒處於等待，大事務會加劇這種情況。
「Waiting for slave workers to process their queues」由於沒有空閑的工作執行緒，協調執行緒會等待。這種情況說明理論上的並行度是理想的，但是可能是參數 slave_parallel_workers 設置不夠。當然設置工作執行緒的個數應該和伺服器的配置和負載相結合考慮，因為第 29 節我們會看到執行緒是 CPU 調度最小的單位。
「Waiting for Slave Worker queue」由於工作執行緒的任務隊列已滿，協調執行緒會等待。這種情況前面說過是由於一個事務包含了過多的 Event 並且工作執行緒應用 Event 的速度趕不上協調執行緒分配 Event 的速度，導致了積壓並且超過了 16384 個 Event。

另外實際上還有一種等待如下：

「Waiting for Slave Workers to free pending events」：由所謂的『big event』造成的，什麼是『big event』呢，源碼中描述為：event size is greater than slave_pending_jobs_size_max but less than slave_max_allowed_packet。我個人認為出現的可能性不大，因此沒做過多考慮。可以在函數 append_item_to_jobs 中找到答案。

我們下面對應日誌中的輸出進行詳細解釋，如下：

我們可以看到這個日誌還是記錄很全的，基本覆蓋了前面我們討論的全部可能性。那麼我們再看看案例中的日誌，waited at clock conflicts=91895169800 大約 91 秒。120 秒鐘大約 91 秒都因為不能並行回放而造成的等待，很明顯應該考慮是否有大事物的存在。

四、並行回放判定的列子

下面是我主庫使用 WRITESET 方式生成的一段 binary log 片段，我們主要觀察 lastcommit 和 seq number，通過分析來熟悉這種過程。

我們根據剛才說的並行判斷規則，即：

如果 last commit 小於等於 current_lwm 表示可以進行並行回放，繼續。
如果 last commit 大於 current_lwm 則表示不能進行並行回放，需要等待。

具體解析如下：

（last commit：22 seq number：23）這個事務會在（last commit：21 seq number：22）事務執行完成後執行因為（last commit：22<= seq number：22），後面的事務直到（last_commit：22 seq number：30），實際上都可以並行執行，我們先假設他們都執行完成了。我們繼續觀察隨後的三個事務如下：

last_committed：29 sequence_number：31
last_committed：30 sequence_number：32
last_committed：27 sequence_number：33

我們注意到到這是基於 WRITESET 的並行複製下明顯的特徵。last commit 可能比上一個事務更小，這就是我們前面說的根據 Writeset 的歷史 MAP 資訊計算出來的。因此還是根據上面的規則它們三個是可以並行執行的。因為很明顯：

last_committed：29 <= current_lwm：30
last_committed：30 <= current_lwm：30
last_committed：27 <= current_lwm：30

但是如果（last commit：22 seq number：30）這個事務之前有一個大事務沒有執行完成的話，那麼 current_lwm 的取值將不會是 30。比如（last commit：22 seq number：27）這個事務是大事務那麼 current_lwm 將會標記為 26，上面的三個事務將會被堵塞，並且分配（last commit：29 seq number：31）的時候就已經堵塞了，原因如下：

last_committed：29 > current_lwm：26
last_committed：30 > current_lwm：26
last_committed：27 > current_lwm：26

我們再考慮一下基於 WRITESET 的並行複製下（last commit：27 seq number：33）這個事務，因為在我們並行規則下 last commit 越小獲得並發的可能性越高。因此基於 WRITESET 的並行複製確實提高了從庫回放的並行度，但正如第 16 節《基於 WRITESET 的並行複製方式》所講主庫會有一定的開銷。

第 19 節結束。

最後推薦高鵬的專欄《深入理解 MySQL 主從原理 32 講》，想要透徹了解學習 MySQL 主從原理的朋友不容錯過。