为啥我们在 MongoDB 复制中需要一个“仲裁者”？

Posted 2023-02-24

【中文标题】为啥我们在 MongoDB 复制中需要一个“仲裁者”？

【英文标题】：Why do we need an 'arbiter' in MongoDB replication?为什么我们在 MongoDB 复制中需要一个“仲裁者”？

【发布时间】：2013-08-15 04:34:53

【问题描述】：

假设我们设置了一个没有仲裁器的 MongoDB 复制，If the primary is unavailable, the replica set will elect a secondary to be primary. 所以我认为它是一种隐式仲裁器，因为副本会自动选择主节点。

所以我想知道为什么我们需要一个专用的仲裁节点？谢谢！

【参考方案1】：

我created a spreadsheet是为了更好地说明副本集中Arbiter节点的效果。

基本上可以归结为以下几点：

如果 RS 有 2 个数据节点，失去 1 个服务器会使您低于您的投票最小值（即“大于 N/2”）。仲裁器解决了这个问题。 对于 偶数数据节点的 RS，添加仲裁器可将容错度提高 1，而不会因拆分而拥有 2 个投票集群。 如果 RS 具有奇数编号的数据节点，添加仲裁器将允许拆分创建 2 个具有“大于 N/2”票的隔离集群，因此会出现脑裂情况。

[详细] 详细解释了选举here。在该文件中声明 RS 可以有 50 个成员（偶数）和 7 个投票成员。我强调“状态”，因为它没有解释它是如何工作的。在我看来，如果你发生分裂，一方有 4 名成员（全部投票），另一方有 46 名成员（3 名投票），你宁愿让 46 人选举初选而 4 人作为阅读 -只有集群。但是，这正是“有限投票”所阻止的。在这种情况下，您实际上将拥有一个 4 成员集群，其中一个主集群和一个 46 成员集群是只读的。解释这是怎么回事超出了这个问题的范围，也超出了我的知识范围。

【讨论】：

原因是，如果这 42 个成员没有投票权，那么如果我没记错的话，即使您在一侧有更多成员，也将被视为您不想将它们用于数据完整性, 只计算有投票权的成员，因为无投票权的成员可能包括各种奇怪的服务器，您真的不希望这些服务器是决定您希望数据来自何处的组的一部分

我同意如果你有“各种奇怪的服务器”，你不会希望他们投票。出于这个原因，我支持 MongoDB 具有无投票权成员的概念。但是，MongoDB 似乎很随意地得出结论，“如果你有 49 台服务器，其中 42 台是应该投票的奇怪服务器”。它是如此武断，我敢肯定这不是他们的推理。因此，我坚持我的主张，即无法解释 7 的投票限制。

也许，自从我上次与 MongoDB Inc 交谈以来已经有一段时间了，所以我不了解他们目前的思维模式

所以如果我有 1 个主要和 2 个辅助我需要一个仲裁器，如果我有 1 个主要和 3 个辅助我不需要仲裁器？

@MostafaHussein 你倒退了。您使用仲裁器来避免偶数。您不会用它们创建偶数。这就是红细胞和绿细胞的区别。

【参考方案2】：

这实际上归结为 CAP 定理，即如果分区两侧的服务器数量相等，则数据库无法维护 CAP（一致性、可用性和分区容限）。仲裁器专门设计用于在一侧创建“不平衡”或多数，以便在这种情况下可以选举主节点。

如果您在任一侧获得偶数个节点，MongoDB 将不会选择主节点，并且您的集合将不接受写入。

编辑

我的意思是，例如，一侧是 2，另一侧是 2。我的英语在那里不太好理解。

所以我真正的意思是双方。

编辑

***为解释 CAP 提供了一个很好的案例：http://en.wikipedia.org/wiki/CAP_theorem

【讨论】：

CAP 的链接会有所帮助。

@DanDascalescu 完成，我想找到教会我的链接，但我再也找不到了，***是唯一一个不使用 CAP 来推广或营销某些东西的人，所以我已经链接了它们

所以简单来说，如果我有一个包含三个成员的副本集，并且我添加了一个 abriter，这会导致问题/僵局吗？谢谢

这是很有可能的，但是，MongoDB 确实有某些措施来否决投票轮次，以尝试让偶数成员实际选择一个主节点，但如果您在网络分区之间有偶数成员，则没有简单的方法这个

【参考方案3】：

由于以下原因，在复制中需要仲裁器：

如果具有奇数个副本集，则复制更可靠。如果有偶数个副本集，最好在副本中添加一个仲裁器。 仲裁者

不保存

数据，他们只是在任何节点故障时投票选举。 Arbiter 是一个轻量级进程，它们不会消耗太多硬件资源。 仲裁者只是在加密的副本集之间交换用户凭据数据。 选举期间的投票、心跳和配置数据在副本集之间通信时未加密。 最好在单独的机器上运行仲裁程序，而不是与任何一个副本集一起运行以保持高可用性。

希望对你有帮助！！！

【讨论】：

我认为第二条语句需要调整，它说：“仲裁器中确实有数据”，但 mongodb 的说法不同：（隐藏节点和仲裁器是不同类型的副本集成员；仲裁器在隐藏节点从 oplog 复制） - 这是我从 mongodb 文档中得到的..!!

Remarkable：Arbiter 里面不保存数据，只是在节点出现故障时投票选举。

【参考方案4】：

仲裁器是一种可选机制，当您在副本集中部署了偶数个 mongod 时，它允许投票成功。仲裁器是轻量级的，意味着部署在不是专用 mongo 副本的服务器上，即：服务器的主要角色是其他一些任务，例如 redis 服务器。由于它们很轻，因此不会（明显）干扰系统资源。

来自文档：

仲裁者没有数据集的副本，不能成为仲裁者 基本的。副本集可能有仲裁者在选举中添加投票 为初级。仲裁器允许副本集具有奇数个 成员，无需复制数据的成员的开销。

http://docs.mongodb.org/manual/core/replica-set-arbiter/ http://docs.mongodb.org/manual/core/replica-set-elections/#replica-set-elections

【讨论】：

你可以在分区的一侧有一个偶数，并且可以选择一个主节点

我假设您在谈论网络拆分。当然，当投票副本成员的总数为奇数时，您最终会得到一个主副本。只要您部署了奇数个成员，其中一个是否是仲裁者都没有关系。 OP 在问“为什么我们需要一个专用的仲裁节点”。我会说，如果您为仲裁器专用一台单独的机器，不妨将其设为一个完整节点。

我的意思是您的第一行：“当您在副本集中部署偶数个 mongod 时”这并不完全正确

虽然据说它们很适合部署在应用程序服务器上，但是是的，一台单独的机器可能在 90% 的情况下作为数据保存节点更好

您说“可选”。但是，如果我正在运行一个主要和一个辅助，那么“可选”似乎是一个松散的术语。在这种情况下，如果没有仲裁者，是否真的不会选举初选？