そのため、レプリカ セットのフェールオーバーに関して発生している深刻な問題を突き止めました。
1 つのマスター、1 つのスレーブ、および 1 つのアービターを持つクラスターを想像してください。接続文字列を使用します。
mongodb://admin:pass@slave,master
両方のホストが起動している場合は、明らかにすべて問題ありませんが、ノードを停止して再起動しようとすると、予期しない動作が発生します。
マスターを削除すると、スレーブが昇格して新しいマスターになり、php ドライバーが新しいマスター (稼働している唯一のノード) に接続されます。
それでは、新しいマスターを停止して、古いマスターを復活させましょう。古いマスターはマスターの役割に再割り当てされ、クラスター内の唯一のノードになります。現在、php ドライバーは完全に動作不能になっています。この時点で 1 つが稼働していても、クラスター内のどのノードにもまったく接続しません。他のノードを元に戻す (したがって、クラスター内のすべてのノードを元の位置に復元する) と、問題が軽減されるのではないかと考えましたが、そうではありませんでした。これで、100% 稼働しているクラスターができましたが、php ドライバーが接続できず、次のエラーが表示されます。
No candidate servers found
100回更新してもこれは修正されません。私が見つけた唯一の解決策は、php-fpmを再起動することです。php-fpm を再起動すると、すぐに接続が開始されます (結果が異なることを期待してテストをさらに 10 回繰り返すまで)。
したがって、これは、アクティブな接続を持つノードがダウンしたときに、永続的な接続が適切に閉じられない/フラッシュされないという問題に違いないと思われます。そのため、両方のノードがダウンしてから復帰したシナリオでは、mongo ドライバーは停止した接続をまだ保持しているように見えます (これは私が観察したことに基づいた私の怠惰な推測です)。ノードがオンラインに戻ったときに、接続を削除して再作成しようとしているわけではありません。
これは悪いことであり、最初に mongo レプリカ セットを使用することにした最大の理由の 1 つ (コンスタント アップ タイム) を台無しにします。
MongoDB バージョン 2.4.5、php ドライバー バージョン 1.4.3、および php-fpm バージョン 5.4.9 を使用しています。
どうすればこれを回避できますか？ノードがダウンするたびにphp-fpmを再起動する必要はありませんが、それが唯一の方法である場合は、php-fpmの再起動を自動的にトリガーするようにある種のヘルスモニターを構成する必要があります-しかし、繰り返しますが、私はむしろこれをする必要はありません。
ありがとう