我正在寻找涵盖AWS托pipe环境中的MongoDB灾难恢复的最佳实践build议。
在这一点上，我们的设置是相当标准的，3台服务器的副本集（1个主服务器，1个仲裁服务器和1个仲裁器），主服务器和辅助服务器上的mongo卷均支持EBS。 全部在一个地区，分布在多个可用区域。 最终我们需要跨越地区，但这是另一天的讨论。
我在Mongo文档中看到的备份build议讨论了EBS快照（这很容易自动化）。 但是，如果发生灾难，他们不会让我们回到失败的时候。
我正在寻找最可靠的战略。 第二次数据保护和系统故障后的恢复速度比价格优先。 稍后我们可以优化价格。
预先感谢所有的build议…
首先，如果您拍摄快照，将包含oplog – oplog仅仅是居住在本地数据库中的上限集合。 快照将回到某个时间点，并且假设您启用了日志function（默认情况下启用了日志function），则不需要对快照执行任何特殊操作即可作为备份。
唯一的绝对要求是，EBS快照必须足够近，才能落入oplog窗口 – 这是在快照备份oplog中logging的最后（最近的）操作还必须位于当前主节点的oplog中，以便它们可以find一个共同点。 如果是这样的话，它会像这样工作：
mongod启动，查找（并应用）任何相关的日志文件 如果快照不够近，那么可以丢弃它 – 在oplog中没有公共点，辅助将不得不从头开始重新同步 。
回答你的具体问题：
我是否需要loggingoplogs并使用它们在失败后恢复？
如上所述，如果你快照，你已经在备份oplog
我是否应该在专门用于备份和快照的复制副本集中创build另一个实例，以获取主要和次要的快照？ 如果是这样，我们又回到oplog的问题是不是？
上面提到的共同点/窗口之外没有oplog问题。 有些人为了这个目的而select有一个辅助（通常是隐藏的 ），以避免向正常节点增加负载。 注意：即使是一个隐藏的成员也会得到一个投票，所以如果你添加了一个用于备份的目的，你可以从你的configuration中删除这个仲裁者，你仍然会有3个投票成员。
我应该快照每个副本卷，并依靠副本集完全覆盖故障和上次快照之间的时间？
副本集的每个成员都是相同的 – 数据是相同的，任何副本都可以成为主要副本等 – 这些不是从属的，每个副本集成员都包含完整的oplog和所有数据。
因此，拍摄多张快照（假设您相信这个过程）将会是多余的（当然您可能需要这种冗余）。 是的，复制集function的全部意图是确保您不需要采取非常措施来以这种方式使用辅助（当然，上述注意事项）。