mysql集群节点宕机怎么办_mysql故障恢复方案

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提升候选主库。

定位宕机原因并尝试原节点恢复

不要急于加新节点，先排查能否复用原实例：

Olli.ai

从web或文件数据快速创建数据可视化

92

查看详情

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

以上就是mysql集群节点宕机怎么办_mysql故障恢复方案的详细内容，更多请关注php中文网其它相关文章！