多个AWS实例中的MongoDB负载平衡

Question

我们将AmazonWeb服务用于使用node的业务应用程序。js服务器和mongodb作为数据库。当前已删除该节点。js服务器正在EC2介质实例上运行。我们将mongodb数据库保存在一个单独的微实例中。现在我们希望在mongodb数据库中部署副本集，这样，如果mongodb被锁定或不可用，我们仍然可以运行数据库并从中获取数据。

因此，我们试图将副本集的每个成员保持在单独的实例中，这样即使主模块的实例关闭，我们也可以从数据库中获取数据。

现在，我想在数据库中添加负载平衡器，这样即使在一次巨大的流量负载下，数据库也能正常工作。在这种情况下，我可以通过在复制集中添加slaveOK config来读取平衡数据库。但是，如果数据库中存在巨大的写操作流量负载，则无法实现数据库的负载平衡。

为了解决这个问题，到目前为止我有两个选择。

选项1：我必须对数据库进行分片，并将每个分片保存在单独的实例中。在每个碎片下，在同一个实例中会有一个reaplica集合。但是有一个问题，因为碎片将数据库划分为多个部分，所以每个碎片不会在其中保存相同的数据。因此，如果一个实例关闭，我们将无法从该实例中的碎片访问数据。

为了解决这个问题，我试图将数据库划分为分片，每个分片在不同的实例中都有一个副本集。因此，即使一个实例关闭，我们也不会面临任何问题。但是如果我们有2个分片，每个分片在复制集中有3个成员，那么我需要6个aws实例。所以我认为这不是最佳解决方案。

选项2：我们可以在mongoDB中创建一个主-主配置，这意味着所有的数据库都是主数据库，所有的数据库都有读/写访问权限，但是我也希望它们能够经常自动同步，所以它们最终都是彼此的克隆。所有这些主数据库都将在单独的实例中。但是我不知道mongodb是否支持这种结构。

我没有任何mongodb文档/博客为这种情况。所以，请建议我什么应该是这个问题的最佳解决方案。

Answer 1

选项1是@Sammaye指出的推荐方式，但您不需要6个实例，可以用4个实例来管理它。

假设需要以下配置。

• 2个碎片（S1、S2）

然后，您可以像下面那样划分服务器配置。

Instance 1 : Runs : S1 (Primary Node)
Instance 2 : Runs : S2 (Primary Node)
Instance 3 : Runs : RS1 (Secondary Node S1) and RA2 (Arbiter Node S2)
Instance 4 : Runs : RS2 (Secondary Node S2) and RA1 (Arbiter Node S1)

您可以将仲裁节点与辅助节点一起运行，这将在故障转移期间帮助您进行选举。

Answer 2

到目前为止，这还不是一个完整的答案，有太多的细节，我可以就这个问题写一篇完整的文章，就像许多其他人一样，但是，因为我没有那种时间，我会添加一些关于我所看到的评论。

现在，我想在数据库中添加负载均衡器，这样即使在一次巨大的流量负载下，数据库也能正常工作。

副本集不是设计为这样工作的。如果您希望实现负载平衡，实际上您可能正在寻找允许您实现负载平衡的切分。

复制用于自动故障转移。

在这种情况下，我可以通过在复制集中添加slaveOK config来读取平衡数据库。

因为，为了保持最新，您的成员将获得与主要成员一样多的老年退休金，这似乎没有太大帮助。

事实上，与其让一台服务器和多个连接排队，不如让多台服务器上的多个连接排队等待过时的数据，因为成员一致性是最终的，不像ACID技术那样是即时的，这就是说，它们最终只有32多毫秒的一致性，这意味着它们没有滞后到足以在主服务器加载时提供体面的吞吐量。

由于读操作是并发的，所以无论是从主设备还是从辅助设备读取，都将获得相同的速度。我想你可以延迟一个从机来创建一个操作暂停，但这会带来大量陈旧的数据作为回报。

更不用说MongoDB不是多主机，因为你一次只能写入一个节点，这使得slaveOK不再是世界上最有用的设置，我已经看到很多次10gen自己建议你在这个设置上使用分片。

选项2：我们可以在mongodb中创建一个主配置，

这将需要您自己的编码。在这一点上，您可能需要考虑实际使用支持http://en.wikipedia.org/wiki/Multi-master_replication数据库

这是因为您所寻找的速度实际上很可能是写的速度，而不是读的速度，正如我上面所讨论的那样。

选项1：我必须对数据库进行分片，并将每个分片保存在单独的实例中。

这是推荐的方法，但您已经找到了警告。不幸的是，这是多主机复制应该解决的尚未解决的问题，然而，多主机复制确实将自己的瘟疫鼠船添加到了欧洲本身，我强烈建议您在考虑MongoDB目前是否无法满足您的需求之前，先进行一些认真的研究。

由于fsync队列设计用于处理IO瓶颈，因此您可能不会真正担心什么，因为它会像在SQL中那样降低写入速度，并且读取是并发的，因此如果您正确规划模式和工作集，您应该能够获得大量的操作。

事实上，这里有一个10gen员工提出的相关问题，非常值得一读：https://stackoverflow.com/a/17459488/383478它显示了MongoDB在负载下可以实现多少吞吐量。

它将很快随着已经在开发分支中的新文档级别锁定而增长。