在我的第一台服务器上，我得到了：
root@prod ~ # du -hs /var/lib/mongodb/
909G /var/lib/mongodb/
使用mongodump / mongorestore迁移此数据库之后 在我的第二台服务器上，我得到了：
root@prod ~ # du -hs /var/lib/mongodb/
30G /var/lib/mongodb/
在我等了几个小时后，mongo完成索引我得到了：
root@prod ~ # du -hs /var/lib/mongodb/
54G /var/lib/mongodb/
我测试了数据库并且没有损坏或遗漏的数据。
为什么迁移前后的大小差异如此之大？
答案 0 :(得分：8)
当实际数据大小因数据删除以及其他原因而丢失时，MongoDB无法恢复磁盘空间。在线文档中有一个不错的解释：
为什么数据目录中的文件大于数据库中的数据？
数据目录中的数据文件，即/ data / db目录 在默认配置中，可能大于插入的数据集 进入数据库。考虑以下可能的原因：
预分配的数据文件。
在数据目录中，MongoDB将数据文件预分配给特定的文件 大小，部分是为了防止文件系统碎片。 MongoDB命名为 第一个数据文件.0，下一个.1等 第一个文件mongod分配是64兆字节，接下来的128兆字节， 等等，最多2千兆字节，此时所有后续文件都是 2千兆字节。数据文件包含具有已分配空间的文件 没有数据。 mongod可能会分配一个1千兆字节的数据文件 90％为空。对于大多数较大的数据库，未使用的分配空间 与数据库相比较小。
在类Unix系统上，mongod预先分配了一个额外的数据文件和 将磁盘空间初始化为0.预分配数据文件 后台可防止新数据库文件出现严重延迟 下次分配。
您可以通过将preallocDataFiles设置为false来禁用预分配。 但是，不要为生产环境禁用preallocDataFiles： 只使用preallocDataFiles进行测试，并使用小数据集 你经常丢弃数据库。
在Linux系统上，您可以使用hdparm来了解成本有多高 分配可能是：
时间hdparm --fallocate $（（1024 * 1024））testfile
oplog。
如果此mongod是副本集的成员，则为数据目录 包括oplog.rs文件，这是一个预先分配的上限集合 在本地数据库中。默认分配约为5％ 64位安装上的磁盘空间，请参阅Oplog大小调整以获取更多信息 信息。在大多数情况下，您不需要调整oplog的大小。 但是，如果这样做，请参阅更改Oplog的大小。
期刊。
数据目录包含存储写入的日志文件 MongoDB将它们应用于数据库之前在磁盘上的操作。看到 日记机制。
清空记录。
MongoDB在删除时维护数据文件中的空记录列表 文件和收藏品。 MongoDB可以重用这个空间，但会 永远不要将此空间返回给操作系统。
要对已分配的存储进行解体，请使用压缩，这会解压缩 分配空间。通过对存储进行分解，MongoDB可以有效地进行 使用分配的空间。紧凑需要高达2千兆字节的额外费用 要运行的磁盘空间。如果你严重不足，请不要使用紧凑型 磁盘空间。
重要
compact只能从MongoDB数据文件中删除碎片 不要将任何磁盘空间返回给操作系统。
要回收已删除的空间，请使用repairDatabase，它会重建 数据库，它可以对存储进行分解，并可以释放空间 操作系统。 repairDatabase最多需要2千兆字节 要运行的磁盘空间。如果您严重不足，请不要使用repairDatabase 在磁盘空间。
http://docs.mongodb.org/manual/faq/storage/
他们没有告诉你的是另外两种恢复/恢复磁盘空间的方法 - mongodump / mongorestore就像你做的那样，或者将新成员添加到具有空磁盘的副本集中，以便从头开始写入databsae文件
如果您对监视此问题感兴趣，db.stats（）命令将返回有关数据，索引，存储和文件大小的大量数据：
答案 1 :(得分：0)
随着时间的推移，MongoDB文件会产生碎片。当您执行＆＃34;迁移＆＃34;或重击数据目录并强制重新同步时，文件打包。如果您的应用程序执行了大量删除或更新，那么文档碎片化的开发速度相当快。在我们的部署中，更新会增加导致此问题的文档。当MongoDB看到更新的文档不适合原始文档的空间时，会以某种方式移动文档。有一些方法可以将填充因子添加到集合中以避免这种情况。