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