MongoDB 4.2版本mongodump备份文件远大于实际数据库大小问题咨询

MongoDB 4.2 mongodump备份体积远超数据库实际大小解决指南 #

差异原因 #

show databases返回的160GB是WiredTiger存储引擎压缩后的实际磁盘占用大小，包含了MongoDB的存储层压缩、碎片空间复用等优化。默认配置下mongodump导出的是未压缩的BSON明文数据，会包含所有逻辑数据、索引元数据，即使是磁盘上已标记为可复用的碎片对应的空逻辑记录也会被导出，最终备份体积就会远大于实际存储大小。

解决方案 #

• 开启内置压缩导出
  MongoDB 4.2版本的mongodump原生支持gzip压缩参数，导出时直接添加--gzip即可实时压缩备份文件，无需二次处理，修改后的命令如下：

  mongodump -u admin -p 'xxxxxxxxx' --authenticationDatabase admin --gzip --out /backup/daily_backup/$date
  

  开启压缩后备份体积通常会和实际数据库大小接近，部分场景下甚至会更小。
• 清理数据库存储碎片
  长期执行大量数据删除操作会产生较多存储碎片，这部分碎片对应的无效逻辑数据会被mongodump导出。可在业务低峰期对集合执行compact操作释放碎片：

  use target_database
  db.runCommand({ compact: 'collection_name', force: true })
  

  注意：compact执行期间会阻塞对应集合的读写，副本集环境建议先在从节点执行，再切换主节点操作原主节点。
• 排除非必要集合
  排查是否存在业务不需要备份的临时集合、日志集合，备份时通过--excludeCollection参数排除，进一步减小备份体积：

  mongodump -u admin -p 'xxxxxxxxx' --authenticationDatabase admin --gzip --excludeCollection temp_log --out /backup/daily_backup/$date
  

• 可选：归档为单文件
  如果需要更方便的备份文件管理，可添加--archive参数将所有备份内容打包为单个压缩文件，减少碎文件占用的额外磁盘开销：

  mongodump -u admin -p 'xxxxxxxxx' --authenticationDatabase admin --gzip --archive=/backup/daily_backup/$date.archive
  

内容的提问来源于stack exchange，提问作者Dhananjay Patil