mysql之 Percona XtraDB Cluster叢集執行緒模型

Percona XtraDB叢集建立一組執行緒來為其操作提供服務，這些執行緒與現有的MySQL執行緒無關。有三個主要執行緒組：

一、Applier執行緒

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事務已被群集接受，並且一些節點可能已經應用了它們。本地衝突交易仍然有一個回滾視窗。

所有需要回滾的事務都被新增到回滾佇列中，並通知回滾執行緒。回滾執行緒然後迭代佇列並執行回滾操作。

如果事務在節點上處於活動狀態，並且節點從群集組接收到與本地活動事務衝突的事務寫入集，則此類本地事務始終被視為受影響事務以回滾。

出現衝突時，事務處於提交狀態或執行階段。執行階段的本地事務被強行kill，以等待Applier事務被允許繼續進行。提交階段的本地事務失敗並出現認證錯誤。

三、其他執行緒

1、服務執行緒

此執行緒在啟動時建立並用於執行輔助服務。它有兩個主要功能：

  在快取記憶體的寫入集被清除到所述級別後，它釋放GCache緩衝區。 
  它通知群集組各個節點已提交到此級別的事務。每個節點都維護有關叢集中其他節點的一些基本狀態資訊。收到該訊息後，資訊將在此本地後設資料中更新。

2、接收執行緒

該gcs_recv_thread執行緒是第一個檢視組中收到的所有訊息的執行緒。

它會嘗試根據收到的每條訊息分配操作。它將這些訊息新增到中央FIFO佇列中，然後由Applier執行緒處理。訊息可以包含不同的操作，如狀態更改，配置更新，流量控制等。

一個重要的操作是處理一個寫集，它實際上是將事務應用於資料庫物件。

3、Gcomm連線執行緒

gcomm連線執行緒GCommConn::run_fn 用於協調低層組通訊活動。把它想象成一個用於溝通的黑匣子。

4、基於動作的執行緒

除上述之外，還有一些執行緒是按需建立。SST為捐助者和joiner建立執行緒（最終派生出一個子程式來託管所需的SST指令碼），IST建立接收者和非同步傳送者執行緒，PageStore建立後臺執行緒以刪除建立的檔案。

如果啟用校驗和並且複製的寫入集足夠大，則校驗和將作為單獨執行緒的一部分完成。

四、參考連結

 作者：Leshami  版權宣告：本文為博主原創文章，轉載請附上博文連結！