mongodb - 需要简单解释仲裁者在给定 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 个仲裁者就足以打破僵局；您不会从多个仲裁者中获得任何好处

Answer 2

以 2 成员副本集为例：如果发生网络分区，即 2 个成员彼此失去联系，谁将成为主副本？将有一个平局，并且需要一个决胜局。如果我们有一个 3 成员副本集，情况就不会如此：包含两个节点的组将获胜，其中一个将成为主节点。这是副本集中奇数节点要求的基础。至于仲裁器，它的重量很轻，所以我想可以通过安装一台更小的机器来省钱，因为我们不希望它保存任何数据，我们只需要它在场即可投票基本的。