構成サーバープロトコル
MongoDB 3.0以前は、MongoDB 3.2以降のレガシーSCCC(同期クラスター接続構成)と呼ばれる単一タイプの構成サーバー展開プロトコルのみをサポートします。 SCCCデプロイメントには、1つの構成サーバー(開発のみ)または3つの構成サーバー(本番)があります。
MongoDB 3.2は、SCCCプロトコルを廃止し、新しいデプロイメントタイプであるレプリカセットとしてのサーバーの構成(CSRS)をサポートします。 CSRSデプロイメントには、標準のレプリカセットと同じ制限があり、MongoDB 3.2の場合と同様に、1つの構成サーバー(開発のみ)または最大50のサーバー(本番)を持つことができます。実稼働環境での高可用性を実現するには、少なくとも3台のCSRSサーバーが推奨されますが、地理的に分散した導入には追加のサーバーが役立つ場合があります。
SCCC(同期クラスター接続構成)
SCCCでは、構成サーバーは2フェーズコミット を使用して更新されます。 トランザクションのために複数のサーバーからのコンセンサスを必要とするプロトコル。テスト/開発の目的で単一の構成サーバーを使用できますが、本番環境では常に3つ必要です。MongoDBで2つ(または3つ以上)のサーバーしか使用できない理由の実際的な答えは、MongoDBコードベースのみ SCCC構成用に1つまたは3つの構成サーバーをサポートします。
3台のサーバーは、2台のサーバーよりも一貫性をより強力に保証し、mongos
で2台のサーバーを使用できる状態で、1台の構成サーバーでのメンテナンスアクティビティ(バックアップなど)を可能にします。 クエリします。サーバーが3つを超えると、すべてのサーバー間でデータをコミットするために必要な時間が長くなります。
シャーディングされたクラスターのメタデータは、すべての構成サーバーで同一である必要があり、MongoDBシャーディングの実装によって維持されます。メタデータには、現在どのシャードがドキュメントの範囲(別名chunks
)を保持しているかの重要な詳細が含まれています )。 SCCC構成では、構成サーバーはではありません レプリカセットであるため、1つ以上の構成サーバーがオフラインの場合、構成データは読み取り専用になります。そうでない場合、オフラインの構成サーバーがオンラインに戻ったときにデータを伝播する手段がありません。
明らかに、1つの構成サーバーは冗長性やバックアップを提供しません。 2つの構成サーバーの場合、潜在的な障害シナリオは、サーバーは使用可能であるが、サーバー上のデータが一致しない場合です(たとえば、サーバーの1つにデータ破損があった場合)。 3つの構成サーバーを使用すると、前のシナリオを改善できます。2/3のサーバーは一貫している可能性があり、奇数のサーバーを特定できます。
CSRS(レプリカセットとしての構成サーバー)
MongoDB 3.2は、ミラーリングされた3つのmongod
の使用を廃止します 構成サーバーのインスタンス、および3.2以降の構成サーバーは、(デフォルトで)レプリカセットとしてデプロイされます。レプリカセット構成サーバーは、WiredTiger 3.2以降のストレージエンジン(または新しい readConcern
読み取り分離セマンティクス)。 CSRSは、デフォルト以外のレプリカセット構成オプション(arbiterOnly
など)も許可していません。 、buildIndexes
、およびslaveDelay
)シャードクラスターメタデータのユースケースには不適切です。
MongoDBは、構成データをシャーディングするための標準のレプリカセットの読み取りおよび書き込みプロトコルを利用できるため、CSRSの展開により、構成サーバーの整合性と可用性が向上します。さらに、これにより、レプリカセットには最大50のメンバーを含めることができるため、シャードクラスターに3つを超える構成サーバーを含めることができます(MongoDB 3.2の場合と同様)。
CSRSデプロイメントでは、書き込みの可用性は、レプリカセットの現在のプライマリを表示できるメンバーのクォーラムを維持することに依存します。たとえば、3ノードのレプリカセットでは、プライマリを維持するために2つの使用可能なメンバーが必要になります。 フォールトトレランスを改善するために、メンバーを追加できます 、同じ選挙規則
に従います。 通常のレプリカセットとして。 readConcern
majority
の mongos
によって使用されます シャーディングされたクラスターメタデータが、レプリカセットメンバーの大部分とreadPreference
にコミットされた場合にのみ、読み取れるようにするため nearest
の リクエストを最も近い構成サーバーにルーティングするために使用されます。