我在MongoDB官方网站上看到了一个解释，解释了为什么要设置奇数个成员副本。我也从同一个网站听说了仲裁者一词，据我所知，它不会被选为初选，而且它确实参加了选举（选自https://docs.mongodb.com/manual/core/replica-set-arbiter/）。
在Why do we need an 'arbiter' in MongoDB replication?中还有一个与仲裁者相关的帖子，然后是与cap定理相关的，它进一步使事情变得更复杂。
首先，我们为什么要把会员的数目设为奇数？另外，有人能给我解释一下这个仲裁者是什么，它在一个简单的外行英语复制集中扮演什么角色吗？？
提前谢谢。
最佳答案
简而言之：如果副本集的两个正常节点彼此失去联系，则停止它们进入split-brain situation中。
MongoDB副本集的设计使得，如果一个或多个成员出现故障或失去联系，其他成员可以继续as long as between them they have a majority。多数子句很重要：如果不这样做，您可能会遇到这样的情况：网络被分成两部分，分区两边的节点认为它们仍在承载副本集，并最终得到不同的数据集。
因此，为了避免分裂大脑的问题，如果复制集的节点不能命令绝对多数，那么它们将不会继续。例如，如果在这样的副本集中有两个节点：
如果他们失去沟通，结果是对称的：
每个人的理由都是一样的：
意识到它已经失去了与对方的沟通
评估是否可以保持副本集正常运行
认识到1个节点（2个节点中的1个）不构成多数
恢复到辅助模式
仲裁者的与众不同之处
如果有第三个节点，那么即使两个主节点彼此失去联系，也仍然会有其中一个节点与仲裁者联系。这允许两个主要节点做出不同的决策，并保持副本集的运行，同时避免了分割大脑的问题。
考虑以下3节点副本集的示例：
无论网络分区以何种方式进行，一个节点仍将与仲裁器联系；例如：
节点A将：
意识到它既不能联系节点B也不能联系仲裁人
评估是否可以保持副本集正常运行
认识到1个节点（3个节点中的1个）不构成多数
恢复到辅助模式
而节点B能够做出不同的反应：
意识到它不能联系节点A，但仍然与仲裁人有联系
评估是否可以保持副本集正常运行
认识到2个节点（3个节点中的2个）确实构成了大多数
作为主要接管
这也说明了how you should deploy an arbiter要获得这一好处：
尝试将仲裁器放在一个独立于两个数据承载节点的系统上，以最大限度地提高它仍然能够在整个网络问题中与任何一个进行通信的机会
它不需要存储数据，所以不需要高规格的硬件
只有一个仲裁员就足以打破僵局；你从多个仲裁员那里得不到任何好处
关于mongodb - 需要简单解释Arbiter在给定mongoDB副本集中的角色，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/43083246/