3 つのシャードを持つ MongoDB シャード クラスターを AWS にデプロイします。各シャードには、3 つのメンバー、1 つの構成サーバー、および 3 つの mongos を持つ replicaSet があります。
[ shard 1 ] [ shard 2 ] [ shard 3 ]
[ mongos0 ] [ mongos1 ] [ mongos2 ]
[ config0 ] [ config1 ] [ config2 ]
[ (p) md0 ] [ (s) md0 ] [ (s) md0 ]
[ (s) md1 ] [ (p) md1 ] [ (s) md1 ]
[ (s) md2 ] [ (s) md2 ] [ (p) md2 ]
ここでは、シャードが 3 つの EC2 インスタンスにどのように分散されているかを示します
[ md0 ][ md1 ][ md2 ]
[ shard 1 ][ shard 1 ][ shard 1 ]
[ shard 2 ][ shard 2 ][ shard 2 ]
[ shard 3 ][ shard 3 ][ shard 3 ]
[ mongos0 ][ mongos1 ][ mongos2 ]
[ config0 ][ config1 ][ config2 ]
replicaSet メンバーが同じインスタンス上にないことがわかります。
しかし、たとえばmd0ダウンした場合、API (解析サーバー) はクラスターとの接続を失いmd1ますmd2が、まだ生きていて、新しいプライマリを既に選出しています。すべての EC2 インスタンスは、複製により、シャード コレクションを含むすべてのコレクションのコピーを保持します。
接続文字列は次のようになります
mongodb://user:password@mongos0:27017,mongos1:27017,mongos2:27017/mydb
クラスター/シャードの構成に問題があると思いますか、それとも他のmongosに接続しようとする代わりに接続を維持するAPIに関連する問題ですか?