Percona XtraDB Cluster(PXC)
---原理介紹篇
目錄
一、簡介 1
二、優缺點 2
三、區別/局限性 3
四、 PXC復制原理 4
五、 服務解釋 5
一、簡介
Percona XtraDB Cluster是MySQL高可用性和可擴展性的解決方案，Percona XtraDB Cluster提供的特性如下：
1).同步復制，事務要么在所有節點提交或不提交。
2).多主復制，可以在任意節點進行寫操作。
3).在從服務器上並行應用事件，真正意義上的並行復制。
4).節點自動配置。
5).數據一致性，不再是異步復制。
Percona XtraDB Cluster完全兼容MySQL和Percona Server，表現在：
1).數據的兼容性
2).應用程序的兼容性：無需更改應用程序
1).集群是有節點組成的，推薦配置至少3個節點，但是也可以運行在2個節點上
2).每個節點都是普通的mysql/percona服務器，可以將現有的數據庫服務器組成集群，反之，也可以將集群拆分成單獨的服務器。
3).每個節點都包含完整的數據副本
PXC集群主要由兩部分組成：Percona Server with XtraDB和Write Set Replication patches（使用了Galera library，一個通用的用於事務型應用的同步、多主復制插件）
二、優缺點
優點如下：
1).當執行一個查詢時，在本地節點上執行。因為所有數據都在本地，無需 遠程訪問
2).無需集中管理。可以在任何時間點失去任何節點，但是集群將照常工作， 不受影響
3).良好的讀負載擴展，任意節點都可以查詢
缺點如下：
1).加入新節點，開銷大。需要復制完整的數據
2).不能有效的解決寫縮放問題，所有的寫操作都將發生在所有節點上
3).有多少個節點就有多少重復的數據
（官方手冊架構圖）
三、區別/局限性
1、區別
Percona XtraDB Cluster與MySQL Replication區別在於：
分布式系統的CAP理論：
C— 一致性，所有節點的數據一致。
A— 可用性，一個或多個節點失效，不影響服務請求。
P— 分區容忍性，節點間的連接失效，仍然可以處理請求。
任何一個分布式系統，需要滿足這三個中的兩個
MySQL Replication: 可用性和分區容忍性
Percona XtraDB Cluster: 一致性和可用性
因此MySQL Replication並不保證數據的一致性，而Percona XtraDB Cluster提供數據一致性
Percona XtraDB Cluster組件：
Percona XtraDB Cluster基於XtraDB的Percona Server以及包含寫復制集補丁，使用Galera 2.x library，事務型應用下的通用的多主同步復制插件。
Galera 2.x新特性有：
1).IST(Incremental State Transfer)增量狀態傳輸。對於WAN特別有用。
2).RSU(Rolling Schema Update)旋轉更新架構。不會阻止對表進行操作。
2、局限性
1).目前的復制僅僅支持InnoDB存儲引擎。任何寫入其他引擎的表，包括mysql.*表將不會復制。但是DDL語句會被復制的，因此創建用戶將會被復制，但是insert into mysql.user…將不會被復制的。
2).DELETE操作不支持沒有主鍵的表。沒有主鍵的表在不同的節點順序將不同，如果執行SELECT…LIMIT… 將出現不同的結果集。
3).在多主環境下LOCK/UNLOCK TABLES不支持。以及鎖函數GET_LOCK(), RELEASE_LOCK()…
4).查詢日志不能保存在表中。如果開啟查詢日志，只能保存到文件中。
5).允許最大的事務大小由wsrep_max_ws_rows和wsrep_max_ws_size定義。任何大型操作將被拒絕。如大型的LOAD DATA操作。
6).由於集群是樂觀的並發控制，事務commit可能在該階段中止。如果有兩個事務向在集群中不同的節點向同一行寫入並提交，失敗的節點將中止。對於集群級別的中止，集群返回死鎖錯誤代碼(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
7).XA事務不支持，由於在提交上可能回滾。
8).整個集群的寫入吞吐量是由最弱的節點限制，如果有一個節點變得緩慢，那么整個集群將是緩慢的。為了穩定的高性能要求，所有的節點應使用統一的硬件。
9).集群節點建議最少3個。2個也可以運行，但是官方不推薦這么做，因為3個節點是為了預防腦裂。
10) .如果DDL語句有問題將破壞集群。建議使用pt-online-schema-change操作DDL
四、PXC復制原理
復制原理架構圖
（來源官方手冊）
原理分析：
1、當client端執行dml操作時，將操作發給server，server的native進程處理請求2、client端收到ok,執行commit，server將復制寫數據集發給group(cluster)，cluster
中每個動作對應一個GTID
3、其它server接收到並通過驗證(合並數據)后，執行appyl_cb動作和commit_cb動作，若驗證沒通過，則會退出處理
4、當前server節點驗證通過后，執行commit_cb，並返回，若沒通過，執行rollback_cb
5、只要當前節點執行了commit_cb和其它節點驗證通過后就可返回
五、服務解釋
PXC會使用大概是4個端口號（端口可配置更改）
3306：數據庫對外服務的端口號
4444：請求SST SST: 指數據一個鏡象傳輸 xtrabackup , rsync ,mysqldump
4567: 組成員之間進行溝通的一個端口號
4568: 傳輸IST用的。相對於SST來說的一個增量
一些名詞介紹：
WS：write set 寫數據集
IST: Incremental State Transfer 增量同步
SST：State Snapshot Transfer 全量同步
PXC環境所涉及的端口：
#mysql實例端口
10Regular MySQL port, default 3306.
#pxc cluster相互通訊的端口
2）Port for group communication, default 4567. It can be changed by the option:
wsrep_provider_options ="gmcast.listen_addr=tcp://0.0.0.0:4010; "
#用於SST傳送的端口
3）Port for State Transfer, default 4444. It can be changed by the option:
wsrep_sst_receive_address=10.11.12.205:5555
#用於IST傳送的端口
4）Port for Incremental State Transfer, default port for group communication + 1 (4568). It can be changed by the option:
wsrep_provider_options = "ist.recv_addr=10.11.12.206:7777
（參考資料：官方手冊文檔及網上資料）