因此，我找到了一个关于副本集中故障转移的严重问题。
想象一个具有一个主设备、一个从设备和一个仲裁器的集群。我们使用连接字符串：
mongodb://admin:pass@slave,master
当两台主机都启动时，一切都很好，很明显，但是当我开始尝试关闭一个节点并重新启动它时，会出现意外的行为。
假设我取消了主节点，然后从节点被提升并成为新的主节点，然后 php 驱动程序连接到新的主节点（唯一启动的节点），这是预期的，这很好......现在。
所以现在让我们把新主人拿下，把老主人带回来。旧的 master 被重新分配给 master 角色，现在它是集群中唯一的节点。现在 php 驱动程序完全无法运行。它根本不会连接到集群中的任何节点，即使此时一个节点已启动。我想也许恢复另一个节点（从而将集群中的所有节点恢复到正常位置）会缓解这个问题——它没有。所以现在我有一个 100% 启动并运行的集群，但是 php 驱动程序无法连接并且它给出了错误：
No candidate servers found
刷新 100 次无法解决此问题，我发现唯一可行的解决方案是重新启动 php-fpm。一旦 php-fpm 重新启动，连接就会立即开始（直到我重复我的测试十几次，希望结果有所不同）。
所以在我看来，这一定是一个问题，当具有活动连接的节点出现故障时，持久连接没有正确关闭/刷新。所以在我看来（请注意，这是我根据我观察到的闲置推测）在两个节点都关闭然后又恢复的情况下，mongo 驱动程序仍然保持死掉的连接并且当节点重新联机时，它不会尝试删除和重新创建连接。
这很糟糕，它破坏了我们决定首先使用 mongo 副本集的最大原因之一（恒定的正常运行时间）。
我正在使用 MongoDB 2.4.5 版、php 驱动程序 1.4.3 版和 php-fpm 5.4.9 版。
知道如何解决这个问题吗？我真的不希望每次节点关闭时都必须重新启动 php-fpm，但如果这是唯一的方法，我将不得不配置某种类型的健康监视器来自动触发 php-fpm 重新启动——但同样，我宁愿不必这样做。
谢谢