MySQL NDB备份的数据文件和日志文件分别保存什么

MySQL NDB 原生备份的 .data 文件保存表记录，.log 文件保存备份所涉及表的已提交事务记录；另外还有 .ctl 文件承载控制信息和表定义。三者是同一备份的不同组成，不能因为名字带 log 就把它当成可随手清理的诊断日志。本文限定 MySQL NDB Cluster 8.4，不讨论普通 InnoDB 数据目录备份。

官方文档入口：https://dev.mysql.com/doc/refman/8.4/en/mysql-cluster.html

先识别原生备份，别套用 SQL 导出经验

NDB 的原生备份和 mysqldump 导出的 SQL 文本不是同一种交付物。看到一组不同后缀的 BACKUP 文件时，应先确认备份方式，再决定归档和交接方法。原生备份恢复使用 NDB 随附的 ndb_restore 工具，而不是把这些文件当 SQL 脚本交给 mysql 客户端。参见 NDB 在线备份说明。

这不是一种需要追逐的新文件命名趋势，而是理解现有备份的基本要求：团队要保存的是一套可用于恢复的材料，不只是占空间最多的那类文件。以下内容帮助辨认职责，不提供直接覆盖生产数据的恢复命令。

数据、事务与表定义各自承担什么

参与备份的节点会保存这些组成。不同节点负责的分片不同，因此不能看到一个节点目录里的文件齐全，就推断已经拥有整套集群备份。表定义与记录内容也不能互相替代。文件职责依据 NDB 备份概念文档。

交接人员应以整套备份为对象

数据库管理员关心恢复所需材料，存储管理员关心归档范围，应用团队关心恢复后的业务数据。三方最好共用同一份备份清单：备份标识、参与节点、版本、归档位置和负责人，而不是分别只说“数据已复制”“日志另存”。

建议在交接单里把节点列为独立维度。即使两台节点的文件类型一样，也不应直接把文件名改成统一短名后混放。原名中的身份信息有助于保留上下文；归档时先保持目录层次，再考虑如何汇总清单。

最容易误判的是日志和节点范围

“有 .data 就够了”“同一备份标识的一份文件可代替所有节点”“.log 只是排错日志”，这些做法都会把文件职责和归档范围混在一起。缺件时应回到原始备份来源处理，不要用另一轮备份里看起来同名的文件凑数，也不要仅凭大小判断它是否可丢弃。

本文的文件说明不能推导出一个通用的时间点恢复方案。需要跨备份点恢复、版本迁移或重建集群时，必须另看对应恢复流程及限制，不能仅从三个后缀决定操作。

用一个不修改文件的目录清单起步

下面是给读者的只读整理示例，假设原始备份材料已经由运维复制到隔离的归档目录。路径是占位示例，先替换为实际目录；命令不会创建备份或执行恢复，本文也未把它作为实测记录。

# 只查看已归档备份的文件名，替换为实际目录。
# 保留目录层次和节点身份，不移动、不删除任何备份文件。
find /srv/ndb-archive/backup-example -type f -print

阅读清单时，先按备份标识分组，再保留每个节点的来源目录，最后把三类文件分别登记。文件名列表只能证明目录里有哪些条目，不能证明备份已成功完成，更不能证明恢复一定成功。

若要安排恢复演练，可从隔离环境开始，先阅读 ndb_restore 官方说明，由有权限的负责人确定目标、版本和操作范围。不要为了“看看能不能恢复”直接对生产环境试命令。

判断归档是否可用，别只看总大小

建议把观察项分开记录：文件范围是否明确、来源是否可追溯、备份完成记录是否保存、隔离恢复演练是否有记录。大文件被成功复制和恢复材料完整是不同结论。对于多人交接，最好写明“已归档但未演练”这样的实际状态，避免把推断写成保证。

.log 可以按普通日志保留策略清理吗？不能仅凭后缀套用排错日志策略。应按整套备份的保留计划处理。

为什么还要保存 .ctl？因为记录数据不等于拥有表定义和控制信息，它也是备份组成。

同一节点的三类文件齐全就能宣布完成吗？不应如此判断。还需明确整次备份的节点范围和实际完成记录；文件清单本身并非恢复证明。

简记为：data 看记录，log 看事务，ctl 看定义与控制。归档按整套备份管理，恢复另按目标环境和官方流程计划。