我注意到有关MongoDB副本集的一些特性。
在3节点replSet中，如果PRIMARY发生故障，我看到该集合选择了一个新PRIMARY，一切都很好，没有经历任何停机。但是如果另一个成员关闭（总共2个），则剩下的1个成员不会成为主要成员，并且会发生完全中断。我理解这是因为replSet没有选举的多数。
但这看起来很愚蠢..我的1名幸存的成员不应该自己动手吗？有没有办法配置它，以便我得到这种行为？
据我所知，arbiters可以用来获得多数，但是，如果我为一个总共4个成员添加一个仲裁器，一个偶数，那么这也不会遇到多数问题吗？或者，如果我为总共5个投票成员添加2个仲裁者，但是1个下降，我是不是会留下偶数个投票成员并且仍然怀疑replSet无法选择PRIMARY？
总的来说，我对于成员上升或下降时会发生什么样的“多数”以及我有哪些配置选项感到有些困惑。我的具体问题是：
答案 0 :(得分：3)
当2个成员关闭时，如何防止3节点replSet中断
你不是。如果两个成员关闭，您的副本集将变为只读，这是正确的。 ＆＃34;向下＆＃34;可以是相对的 - 服务器1可能会说2和3都关闭，但实际上1是在网络分区的另一端。如果服务器1防止2个成员的中断，它将成为主要的并接受写入。然而，2或3中的一个也是主要的，所以现在该集合有两个原色。当分区结束时，如何协调发送到1的冲突写入并发送到2,3的主要？如果服务器在1％的时间内停机，那么概率就是防止大部分副本集成员关闭的屏障，每个服务器停机都是独立于另一个服务器的下降（假设这可能是真的，除非是服务器是共处的），然后至少2个将只下降1/10000的时间。如果您需要更好的赔率，请在副本集中使用5台服务器。
当奇数个成员离开并且在线会员数量为偶数时，会发生什么？
副本集需要占多数（就副本集成员的总数而言，而不是当前从任何一个成员的角度来看的数量）才能选出主要副本。如果某些副本集成员，无论它是偶数还是奇数，看到它们构成副本集的大多数，它们将尝试选择主副本。大多数情况保证只能有一个主要。所以8/11成员互相交谈将选择一个小学，如7/11或9/11。
答案 1 :(得分：0)
安全修复此方案中发生的中断的最佳做法是什么？
正如之前的回答所提到的，MongoDB正在努力避免在副本集中有两个原色，因为这会导致严重的损坏。如果您知道某个节点已关闭但未返回，则可以将其从副本集中删除。即使您只有一个幸存节点，您也可以告诉该节点从配置中删除关闭节点，因此您最终得到一个单节点副本集，并且该节点将成为主节点。如果没有主数据库，则必须使用rs.reconfig（）中的“force”选项来删除down节点。之后，您可以将新节点添加到副本集，并且它们将开始从幸存节点复制数据。您可能需要调整应用配置以引用新节点。