sql >> データベース >  >> NoSQL >> MongoDB

なぜMongoDB構成サーバーは1つまたは3つだけでなければならないのですか?

    構成サーバープロトコル

    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 majoritymongosによって使用されます シャーディングされたクラスターメタデータが、レプリカセットメンバーの大部分とreadPreferenceにコミットされた場合にのみ、読み取れるようにするため nearestの リクエストを最も近い構成サーバーにルーティングするために使用されます。




    1. Microsoft.Extensions.Cashing.RedisとMicrosoft.Extensions.Caching.StackExchangeRedis.RedisCacheの違い

    2. Rails Mongoidモデルのクエリ結果は、limitを使用している場合でも、間違ったサイズ/長さ/カウント情報を返します

    3. CODとCMLを使用して、株式データを予測するアプリケーションを構築する

    4. あなたのビジネスに最適なMongoDBホスティングを選択する方法