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