Galera Cluster节点状态优先看wsrep_local_state_comment，值为Synced才真正可用；Joiner表示同步中，Donor表示正传输数据，Initialized或Disconnected说明未加入集群。
查 Galera Cluster 节点状态，优先看 wsrep_local_state_comment
galera 不是靠主从复制的“io/sql线程”状态判断存活，而是靠自身的一套同步状态机。直接查 show status like 'wsrep_%'; 里最核心的是 wsrep_local_state_comment，它比 wsrep_local_state（数字）更直观。值为 synced 才算真正可用；joiner 是正在同步中，donor 表示在给别的节点传数据，initialized 或 disconnected 都意味着这个节点没加入集群。
-
wsrep_cluster_size显示当前集群里有多少个Synced节点，不是总启动数 - 如果
wsrep_connected是OFF，说明网络或配置问题导致节点根本连不上集群，先别看同步状态 -
wsrep_ready必须是ON，否则即使 Synced 也不接受写入（常被忽略）
连接多活节点前，必须检查 wsrep_sync_wait 和事务隔离级别
Galera 的多活不是无条件的“任意节点都能写”。默认所有节点都可写，但一旦遇到冲突（比如两个节点同时更新同一行），会回滚其中一个事务。所以应用层不能假设“写成功就落地了”，得处理 Deadlock found when trying to get lock; try restarting transaction 这类错误。
- 设置
SET SESSION wsrep_sync_wait = 7;可让 SELECT 等待本地已同步到最新状态，避免读到旧数据（但会拖慢查询） - 推荐用
READ-COMMITTED隔离级别，REPEATABLE-READ在 Galera 下容易触发更多冲突回滚 - 不要依赖自增主键连续性——不同节点生成的 ID 会交错，且重启后可能跳变
mysqld 启动失败常见报错：卡在 WSREP: Failed to prepare for 'gcomm://'
这基本等于节点根本没连上集群，不是数据不一致问题，而是网络或配置层面断联。重点排查 gcomm 地址、防火墙、节点名是否拼错。
- 确认
wsrep_cluster_address配置里写的 IP 是其他节点能真实访问的（别用127.0.0.1或localhost） - 检查
wsrep_node_name在整个集群中是否唯一，重复会导致握手失败 - CentOS 7+ 默认 firewalld 拦了
4567（gcs）、4568（ist）、4444（sst）端口，firewall-cmd --permanent --add-port=4567-4568/tcp得全开 - 首次启动新节点时，如果集群已有数据，别用
systemctl start mysqld直接启，先手动跑galera_new_cluster（仅限第一个节点）或清空grastate.dat再启
应用连接字符串里不能只写一个节点 IP
Galera 多活的价值在于故障转移能力，但 MySQL 客户端驱动本身不感知集群拓扑。如果你的应用连接串只写死一个 IP，那个节点挂了就彻底断连，和单点没区别。
- 用 ProxySQL 或 HAProxy 做前端负载，把健康检查指向
SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='wsrep_local_state_comment';返回Synced的节点 - 某些驱动（如 Python 的 PyMySQL）支持
host列表，但需配合重试逻辑，不能指望它自动切节点 - 避免在应用里做“轮询连接”，连接池初始化阶段就应完成节点健康探测，而不是每次 query 前试连
真正麻烦的从来不是查状态，而是当 wsrep_ready 突然变成 OFF 时，你的应用有没有立刻拒绝写请求，而不是等超时或报错才反应过来。
