假设一个典型的副本集（一个主、一个辅助和一个仲裁器）的场景，其中 3 个成员部署在 3 个独立的网络节点上。如果主从之间的网络连接断开，而其他一切都很好，那么mongodb如何反应？
这种情况下，arbiter知道primary和secondary都活着，primary实际上并没有受到影响，虽然它会继续报告secondary的断线，但是对于secondary，会不会触发选举成为primary ?那么原来的primary会怎样呢？等等。
我不知道会发生什么，而且这种场景很难在我的 PC 上创建。有人知道吗？
【问题讨论】：
如果您有一个三节点副本集，只要两个成员可以互相看到（其中一个是数据承载节点），就可以选举主节点。
因此一个节点完全断开连接的可能场景：
如果primary和arbiter可以看到其他（但不是secondary），除了没有选举次要 将开始累积复制延迟，直到网络连接恢复（或 次要的 oplog 不再与 主要 有共同点，必须是re-synced)。
如果 primary 和 secondary 可以看到对方（但不能看到 arbiter），则没有选举，复制将继续正常。
如果 secondary 和 arbiter 可以看到其他（但不是 primary），则 secondary将被选为初选。如果存在复制延迟，则可能有一些条目写在前一个主节点上，而这些条目在辅助节点上不被接受。当前一个主节点能够重新加入副本集（作为辅助节点）时，任何未复制到当前主节点的操作都将保存为rollback。
如果发生部分断开连接，primary 和 secondary 可以看到 arbiter 而不是彼此，我希望secondary 将尝试开始选举但被否决，因为 arbiter 可以看到比 secondary 更新的活动 primary em>（如果有节点否决，则选举失败）。
当网络可用性不一致时，有一个更棘手的情况。在这种情况下，如果主节点间歇性无法访问，则副本集可能会经历“抖动”（连续选举）。
模拟网络场景的一种方法是使用防火墙规则（用于阻止）和tc (traffic control 等工具来引入延迟或丢包。还有一个 mongobridge 工具可以在 MongoDB 源代码树中编译（参见：Simulating Network Partitions with mongobridge）。
其他有用的阅读：
【讨论】：
我认为这个问题是由这个错误回答的：https://jira.mongodb.org/browse/SERVER-9730 “在任何情况下，当一个主节点已经存在时，不要投票赞成”，所以不会有两个主节点。
【讨论】：