MongoDB:两个节点和初选

pet*_*nar 0 replication mongodb

根据 Mongo 文档,为了安全地部署复制集,您至少需要两个活动节点和一个仲裁节点,因为主节点的选举需要多数票。

假设我可以拥有三台机器,因此部署三个成熟的 mongo 实例,没有仲裁者。

如果选定的主节点失败,我最终会得到两个节点,其中两个节点具有相同的“功率”级别:对我来说,这似乎是部署中描述的必须避免的情况。

有人可以解释为什么在初始设置相同的情况下在这种情况下选择一个主节点不是问题吗?

小智 7

只要两个节点都可用,在两个节点集中选举一个主节点就不是问题。规则是该集合的大多数需要成功选举一个主要。

在两个节点集中:

  • 如果两个节点都已启动,则可以选举一个主节点
  • 如果只有一个节点启动,它看不到多数,将保持只读状态

在三节点集中:

  • 如果三个节点都启动了,一个可以成为主节点
  • 如果两个节点都启动了,一个可以成为主节点
  • 如果只有一个节点启动,它是只读的

一个二节点 + 仲裁器集的行为就像一个三节点集,所以如果任何一个节点(包括仲裁器)出现故障,它可以选举一个主节点。

重要的是要意识到只有两个投票节点的集合在没有写冗余的情况下运行。您不希望创建一个总是像这样运行的集合(因此,仲裁器),并且您还希望在发生中断时尽快恢复第三个节点。

  • 我知道这是一个老问题,但万一有人仍然感到困惑,在 3 节点集中,如果丢失一个节点,它不会成为 2 节点集。它仍然是一个 3 节点集,其中 2/3(超过一半)是可操作的。在 2 节点组中,如果一个节点出现故障,则它是一个 2 节点组,其中 1/2 可操作(不是多数)。我花了一段时间才明白这不是有 2 个节点的事实,而是 2/3 对 2/2 的事实。 (3认同)
  • 实际上,它确实回答了这个问题——2/3 = 多数,2/2 = 多数。不同之处在于,在 3 节点集中,如果您失去一个节点,您仍然拥有一个功能齐全的主节点和一个辅助节点,而在 2 节点集中,如果您失去一个节点,则您是只读的(无主节点)。您可以使用 2 个节点运行,但从冗余的角度来看,它不会为您带来任何好处 - 事实上,您使系统更容易出现故障。 (2认同)