mongodbの構成サーバーに関するこのステートメントについて疑問に思います（ドキュメントから）：
構成サーバーのいずれかがダウンしている場合、クラスターのメタデータは読み取り専用になります。ただし、このような障害状態でも、MongoDBクラスターの読み取りと書き込みは可能です。
1つまたは3つの構成サーバーを使用できます。3つの構成サーバーを使用していて、1つのサーバーがダウンしている場合、クラスターが読み取り専用モードになるのはなぜですか？上記のリンクからわかるように、Each config server has a complete copy of all chunk information。
各サーバーにすべてのチャンク情報の完全なコピーがある場合、1つの構成サーバーがダウンした後にのみ読み取りが行われるのはなぜですか？
したがって、この理由は、構成サーバーが2フェーズコミットを実行する方法です。一方、構成サーバーが1つあり、それが失敗すると、システム全体が失敗します。3つあり、1つが失敗した場合でも、すべてのメタデータは引き続き使用できますが、2フェーズコミットの復元係数は失われます。3つのメンバーがないと、2フェーズコミットを実行できません。
したがって、読み取りのために他の2つを使い果たすことはできますが、チャンクの移行や分割が発生しないように、バランサーは基本的にオフになっています（したがって、メタデータは読み取り専用になります）。これは、3ノード構成セットアップが使用するコミットプロセスを使用して分割または移行をコミットできないため、それらが発生しないためです。
1つの構成サーバーで実行することはお勧めしません。基本的に、データがダウンした場合、データがどこにあるかわかりません。
2フェーズコミットは、データを一貫した状態に保つことができるため、3台のマシンでのみ機能します。これは、マシンが更新の途中で停止した場合、その更新は、3番目を更新する少なくとも別のノードにコミットされたかどうかに応じて失敗または持続することを意味します（したがって、2フェーズコミット）。したがって、残りの2つの構成サーバーを使用してシャーディングされたクラスターを読み取るのは安全です。
2つのノードではそれを行うことはできません。他のノードがダウンしているため、最後に残っているノードを他のノードと比較できないため、通過した可能性がありますが、通過していない可能性があります。したがって、安全な方法は、3番目のノードがバックアップされるまで更新を行わないことです。そうしないと、古いデータが読み取られる可能性があります。
シームレスな障害耐性が必要な場合は、2フェーズコミットを使用する理由から、2を使用することは意味がありません。データが正しくない可能性がある場合は、1ノードよりも耐久性はありません。また、シャーディングされたクラスターでは、チャンクの場所がわからないため、何も正しくないデータが密接に関連しています。
これは基本的に、潜在的な構成データの破損や不整合からユーザーを保護するために行われます。