MySQL集群备份需分层设计，优先物理备份（如xtrabackup），按主从、MGR、InnoDB Cluster类型差异化实施，同步保存位点/GTID、binlog及拓扑信息，并定期验证恢复有效性。

MySQL集群备份不能只靠单点导出，必须结合架构特点设计分层策略。核心是保障数据一致性、减少业务影响、支持快速恢复。

理解MySQL集群类型再定备份方式

不同集群架构的备份逻辑差异很大：

• 主从复制（Replication）集群：优先在从库做物理备份（如xtrabackup），避免锁主库；逻辑备份（mysqldump）建议加--single-transaction和--master-data=2，记录位点便于搭建新从库。
• MySQL Group Replication（MGR）：所有节点数据强一致，任选一个可读节点备份即可；但需确认group_replication_single_primary_mode=ON时只在主节点写入，备份前检查SELECT MEMBER_ROLE, MEMBER_STATE FROM performance_schema.replication_group_members;确保目标节点状态为PRIMARY且ONLINE。
• InnoDB Cluster（基于MGR+MySQL Shell）：用mysqlsh配合util.dumpInstance()或util.dumpSchemas()，自动处理一致性快照和GTID信息，比手工备份更可靠。

物理备份为主，逻辑备份为辅

生产环境推荐以Percona XtraBackup做全量+增量物理备份：

• 全量备份命令示例：xtrabackup --backup --target-dir=/backup/full_$(date +%F)
• 增量备份依赖上一次备份的xtrabackup_checkpoints，命令如：xtrabackup --backup --incremental-basedir=/backup/full_2025-06-01 --target-dir=/backup/inc_2025-06-02
• 逻辑备份（mysqldump）仅用于小库、跨版本迁移或DDL审计，不建议作为主力恢复手段——大库导出慢、恢复更慢、无法保证binlog连续性。

备份必须包含元数据与日志链路

光有数据文件不够，恢复时需要完整上下文：

• 备份时同步保存SHOW MASTER STATUS或SELECT BINLOG_GTID_POS()结果，记录起始位点或GTID集合。
• 保留至少7天的binlog（配置expire_logs_days=7），确保能前滚到任意时间点。
• 把备份集、位点信息、binlog路径、集群拓扑说明（如哪些是primary、哪些是secondary）打包存档，命名带日期和集群标识，例如cluster-prod-mgr-full-20250601.tar.gz。

定期验证备份有效性

90%的备份失效发生在“以为能恢复”却没真正试过：

• 每月至少一次在隔离环境还原全量+最近增量+binlog到指定时间点，执行SELECT COUNT(*)和关键业务查询校验数据完整性。
• 用xtrabackup --prepare检查备份集是否可启动；用mysqldump --no-data快速验证SQL文件语法是否合法。
• 把验证脚本加入CI/CD或定时任务，失败立即告警，不依赖人工抽查。

不复杂但容易忽略。关键是按集群类型选对工具、留全日志链路、坚持验证。