MongoDB复制集磁盘清理

Question

我试图缩小MongoDB副本集的大小(集合大小相同，但磁盘空间不断增加)。根据MongoDB网站的说法，我应该在主节点上运行单神修复来压缩所有的集合。问题是网站的停工时间。因此，我有两个选择(我知道)：

1. 从复制集中取出次要节点并对其运行单神修复，然后在复制集上重新启动。我试过了，但是无法通过本地集合的权限错误。
2. 关闭辅助节点并删除数据目录中的所有文件。重新启动芒果，让它从师父那里恢复过来。这实际上对我有用，但我唯一关心的是，如果您的日志集是满的，并且它是一个上限的集合，您是只接收在日志中的数据，还是您真的会复制所有的主人的数据？

还有其他人遇到过这种情况吗？当我试图寻找这个的时候，我对缺少信息感到惊讶。

Answer 1

从复制集中取出次要节点并对其运行单神修复，然后在复制集上重新启动。

这是一种常见的做法，通常被称为“滚动修理”。您可以将复制集中的每个次要部分提取出来并修复它，并最终作为最后一步将修复的主步骤放下。只要您始终拥有大多数副本集节点可用，这种方法将最大限度地减少潜在的停机时间。

如果经常删除数据，则应考虑在PowerOf2Sizes 2.2中使用新的MongoDB集合选项。这就改变了分配方法，将文档空间按2的幂分配(例如。一个500字节的文档将被分配到512字节)，这允许更有效地重用已删除的文档中的空间(每个文档只需要稍微多几个字节)。

我试过了，但是无法通过本地集合的权限错误。

“本地”集合上的权限错误听起来类似于文件系统权限(即基于运行mongod的用户)。您应该使用同一个用户运行修复过程。

关闭辅助节点并删除数据目录中的所有文件。重新启动芒果，让它从师父那里恢复过来。这实际上对我有用，但我唯一关心的是，如果您的日志集是满的，并且它是一个上限的集合，您是只接收在日志中的数据，还是您真的会复制所有的主人的数据？

听起来，您将用于持久性和崩溃恢复的Journal与用于复制的Oplog混为一谈。

如果从主节点重新生成节点，则将复制所有数据。在此初始阶段，节点将处于恢复状态，不被视为“健康”节点(即可用于查询)。

一旦节点被捕获，它将改变为一个正常的次要状态，此时oplog将被用于正在进行的同步。

再读一读：

• 复制基础
• 副本集状态引用