一、PXC方案概述
Percona XtraDB Cluster (PXC) 是一個完全開源的 MySQL 數據庫集群解決方案，它可確保高可用性，防止停機和數據丟失，並為不斷增長的環境提供線性可擴展性。它將 Percona Server 和 Percona XtraBackup 與 Galera 庫集成在一起，以實現同步多源復制。
集群由節點組成，其中每個節點包含在節點間同步的相同數據集。推薦的配置是至少有 3 個節點，也可以有 2 個節點，但不建議使用2個節點。每個節點都是一個常規的 MySQL Server 實例。可以將現有的 MySQL Server 實例轉換為節點，並使用該節點作為基礎運行集群。還可以從集群中分離任何節點並將其用作常規 MySQL 服務器實例。
當執行查詢時，它會在節點上本地執行。所有數據都在本地可用，無需遠程訪問。
沒有中央管理。可以在任何時間點解綁任何節點，集群將繼續運行而不會丟失任何數據。
PXC是擴展讀取工作負載的好解決方案，可橫向擴展以實現負荷降低。可以對任何節點進行讀取查詢。
新近實施的PXC集群版本均為 8.0，Percona XtraDB Cluster 8.0與MySQL Server Community Edition 8.0和Percona Server for MySQL 8.0完全兼容。
如圖是3節點的架構，可以看到每個節點都支持讀寫。
二、PXC基礎知識
■ PXC集群使用四個端口
端口 描述
3306 MySQL服務端口
4444 請求全量同步（SST）端口
4567 數據庫節點之間的通信端口
4568 請求增量同步（IST）端口
因此如系統啟用了防火牆則需開放這些端口，或者關閉防火牆
firewall-cmd --zone=public --add-port=3306/tcp --permanent
firewall-cmd --zone=public --add-port=4444/tcp --permanent
firewall-cmd --zone=public --add-port=4567/tcp --permanent
firewall-cmd --zone=public --add-port=4568/tcp --permanent
firewall-cmd --reload
■ 關於SST同步
Different from previous version
The variable wsrep_sst_auth has been removed. Percona XtraDB Cluster 8.0 automatically creates the system user mysql.pxc.internal.session. During SST, the user mysql.pxc.sst.user and the role mysql.pxc.sst.role are created on the donor node.
■ 節點狀態定義
OPEN: 節點啟動成功
PRIMARY: 節點成功加入集群
JOINER: 與其他節點同步數據
JOINED: 與其他節點同步數據成功
SYNCED: 與集群同步完成，可以對外提供服務
DONER: 接收其他節點的全量數據同步，處於不可用
【wsrep_local_state】當前節點狀態,值為4表示正常
共有四個值:
joining:節點正在加入集群
doner: 節點處於為新加入節點提供全量數據時的狀態
joined: 當前節點已成功加入集群
synced: 當前節點與集群中各節點是同步狀態
【wsrep_cluster_status】集群組成的狀態，應為"Primary", 否則說明出現腦裂現象
【wsrep_ready】應為為ON，表示當前節點可以正常提供服務；若為OFF, 則該節點可能發生腦裂或網絡問題導致
【wsrep_local_state_uuid】集群中所有節點的該狀態值應該是相同的，如果有不同值節點，說明其沒有加入集群
【wsrep_cluster_state_uuid】與【wsrep_local_state_uuid】值一致
【wsrep_gcomm_uuid】各個節點的值不同
■ 最常使用的查看命令
show variables like 'wsrep%';
show status like 'wsrep%';
三、PXC節點的配置安裝
最靠譜的參考文檔，一定是官方文檔
https://www.percona.com/doc/percona-xtradb-cluster/8.0/index.html
各類網文水平參差不齊，錯誤百出，僅供參考
四、PXC節點的上線與下線
■ 查看節點的服務狀態
systemctl status mysql
systemctl status mysql@bootstrap
根據以上命令可以確認哪個節點是集群啟動的首節點
■ PXC節點的安全下線
節點是怎么啟動的，就使用對應的命令去關閉
啟動【首節點】命令：
systemctl start mysql@bootstrap
對應關閉命令：
systemctl stop mysql@bootstrap
啟動【其他節點】命令：
systemctl start mysql
對應關閉命令：
systemctl stop mysql
■ 如集群中還有正常運行的節點，其他節點只需按普通節點上線即可
systemctl start mysql
■ 如所有PXC節點都是安全下線的，則在啟動集群時，需先啟動最后下線的節點
systemctl start mysql@bootstrap
■ 某節點能否作為首節點啟動，可以通過查看 grastate.dat 文件得知
cat /mysql/pxc/data/grastate.dat
safe_to_bootstrap: 0
說明：safe_to_bootstrap 的值為 0 時不能作為首節點啟動，為1時可以作為首節點啟動
PXC集群中最后一個下線的節點會將 safe_to_bootstrap 的值改為1，下次啟動集群時就需將該節點作為首節點啟動
最后一個下線的節點數據是最新的，將其作為首節點啟動，然后讓其他節點與該節點進行數據同步，這樣才能保證集群中的數據是最新的，否則可能導致集群中數據是某個時間點之前的舊數據
safe_to_bootstrap 為 1時，必須使用 systemctl start mysql@bootstrap 的方式啟動
■ 如PXC節點都是意外退出的，且不是在同一時間退出的
PXC集群中一半以上的節點因意外宕機而無法訪問時，PXC集群就會停止運行
但如果這些PXC節點是以安全下線的方式退出，則不會引發集群自動停止運行的問題，只會縮小集群的規模
只有意外下線一半以上節點時集群才會自動停止，意外下線的情況包括：
宕機、掛起、關機、重啟、斷電、斷網等，就是沒有使用相應停止命令安全下線都屬意外下線
只要PXC集群中的節點不是同時意外退出的，那么當集群還剩一個節點時，該節點就會自動將grastate.dat文件中的 safe_to_bootstrap 值改為1，所以在重啟集群時，也是先啟動最后一個退出的節點
■ 如PXC節點都是同時意外退出的，則需要修改grastate.dat文件
當集群所有節點正常運行時，safe_to_bootstrap 值都為 0
當集群中所有節點都是在同一時間因意外情況而退出，此時所有節點的 safe_to_bootstrap 都為 0 ，因為沒有一個節點來得及去修改 safe_to_bootstrap 的值。當所有節點的 safe_to_bootstrap 均為 0 時，PXC集群是無法啟動的。
在這種情況下我們就只能手動選擇一個節點，將 safe_to_bootstrap 修改為 1 ，然后將該節點作為首節點進行啟動：
vim grastate.dat
safe_to_bootstrap: 1
systemctl start mysql@bootstrap
接着再依次正常啟動其他節點：
systemctl start mysql
五、其他
關於ProxySQL與keepalive的配置與運維，此處暫不贅述。