我正在寻找涵盖 AWS 托管环境内的 MongoDB 灾难恢复的最佳实践建议。
目前我们的设置相当标准，副本集由 3 台服务器组成（1 台主服务器、1 台辅助服务器和 1 台仲裁服务器），主服务器和辅助服务器上的 mongo 卷由 EBS 支持。全部位于一个区域，分布在多个可用区。最终我们需要跨区域，但这是另一天的讨论。
我在 Mongo 文档中看到的备份建议谈到了 EBS 快照（很容易实现自动化）。但是，如果发生灾难，它们无法让我们回到发生故障时的状态。
- 我是否需要记录 oplog 并在发生故障后使用它们进行恢复？
- 我是否应该在副本集中启动另一个实例，专门用于备份和快照，而不是拍摄主副本和次副本的快照？如果是这样，我们又回到了 oplog 问题，不是吗？
- 我应该快照吗每个副本卷并完全依赖副本集来覆盖故障和最后一次快照之间的时间？
我正在寻找最强大的策略。高达 1 秒的数据保护和故障后系统恢复速度比价格更重要。我们可以稍后优化价格。
提前感谢所有建议...
答案1
首先，如果您拍摄快照，它将包含 oplog - oplog 只是本地数据库中的上限集合。快照将返回到某个时间点，并且假设您已启用日志功能（默认情况下处于启用状态），则您无需执行任何特殊操作即可使快照充当备份。
唯一的绝对要求是 EBS 快照必须足够新，以符合您的操作日志窗口 - 即快照备份 oplog 中记录的最后一个（最近）操作也必须仍在当前主节点的 oplog 中，以便它们可以找到一个共同点。如果是这样的话，它将像这样工作：
- 从 EBS 快照备份中恢复辅助数据
- 启动
mongod、查找（并应用）任何相关的日志文件 - 接下来，辅助节点连接到主节点，并在两个 oplog 中找到一个共同点
- 主服务器的任何后续操作都将应用于恢复次要的
- 一旦辅助服务器足够赶上进度，它就会转为 SECONDARY 状态，备份就完成了
如果快照不够新，则可以丢弃它——如果没有 oplog 中的公共点，辅助节点将必须从头开始重新同步反正。
回答您的具体问题：
我是否需要记录 oplog 并在发生故障后使用它们进行恢复？
如上所述，如果你创建了快照，则你已经备份了 oplog
我是否应该在副本集中启动另一个实例，专门用于备份和快照，而不是拍摄主副本和次副本的快照？如果是这样，我们又回到了 oplog 问题，不是吗？
除了我上面提到的常见点/窗口问题之外，没有其他 oplog 问题。有些人确实选择使用辅助节点（通常隐) 以避免给正常节点增加负载。注意：即使是隐藏成员也会获得投票，因此如果您出于备份目的添加了一个仲裁者，则可以从配置中删除该仲裁者，您仍然会有 3 个投票成员。
我是否应该对每个副本卷进行快照，并完全依赖副本集来覆盖故障和上次快照之间的时间？
副本集的每个成员都应相同 - 数据相同，任何辅助成员都可以成为主成员等 - 这些不是从属成员，每个副本集成员都包含完整的 oplog 和所有数据。
因此，拍摄多个快照（假设您信任该过程）将是多余的（当然您可能想要这种冗余）。是的，副本集功能的全部意图是确保您不需要采取特别措施来以这种方式使用辅助副本（当然，请牢记上述注意事项）。