为什么我们需要MongoDB复制中的"仲裁者"？

Question

假设我们在没有仲裁的情况下设置MongoDB复制,如果主服务器不可用,则副本集将选择辅助服务器作为主服务器.所以我认为它是一种隐式仲裁器,因为副本将自动选择一个主节点.

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

Answer 1

我创建了一个电子表格,以更好地说明Arbiter节点在副本集中的效果.

它基本上归结为以下几点:

1. 如果RS为2个数据节点,则丢失1个服务器会使您低于投票最小值("大于N/2").仲裁者解决了这个问题.
2. 使用偶数编号的RS 数据节点,添加仲裁器会使您的容错能力提高1,而不会因为拆分而产生2个投票群集.
3. 对于具有奇数编号数据节点的RS ,添加仲裁器将允许分割以创建具有"大于N/2"投票的2个隔离群集,因此是分裂脑情景.

选举在这里详细解释[详细] .在该文件中,它声明 RS可以有50个成员(偶数)和7个投票成员.我强调"状态",因为它没有解释它是如何工作的.对我而言,如果你发生分裂,一方有4名成员(所有投票)而另一方有46名成员(3名投票),你宁愿让46人选出一名主要成员,4名成员阅读 - 只有集群.但是,这正是"有限投票"所阻止的.在这种情况下,您实际上将拥有一个4成员集群,其中一个主集群和一个46成员集群是只读的.解释这有多大意义超出了这个问题的范围,超出了我的知识范围.

Answer 2

这实际上归结为CAP定理,其中声明如果分区两侧的服务器数量相等,则数据库无法维护CAP(一致性,可用性和分区容差).仲裁者专门设计用于在一侧创建"不平衡"或多数,以便在这种情况下可以选出主要人员.

如果你在任何一方获得偶数个节点,MongoDB将不会选择主节点,你的集合将不接受写入.

编辑

在任何一方,我的意思是,例如,一边是2,另一边是2.我的英语在那里不容易理解.

所以我的意思是双方.

编辑

维基百科为解释CAP提供了一个很好的案例:http://en.wikipedia.org/wiki/CAP_theorem

Answer 3

由于以下原因，必须在复制中使用仲裁器：

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

希望这可以帮助 ！！！