2

我正在尝试缩小我的 MongoDB 副本集的大小（集合大小相同，但磁盘空间不断增长）。根据 MongoDB 网站，我应该只在主节点上运行 mongod --repair 以压缩所有集合。问题将是网站的停机时间。所以，我有两个选择（我知道）：

  1. 从副本集上取下辅助节点并在其上运行 mongod --repair 并在副本集上重新启动。我试过这个，但无法通过“本地”集合的权限错误。

  2. 关闭辅助节点并删除数据目录中的所有文件。重新启动 mongo 并让它从 master 中恢复。这实际上对我有用，但我唯一担心的是，如果您的期刊收藏已满，并且由于它是有上限的收藏，您会只收到期刊中的数据还是实际上复制所有主数据？

有没有其他人遇到过这种情况？在尝试搜索此内容时，我对缺乏信息感到惊讶。

4

1 回答 1

1

从副本集上取下辅助节点并在其上运行 mongod --repair 并在副本集上重新启动。

这是一种常见的做法，通常被称为“滚动修复”。您从副本集中取出每个辅助节点并对其进行修复，并最终将主节点降级以作为最后一步进行修复。只要您始终拥有大部分可用的副本集节点，这种方法就会最大限度地减少潜在的停机时间。

如果您经常删除数据，您应该考虑使用 MongoDB 2.2 中新的PowerOf2Sizes集合选项。这将分配方法更改为以 2 的幂次方分配文档空间（例如，一个 500 字节的文档将分配 512 个字节），这允许更有效地重用已删除文档的空间（以每个多字节为代价）文档）。

我试过这个，但无法通过“本地”集合的权限错误。

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

关闭辅助节点并删除数据目录中的所有文件。重新启动 mongo 并让它从 master 中恢复。这实际上对我有用，但我唯一担心的是，如果您的期刊收藏已满，并且由于它是有上限的收藏，您会只收到日记中的数据还是会实际复制所有主数据？

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

如果您从主节点重新同步一个节点，所有数据都将被复制过来。在这个初始阶段，节点将处于 RECOVERING 状态并且不被视为“健康”节点（即可用于查询）。

一旦节点被赶上，它将变为正常的 SECONDARY 状态，此时oplog将用于正在进行的同步。

一些进一步的阅读：

于 2012-12-04T01:12:32.800 回答