PXC使用與總結
1、PXC是什麼
基於Galera協議的Codership提供多主數據同步複製機制，可以實現多個節點間的數據同步複製以及讀寫，並且可保障數據庫的服務高可用及數據一致性。
基於Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（簡稱PXC），目前PXC用的會比較多一些。
MariaDB的集羣原理跟PXC一樣,MariDB-Cluster其實就是PXC，兩者原理是一樣的。要搭建PXC架構至少需要3個mysql實例來組成一個集羣，三個實例之間不是主從模式，而是各自爲主，所以三者是對等關係，不分從屬。
2、PXC的特點
多主架構：真正的多點讀寫集羣，在任何時候讀寫的數據都是最新的。
同步複製：集羣不同節點之間的數據同步，沒有延遲，在數據庫掛掉之後，數據不會丟失。
併發複製：從節點在apply數據時，支持並行執行，有更好的性能表現，真正意義上的並行複製。
故障切換：因爲支持多節點寫入，所以在出現數據庫故障時可以很容易的進行故障切換。
熱插拔：在服務期間，如果數據庫掛了，只要監控程序發現的夠快，不可服務時間就會非常少，在節點故障期間，節點本身對集羣的影響非常小。
自動節點克隆：在新增節點或停機維護時，增量數據或基礎數據不需要人工手動備份提供，galera cluster會自動拉取在線節點數據，集羣最終會變爲一致。
對應用透明：集羣的維護，對應用程序是透明的，幾乎感覺不到。
PXC最大的優勢：強一致性、無同步延遲。
3、PXC的優缺點
3.1、PXC的優點
1）實現mysql數據庫集羣架構的高可用性和數據的強一致性。
2）完成了真正的多節點讀寫的集羣方案。
3）改善了傳統意義上的主從複製延遲問題，基本上達到了實時同步。
4）新加入的節點可以自動部署，無須提供手動備份，維護起來很方便。
5）由於是多節點寫入，所以數據庫故障切換很容易。
6）完全兼容MySQL；
3.2、PXC的缺點
1）新加入的節點開銷大，需要複製完整的數據。採用SST傳輸開銷太大。
2）任何更新事務都需要全局驗證通過，纔會在每個節點庫上執行，集羣性能受限於性能最差的節點。
3）因爲需要保證數據的一致性，所以在多節點併發寫時，鎖衝突問題比較嚴重。
4）因爲使用樂觀鎖，所以建議使用小事物。
5）存在寫擴大問題，所有的節點上都會發生相同操作。
6）只支持innodb存儲引擎的表。
7）沒有表級別的鎖定，執行DDL語句操作會把整個集羣鎖住，而且也 kill 不了(建議使用Osc操作，即在線DDL）
8）所有的表必須含有主鍵，不然操作數據時會報錯。
4、PXC的原理
4.1、名詞介紹
WS：write set 寫集
IST: Incremental State Transfer 增量同步
SST：State Snapshot Transfer 全量同步
pxc中一個事務=一個寫集=一個GTID（PXC特有）
GTID由UUID（集羣唯一) + seqno（集羣唯一）組成
4.2、工作原理
PXC使用的4個端口號
3306：數據庫對外服務的端口號
4444：請求SST用的。 SST: 鏡象傳輸方法 xtrabackup , rsync ,mysqldump
4567: 組成員之間進行溝通的一個端口號
4568: 傳輸IST用的。相對於SST來說的一個增量。
原理：
首先客戶端先發起一個事務，該事務先在本地執行，執行完成之後就要發起對事務的提交操作了。在提交之前需要將產生的數據寫集廣播出去，然後獲取到一個全局的事務ID號，一併傳送到另外的節點上面。通過合併數據之後，發現沒有衝突數據，執行apply_cd和commit_cb動作，如果發現衝突就需要取消此次事務的操作。而當前server節點通過驗證之後，執行提交操作，並返回OK，如果驗證沒通過，則執行回滾。當然在生產中至少要有3個節點的集羣環境，如果其中一個節點沒有驗證通過，出現了數據衝突，那麼此時採取的方式就是將出現不一致的節點踢出集羣環境，而且它自己會執行shutdown命令，自動關機。
4.3、節點狀態變化階段：
open：節點啓動成功，嘗試連接到集羣。
primary：節點已處於集羣中，在新節點加入時，選取donor進行數據同步時會產生的狀態。
joiner：節點處於等待接收/接收數據同步文件時的狀態。
joined：節點完成數據同步的工作，嘗試保持和集羣進度一致。
synced：節點正常提供服務的狀態，表示已經同步完成並和集羣進度保持一致。
doner：節點處於爲新加入的節點提供全量數據時的狀態。