我们在 AWS 中运行了一个相当大的 Mongo DB。目前，我们正在运行一个包含 3 个实例的副本集。每个实例都有 5TB 的附加 EBS 存储。每个实例每月的费用超过 1000 美元。除此之外，我们还有一个生产环境和一个暂存环境（第三个“开发”环境即将推出）。此外，当我们转向分片环境时，这些成本在未来可能会激增。
问题是，在 AWS 环境中 3 个副本有多必要？
好的，好的，我已经知道答案是“视情况而定”。我正在寻找一些关于如何最好地权衡利弊的建议。例如...
考虑到每个 EBS 卷已内置三重冗余，并且从备份中恢复相当简单，我如何衡量 2 个副本与 3 个副本所增加的容错能力。
在考虑权衡时，除了冗余之外，还需要考虑其他什么？
是否有人有仅运行 2 个副本 + 一个仲裁器的经验（好或坏）？
答案1
- 考虑到每个 EBS 卷已内置三重冗余，并且从备份中恢复相当简单，我如何衡量 2 个副本与 3 个副本所增加的容错能力。
就 MongoDB 而言，三节点副本集中只有两个数据承载成员的关键考虑因素是，如果其中一个数据承载成员由于任何原因（计划维护或计划外故障）不可用：
- 您不再具有活动复制（仅剩下一个承载数据的成员）
- 您的部署无法再确认高于以下级别的写入关注
w:1（例如：w:majority或w:2）
此配置在单个成员发生故障时维护/选举主节点方面具有高可用性，但如果您的某个数据承载成员不可用，仲裁器会损害数据冗余。假设您有合理的时间从 EBS 备份中恢复（并且信任 EBS 冗余），这可能是适合您用例的可接受的折衷方案。
- 在考虑权衡时，除了冗余之外，还需要考虑其他什么？
如果您的代码使用 MongoDB写关注点高于默认值（w:1），您需要添加一个wtimeout值。如果不指定该wtimeout选项，并且无法实现写入关注级别，则写入操作将无限期阻塞。
AWS 对冗余基础设施的保证通常仅扩展到跨多个可用区域的故障，因此为了最大限度地提高可用性，您还应该将副本集成员部署到不同的可用区域。
- 有没有人有只运行 2 个副本 + 一个仲裁器的经验（好的或坏的）
我确实看到过用户未能考虑上述几点（尤其是考虑写入问题和超时）而导致的不良结果。如果您在计划（和测试）时牢记这些注意事项，您应该能够获得良好的体验。
除此之外，我们还有一个生产环境和一个暂存环境（第三个“开发”环境即将推出）
拥有类似生产环境的暂存和开发环境肯定是有争议的，但典型的成本节约是为开发部署较低规格的环境，其故障转移比生产环境要少。对于暂存，您可能希望部署较低规格的环境，但具有类似的配置，以便您可以测试真实的故障转移场景。如果您在暂存环境中进行性能或负载测试，则应为它们配置与生产相同的规格。