需要对给定 mongoDB 副本集中仲裁者的角色进行简单解释

Question

我偶然发现 MongoDB 官方网站解释了如何设置奇数成员副本。我还从同一站点听说了Arbiter一词，根据我的理解，它不会被选为主要节点，但它确实参与选举（来自https://docs.mongodb.com/manual/core/replica-set ） -仲裁者/）。

在《为什么我们在 MongoDB 复制中需要“仲裁器”？》中还有一篇与仲裁器相关的帖子。这就涉及到 CAP 定理，这使得事情变得更加复杂。

首先，为什么我们需要使成员数量为奇数？另外，有人可以用简单的外行英语向我解释一下这个仲裁者是什么以及它在给定副本集中的作用是什么？

提前致谢。

Answer 1

简而言之：就是阻止副本集的两个正常节点在彼此失去联系时陷入裂脑情况。

MongoDB 副本集的设计是为了，如果一个或多个成员出现故障或失去联系，其他成员能够继续运行，只要他们之间拥有多数成员。大多数子句很重要：如果没有它，您可能会遇到这样的情况：网络被分成两部分，并且分区每一侧的节点认为它们仍在承载副本集，并最终得到不同的副本集。数据。

因此，为了避免脑裂问题，如果副本集的节点不能获得绝对多数，则它们将不会继续。一个例子是，如果您有两个节点，在副本集中如下所示：

如果他们失去沟通，结果是对称的：

每个人都会以同样的方式推理：

• 意识到它已经与对方失去了联系
• 评估是否可以让副本集继续运行
• 认识到 1 个节点（2 个中的一个）不构成多数节点
• 恢复到辅助模式

仲裁员带来的不同

如果有第三个节点，那么即使两个主节点失去联系，仍然会有其中一个与仲裁器保持联系。这允许两个主节点做出不同的决策，并保持副本集运行，同时避免裂脑问题。

考虑以下 3 节点副本集示例：

无论网络分区朝哪一种方向发展，一个节点仍将与仲裁器保持联系；例如这样：

节点 A 将：

• 意识到它既不能联系节点 B 也不能联系仲裁者
• 评估是否可以让副本集继续运行
• 认识到 1 个节点（共 3 个）不构成多数节点
• 恢复到辅助模式

而节点 B 能够做出不同的反应：

• 意识到它无法联系节点 A，但仍然与仲裁者有联系
• 评估是否可以让副本集继续运行
• 意识到 2 个节点（共 3 个）确实构成了多数
• 接任主要职务

这也说明了您应该如何部署仲裁器来获得该好处：

1. 尝试将仲裁器放置在独立于两个数据承载节点的系统上，以最大程度地提高其在整个网络问题中仍然能够与任一节点通信的机会
2. 它不需要存储数据，因此您不需要高规格的硬件
3. 只需1个仲裁者就足以打破僵局；你不会从多个仲裁者那里得到任何好处