我们在 AWS 中托管了一个具有三个节点的 MongoDB 3.4 副本集：一个主节点、一个辅助故障转移节点和一个仲裁节点。通常，如果主实例挂掉，到辅助实例的故障转移会非常快（10-30 秒）。
今天我们遇到了一个网络问题，MongoDB 主实例与包含数据库的磁盘失去连接大约 3 分钟，CPU IOWait 达到 100%。在此期间，对主节点的查询刚刚挂起并进入超时状态。可能是因为主节点仍在运行（尽管没有响应），副本集没有进行故障转移，甚至没有开始投票。
在这种情况下是否有也会产生故障转移的配置？或者是否有一些现成的工具可以在对主节点的简单查询开始花费太长时间时强制进行故障转移？
在SERVER-14139的评论中广泛讨论了一个密切相关的问题，这是针对 mongodb 提交的错误报告。总而言之，在服务器进程中构建一个完全通用的挂起检测系统是不可行的。
中的评论讨论了一种监视方法，该方法可以终止进程或关闭操作系统，并且可以使用 cron 作业或看门狗守护程序来完成。Because a mongod process cannot win an election before it has read and written some data to its storage engine, it is safe to immediately attempt to restart mongod after you kill it. 重新启动的进程不应该接受连接，当然也无法赢得主要选举。
链接到 SERVER-14139 的票证涵盖了企业（非免费）MongoDB 版本中存储看门狗定时器的实现。可以使用看门狗守护程序或外部监控进程的组织应该更喜欢这种方法，因为它可以防止更多类型的资源故障。
通常在主服务器上，你给出 command
rs.stepDown()，但我认为这种情况下它不会工作，因为你的辅助服务器无法读取主 opLog。在这种情况下，最快的做法是在这些节点之间设置防火墙。因此，您发出命令阻止端口 27017（或您使用的任何端口）。您的辅助节点和仲裁节点无法获得心跳，他们投票决定必须移动主要节点。