有人知道为什么mongodb副本集会很快地进行主交换和辅助交换吗？

我们将3台mongo服务器设置为副本，其中一台永远无法成为主服务器（备份）。假设mongo1是主要的，mongo[2..3]是次要的。mongo2和mongo3无法随机访问mongo1，这导致mongo2被选为主要用户。Mongo1随后看到了这一点，并成为主要的。然后mongo2和Mongo3在几秒钟后再次看到mongo1，并再次当选

有没有理由让它如此迅速地重新选举mongo1？mongo 1和mongo 2具有相同的优先级

问题是它会断开mongo路由器与我们每个Web服务器的连接，这需要一段时间来重新发现哪个是主服务器并连接到它

此外，mongodb路由器应该位于应用服务器上还是单独的服务器上？在mongodb手册中，它建议将它放在每个应用服务器上，但这样做的好处是什么？在应用程序和mongo服务器之间安装路由器服务器有什么好处和问题

我应该在AWS（ec2）中提到这一点，如果这有区别的话

编辑：

将Mongo2.4.6作为分片副本集运行。很抱歉，我忘了提到那一部分。它们的负载相当高。mongo实例在EC2中都位于同一区域和同一可用性区域

为什么要将mongos与应用服务器放在同一个实例上？
网络跳数/延迟。查询本地mongos的权威碎片比执行远程查询要快-这两种方法都需要从正确的碎片中获取数据。
另一方面：Couchbase等其他数据库避免使用mongos/router组件，以完全避免这种开销

我假设您已将主备份和辅助备份拆分到多个可用区域？也许网络有点不稳定，尽管它不应该如此？不幸的是，如果您进行了网络拆分，您对故障切换无能为力-不快速故障切换将打开更大的回滚窗口，这是您希望避免的。除非您想完全禁用自动故障切换。
而只有在新的主节点失去多数时，节点才应该重新当选。因此，在您的情况下，2和3似乎无法连接到2。So 2成为新的主要元素。但不久之后，1和3无法连接到2，因为他们拥有多数票，他们选择1再次成为主

---

mongodb路由器是指mongos进程吗？您能运行rs.status（）和rs.conf（）并将输出添加到您的问题中吗？这里是rs.status和rs.conf的粘贴箱，是的，可以通过分析日志了解mongos processExact问题。它是高负载环境吗？您是否尝试重新同步辅助服务器？您正在运行副本集还是分片群集？在副本集配置中，没有单独的路由器组件（分片集群具有

mongos

进程）。你能澄清一下你所说的“路由器”吗？您还可以提供关于副本集部署的更多详细信息吗：您的MongoDB服务器是否在地理上分布？这些是什么类型的AWS实例？另外，什么版本的MongoDB？在原始帖子中添加了更多信息