我正在尝试缩小MongoDB副本集的大小（集合大小相同但磁盘空间不断增长）。根据MongoDB网站，我应该在主节点上运行mongod --repair来压缩所有集合。问题是网站的停机时间。所以，我有两个选择（我知道）：
从副本集中取出辅助节点并在其上运行mongod --repair并在replica-set上重新启动。我试过这个并且无法通过'本地'集合获得过去的权限错误。
关闭辅助节点并删除数据目录中的所有文件。重启mongo并让它从master恢复。这实际上对我有用，但我唯一担心的是，如果您的期刊收集已满，如果它是一个上限集合，您是否只会收到期刊中的数据，或者您是否实际复制了所有主数据？
还有其他人遇到过这种情况吗？在尝试搜索时，我对于缺乏信息感到惊讶。
答案 0 :(得分：1)
从副本集中取出辅助节点并在其上运行mongod --repair并在副本集上重新启动。
这是一种常见的做法，通常被称为“滚动修复”。您从副本集中取出每个辅助节点并进行修复，最后作为最后一步逐步降低主节点进行修复。只要您始终拥有大部分可用的副本集节点，此方法将最大限度地减少潜在的停机时间。
如果您经常删除数据，则应考虑使用MongoDB 2.2中的新PowerOf2Sizes集合选项。这改变了分配方法，以两个幂的方式分配文档空间（例如，一个500字节的文档将被分配512个字节），这允许更有效地重用已删除文档中的空间（以每个更多字节的少量费用为代价）文件）。
我试过这个并且无法在“本地”收藏中获得过去的权限错误。
“本地”集合上的权限错误听起来像文件系统权限（即基于您运行mongod as的用户）。您应该使用同一个用户运行修复过程。
关闭辅助节点并删除数据目录中的所有文件。重启mongo并让它从master恢复。这实际上对我有用，但我唯一担心的是，如果您的期刊收集已满，如果它是一个上限集合，您是否只会收到期刊中的数据，或者您是否实际复制了所有主数据？
听起来您正在将用于持久性和崩溃恢复的Journal与用于复制的Oplog混为一谈。
如果您从主节点重新同步节点，则将复制所有数据。在这个初始阶段 节点将处于RECOVERING状态，不被视为“健康”节点（即可用于查询）。
一旦节点被捕获，它将变为正常的SECONDARY状态，此时oplog将用于持续同步。
进一步阅读：