成员数为奇数和偶数的MongoDB副本集

我注意到MongoDB副本集的一些特性

在一个3节点的replSet中，如果主节点发生故障，我会看到该集选择了一个新的主节点，并且一切正常，不会出现任何停机。但是，如果另一个成员宕机（总共宕机2个），剩下的1个成员不会成为主成员，并且会发生完全宕机。据我所知，这是因为被选者在选举中没有多数票

但这似乎很愚蠢。。难道我的1名幸存成员不能独立工作吗？有没有办法对其进行配置以获得此行为

我知道仲裁者可以用来获得多数票，但是，如果我为总共4名成员添加仲裁者，一个偶数，那么这不也会遇到多数票的问题吗？或者，如果我为总共5名有投票权的成员添加了2名仲裁员，但其中1名被否决，那么我是否会留下偶数名有投票权的成员，并且仍然怀疑回答集无法选出初选成员

总的来说，我有点搞不清楚“多数”是如何建立的，当成员上下时会发生什么，我有什么配置选项。我的具体问题是：

• 当2个成员宕机时，如何防止3节点应答集中的宕机，和/或安全修复此场景中发生的宕机的最佳实践是什么
• 在奇数成员回复集中，当奇数个成员下降并在偶数个成员在线的情况下离开回复集时会发生什么情况（相对于能够进行多数选举的回复集）

当2个成员宕机时，如何防止3节点应答集中的中断

---

你没有。如果两个成员宕机，您的副本集将成为只读的，这是正确的。“down”可以是相对的-服务器1可能会说2和3已关闭，但实际上1位于网络分区的另一端。如果服务器1防止2个成员中断，它将成为主服务器并接受写操作。但是，2或3中的一个也是主项，因此现在集合有两个主项。当分区结束时，如何协调发送到1和发送到2、3的主分区的冲突写入？概率是防止大多数副本集成员宕机的屏障—如果一台服务器宕机的时间为1%，而每台服务器的宕机都独立于另一台服务器的宕机（这一假设很可能是正确的，除非服务器位于同一位置），那么至少有2台服务器将在1/10000的时间内宕机。如果需要更高的赔率，请在副本集中使用5台服务器

当奇数个成员下降，而回复集中有偶数个成员在线时会发生什么情况

---

副本集需要多数（就副本集成员的总数而言，而不是从任何一个成员的角度来看当前增加的数目而言）才能选择主副本集。如果某个复制集成员组（无论是偶数还是奇数）发现它们构成了复制集的大多数，则它们将尝试选择一个主复制集。多数条件保证只能有一个主。因此，8/11成员之间的对话将像7/11或9/11那样巧妙地选出初选

安全补救这种情况下发生的停机的最佳实践是什么

---

正如前面的答案所提到的，MongoDB正在努力避免在副本集中有两个原色，因为这将导致严重的损坏。如果您知道某个节点已关闭且不再返回，则可以将其从副本集中删除。即使只有一个幸存节点，您也可以告诉该节点从配置中删除停止的节点，因此最终会得到一个节点副本集，并且该节点将成为主节点。如果没有主节点，则必须使用rs.reconfig（）中的“force”选项来删除下行节点。之后，您可以向副本集中添加新节点，它们将开始从幸存节点复制数据。您可能需要调整应用程序配置以引用新节点。

有，但我不建议这样做。它不允许只剩下一个主服务器来分发工作的原因是，无法确定所讨论的主服务器是否确实是合法的主服务器，或者是否只是一个断开的节点等等“如果需要更好的几率，请在副本集中使用5台服务器。”然后，如果它们被分成两台机器：机器A运行3个节点，机器B运行2个节点。有一天他们失去了连接，难道这不意味着这两台机器现在都有了自己的主设备吗？Thx“因此，8/11成员之间的对话将像7/11或9/11那样巧妙地选举初选。”——但在8/11的情况下，有机会举行平局选举，不是吗？而在7/11和9/11事件中，可能性是零？