MySQL集群恢复需先确认集群类型和故障范围，再依数据同步机制制定策略：主从复制重搭从库或恢复主库+重建链；MGR需清空数据目录后克隆同步再加入；PXC依赖SST/IST，全集群宕机时以最后安全关闭节点为引导。

MySQL集群环境的恢复不是简单还原单个实例，关键在于区分集群类型（如主从复制、MGR、InnoDB Cluster、Percona XtraDB Cluster等），并依据其数据同步机制和元数据状态制定恢复策略。没有统一“一键恢复”流程，必须先确认集群当前状态和故障范围。

明确集群类型和故障场景

不同架构的恢复逻辑差异极大：

• 主从复制集群：若仅从库宕机，通常重搭从库即可；若主库崩溃且无可用binlog，需从最近全备+binlog恢复主库，再重建从库复制链。
• MGR（MySQL Group Replication）：节点离线后无法自动重加入，需确认该节点数据是否滞后、GTID是否连续；恢复前必须清空其数据目录，用备份或克隆（CLONE plugin）同步最新数据，再启动实例并加入组。
• PXC（Percona XtraDB Cluster）：依赖SST/IST同步，新节点加入时会自动拉取全量或增量数据；但若整个集群宕机，需按“最后一个安全关闭节点”为引导节点（donor），其余节点以它为基准恢复。

准备恢复前的必要检查

跳过这步极易导致恢复失败或数据不一致：

Blender Geometry Nodes Script Generator

生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。

下载

• 确认集群中是否存在仍在运行且数据最新的节点（通过SELECT * FROM performance_schema.replication_group_members;或SHOW STATUS LIKE 'wsrep%';）。
• 检查binlog/GTID状态：SHOW MASTER STATUS;、SELECT @@gtid_executed;，比对各节点是否一致。
• 验证备份有效性：全备是否包含完整mysqldump或xtrabackup --prepare完成的备份集？binlog归档是否连续、未被误删？
• 停用应用写入，避免在恢复过程中产生新数据冲突。

典型恢复操作步骤（以MGR单节点故障为例）

假设Node2异常退出，其他节点正常运行，需重建Node2：

• 停止Node2的MySQL服务，清空其数据目录（rm -rf /var/lib/mysql/*）。
• 使用XtraBackup或物理拷贝方式，从当前在线节点（如Node1）拉取一份一致性快照到Node2的数据路径。
• 在Node2上启动MySQL，确保group_replication_start_on_boot=OFF，避免自动加入失败。
• 执行START GROUP_REPLICATION;，观察performance_schema.replication_group_members中状态是否变为ONLINE。
• 验证数据一致性：对比关键表行数、校验和，或使用pt-table-checksum工具扫描。

注意事项与避坑点

恢复过程中的高频风险点：

• 不要直接用mysqldump恢复MGR/PXC节点——缺少GTID或wsrep信息会导致加入失败。
• 切勿在多节点同时执行SST或强制引导（bootstrap）——易引发脑裂或数据覆盖。
• 恢复后务必检查复制延迟、错误日志（SHOW REPLICA STATUS\G）、以及集群健康状态（如SELECT * FROM performance_schema.replication_group_members;）。
• 生产环境建议启用自动备份+binlog归档+定期恢复演练，避免真正故障时手忙脚乱。

不复杂但容易忽略的是：恢复不是技术动作的堆砌，而是对集群状态的理解、对备份链完整性的信任、以及对每一步操作影响的预判。动手前多看一眼SHOW STATUS，往往比重做三遍更省时间。