MySQL集群节点异常时，核心思路是分层排查：先确认节点是否存活，再查网络连通性、配置一致性、数据同步状态和错误日志；定位关键在“看状态、查日志、验连接、比配置”。

MySQL集群节点异常时，核心思路是分层排查：先确认节点是否存活，再查网络连通性、配置一致性、数据同步状态和错误日志。定位关键在“看状态、查日志、验连接、比配置”。

检查集群节点运行状态

登录任意正常节点，执行 SHOW STATUS LIKE 'wsrep_%'; 查看 Galera 状态关键指标：

• wsrep_local_state_comment：应为 Synced，若为 Joiner、Donor 或 Disconnected，说明未完成加入或已失联
• wsrep_cluster_size：显示当前在线节点数，明显少于预期即存在掉线节点
• wsrep_ready：必须为 ON，否则该节点拒绝写入
• wsrep_connected 和 wsrep_primary：二者都需为 ON，否则无法参与集群决策

查看错误日志定位根本原因

直接读取 MySQL 错误日志（默认 /var/log/mysql/error.log 或 /var/lib/mysql/hostname.err），重点关注以下几类信息：

Mysql Skill 1.0.0 (3)

MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。

下载

• 包含 "gcomm://" 或 "IST failed" 的行：通常指向组通信层失败或状态传输中断
• 出现 "Failed to open gcache" 或 "No cache memory"：gcache 文件损坏或空间不足
• 反复出现 "Connection refused" 或 "Timeout"：网络或防火墙阻断了端口（默认 4567、4568）
• 报错 "Node is not ready" 或 "Waiting for SST"：SST 正在进行中，但耗时过长可能因磁盘 I/O 或网络慢

验证节点间网络与端口连通性

集群依赖稳定低延迟的 TCP 连接，需逐项验证：

• 使用 telnet NODE_IP 4567 或 nc -zv NODE_IP 4567 测试组通信端口是否可达
• 确认防火墙放行：CentOS 用 firewall-cmd --list-ports，Ubuntu 检查 ufw 状态
• 检查 hosts 解析是否一致：cat /etc/hosts 中各节点 hostname 对应 IP 必须完全相同，避免 Galera 因解析失败拒绝加入
• 禁用 NetworkManager 或设置其不管理集群网卡，防止 IP 地址被意外重置

核对集群配置一致性

所有节点的 my.cnf 中 Galera 相关参数必须严格一致（除 wsrep_node_address 和 wsrep_node_name 外）：

• wsrep_cluster_address：必须指向同一集群地址，如 gcomm://192.168.1.10,192.168.1.11,192.168.1.12
• wsrep_provider_options：尤其是 gcache.size、evs.keepalive_period 等参数不一致会导致脑裂或同步卡死
• binlog_format=ROW、default_storage_engine=InnoDB、innodb_autoinc_lock_mode=2 这三项必须启用，否则无法兼容 Galera 复制
• 注意：新增节点启动时，首次需清空数据目录并指定 --wsrep-new-cluster 仅用于初始化，其他节点严禁使用