PXC / Galera Cluster集群概述及原理分析

mariadb的galera cluster集群抄襲percona的PXC數據庫集群，所以原理一樣

### Galera Cluster/ PXC 集群工作原理

client端向server端發送dml更新操作請求時，server的native本地進程處理請求，并返回OK準備接收，client發送commit更新事務給server，server將replicate writeset復制寫數據集發給group（cluster集群），cluster將該數據集對應產生的唯一的GTID（global transaction ID）發送給集群每個server（節點）。當前server節點驗證通過后，執行commit_cd動作更新本地數據庫，并返回OK；若其他節點驗證不通過，則執行rollback_cd，回滾剛提交的事務。其他server(other server)接收并驗證通過后，執行apply_cd和commit_cd動作更新本地數據庫；若驗證不通過，則丟棄該數據集。

任意節點收到sql請求，對于dml更新操作事務，在commit之前，由wsrep API調用galera庫進行集群內部廣播，驗證當前事務是否能在所有節點中執行，驗證通過后該事務真正提交到集群所有節點執行，反之roll back回滾。此驗證機制則是為了保證所有節點的數據一致性。

innodb內部使用悲觀鎖，保證事務的成功提交和執行。

pxc/galera集群采用樂觀鎖，所有的事務都廣播給集群每個節點，驗證不通過再回滾 

### PXC/Galera Cluster集群架構

group communication層：主要實現統一全局數據同步策略和集群內部所有事務的排序，便于生成GTID

replication層：主要用于完成數據同步，由applier和slave queue組成。replication模塊的效率直接影響整個集群的寫入功能

### 主要名詞解釋

WS    write set寫數據集，寫/更新事務

IST   Incremental State Transfer增量同步

SST   State Snapshot Transfer增量同步。傳輸SST的幾種方法：mysqldump/xtrabackup/rsync

UUID    節點狀態改變及順序的唯一標識

GTID    Global Transaction ID，由UUID和sequence number偏移量組成。wsrep api中定義的集群內部全局事務id，用于記錄集群中發生狀態改變的唯一標識以及隊列中的偏移量。

wsrep API    在DBMS庫和wsrep provider之間提供接口

commit       把事務所做的修改提交到數據庫，即在庫中執行用戶的sql請求 

### PXC/Galera Cluster集群端口

3306    數據庫對外提供服務的端口

4444    鏡像數據傳輸SST，集群數據同步端口，全量同步，新節點加入時起作用

4567    集群節點間相互通信的端口

4568    增量數據同步IST，節點下線、重啟后使用該端口，增量同步數據。

### 節點狀態

1. OPEN    節點啟動成功，嘗試連接到集群，如果失敗則根據配置退出或創建新的集群

2. PRIMARY 節點已處于集群中，在新節點加入時，選取donor進行數據同步時會產生的狀態

3. JOINER  節點處于等待接收/接收同步文件時的狀態

4. JOINED   節點完成數據同步，但有部分數據沒跟上，在嘗試保持和集群進度一致的過程狀態

         例如某個節點故障后，重新加入集群，在追趕集群進度時的狀態

5. SYNCED    節點正常提供服務的狀態，表示已經同步完成并和集群進度保持一致。

6. DONOR     節點處于為新節點提供全量數據數據同步時的狀態。此時該節點對客戶端不提供服務。

##節點狀態發生變化因素

1. 新節點加入集群 
   

2. 節點故障恢復，重新加入集群

3. 節點同步失效

### PXC/Galera Cluster集群優缺點

優點：

    1.高可用性。集群多個節點功能平等，提供負載和冗余，避免單點故障

    2.強一致性。集群所有節點同步修改數據，真正同步讀寫，不存延遲。

    3.易擴展。增加新節點，只需扔進集群，會自動完成SST全量同步，和后續IST增量同步

缺點：

    1.任何更新事務都需要全局驗證通過，才會在每個節點庫執行。集群性能受限于性能最差的節點

    2.galera/pxc集群保證數據一致性，必須所有節點驗證通過。多點并發寫入，鎖沖突嚴重。

        例如：多臺同時有寫操作，每個更新操作時，都會鎖庫來驗證

    3.新節點或延后較大的節點重新加入時，會進行全量拷貝數據SST，作為donor（提供同步文件的節點）的節點在同步過程中無法提供讀寫，顯示狀態為donor。完成后的狀態為syncd

###當galera cluster集群單個節點或所有節點停機情況分析

1. 單個節點停機

   節點停機重啟，重新加入集群，通過IST增量同步數據，來保持集群數據的一致性。IST的實現由wsrep_provider_options="gcache.size=1G"參數決定，一般設置為1G。參數大小由什么決定，根據停機時間，若停機一小時，需要確認一小時產生多大的binlog來算出參數大小。

1.1 停機時間過長，部分數據gcache沒有，此時該節點SST全量同步數據。

2. 所有節點關閉，應采用輪巡滾動關閉的方式：a節點關閉修復，加回集群；b節點關閉修復，加回集群...

    原則就是保持cluster中最少一個成員存活，進行滾動重啟。

2.1 集群所有節點都關閉了，沒有存活的節點的情況

    每個節點數據庫關閉后，都會保存最后一個GTID，啟動集群時要先啟動最后一個關閉的節點，啟動順序和關閉順序相反。

3. 避免關閉和啟動節點時數據丟失

    3.1 原則保持cluster集群中最少有一個成員存貨，然后進行滾動重啟

    3.2 利用主從的概念，把一個從節點轉化為PXC/Galera集群中的節點

### 常見問題匯總

1. 如果主節點（負責寫入的節點）寫入過大，apply_cd時間過長，導致數據更新操作時間過長，怎么處理?

   Wrep_slave_threads參數配置成cpu的個數或者1.5倍。

2. 腦裂

   任何命令執行出現unknown command，表示出現腦裂，集群中任意兩個節點間通信的4567端口不通，并且無法對外提供服務。SET GLOBAL wsrep_provider_options="pc.ignore_sb=true";

3. 并發寫

   如果在集群多個節點進行寫/更新操作，有可能同時不同節點update同一行操作時就會出現鎖死問題，出現:Error：1213 SQLSTATE:4001.解決：指定更新和寫入都在都一個節點操作。

4. DDL全局鎖

   采用pt-online-schema-change

5. 只支持innodb引擎，表結構必須要有主鍵，不然會造成集中每個節點的data page里的數據不一致。

   不支持表級鎖，即不能lock/unlock tables，使用行級鎖

6. 新節點加入加入&故障節點恢復加入集群，此時不能有寫操作，不然會導致被寫入的那臺庫DDL死鎖。所以需要暫停集群業務寫操作，等數據一致后在開啟寫操作。