使用MongoRestore 4.2恢复MongoDump 4.0备份后数据库大小减半是否可行？

存储空间缩小的根因 #

• mongodump是逻辑备份工具，导出的文件仅包含实际有效文档数据、索引定义，不会携带原MongoDB实例运行过程中产生的磁盘碎片、预分配的空闲存储空间、历史无效数据块。
• 方案1用4.2版本的mongorestore恢复数据时，相当于将所有数据重新写入全新的4.2实例，会触发两层优化：
  1. WiredTiger存储引擎在4.2版本对默认snappy压缩算法做了效率优化，新写入的全量数据都会采用更优的压缩规则存储，压缩比高于4.0版本
  2. 历史运行产生的存储碎片被完全清理，所有数据按连续的最优结构存储，没有冗余空间占用
• 方案2是先恢复到4.0实例再原地升级到4.2，原地升级逻辑仅修改数据库元数据、适配新版本引擎规则，不会重写已有的磁盘数据文件，原4.0实例的碎片、旧压缩格式的文件都会完整保留，所以存储空间不会发生变化。

你已经通过db.stats()验证不存在未释放的空闲空间，且文档数量、结构、索引全部正常，说明缩小的空间全部是冗余占用的无效空间，没有数据丢失风险。 #

跨版本恢复方案的使用建议 #

官方不推荐跨版本使用mongodump/mongorestore的核心原因是不同版本间可能存在元数据格式、特殊字段类型的兼容问题，极端情况下会导致数据丢失、异常。你已经完成多轮测试的前提下，可以选择方案1，但上线前必须完成以下校验：

• 全量数据一致性校验：逐集合执行db.collection.countDocuments()确认文档总数完全匹配，随机抽取至少10%的文档对比字段内容完全一致，调用db.collection.getIndexes()对比所有索引的定义、类型、大小完全匹配
• 业务可用性校验：将恢复完成的4.2实例接入测试环境，运行至少72小时的全量业务模拟流量，确认没有查询报错、统计结果异常、写入失败的问题
• 生产环境操作前必须额外留存一份原4.0实例的全量物理备份，作为极端情况的兜底恢复手段

内容的提问来源于stack exchange，提问作者M.Ahmed Amjad