标签: replica-set

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

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

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

• 我是否需要记录 oplog 并结合使用它们来在故障后恢复？
• 我是否应该在副本集中启动另一个实例，专门用于备份和快照，而不是拍摄主要和次要快照？如果是这样，我们又回到了 oplog 问题，不是吗？
• 我是否应该对每个副本卷进行快照并完全依赖副本集来覆盖故障和最后一个快照之间的时间？

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

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

我正在尝试在 MongoDB 3.04 版中创建副本集。我遵循本教程并在尝试使用主服务器添加节点时遇到下一个错误：

vacrep:PRIMARY> rs.add('server address here')
{
    "ok" : 0,
    "errmsg" : "Quorum check failed because not enough voting nodes responded;
     required 2 but only the following 1 voting nodes responded: PRIMARYSERVER:27017; 
     the following nodes did not respond affirmatively: 'server address here':27017 
     failed with Missing credentials for authenticating as internal user",
     "code" : 74
}

这是到目前为止所做的：

1. 使用 MongoDB 3.04 安装 3 个服务器
2. 使用 repSet 模式运行所有 MongoDB 实例
3. 使用此方法验证服务器之间的连接
4. 在主服务器中启动一个副本）

我发现有关此错误的线程很少，但在其中任何一个中都找不到解决方案。我该如何解决这个问题？

我有三台安装了 mongod 的服务器作为复制集运行。突然，这两个辅助变得不可用（mongod 进程死亡） - 我认为是因为它们太陈旧了。

问题是原来的 PRIMARY 现在是 SECONDARY，我的应用程序无法工作，因为它无法连接到 PRIMARY。

我的意思是，这对我有什么帮助？如果副本集无法进行故障转移？！我错过了什么吗？

此外，我还问自己为什么 SECONDARIES 会死掉/为什么它们太陈旧了？我能做什么呢？

仅供参考：我的数据库相当大（磁盘上有 40GB）。