如果您有一个三节点副本集，只要两个成员可以互相看到（其中一个是数据承载节点），就可以选举主节点。
因此，一个节点完全断开连接的可能场景：
如果primary和arbiter可以看到其他（但不是从属），则没有选举但从属将开始累积复制延迟，直到网络连接恢复（或从属的 oplog不再与主有共同点，必须重新同步）。
如果primary和secondary可以看到对方（但不是arbiter），则没有选举，复制将正常继续。
如果secondary和arbiter可以看到其他（但不是primary），则从节点将被选为主节点。如果存在复制延迟，则可能有一些条目写在前一个主节点上，而这些条目在辅助节点上不被接受。当前一个主节点能够重新加入副本集（作为辅助节点）时，任何未复制到当前主节点的操作都将保存为回滚。
在主节点和辅助节点可以看到仲裁器但彼此看不到的部分断开连接的情况下，我希望辅助节点将尝试开始选举但被否决，因为仲裁器可以看到比辅助节点更新的活动主节点（如果任何节点否决，则选举失败）。
当网络可用性不一致时，还有一个更棘手的情况。在这种情况下，如果主节点间歇性无法访问，则副本集可能会经历“抖动”（连续选举）。
模拟网络场景的一种方法是使用防火墙规则（用于阻止）和工具，例如tc（流量控制引入延迟或丢包。还有一个mongobridge工具可以在 MongoDB 源代码树中编译（请参阅：使用 mongobridge 模拟网络分区） .
其他有用的阅读：
我认为这个问题是由这个错误回答的：https ://jira.mongodb.org/browse/SERVER-9730 “在任何情况下，当主已经存在时不要投票”，所以不会有两个主。