MySQL集群节点宕机需据类型（MGR/PXC/MHA/双主）和角色判断：先保可用性，再保一致性，最后恢复拓扑；查状态、定位原因、修复或重建、校验数据、加固预防。
MySQL集群节点宕机不是单点服务重启就能解决的问题，关键要看集群类型（MGR、PXC、MHA 或双主）、宕机节点角色（主/从/多数派）、以及是否触发脑裂或不可用状态。核心原则是：先保服务可用性，再保数据一致性，最后恢复拓扑完整性。
确认集群类型和当前状态
不同架构的响应逻辑差异很大：
-
MGR集群：查
performance_schema.replication_group_members，重点看MEMBER_STATE（ONLINE/UNREACHABLE/ERROR/RECOVERING）和group_replication_group_size。若剩余节点数 ≤ ⌊N/2⌋（如3节点挂2个），集群已不可写，必须人工干预；若仍满足多数派（如3节点剩2个），服务自动维持，只需修复宕机节点。 -
PXC/Galera集群：执行
SHOW STATUS LIKE 'wsrep_%'，关注wsrep_cluster_size和wsrep_local_state_comment。若节点状态为Joiner或Donor/Desynced，说明同步卡住；若为Non-Primary，代表已脑裂，需手动选择一个子集重建集群。 -
MHA或传统主从：运行
masterha_check_repl --conf=/etc/mha/app1.cnf，检查Seconds_Behind_Master和复制线程状态。若主库宕机，MHA通常已自动切换；若未触发，需人工执行masterha_master_switch提升候选主库。
定位宕机原因并尝试原节点恢复
不要急于加新节点，先排查能否复用原实例：
- 查看
/var/log/mysql/error.log和系统日志/var/log/messages，确认是OOM、磁盘满、InnoDB崩溃还是网络隔离； - 若为临时故障（如进程被kill、资源争用），直接重启：
systemctl start mysql； - 若启动失败，检查
innodb_force_recovery级别（1~6），尝试强制启动导出关键数据； - 若数据文件损坏且无备份，优先对
datadir做完整镜像备份，再使用mysqlcheck（MyISAM）或innodb_table_monitor（InnoDB）辅助诊断。
数据一致性校验与补同步
节点重新上线或切换完成后，必须验证数据是否一致：
- 用
pt-table-checksum在新主库上生成校验和，再用pt-table-sync修复从库差异（适用于MHA/主从）； - MGR中，新加入节点会自动通过异步复制追平，但需确认
MEMBER_STATE最终变为ONLINE，且SELECT * FROM performance_schema.replication_group_member_stats中COUNT_TRANSACTIONS_IN_QUEUE趋近于0； - 若发现binlog位置不一致或GTID gap，可手工
SET GTID_NEXT跳过空事务，或用mysqlbinlog --skip-gtids重放缺失日志段。
预防性加固建议
多数宕机问题本可提前规避：
- 所有节点启用
binlog_format=ROW+gtid_mode=ON，确保复制可追溯； - MGR集群至少部署3节点（奇数），禁用
report_host自动解析，显式配置IP避免DNS失效； - 每日全量物理备份（XtraBackup）+ 每小时binlog归档，异地保存；
- 部署Zabbix/Prometheus监控
Threads_running、wsrep_local_recv_queue、group_replication_transactions_waiting_apply等关键指标，设置阈值告警。
