今天就跟大家聊聊有關(guān)怎么進(jìn)行從庫(kù)MTS多線程并行回放，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
與單SQL線程的回放不同，MTS包含多個(gè)工作線程，原有的SQL線程蛻變?yōu)閰f(xié)調(diào)線程。SQL協(xié)調(diào)線程同時(shí)還承擔(dān)了檢查點(diǎn)的工作。我們知道并行回放的方式有兩種，包含LOGICAL_CLOCK和DATABASE，體現(xiàn)在判定哪些事物能夠并行回放的規(guī)則不同。實(shí)際上源碼對(duì)應(yīng)兩個(gè)不同的類(lèi)：
Mts_submode_logical_clock
Mts_submode_database
這里只準(zhǔn)備討論基于LOGICAL_CLOCK的并發(fā)方式，而不會(huì)討論老的基于DATABASE的方式，下面是我設(shè)置的參數(shù)：
slave_parallel_type：LOGICAL_CLOCK
slave_parallel_workers ：4
注意slave_parallel_workers設(shè)置的是工作線程的個(gè)數(shù)，且不包協(xié)調(diào)線程，因此如果不想使用MTS應(yīng)該將這個(gè)參數(shù)設(shè)置為0，然后‘stop slave;start slave’才能生效。因?yàn)楣ぷ骶€程在啟動(dòng)的時(shí)候已經(jīng)初始化完畢了。
因?yàn)槲覀冎涝?.7中即便不開(kāi)啟GTID也包含的匿名的GTID Event，它攜帶了last commit和seq number，因此即便關(guān)閉GTID也可以使用MTS，但是不建議后面第26節(jié)可以找到原因。
在前面我們討論了MySQL層事務(wù)提交的流程和基于WRITESET的并行復(fù)制方式，我們總共提到了三種生成last commit和seq number的方式：
ORDER_COMMIT
WRITESET
WRITESET_SESSION
它們控制的是生成last commit和seq number的規(guī)則。而從庫(kù)只要將參數(shù)slave_parallel_type設(shè)置為L(zhǎng)OGICAL_CLOCK，其能否并行的依據(jù)就是last commit和seq number。
我們下面的描述還是以一個(gè)正常的‘Delete’語(yǔ)句刪除一行數(shù)據(jù)的Event來(lái)描述，那么這個(gè)事物Event的順序如下：
| Event類(lèi)型 |
|---|
| GTID_LOG_EVENT |
| QUERY_EVENT |
| MAP_EVENT |
| DELETE_EVENT |
| XID_EVENT |
同時(shí)在此之前我們先來(lái)明確一下MySQL中持久化MTS信息的三個(gè)場(chǎng)所，因?yàn)楹蛡鹘y(tǒng)的單SQL線程的主從不同，MTS需要存儲(chǔ)更多的信息。注意我們只討論master_info_repository和relay_log_info_repository為T(mén)ABLE的情況，如下：
slave_master_info表：由IO線程進(jìn)行更新，超過(guò)sync_master_info設(shè)置更新，單位Event個(gè)數(shù)。
relay_log_info_repository表：由SQL協(xié)調(diào)線程執(zhí)行檢查點(diǎn)的時(shí)候進(jìn)行更新。
slave_worker_info表：由工作線程每次提交事務(wù)的時(shí)候更新。
更加詳細(xì)的解釋參考第25節(jié)，同時(shí)會(huì)解釋為什么只考慮master_info_repository和relay_log_info_repository為T(mén)ABLE的原因。
協(xié)調(diào)線程在Event的分發(fā)中主要完成下面兩個(gè)工作：
判定事務(wù)是否可以并行回放。
判定事務(wù)由哪一個(gè)工作線程進(jìn)行回放。
和單SQL線程執(zhí)行的流程不同，主要體現(xiàn)在函數(shù)apply_event_and_update_pos下面，對(duì)于單線程而言會(huì)完成Event的應(yīng)用，而對(duì)用MTS而言就是只會(huì)完成Event的分發(fā)，具體的應(yīng)用將會(huì)由工作線程完成。
這里說(shuō)一下簡(jiǎn)化的流程，具體函數(shù)調(diào)用參考筆記。下面是一張流程圖（圖19-1，高清原圖包含在文末原圖中）：
下面對(duì)每一步進(jìn)行解析如下：
（1）如果是GTID_LOG_EVENT代表事物開(kāi)始，將本事物加入到GAQ隊(duì)列中（下一節(jié)會(huì)詳細(xì)描述GAQ）。可參考函數(shù)Log_event::get_slave_worker。
（2）將GTID_LOG_EVENT加入到curr_group_da隊(duì)列中暫存?？蓞⒖己瘮?shù)Log_event::get_slave_worker。
（3）獲取GTID_LOG_EVENT中的last commit和seq number值。可參考函數(shù)Mts_submode_logical_clock::schedule_next_event。
（4）獲取current_lwm值，這個(gè)值代表的是所有在GAQ隊(duì)列上還沒(méi)有提交完成事務(wù)中最早的那個(gè)事務(wù)的前一個(gè)已經(jīng)提交事務(wù)的seq number，可能后面的事務(wù)已經(jīng)提交完成了，聽(tīng)起來(lái)可能比較拗口但很重要，如果都提交完成了那么就是取最新提交的事務(wù)的seq number，下面的圖表達(dá)的就是這個(gè)意思，這個(gè)圖是源碼中的。這個(gè)值的獲取可參考函數(shù)Mts_submode_logical_clock::get_lwm_timestamp。
the last time index containg lwm +------+ | LWM | | | | V V V GAQ:x xoooooxxxxxXXXXX...X ^ ^ | | LWM+1（LWM代表的是檢查點(diǎn)指向的位置） | + 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部分，對(duì)于檢查點(diǎn)的LWM后面在討論。seq number從右向左遞增，在GAQ中實(shí)際上有三種值：
X：已經(jīng)做了檢查點(diǎn)，在GAQ中出隊(duì)的事物。
x：已經(jīng)提交完成的事物。
o：沒(méi)有提交完成的事物。
我們可以看到我們需要獲取的current_lwm并不是最新一次提交事物的seq number的值，而是最早未提交事物的前一個(gè)已經(jīng)提交事物的seq number。這一點(diǎn)很重要，因?yàn)槔斫夂缶蜁?huì)知道大事務(wù)是如何影響MTS的并行回放的，同時(shí)中間的5個(gè)‘o’實(shí)際上就是所謂的‘gap’，關(guān)于‘gap’下一節(jié)還會(huì)詳細(xì)描述。
（5）將GTID_LOG_EVENT中的last commit和當(dāng)前current_lwm進(jìn)行比較?？梢詤⒖己瘮?shù)Mts_submode_logical_clock::schedule_next_event。下面是大概的規(guī)則：
如果last commit小于等于current_lwm表示可以進(jìn)行并行回放，繼續(xù)。
如果last commit大于current_lwm則表示不能進(jìn)行并行回放。這個(gè)時(shí)候協(xié)調(diào)線程就需要等待了，直到小于等于的條件成立。成立后協(xié)調(diào)線程會(huì)被工作線程喚醒。等待期間狀態(tài)被置為“Waiting for dependent transaction to commit”。
源碼處也比較簡(jiǎn)單如下：
重慶分公司
重慶分公司
longlong lwm_estimate= estimate_lwm_timestamp();
//這個(gè)值 只有在 出現(xiàn) 下面等待的時(shí)候 才會(huì)設(shè)置 min_waited_timestamp ，
//設(shè)置了min_waited_timestamp才會(huì)更新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隊(duì)列中暫存。
（7）如果是MAP_EVENT進(jìn)行工作線程的分配。參考函數(shù)Mts_submode_logical_clock::get_least_occupied_worker，分配工作線程如下：
如果有空閑的工作線程則分配完成，繼續(xù)。
如果沒(méi)有空閑的工作線程則等待空閑的工作線程。這種情況下?tīng)顟B(tài)會(huì)置為“Waiting for slave workers to process their queues”。
下面是分配的標(biāo)準(zhǔn)，其實(shí)也很簡(jiǎn)單：
for (Slave_worker **it= rli->workers.begin(); it != rli->workers.end(); ++it)
{
Slave_worker *w_i= *it;
if (w_i->jobs.len == 0)
//任務(wù)隊(duì)列為0表示本W(wǎng)orker線程空閑可以分配
return w_i;
}
return 0;（8）將GTID_LOG_EVENT和QUERY_EVENT分配給工作線程?？蓞⒖糰ppend_item_to_jobs函數(shù)。
前面工作線程已經(jīng)分配了，這里就可以開(kāi)始將Event分配給這個(gè)工作線程了。分配的時(shí)候需要檢查工作線程的任務(wù)隊(duì)列是否已滿，如果滿了需要等待，狀態(tài)置為“Waiting for Slave Worker queue”。因?yàn)榉峙涞膯挝皇荅vent，對(duì)于一個(gè)事務(wù)而言可能包含很多Event，如果工作線程應(yīng)用的速度趕不上協(xié)調(diào)線程入隊(duì)的速度，可能導(dǎo)致任務(wù)隊(duì)列的積壓，因此任務(wù)隊(duì)列被占滿是可能的。任務(wù)隊(duì)列的大小為16384如下：
mts_slave_worker_queue_len_max= 16384;
下面是入隊(duì)的部分代碼：
while (worker->running_status == Slave_worker::RUNNING && !thd->killed &&
(ret= en_queue(&worker->jobs, job_item)) == -1)
//如果已經(jīng)滿了
{
thd->ENTER_COND(&worker->jobs_cond, &worker->jobs_lock,
&stage_slave_waiting_worker_queue, &old_stage);
//標(biāo)記等待狀態(tài)
worker->jobs.overfill= TRUE;
worker->jobs.waited_overfill++;
rli->mts_wq_overfill_cnt++; //標(biāo)記隊(duì)列滿的次數(shù)
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分配給工作線程，但是這里還需要額外的處理，主要處理一些和檢查點(diǎn)相關(guān)的信息，這里關(guān)注一點(diǎn)如下：
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 //的時(shí)候會(huì)將這個(gè)值再次傳遞 mts_checkpoint_routine() ptr_group->checkpoint_seqno= rli->checkpoint_seqno; //獲取seqno 這個(gè)值會(huì)在chkpt后減去偏移量
如果檢查點(diǎn)處于這個(gè)事務(wù)上，那么這些信息會(huì)出現(xiàn)在表 slave_worker_info中，并且會(huì)出現(xiàn)在show slave status中。也就是說(shuō)，show slave status中很多信息是來(lái)自MTS的檢查點(diǎn)。下一節(jié)將詳細(xì)描述檢查點(diǎn)。
（12）如果上面Event的分配過(guò)程大于2分鐘（120秒），可能會(huì)出現(xiàn)一個(gè)日志如下：
這個(gè)截圖也是一個(gè)朋友問(wèn)的問(wèn)題。實(shí)際上這個(gè)日志可以算一個(gè)警告。實(shí)際上對(duì)應(yīng)的源碼為：
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
(my_now - rli->mts_last_online_stat),
//消耗總時(shí)間 單位秒
rli->mts_events_assigned,
//總的event分配的個(gè)數(shù)
rli->mts_wq_overrun_cnt,
// worker線程分配隊(duì)列大于 90%的次數(shù) 當(dāng)前硬編碼 14746
rli->mts_wq_overfill_cnt,
//由于work 分配隊(duì)列已滿造成的等待次數(shù) 當(dāng)前硬編碼 16384
rli->wq_size_waits_cnt,
//大Event的個(gè)數(shù) 一般不會(huì)存在
rli->mts_total_wait_overlap,
//由于上一組并行有大事物沒(méi)有提交導(dǎo)致不能分配worker線程的等待時(shí)間 單位納秒
rli->mts_wq_no_underrun_cnt,
//work線程由于沒(méi)有空閑的而等待的次數(shù)
rli->mts_total_wait_worker_avail);
//work線程由于沒(méi)有空閑的而等待的時(shí)間 單位納秒 因?yàn)榻?jīng)?？吹脚笥褑?wèn)這里詳細(xì)說(shuō)明一下它們的含義，從前面的分析中我們一共看到三個(gè)等待點(diǎn)：
“Waiting for dependent transaction to commit”
由于協(xié)調(diào)線程判定本事務(wù)由于last commit大于current_lwm因此不能并行回放，協(xié)調(diào)線程處于等待，大事務(wù)會(huì)加劇這種情況。
“Waiting for slave workers to process their queues”
由于沒(méi)有空閑的工作線程，協(xié)調(diào)線程會(huì)等待。這種情況說(shuō)明理論上的并行度是理想的，但是可能是參數(shù)slave_parallel_workers設(shè)置不夠。當(dāng)然設(shè)置工作線程的個(gè)數(shù)應(yīng)該和服務(wù)器的配置和負(fù)載相結(jié)合考慮，因?yàn)榈?9節(jié)我們會(huì)看到線程是CPU調(diào)度最小的單位。
“Waiting for Slave Worker queue”
由于工作線程的任務(wù)隊(duì)列已滿，協(xié)調(diào)線程會(huì)等待。這種情況前面說(shuō)過(guò)是由于一個(gè)事務(wù)包含了過(guò)多的Event并且工作線程應(yīng)用Event的速度趕不上協(xié)調(diào)線程分配Event的速度，導(dǎo)致了積壓并且超過(guò)了16384個(gè)Event。
另外實(shí)際上還有一種等待如下：
“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。我個(gè)人認(rèn)為出現(xiàn)的可能性不大，因此沒(méi)做過(guò)多考慮。可以在函數(shù)append_item_to_jobs中找到答案。
我們下面對(duì)應(yīng)日志中的輸出進(jìn)行詳細(xì)解釋?zhuān)缦拢?/p>
| 指標(biāo) | 解釋 |
|---|---|
| seconds elapsed | 整個(gè)分配過(guò)程消耗的時(shí)間，單位秒，超過(guò)120秒會(huì)出現(xiàn)這個(gè)日志。 |
| events assigned | 本工作線程分配的Event數(shù)量。 |
| worker queues filled over overrun level | 本工作線程任務(wù)隊(duì)列中Event個(gè)數(shù)大于90%的次數(shù)。當(dāng)前硬編碼大于14746。 |
| waited due a Worker queue full | 本工作線程任務(wù)隊(duì)列已滿的次數(shù)。當(dāng)前硬編碼大于16384。和前面第三點(diǎn)對(duì)應(yīng)。 |
| waited due the total size | ‘big event’的出現(xiàn)的次數(shù)。 |
| waited at clock conflicts | 由于不能并行回放，協(xié)調(diào)線程等待的時(shí)間，單位納秒。和前面第一點(diǎn)對(duì)應(yīng)。 |
| waited (count) when Workers occupied | 由于沒(méi)有空閑的工作線程而等待的次數(shù)。對(duì)應(yīng)前面第二點(diǎn)。 |
| waited when Workers occupied | 由于沒(méi)有空閑的工作線程而等待的時(shí)間。對(duì)應(yīng)前面第二點(diǎn)。 |
我們可以看到這個(gè)日志還是記錄很全的，基本覆蓋了前面我們討論的全部可能性。那么我們?cè)倏纯窗咐械娜罩?，waited at clock conflicts=91895169800 大約91秒。120秒鐘大約91秒都因?yàn)椴荒懿⑿谢胤哦斐傻牡却?，很明顯應(yīng)該考慮是否有大事物的存在。
下面是我主庫(kù)使用WRITESET方式生成的一段binary log片段，我們主要觀察lastcommit和seq number，通過(guò)分析來(lái)熟悉這種過(guò)程。
我們根據(jù)剛才說(shuō)的并行判斷規(guī)則，即：
如果last commit小于等于current_lwm表示可以進(jìn)行并行回放，繼續(xù)。
如果last commit大于current_lwm則表示不能進(jìn)行并行回放，需要等待。
（last commit：22 seq number：23）這個(gè)事務(wù)會(huì)在（last commit：21 seq number：22）事務(wù)執(zhí)行完成后執(zhí)行因?yàn)椋╨ast commit：22<= seq number：22），后面的事務(wù)直到（last_commit：22 seq number：30），實(shí)際上都可以并行執(zhí)行，我們先假設(shè)他們都執(zhí)行完成了。我們繼續(xù)觀察隨后的三個(gè)事務(wù)如下：
last_committed：29 sequence_number：31
last_committed：30 sequence_number：32
last_committed：27 sequence_number：33
我們注意到到這是基于WRITESET的并行復(fù)制下明顯的特征。 last commit可能比上一個(gè)事務(wù)更小，這就是我們前面說(shuō)的根據(jù)Writeset的歷史MAP信息計(jì)算出來(lái)的。因此還是根據(jù)上面的規(guī)則它們?nèi)齻€(gè)是可以并行執(zhí)行的。因?yàn)楹苊黠@：
last_committed：29 <= current_lwm：30
last_committed：30 <= current_lwm：30
last_committed：27 <= current_lwm：30
但是如果（last commit：22 seq number：30）這個(gè)事務(wù)之前有一個(gè)大事務(wù)沒(méi)有執(zhí)行完成的話，那么current_lwm的取值將不會(huì)是30。比如（last commit：22 seq number：27）這個(gè)事務(wù)是大事務(wù)那么current_lwm將會(huì)標(biāo)記為26，上面的三個(gè)事務(wù)將會(huì)被堵塞，并且分配（last commit：29 seq number：31）的時(shí)候就已經(jīng)堵塞了，原因如下：
last_committed：29 > current_lwm：26
last_committed：30 > current_lwm：26
last_committed：27 > current_lwm：26
我們?cè)倏紤]一下基于WRITESET的并行復(fù)制下（last commit：27 seq number：33）這個(gè)事務(wù)，因?yàn)樵谖覀儾⑿幸?guī)則下last commit越小獲得并發(fā)的可能性越高。因此基于WRITESET的并行復(fù)制確實(shí)提高了從庫(kù)回放的并行度，但正如第16節(jié)所講主庫(kù)會(huì)有一定的開(kāi)銷(xiāo)。
看完上述內(nèi)容，你們對(duì)怎么進(jìn)行從庫(kù)MTS多線程并行回放有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，感謝大家的支持。
