首次bootstrap后必须确认wsrep_ready=ON、wsrep_cluster_size=1、wsrep_cluster_status=Primary；第一个节点须用mysql-bootstrap启动，不可直接systemctl start mysql，否则因无法连接集群而卡在wsrep_connected=OFF。
能快速搭，但“快速”不等于“跳过验证”——首次 bootstrap 后必须确认 wsrep_ready=ON、wsrep_cluster_size=1、wsrep_cluster_status=Primary 三个状态，否则后续节点根本加不进去。
第一个节点必须用 bootstrap 启动，不能直接 systemctl start mysql
普通启动会尝试连接已有集群（gcomm://...），而第一个节点根本没集群可连，直接失败并卡在 wsrep_connected=OFF。必须显式触发自举：
- CentOS/RHEL 系统：运行
systemctl start mysql-bootstrap（或mysqld_bootstrap） - Ubuntu/Debian 系统：执行
sudo /etc/init.d/mysql bootstrap-pxc - Docker 镜像（如
percona/percona-xtradb-cluster:8.0）：启动时加环境变量CLUSTER_JOIN=（留空）或用--bootstrap参数
启动后立刻检查：mysql -e "SHOW STATUS LIKE 'wsrep_%';"。如果 wsrep_ready 是 OFF，大概率是 wsrep_provider 路径错（比如写成 libgalera_smm.so 但实际在 /usr/lib64/galera4/ 下），或 SELinux 拦截了共享库加载。
wsrep_cluster_address 的写法决定节点能否互相发现
所有节点的配置里，wsrep_cluster_address 必须包含**全部节点 IP 或可解析主机名**，格式为 gcomm://ip1,ip2,ip3（注意无空格、无端口、无协议前缀）。常见错误：
- 只写自己 IP（
gcomm://10.0.0.231）→ 其他节点无法加入 - 混用 hostname 和 IP（
gcomm://node1,10.0.0.232）→ 若/etc/hosts或 DNS 解析失败，节点间通信中断 - 漏掉某个节点（
gcomm://10.0.0.231,10.0.0.232，但实际有 3 台）→ 第三台永远处于Joiner状态，日志报Failed to open gcomm backend connection
验证方法：在任一节点执行 ping -c2 node2 && ping -c2 node3，确保全通；再检查 netstat -tlnp | grep :4567，确认 Galera 端口监听正常。
SST 方法选 xtrabackup-v2，别用 rsync 或 mysqldump
新节点加入时，SST（State Snapshot Transfer）负责全量同步数据。rsync 不锁表、速度快，但不保证事务一致性；mysqldump 会锁全库、慢且无法恢复 binlog 位点；只有 xtrabackup-v2 支持热备 + 一致性快照 + 自动流式传输，是生产唯一推荐选项。
- 必须提前创建 SST 用户：
CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 's3cretPass'; GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost'; - 配置中严格匹配：
wsrep_sst_auth=sstuser:s3cretPass（冒号前后无空格） - 若启动后日志出现
Failed to authenticate with SST donor，优先检查密码是否被 shell 特殊字符（如$、!）截断，建议用单引号包裹整个值
集群健康检查不能只看 cluster_size
SHOW STATUS LIKE 'wsrep_cluster_size' 显示 3，不代表三节点都真正就绪。必须逐项核对：
-
wsrep_ready = ON：节点已准备好接受 SQL 请求（OFF表示正在同步或认证失败） -
wsrep_local_state_comment = 'Synced'：本地已与集群状态同步（不是Joiner或Donor） -
wsrep_incoming_addresses应列出所有节点 IP+端口（如10.0.0.231:3306,10.0.0.232:3306,10.0.0.233:3306） - 任意节点执行写入后，在其他节点立即
SELECT验证——PXC 的强一致是实时的，延迟超过 1 秒基本说明某环节卡住了
最容易被忽略的是 pxc_strict_mode：设为 ENFORCING 才强制校验主键、InnoDB 引擎、无 LOCK TABLES 等限制；设成 DISABLED 虽然能启动，但后续写入可能静默失败或引发脑裂。
