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

Question

我正在尝试弄清楚是否有一种方法可以无缝地对大多数mongodb节点位于主数据中心的mongo副本集进行故障转移。我目前的限制是2个数据中心，而第三个数据中心是不可能的。我遇到的问题是，如果数据中心1出现故障，如果没有人工干预，数据中心2中的辅助节点将不会升级为主要节点。

数据中心1(主要)：Mongo节点(主要) Mongo节点(仲裁器)

数据中心2(辅助)：Mongo节点(辅助)

我看过mongodb白皮书，但它们指出，如果dc1丢失，则需要手动干预才能使mongodb实例成为dc2主实例。

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

谢谢。

Answer 1

如果你有两个数据中心，对我来说，最简单的解决方案是只覆盖主要故障。好消息是，如果Slave死了，你只需要等待。

如果访问主节点失败，您需要回调过程，强制Slave到主节点。如果您没有花费更多的时间来创建一个网关来缓冲查询并等待来自交换机的回调，则此切换将导致应用程序停机。这样，随着超时时间的增加，你只会变得很慢。

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

强制将Slave作为主要对象的手动干预可以封装到脚本中。

对我来说，最好的解决方案是第三个数据中心，仲裁者将驻扎在那里。跳过这一步并将应用程序逻辑放在那里的努力是不值得的。Mongo中的自动故障转移工作得很好，而且很可靠。如果你用两个数据中心的应用逻辑来实现这一点，你可能会遇到很多问题……我宁愿接受他们的建议。

Answer 2

首先，正如您已经注意到的，您不能仅使用两个节点进行自动故障转移。其次，当你想到“第三”数据中心时，钱并不是真正的问题。你可能会问为什么或者“为什么”？如你所知，你需要仲裁者。仲裁器实际上不需要资源，任何一台小型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。