我试图弄清楚是否有一种方法可以无缝地故障转移大多数 mongodb 节点位于主数据中心的 mongo 副本集。我目前的限制是 2 个数据中心，第三个数据中心是不可能的。我遇到的问题是，如果数据中心 1 出现故障，数据中心 2 中的辅助节点不会在没有人工干预的情况下提升为主节点。
数据中心1（Primary）：Mongo Node（Primary） Mongo Node（Arbiter）
数据中心2（二级）：Mongo Node（二级）
我查看了 mongodb 白皮书，但他们指出，如果 dc1 丢失，则需要手动干预才能使 dc2 中的 mongodb 实例成为主要实例。
我的问题是，是否有一种架构或配置可以让数据中心 1 丢失，并且仍然能够在无需手动干预/重新配置的情况下启用写入启用数据中心 2 接管。如果不走 3 个数据中心架构路径，这是否可能。是否可以在每个站点上保持两个 3 成员副本集同步，并可能在网络级别为连接的应用程序进行故障转移？
谢谢。
如果您使用 2 个数据中心，对我来说最简单的解决方案是仅覆盖主节点中的失败。好消息是如果奴隶死了 - 你只需要等待。
如果对主节点的访问失败，您需要回调将强制从节点到主节点的过程。如果您不花更多时间创建一个网关来缓冲查询并等待来自交换机的回调，那么此交换机将导致您的应用程序停机。这样一来，随着超时的增加，您只会变得缓慢。
在 Primary 再次运行后，您需要重新连接到它（因为您的 Slave 节点不可靠） - 这将再次导致停机 - 您需要另一个进程来检查 Primary 是否处于活动状态（来自数据中心 2）以及它是否是触发事件并继续回调。
强制从属为主的手动干预可以包装到脚本中。
对我来说，最好的解决方案是使用仲裁者将留在的第三个数据中心。跳过它并将应用程序逻辑放在那里的努力是不值得的。Mongo 中的自动故障转移运行良好且可靠。如果您使用应用程序逻辑来通过 2 个数据中心实现这一目标，您可能会遇到很多问题……我宁愿接受他们的建议。
首先，正如您所注意到的，您不能仅使用两个节点进行自动故障转移。其次，当您认为“第三”数据中心时，钱并不是真正的问题。你可能会问为什么或“怎么会”？如您所知，您需要仲裁者。Arbiter 真的不需要资源，任何小型 Linux 机器都可以。小型 VPS 机器的成本并不高。 在这里您可以找到机器 1 x 2.40 GHz、512 MB、20 GB，每月仅需 1,24 欧元。从这里你会得到更强大的机器，每月 1.99 欧元。
实际上，这两个地方都可以用那些“小”机器运行相当大的 mongodb。