mysql之 Percona XtraDB Cluster集群線程模型

Percona XtraDB集群創(chuàng)建一組線程來為其操作提供服務(wù)，這些線程與現(xiàn)有的MySQL線程無關(guān)。有三個主要線程組：

一、Applier線程

Applier線程應(yīng)用從其他節(jié)點接收的寫入集。寫消息直接通過gcv_recv_thread。

使用wsrep_slave_threads變量控制線程的數(shù)量。默認(rèn)值是1，這意味著至少有一個wsrep applier線程存在來處理請求。

Applier線程等待一個事件，一旦它捕獲到事件，它就使用普通的從應(yīng)用線程路徑應(yīng)用它，并用wsrep-customization中繼日志信息應(yīng)用路徑。這些線程與從屬工作線程類似（但不完全相同）。

使用“ Apply and Commit Monitor ” 可以實現(xiàn)協(xié)調(diào)。一個事務(wù)通過兩個重要的狀態(tài)：APPLY和COMMIT。每個事務(wù)都向自己申請的監(jiān)控器進(jìn)行注冊，其申請順序已經(jīng)定義。 因此，在應(yīng)用此事務(wù)之前，應(yīng)用所有具有小于此事務(wù)序號的序號（seqno）的事務(wù)。 commit也是這樣做的（last_left> = trx_.depends_seqno（））。

二、回滾線程

只有一個回滾線程在發(fā)生沖突時執(zhí)行回滾。

??并行執(zhí)行的事務(wù)可能會發(fā)生沖突并可能需要回滾。 
??Applier事務(wù)總是優(yōu)先于本地事務(wù)。這很自然，因為Applier事務(wù)已被群集接受，并且一些節(jié)點可能已經(jīng)應(yīng)用了它們。本地沖突交易仍然有一個回滾窗口。

所有需要回滾的事務(wù)都被添加到回滾隊列中，并通知回滾線程?；貪L線程然后迭代隊列并執(zhí)行回滾操作。

如果事務(wù)在節(jié)點上處于活動狀態(tài)，并且節(jié)點從群集組接收到與本地活動事務(wù)沖突的事務(wù)寫入集，則此類本地事務(wù)始終被視為受影響事務(wù)以回滾。

出現(xiàn)沖突時，事務(wù)處于提交狀態(tài)或執(zhí)行階段。執(zhí)行階段的本地事務(wù)被強(qiáng)行kill，以等待Applier事務(wù)被允許繼續(xù)進(jìn)行。提交階段的本地事務(wù)失敗并出現(xiàn)認(rèn)證錯誤。

三、其他線程

1、服務(wù)線程

此線程在啟動時創(chuàng)建并用于執(zhí)行輔助服務(wù)。它有兩個主要功能：

??在高速緩存的寫入集被清除到所述級別后，它釋放GCache緩沖區(qū)。 
??它通知群集組各個節(jié)點已提交到此級別的事務(wù)。每個節(jié)點都維護(hù)有關(guān)集群中其他節(jié)點的一些基本狀態(tài)信息。收到該消息后，信息將在此本地元數(shù)據(jù)中更新。

2、接收線程

該gcs_recv_thread線程是第一個查看組中收到的所有消息的線程。

它會嘗試根據(jù)收到的每條消息分配操作。它將這些消息添加到中央FIFO隊列中，然后由Applier線程處理。消息可以包含不同的操作，如狀態(tài)更改，配置更新，流量控制等。

一個重要的操作是處理一個寫集，它實際上是將事務(wù)應(yīng)用于數(shù)據(jù)庫對象。

3、Gcomm連接線程

gcomm連接線程GCommConn::run_fn 用于協(xié)調(diào)低層組通信活動。把它想象成一個用于溝通的黑匣子。

4、基于動作的線程

除上述之外，還有一些線程是按需創(chuàng)建。SST為捐助者和joiner創(chuàng)建線程（最終派生出一個子進(jìn)程來托管所需的SST腳本），IST創(chuàng)建接收者和異步發(fā)送者線程，PageStore創(chuàng)建后臺線程以刪除創(chuàng)建的文件。

如果啟用校驗和并且復(fù)制的寫入集足夠大，則校驗和將作為單獨線程的一部分完成。

四、參考鏈接

https://www.percona.com/doc/percona-xtradb-cluster/LATEST/manual/threading_model.html

 作者：Leshami  版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請附上博文鏈接！