AWS 上的 MongoDB 灾难准备

Question

我正在寻找有关 AWS 托管环境中 MongoDB 灾难恢复的最佳实践建议。

我们的设置在这一点上是相当标准的，3 个服务器的副本集（1 个主服务器、1 个辅助服务器和 1 个仲裁器），主服务器和辅助服务器上的 mongo 卷是 EBS 支持的。所有这些都在一个区域中，分布在多个可用区中。最终我们需要跨越区域，但这是改天的讨论。

我在 Mongo 文档中看到的备份建议谈到了 EBS 快照（这很容易实现自动化）。然而，如果灾难来袭，它们不会让我们回到失败的时代。

我正在寻找可用的最强大的策略。高达第二次数据保护和故障后系统恢复速度的优先级高于价格。我们可以稍后优化价格。

在此先感谢您的所有建议...

Answer 1

首先，如果您拍摄快照，它将包含 oplog - oplog 只是一个存在于本地数据库中的有上限的集合。快照将返回到某个时间点，并且假设您已启用日记功能（默认情况下已启用），您无需为快照执行任何特殊操作即可作为备份。

唯一的绝对要求是 EBS 快照必须足够新才能落入您的oplog窗口 - 即快照备份 oplog 中记录的最后（最近）操作也必须仍然在当前主要的 oplog 中，以便它们可以找到一个共同点。如果是这种情况，它将像这样工作：

如果快照不够新，则可以将其丢弃 - 在 oplog 中没有公共点，辅助节点无论如何都必须从头开始重新同步。

要回答您的具体问题：

我是否需要记录 oplog 并结合使用它们来在故障后恢复？

如上所述，如果你快照，你已经在备份 oplog

我是否应该在副本集中启动另一个实例，专门用于备份和快照，而不是拍摄主要和次要快照？如果是这样，我们又回到了 oplog 问题，不是吗？

除了我上面提到的共同点/窗口之外，没有任何 oplog 问题。有些人确实为此选择了一个辅助节点（通常是隐藏的），以避免向普通节点增加负载。注意：即使是隐藏成员也会获得投票，因此如果您出于备份目的添加了一个，您可以从配置中删除仲裁器，您仍然会有 3 个投票成员。

我是否应该对每个副本卷进行快照并完全依赖副本集来覆盖故障和最后一个快照之间的时间？

副本集的每个成员都应该是相同的——数据是相同的，任何辅助节点都可以成为主节点等等——这些不是从节点，每个副本集成员都包含完整的 oplog 和所有数据。

因此，拍摄多个快照（假设您信任该过程）将是多余的（当然您可能需要这种冗余）。是的，副本集功能的全部目的是确保您不需要采取特殊措施以这种方式使用辅助（当然要记住上面的警告）。