如何使 MongoDB `repairDatabase` 和 `compact` 命令与副本集一起使用？停机时间没问题

Question

我们需要释放一些 MongoDB 空间，并且我们确定了可以从集合中安全删除的超过 100Gb 的文档。

因此，我们将它们从具有以下设置的测试环境中删除：

• mongodb版本3.0.1
• 没有分片
• 1 个节点，无副本
• 有线虎引擎

完成后，我们发现磁盘上的空间仍然被使用，需要回收。我们找到了这篇文章，它对我们有帮助：运行完两者后

db.runCommand({repairDatabase: 1})

和

db.runCommand({compact: collection-name })

我们释放了 100Gb 以上。

然后我们继续生产，忘记了设置是不同的，因为我们有 1 个副本节点：

• mongodb版本3.0.1
• 没有分片
• 1 个主节点、1 个副本节点
• 有线虎引擎

删除文档后，我们运行

db.runCommand({repairDatabase: 1})

并收到OK消息（过了一会儿，10 分钟以上）。我们尝试跑步

db.runCommand({compact: collection-name })

并得到这个错误：

不会在活动副本集主节点上运行紧凑型操作，因为这是一个缓慢的阻塞操作。用力：真实用力

所以我们跑

db.runCommand({compact: collection-name, force: true })

并收到“确定”消息（几乎立即），但空间上的磁盘仍然被使用，它没有被释放。

我们寻找使用副本集运行repairDatabase和compact命令的解决方案，但建议的重点是避免停机，就好像这是唯一的问题一样。但是，我们可以安排停机时间，但我们的问题是命令无法按预期工作，因为空间实际上并未被回收。

我们做错了什么？

Answer 1

对于副本集配置，恢复空间的最佳且最安全的方法是执行初始同步。如果需要从集合中的所有节点恢复空间，可以执行滚动初始同步。也就是说，在最终降低主节点并对其执行初始同步之前，在每个辅助节点上执行初始同步。

请注意，只有当您的部署包含至少三个节点副本集时，才可能进行滚动初始同步（原因我将在下面描述）。

滚动初始同步方法是执行副本集维护的最安全方法，而且它的优点是不涉及停机。

话虽如此，有一些事情值得一提：

关于compact：

MongoDB 3.0.x 上的 WiredTiger 上的命令compact受到此错误的影响：SERVER-21833，该错误已在 MongoDB 3.2.3 中修复。在此版本之前，compactWiredTiger 可能会默默失败。

关于repairDatabase：

请不要repairDatabase在副本集节点上运行。正如在RepairDatabase 页面中提到的，强烈不建议这样做。该名称有点误导，因为该命令不会尝试修复任何内容。该命令旨在在磁盘损坏时使用，这可能会导致文档损坏。repairDatabase

该repairDatabase命令可以更准确地描述为“抢救数据库”。也就是说，它通过丢弃损坏的文档来重新创建数据库，试图使数据库进入可以启动它并从中挽救完整文档的状态。

在副本集中，MongoDB 希望该集中的所有节点都包含相同的数据。如果您repairDatabase在副本集节点上运行，则该节点有可能包含未检测到的损坏，并且repairDatabase将尽职地删除损坏的文档。可以预见的是，这使得该节点包含与该集合的其余部分不同的数据集。如果更新碰巧影响了该单个文档，则整个集合可能会崩溃。更糟糕的是，这种情况完全有可能在潜伏很长一段时间后，突然无缘无故地突然袭来。

关于您的设置：

我注意到在您的生产环境中，您创建了一个具有两个节点的副本集。不建议进行此设置，因为单个节点的故障将使剩余节点成为辅助节点，从而不允许写入该集。

由于 MongoDB 高可用性的工作方式（请参阅副本集选举），强烈建议至少部署三个数据承载节点，或者至少添加一个仲裁节点（请参阅副本集成员），以便您的副本集包含奇数个节点。成员数量。

副本集中只有两个成员也会使滚动升级/初始同步/维护变得更加困难，在某些情况下甚至不可能。

MongoDB 3.0.1 于2015 年 3 月 17 日发布，截至本文撰写时已过去 2 年多了。如果您被迫使用 MongoDB 3.0 系列，请考虑迁移到 3.0.15。或者更好的是，升级到 3.4.7（最新版本截至 2017 年 8 月 10 日），其中包含相对于 3.0.1 的巨大改进。