我退出主节点，删除其数据并从新的主节点执行初始重新同步。但是当我在初始重新同步完成后检查数据大小时，我发现该节点中的数据大小为409G，而该节点同步其数据的其他节点中的数据大小为326G。因此，在重新同步后大小增加了 83G。
早些时候我也做过这样的初始重新同步，每次我发现重新同步后数据的大小都会减少。但在这种情况下恰恰相反。
最近我把cluster的版本从2.4.9升级到了2.6.7。这是我在版本升级后的第一次初始重新同步。大小的增加也是因为新的 MongoDB 版本。相同的数据在 2.6 版本中是否比在 2.4 版本中占用更多的存储空间？
同样的数据在2.6版本中会占用更多的存储空间吗？
如 MongoDB 2.6 发行说明中所述，默认存储分配策略从使用具有填充因子的精确匹配分配更改为
usePowerOfTwoSizes. powerOfTwoSizes 分配可能占用更多的初始空间，但通常会导致更少的存储碎片和更好地重用已删除文档的空间。一个值得注意的例外是，如果您使用的是 GridFS 并且使用旧驱动程序保存数据。原始 GridFS 块大小为 256KB（2 的精确幂），结果四舍五入为 512KB（2 的次幂）。驱动程序已更新以将 GridFS 块大小降低到 255KB，但如果您与 powerOf2 分配重新同步，这是数据库大小增加的常见原因（请参阅MongoDB 问题跟踪器中的SERVER-13331）。
更改分配策略
collMod在 MongoDB 2.6 中，您可以使用命令更改集合级别的分配策略，或使用newCollectionsUsePowerOf2Sizes配置参数更改服务器级别的分配策略。如果您更改现有集合的分配策略，这只会影响更改后在存储中创建或移动的新文档。您将不得不重新同步、压缩或修复数据库，以使用新分配重写所有文档。如果您正在使用 GridFS 并且拥有块大小为 256K 的旧文档，则将任何 gridfs
chunks集合的分配策略更改为不使用 PowerOf2Sizes 是有意义的。同样，如果您的集合数据用例恰好是仅插入的（或者不会通过更新增加大小），那么精确匹配分配将更有效。否则，建议使用 powerOf2Sizes 分配。
WiredTiger 存储引擎支持 MongoDB 3.0+ 中的压缩
如果磁盘上的存储大小是一个问题，您还应该考虑测试 MongoDB 3.0 中新的WiredTiger 存储引擎，它包括对索引和数据压缩的支持。升级到 MongoDB 3.0 和 WiredTiger 将需要您使用更新的驱动程序和工具，并且与任何主要版本升级一样，您应该查看与您的部署相关的升级过程以及任何兼容性更改。