具有两个数据中心的Mongodb架构和故障转移

Question

我正在试图弄清楚是否有一种无缝故障转移mongo复制集的方法，其中大多数mongodb节点都存在于主数据中心。我目前的限制是2个数据中心，第三个数据中心是不可能的。我遇到的问题是，如果数据中心1出现故障，数据中心2中的辅助节点将无法在没有人工干预的情况下升级为主节点。

数据中心1（小学）： Mongo节点（主要） Mongo Node（Arbiter）

数据中心2（中学）： Mongo节点（辅助）

我看过mongodb白皮书，但他们表示如果dc1丢失，则需要手动干预才能将dcongb实例设置为dc2 primary。

我的问题是，是否有一个架构或配置可以丢失数据中心1，并且仍然能够在没有手动干预/重新配置的情况下使数据中心2接管并启用写入。如果没有沿着3数据中心架构路径走下去，这是否可行？是否可以在每个站点保持两个3成员副本集同步，并可能在网络级别为连接应用程序进行故障转移？

感谢。

Answer 1

如果您使用2个数据中心，我最简单的解决方案是仅覆盖主要故障。好消息是奴隶死了 - 你只需要等待。

如果访问主节点失败，则需要回调过程以强制Slave为Primary。如果您没有花费更多时间来创建一个缓冲查询并等待来自交换机的回调的网关，则此开关将导致应用程序停机。通过这种方式，你只会因为增加超时而变慢。

在Primary再次运行之后，您需要连接回来（因为您的Slave节点不可靠） - 这将再次导致停机 - 您需要另一个进程来检查Primary是否处于活动状态（来自数据中心2）以及是否存在是触发事件并继续回调。

强制Slave as Primary的手动干预可以包装到脚本中。

对我而言，最好的解决方案是使用仲裁器所在的第三个数据中心。跳过这个并将应用程序逻辑放在那里的努力是不值得的。 Mongo中的自动故障转移工作非常好并且可靠。如果你使用应用程序逻辑来实现2个数据中心的话，你可能会遇到很多问题......我宁愿选择他们的建议。

Answer 2

首先，正如您所注意到的，您不能仅使用两个节点进行自动故障转移。其次，当你认为“第三”数据中心时，钱并不是真正的问题。你可能会问为什么或“如何”？ 如你所知，你需要仲裁者。 Arbiter真的不需要资源，任何小型Linux机器都可以。小型VPS机器的成本不高。 Here you can find machine 1 x 2.40 GHz, 512 MB, 20 GB 只有1,24欧元/月。 From here you get beefier machine with 1.99€/month.

实际上这两个地方都可以用那些“微型”机器运行相当大的mongodb。