MongoDB 分片、仲裁器和集群设置

Posted 2023-03-04

【中文标题】MongoDB 分片、仲裁器和集群设置

【英文标题】：MongoDB sharding, arbiter and cluster setup

【发布时间】：2014-11-28 09:09:06

【问题描述】：

有人可以帮助验证我们的设置

设置 4 节点 MongoDB 集群 1 个主要（写入），3 个辅助（读取）如果主要发生故障，3 个辅助可以打破平局并选择辅助到主要

此设置是否有效？ 在这种情况下是否需要仲裁器？

一旦我一开始就以这种方式设置它，那么随着负载的增加，我需要做的就是继续成对地向集群添加节点。 （成对添加节点将帮助我们跟上性能并减少集群更改的频率，而且我们的读重于写，在某些时候我们将不得不考虑横向扩展写）

非常感谢您的帮助。

谢谢。

【问题讨论】：

我已在下面回答，并投票决定将其移至 DBA Stack Exchange 站点 (dba.stackexchange.com)。 *** 是用于编程相关问题而不是数据库管理问题，因此您将来应该在那里问这类问题。对于这个问题，您可以迁移它，或者一旦有足够的票数移动它就会自动移动它。

我正在尝试找到如何将其移至 dba。

不知道如何迁移到 DBA.Stack

【参考方案1】：

是的，需要仲裁器，否则如果 2 个节点出现故障或不可用，您将没有主节点 - MongoDB 需要严格多数 (>50%) 的选票来选举主节点，在您的情况下，多数数为 4 分之 3（4 分之二不大于 50%）。如果添加仲裁器，该数字仍为 3，但您将能够拥有一个包含 2 个数据承载节点的主节点。

至于为什么，考虑以下可能：

2 个节点与其他 2 个节点隔离 - 它们仍然正常运行，正常运行，但无法相互通信。现在，这种“分裂”的任何一方都有 2 票，而且没有办法打破平局 - 每一方在对初选投票方面都同样有效，如果没有严格的多数规则，你最终会得到 2 个初选，而且没有办法在拆分自行解决后解决写入问题。将仲裁器添加到拆分的任一侧，您就没有这种歧义了。

当投票数是偶数时，这种类型的场景有许多排列，我不会在这里讨论。可以说，运行副本集时的最佳做法是始终拥有奇数票数，从而避免这些情况。

【讨论】：

看来 MongoDB 总是需要仲裁器（至少作为最佳实践）感谢您的回复。

如果您有奇数个数据承载节点（3、5、7 等），则不会。如果您有偶数个数据承载节点以打破联系，则它是必需的。好吧，你也可以操纵选票，但以上是一般情况