Percona XtraDB Cluster (PXC) 5.6 三節點集群部署全流程實戰

Percona XtraDB Cluster (PXC) 5.6 三節點集群部署全流程實戰

Percona XtraDB Cluster (PXC) 基於 Galera 庫實現多主同步復制，提供強一致性、自動故障轉移、讀寫任意節點的企業級高可用方案。本文詳細記錄 PXC 5.6.30 在 CentOS 7 上的三節點生產級部署流程，包含環境準備、YUM 安裝、配置詳解、啟動驗證與踩坑避雷。

架構優勢與適用場景

適用場景

• 核心業務數據庫：訂單、支付、用戶中心，要求零數據丟失、秒級恢復
• 讀寫壓力均衡：無明顯讀寫分離邊界，任意節點可讀寫
• 避免單點故障：自動故障檢測與切換，無需外部協調器
• 遷移成本低：標準 SQL 接口，應用幾無感知 (需處理死鎖重試)

環境準備 (三節點)

系統級預配置 (三節點同執行)

# 1. 關閉防火牆或開放端口
firewall-cmd --permanent --add-port={3306,4444,4567,4568}/tcp
firewall-cmd --reload
# 或關閉: systemctl stop firewalld && systemctl disable firewalld

# 2. 關閉 SELinux (關鍵！SST 失敗 90% 因 SELinux)
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

# 3. 設置主機名解析
cat >> /etc/hosts <> /etc/sysctl.conf <

YUM 安裝 PXC
1. 配置 Percona YUM 源
yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
percona-release enable pxc-56 release

2. 安裝核心包
yum install -y Percona-XtraDB-Cluster-56 Percona-XtraDB-Cluster-client-56
# 自動安裝依賴: galera3, percona-xtrabackup-24, socat 等

# 驗證版本
rpm -qa | grep -E 'Percona-XtraDB-Cluster|galera|xtrabackup'
# 預期: Percona-XtraDB-Cluster-56-5.6.30, galera3-25.3.x, percona-xtrabackup-24-2.4.x

節點配置文件 (/etc/my.cnf)
Node1 (引導節點) 配置
[mysqld]
# 基礎
datadir=/var/lib/mysql
user=mysql
server-id=1
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci

# Galera 核心
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so
wsrep_cluster_address=gcomm://192.168.244.146,192.168.244.147,192.168.244.148
wsrep_cluster_name=pxc_cluster
wsrep_node_name=node1
wsrep_node_address=192.168.244.146

# SST (State Snapshot Transfer) 配置
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth="sstuser:SstPass123!"

# 性能優化
innodb_buffer_pool_size=2G
innodb_log_file_size=512M
innodb_flush_log_at_trx_commit=1
innodb_file_per_table=ON
innodb_flush_method=O_DIRECT

# 日志
log_error=/var/log/mysql/error.log
slow_query_log=1
slow_query_log_file=/var/log/mysql/slow.log
long_query_time=1

# 確保目錄
mkdir -p /var/log/mysql && chown mysql:mysql /var/log/mysql

Node2 / Node3 配置差異點
# Node2
server-id=2
wsrep_node_name=node2
wsrep_node_address=192.168.244.147

# Node3
server-id=3
wsrep_node_name=node3
wsrep_node_address=192.168.244.148

# 其餘參數與 Node1 完全一致 (wsrep_cluster_address, wsrep_cluster_name, wsrep_sst_auth 等)

集群啟動流程 (關鍵順序)
1. 啟動引導節點
# Node1 執行 (CentOS 7 systemd)
systemctl start mysql@bootstrap.service
# 或舊版: /etc/init.d/mysql bootstrap-pxc

# 此模式相當於 wsrep_cluster_address=gcomm:// (空集群地址)
# 不嘗試連接其他節點，直接形成新集群

2. 創建 SST 用戶 (Node1 上)
mysql -u root -p
CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'SstPass123!';
GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';
FLUSH PRIVILEGES;

