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等关键指标，设置阈值告警。
