2

使用分布在 3 个数据中心的 mongo

对于此示例，数据中心名称为 A、B、C

当一切顺利时，所有用户流量都指向 A

所以mongo主要在A上，mongo设置是：

  • A 中的 3 台服务器（具有高优先级）
  • B 中的 1 台服务器（低优先级）
  • C 中的 1 个服务器（优先级 0 ）

当发生 2 种情况时，问题是支持 mongo-writes：

  1. ABC 之间没有网络（网络隧道已关闭）
  2. 数据中心 A 着火了 :)，假设数据中心不工作，此时所有用户流量都指向 B，并且预计 B 中的主要选举。

方案 1 不是问题，当没有数据中心网络隧道时，A 仍然有大部分副本和高优先级，所以一切都还在工作。

场景 2 将不起作用，因为当 A 停止工作时，所有 3 个副本（在 A 上）都无法访问，这样在 B 或 C 中将不会重新生成新的主副本，因为大多数副本都已关闭。

如何设置我的副本集以支持 2 个场景？

4

1 回答 1

3

这是不可能的：在整个网络分区的情况下，以及在使用 MongoDB 使用的多数选举方法的 DC 发生故障的情况下，您不能拥有一个“可用”系统：多数人在一个 DC 中，那么它将在分区中幸存下来，但在 DC 宕机时不能幸存，或者大多数需要 2 个 DC 启动，这可以在一个 DC 宕机但不能在完全网络故障时幸免于难。

您的选择：

  • 接受分区问题并将设置更改为 2-2-1。不可靠的隧道应该是可以解决的，如果 DC 的整个网络出现故障，您就处于方案 2。
  • 接受 DC 问题并坚持您的配置。最可能的问题可能是大规模网络问题和大规模停电，而不是火灾。
  • 使用支持其他类型容错的数据库。然而，这并不是万能的，因为这需要其他必须很好理解的权衡。

为了在 DC A 出现故障时保持系统正常运行，还需要DC B 或 C 中的应用程序服务器，这本身就是一个棘手的问题。例如，如果您使用分区容忍度更高的数据库，您可能很容易遇到“脑裂”问题，即不同 DC 中的应用程序服务器接受不同但相互冲突的写入。此类问题只能在应用层面解决。

于 2015-05-17T20:33:08.440 回答