MongoDB シャーディング アーキテクチャの公式ドキュメントを読んだ後、別の数ではなく、1 つまたは 3 つの構成サーバーが必要な理由がわかりませんでした。
構成サーバーに関するMongoDBのドキュメントには、次のように記載されています。
「1 つまたは 2 つの構成サーバーが使用できなくなると、クラスターのメタデータは読み取り専用になります。シャードからデータを読み書きすることはできますが、3 つのサーバーすべてが使用可能になるまで、チャンクの移行や分割は行われません。」
つまり、1 台のサーバーは単一障害点に相当しますが、2 台のサーバーでは 3 台と同じ動作になりますよね?
では、たとえば、2 つ以上のサーバーではなく、絶対に 3 つのサーバーを使用するのはなぜでしょうか?
ドキュメントにも次のように書かれているためです。
構成サーバーは、レプリカ セットとして実行されません。
MongoDB 3.0 以前は、MongoDB 3.2 の時点でレガシー SCCC (同期クラスター接続構成) と呼ばれる単一タイプの構成サーバー展開プロトコルのみをサポートします。SCCC デプロイメントには、1 つの構成サーバー (開発のみ) または 3 つの構成サーバー (実稼働) があります。
MongoDB 3.2 は SCCC プロトコルを廃止し、新しい展開タイプをサポートします: Config Servers as Replica Sets (CSRS)。CSRS デプロイメントには、標準のレプリカ セットと同じ制限があり、MongoDB 3.2 のように 1 つの構成サーバー (開発のみ) または最大 50 サーバー (実稼働) を持つことができます。本番環境での高可用性のためには、最低 3 台の CSRS サーバーが推奨されますが、地理的に分散した環境では追加のサーバーが役立つ場合があります。
SCCC では、構成サーバーは、トランザクションのために複数のサーバーからのコンセンサスを必要とする2 フェーズ コミットプロトコルを使用して更新されます。テスト/開発目的で単一の構成サーバーを使用できますが、本番環境で使用する場合は常に 3 つにする必要があります。 SCCC 構成用の 1 つまたは 3 つの構成サーバー。
3 台のサーバーを使用すると、2 台のサーバーよりも強力な整合性が保証され、1 台の構成サーバーでメンテナンス アクティビティ (バックアップなど) を実行しながら、2 台のサーバーmongosをクエリに使用できます。サーバーが 3 つを超えると、すべてのサーバーでデータをコミットするのに必要な時間が長くなります。
シャード クラスターのメタデータは、すべての構成サーバーで同一である必要があり、MongoDB シャーディング実装によって維持されます。メタデータには、現在どのシャードが一連のドキュメント (別名chunks) を保持しているかの重要な詳細が含まれています。SCCC 構成では、構成サーバーはレプリカ セットではないため、1 つ以上の構成サーバーがオフラインの場合、構成データは読み取り専用になります。それ以外の場合、データがオフラインの構成サーバーに伝播する手段はありません。オンラインに戻ります。
明らかに、1 つの構成サーバーでは冗長性やバックアップは提供されません。構成サーバーが 2 つの場合、サーバーは使用可能であるが、サーバー上のデータが一致しない場合に障害が発生する可能性があります (たとえば、サーバーの 1 つでデータが破損している場合など)。3 つの構成サーバーを使用すると、前のシナリオを改善できます。2/3 のサーバーは一貫しており、奇数のサーバーを特定できます。
MongoDB 3.2 では、構成サーバーに 3 つのミラー化されたmongodインスタンスを使用することは推奨されておらず、3.2 以降の構成サーバーは (デフォルトで) レプリカ セットとしてデプロイされます。レプリカ セット構成サーバーは、WiredTiger 3.2+ ストレージ エンジン (または新しいreadConcern読み取り分離セマンティクスをサポートする別のストレージ エンジン) を使用する必要があります。また、CSRSは、シャード クラスター メタデータのユース ケースに適さない一部のデフォルト以外のレプリカ セット構成オプション (例: 、および ) をarbiterOnly許可buildIndexesしません。slaveDelay
CSRS の導入により、構成サーバーの一貫性と可用性が向上します。これは、MongoDB が構成データのシャーディングに標準のレプリカ セットの読み取りおよび書き込みプロトコルを利用できるためです。さらに、レプリカ セットには最大 50 のメンバーを含めることができるため (MongoDB 3.2 のように)、シャード クラスターに 3 つ以上の構成サーバーを含めることができます。
CSRS 展開では、書き込みの可用性は、レプリカ セットの現在のプライマリを確認できるメンバーのクォーラムを維持することに依存します。たとえば、3 ノードのレプリカ セットでは、プライマリを維持するために 2 つの利用可能なメンバーが必要になります。通常のレプリカ セットと同じ選択ルールに従って、フォールト トレランスを向上させるために追加のメンバーを追加できます。ofは、シャードされたクラスター メタデータが大多数のレプリカ セット メンバーにコミットされた後にのみ読み取れるようにするために使用され、ofは要求を最も近い構成サーバーにルーティングするために使用されます。readConcernmajoritymongosreadPreferencenearest