3. 驗證引導節點狀態
mysql -e "SHOW STATUS LIKE 'wsrep%';"
# 關鍵指標:
wsrep_local_state_uuid:         # 集群 UUID
wsrep_local_state: 4                  # 4 = Synced
wsrep_local_state_comment: Synced
wsrep_cluster_size: 1                 # 當前節點數
wsrep_cluster_status: Primary         # Primary = 可服務
wsrep_connected: ON
wsrep_ready: ON

4. 啟動加入節點
# Node2 執行
systemctl start mysql

# Node3 執行
systemctl start mysql

# 啟動過程: 連接 gcomm:// 列表 → 選擇 Donor → SST 全量同步 → 加入集群
# SST 耗時取決於數據量與網絡，大數據量建議預先物理備份加速

5. 驗證三節點集群
# 任意節點執行
mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
# 輸出: wsrep_cluster_size = 3

# 完整狀態檢查
mysql -e "SHOW STATUS LIKE 'wsrep%';" | grep -E 'cluster_size|cluster_status|connected|ready|local_state_comment'
# 預期:
# wsrep_cluster_size = 3
# wsrep_cluster_status = Primary
# wsrep_connected = ON
# wsrep_ready = ON
# wsrep_local_state_comment = Synced

功能驗證測試

踩坑避雷指南 (血淚總結)

錯誤現象
根因
解決方案
Node2 啟動報: failed to reach primary view: 110 (Connection timed out)
網絡不通 / 防火牆攔截 4567/4568 端口
開放端口: firewall-cmd --add-port={4567,4568}/tcp; 檢查安全組
SST 失敗: wsrep_sst_xtrabackup-v2 ... No such file or directory
1. SELinux 未關閉 2. socat 版本過低 3. xtrabackup 路徑問題
優先關閉 SELinux! 其次嘗試 wsrep_sst_method=rsync 測試網絡連通性
集群大小卡在 1 或 2
節點間無法通訊 / gcomm 地址錯誤 / UUID 不一致
檢查 wsrep_cluster_address 包含所有 IP; 確保首次啟動 bootstrap 只執行一次
寫入報錯: Deadlock found when trying to get lock; try restarting transaction
Galera 認證機制導致的認證失敗 (非傳統死鎖)
應用層捕獲錯誤碼 1213/ER_LOCK_DEADLOCK 重試 3 次; 縮短事務、避免熱點行並發更新
節點重啟後無法加入
grastate.dat seqno = -1 (需 SST) / 磁盤空間不足
檢查磁盤空間; 如需 IST 增量同步確保 Doner 節點保留足夠 Binlog/gtid


運維核心指標監控

生產環境建議清單

網絡專線：三節點同機房、同交換機、千兆/萬兆專線，延遲 < 0.5ms
奇數節點：3/5/7 節點，滿足多數派協議，避免腦裂
負載均衡：ProxySQL / HAProxy / MaxScale 前置，讀寫分離、故障自動摘除
備份策略：單節點 XtraBackup 物理備份 + Binlog 增量，避免集群級備份鎖定
升級方案：滾動升級 (一次一節點)，保證集群持續 Primary
應用改造：捕獲死鎖錯誤重試、避免大事務、主鍵必須顯式定義


總結
PXC 5.6 三節點集群部署的核心成功要素：

環境一致性：三節點同版本、同配置、同內核參數
網絡通暢：3306/4444/4567/4568 端口雙向通、SELinux 關閉
啟動順序：Node1 bootstrap → 創建 SST 用戶 → Node2/3 依次啟動
驗證閉環：wsrep_cluster_size=3 + 多主寫入測試 + 監控指標基線

PXC 以「強一致、多主寫、自動故障轉移」三大特性，成為核心業務高可用的首選方案。掌握標準化部署與運維體系，是架構師邁向分佈式數據庫的關鍵一步。