在EC2上部署MongoDB进行生产的建议做法？

Question

我想在EC2上为我的生产部署mongoDB。但是，我无法在网上找到足够的信息来帮助解答我的架构问题。

1. 一般来说，什么应该是初始簇w/N碎片？
2. 添加额外碎片的部署计划应该是什么？
3. 什么应该是故障转移策略（当一个或多个节点发生故障时会发生什么）？
4. 灾难恢复策略应该是什么？我正在考虑在美国东部和美国西部的其他节点设立一些节点，如this powerpoint file说。

回答非常感谢。

Answer 1

1. 从启用分片开始，但将分片数量限制为您实际需要的 。启用分片功能意味着已有 mongos守护进程，请选择相关 集合的分片键，并尽可能使查询成为有针对性的，而不是全局 。从这一点开始，当负载增加时增加碎片。 可能的例外情况是，当您期待大量流量涌入 启动时，在这种情况下，您希望同时添加更多分片和预分割 并将块预先移至适当的分片，因为块平衡是一个缓慢的过程。
2. 没有这样的计划是必要的。碎片可以在飞行中添加和删除。 请注意，删除碎片涉及到它们的退役。从该点开始， 将在所有块被移动到其他碎片之前花费（显着）的时间量，以便实例可以被移除。
3. 副本集允许这样做。如果您的耐用性要求不是 超级关键，您可以通过在单个实例上托管 多个仲裁者而不是执行完整的3 成员复制来实现一定的成本效率。另请注意，使用“slaveOk” 标志，复制将提高最终一致性兼容查询的读取性能 。此外，您可以考虑通过使用磁盘级故障转移（例如RAID10）以较低的开销实现类似级别的耐用性 。 很明显，这并没有发现完整的实例失败。
4. 地理数据中心拆分总是一个好主意，但请注意 复制性能将受到严重影响。策略 对此没有任何其他数据库不同。

附加说明：

• EC2网络层被限制为每秒100k的数据包。对于小型高吞吐量查询，这将很快成为瓶颈。
• RAID您的EBS卷。在单个EBS卷上运行将会导致非常不稳定的性能。随着更多卷成为RAID设置的一部分，这变得更加稳定。一定有！
• 使用高内存实例。我们已经看到显着的性能 这里的改进，因为只有很多你可以做的关于权利 平衡你的索引，并保持相关的数据在内存中。保留 注意你的故障/秒在mongostat。这些是页面错误，因此mongo不得不打开磁盘换出页面的次数。

Answer 2

温斯顿，克里斯蒂娜·乔多罗的 “缩放MongoDB的” 是你想要什么：

http://oreilly.com/catalog/0636920018308

据我了解，

1）你想副本集的3个或更多（一些奇数）每个分片的实例，加上每个分片中的一些时间延迟实例作为备份

2）简单地将它们添加到集群中 - Mongo将缓慢地将分片移动到新节点上，直到集群被重新平衡

3）副本集通常会很好地处理故障转移;但是，您可能需要将Mongo的仲裁实例添加到运行应用程序前端的服务器 - 这些仲裁者将投票支持其余实例成为初选，以防许多节点停止运行，并且有助于确保任何可以访问的Mongo实例您的前端服务器将能够接管主要角色

4）将时间延迟实例添加到每个副本集是一个好主意，尤其是如果（如您所说）在地理上分布，或者如果它们在几个托管服务提供商（例如，如果您的主服务器在亚马逊上，您可能需要在Rackspace上进行备份）。如果副本集的大部分发生故障，剩余的节点将不会自动选择新的主节点，但是您可以在发生这种灾难时手动执行此操作。

Answer 3

myNoSQL是我最喜欢的NoSQL博客，最近发布了一篇名为Running MongoDB in the Cloud的文章，列出了几篇关于在Amazon云中部署MongoDB的文章。

• 的MongoDB在Amazon EC2上使用EBS卷
• 的MongoDB在EC2上
• 的MongoDB在亚马逊云
• 设置的MongoDB副本集在Amazon EC2上
• 的MongoDB和亚马逊：为什么EBS？
• 亚马逊EBS VS SSD：价格，性能，服务质量
• 多租户和云存储性能

Answer 4

1）我想用几个碎片，除非你知道你肯定需要更多的开始。
2）添加更多分片的棘手部分是重新平衡所花费的时间。根据您的数据和负载情况，整个分片可能需要几天才能重新平衡。因此，您希望在低负载时间安排分片添加
3）每个分片应至少有一个2 + 1副本集，副本分布在可用区域内。
4）如果您对灾难恢复感兴趣，应该在各个区域而不是跨可用区域分布副本。更多信息在这里 - EC2 best practices。另外请记住，如果您在各地区分发副本，请正确配置副本集的优先级。