Percona XtraDB集群創(chuàng)建一組線程來為其操作提供服務，這些線程與現(xiàn)有的MySQL線程無關。有三個主要線程組：
Applier線程應用從其他節(jié)點接收的寫入集。寫消息直接通過gcv_recv_thread。
使用wsrep_slave_threads變量控制線程的數(shù)量。默認值是1，這意味著至少有一個wsrep applier線程存在來處理請求。
Applier線程等待一個事件，一旦它捕獲到事件，它就使用普通的從應用線程路徑應用它，并用wsrep-customization中繼日志信息應用路徑。這些線程與從屬工作線程類似（但不完全相同）。
使用“ Apply and Commit Monitor ” 可以實現(xiàn)協(xié)調(diào)。一個事務通過兩個重要的狀態(tài)：APPLY和COMMIT。每個事務都向自己申請的監(jiān)控器進行注冊，其申請順序已經(jīng)定義。 因此，在應用此事務之前，應用所有具有小于此事務序號的序號（seqno）的事務。 commit也是這樣做的（last_left> = trx_.depends_seqno（））。
只有一個回滾線程在發(fā)生沖突時執(zhí)行回滾。
??并行執(zhí)行的事務可能會發(fā)生沖突并可能需要回滾。
??Applier事務總是優(yōu)先于本地事務。這很自然，因為Applier事務已被群集接受，并且一些節(jié)點可能已經(jīng)應用了它們。本地沖突交易仍然有一個回滾窗口。
所有需要回滾的事務都被添加到回滾隊列中，并通知回滾線程。回滾線程然后迭代隊列并執(zhí)行回滾操作。
如果事務在節(jié)點上處于活動狀態(tài)，并且節(jié)點從群集組接收到與本地活動事務沖突的事務寫入集，則此類本地事務始終被視為受影響事務以回滾。
出現(xiàn)沖突時，事務處于提交狀態(tài)或執(zhí)行階段。執(zhí)行階段的本地事務被強行kill，以等待Applier事務被允許繼續(xù)進行。提交階段的本地事務失敗并出現(xiàn)認證錯誤。
此線程在啟動時創(chuàng)建并用于執(zhí)行輔助服務。它有兩個主要功能：
??在高速緩存的寫入集被清除到所述級別后，它釋放GCache緩沖區(qū)。
??它通知群集組各個節(jié)點已提交到此級別的事務。每個節(jié)點都維護有關集群中其他節(jié)點的一些基本狀態(tài)信息。收到該消息后，信息將在此本地元數(shù)據(jù)中更新。
該gcs_recv_thread線程是第一個查看組中收到的所有消息的線程。
它會嘗試根據(jù)收到的每條消息分配操作。它將這些消息添加到中央FIFO隊列中，然后由Applier線程處理。消息可以包含不同的操作，如狀態(tài)更改，配置更新，流量控制等。
一個重要的操作是處理一個寫集，它實際上是將事務應用于數(shù)據(jù)庫對象。
gcomm連接線程GCommConn::run_fn 用于協(xié)調(diào)低層組通信活動。把它想象成一個用于溝通的黑匣子。
除上述之外，還有一些線程是按需創(chuàng)建。SST為捐助者和joiner創(chuàng)建線程（最終派生出一個子進程來托管所需的SST腳本），IST創(chuàng)建接收者和異步發(fā)送者線程，PageStore創(chuàng)建后臺線程以刪除創(chuàng)建的文件。
如果啟用校驗和并且復制的寫入集足夠大，則校驗和將作為單獨線程的一部分完成。
/tupian/20230522/threading_model.html
作者：Leshami 版權聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請附上博文鏈接！
重慶分公司
重慶分公司
