innodb cluster备份只需在任一online节点执行mysqldump --single-transaction,要求全为innodb表;恢复时须先单机模式导入,再通过分布式恢复加入集群,避免gtid冲突。

备份只需在一个节点上执行,但必须用 mysqldump 加 --single-transaction
InnoDB Cluster 本质是基于组复制(Group Replication)的多节点集群,所有节点数据最终一致。因此备份不需要每个节点都跑一遍——在任意一个 ONLINE 节点上执行逻辑备份即可,但必须满足两个硬性条件:mysqldump 必须加 --single-transaction,且目标库全为 InnoDB 表。
不加 --single-transaction 会导致备份过程中其他事务写入被阻塞,或产生不一致快照;如果混有 MyISAM 表,该参数无效,备份将不可靠。
- 推荐命令:
mysqldump -u root -p --single-transaction --master-data=2 --all-databases > full_backup.sql -
--master-data=2会把当前 binlog 位置写进 SQL 文件开头,后续做增量恢复时能准确定位起点 - 避免使用
--lock-all-tables或FLUSH TABLES WITH READ LOCK—— 这会阻塞整个集群写入,违背“在线”前提
恢复到同一节点时,别前滚 binlog,让组复制自动补数据
在同一节点恢复备份后,不能直接启动组复制服务,否则节点会因数据落后被踢出集群。正确做法是先以单机模式恢复,再加入集群,由分布式恢复(Distributed Recovery)机制自动同步缺失数据。
关键点在于:恢复时必须选择“恢复到备份状态(最短恢复时间)”,而不是“恢复到指定时间点”。后者会尝试应用 binlog,但在集群场景下极易导致 GTID 冲突或事务重复。
- 停掉该节点:
/usr/bin/mysqlsh --dba stopSandboxInstance 3310 - 清空数据目录并导入:
mysql -u root -p - 启动但不加入集群:
/usr/bin/mysqlsh --dba startSandboxInstance 3310 - 最后用
cluster.rejoinInstance()让它重新申请加入——此时其他节点会把它当作新成员,通过clone或distributed recovery补齐数据
恢复到不同节点时,auto.cnf 的 server_uuid 必须改
如果你把备份恢复到另一个物理/虚拟机上的 MySQL 实例(比如灾备机),哪怕端口、配置完全一样,也必须手动修改 auto.cnf 和 mysqld-auto.cnf 中的 server_uuid 值。否则组复制会拒绝它加入,报错类似:ERROR 3092 (HY000): The server is not configured properly to be an active member of the group。
原因很直接:MySQL 组复制靠 server_uuid 唯一标识节点,重复 UUID 会被认为是“同一个节点故障重启”,而非新成员加入。
- 查当前 UUID:
SELECT @@server_uuid; - 停 mysqld 后编辑
auto.cnf(通常在datadir下),替换server-uuid=xxx行为新值(可用uuidgen生成) - 同时检查
mysqld-auto.cnf,里面可能也有server_uuid字段,一并更新 - 重启 mysqld,再执行
cluster.addInstance(),否则会卡在RECOVERING状态不动
ndb_restore 不适用于 InnoDB Cluster,别和 NDB Cluster 混用
看到 “MySQL Cluster” 就去翻 ndb_restore 文档?停一下。InnoDB Cluster 和 NDB Cluster 是两套完全不同的技术栈:前者用组复制 + MySQL Router,后者是共享-nothing 架构的内存数据库集群。它们的备份工具、恢复流程、甚至配置文件都不兼容。
如果你在 InnoDB Cluster 环境里误用 ndb_restore,会出现明确报错:Failed to connect to management server 或 Unknown command 'ndb_restore' —— 因为该命令只存在于 NDB 安装包中,标准 MySQL Server 发行版根本不带。
- InnoDB Cluster 备份恢复走的是标准 MySQL 协议:逻辑导出/导入 + binlog + 组复制同步
- NDB Cluster 才用
START BACKUP+ndb_restore+ 数据节点逐个还原 - 混淆两者最常发生在文档搜索时——注意看官方手册章节标题:《InnoDB Cluster》 vs 《NDB Cluster》
真正容易被忽略的是:恢复后必须验证 performance_schema.replication_group_members 中的 MEMBER_STATE 是否为 ONLINE,以及 MEMBER_ROLE 是否已正确选举。光看命令返回 success 不代表数据已同步完成。











