コンフィギュレーションサーバー
項目一覧
重要
非推奨のミラー化された mongod インスタンスをコンフィギュレーションサーバー（SCCC）として使用することはサポートされなくなりました。シャーディングされたクラスターを 3.4 にアップグレードする前に、コンフィギュレーションサーバーを SCCC から CSRS に変換する必要があります。
コンフィギュレーションサーバーを SCCC から CSRS に変換するには、MongoDB 3.4 マニュアル「コンフィギュレーションサーバーをレプリカセットにアップグレードする」を参照してください。
コンフィギュレーションサーバーは、シャーディングされたクラスターのメタデータをストアします。メタデータは、シャーディングされたクラスター内のすべてのデータとコンポーネントの状態と組織を反映します。メタデータには、各シャード上のチャンクのリストと、チャンクを定義する範囲が含まれます。
mongos インスタンスはこのデータをキャッシュし、それを使用して読み取りおよび書き込み操作を正しいシャードにルーティングします。mongos は、シャードの追加など、クラスターのメタデータが変更されたときにキャッシュをアップデートします。シャードは、コンフィギュレーションサーバーからチャンクのメタデータも読み取ります。
コンフィギュレーションサーバーには、 ロールベースのアクセス制御 やクラスターの 内部認証 設定など の 自己管理型配置の認証 構成情報も保存されます。
MongoDB は、分散されたロックの管理にもコンフィギュレーションサーバーを使用します。
各シャーディングされたクラスターには独自のコンフィギュレーションサーバーが必要です。異なるシャーディングされたクラスターに、同じコンフィギュレーションサーバーを使用しないでください。
警告
コンフィギュレーションサーバーで実行される管理操作は、シャーディングされたクラスターのパフォーマンスと可用性に大きな影響を与える可能性があります。影響を受けるコンフィギュレーションサーバーの数に応じて、クラスターは一定期間読み取り専用になるか、オフラインになる場合があります。
レプリカセットのコンフィギュレーションサーバー
バージョン 3.4 で変更。
シャーディングされたクラスターのコンフィギュレーションサーバーは、レプリカセット（CSRS） としてデプロイできます。コンフィギュレーションサーバーにレプリカセットを使用すると、複数のコンフィギュレーションサーバー間での整合性を高めることができます。これは、MongoDB がコンフィギュレーションデータに対して標準レプリカセットの読み取りおよび書き込みプロトコルを利用できるためです。さらに、コンフィギュレーションサーバーにレプリカセットを使用すると、レプリカセット 1 つに最大 50 ノードを含めることができるため、シャーディングされたクラスターに 3 台を超えるコンフィギュレーションサーバーを設定することができます。コンフィギュレーションサーバーをレプリカセットとして展開するには、コンフィギュレーションサーバーによりWiredTiger ストレージ エンジンが実行されている必要があります。
次の制限は、コンフィギュレーションサーバーに使用するレプリカセット構成に適用されます。
インデックスを構築する必要があります（つまり、どのノードも
members[n].buildIndexes設定を false に設定しないでください。）
コンフィギュレーションサーバーでの読み取りおよび書き込み操作
admin データベースとコンフィギュレーションデータベースはコンフィギュレーションサーバーにあります。
コンフィギュレーションサーバーへの書き込み
admin データベースには、認証と承認に関連するコレクションと、内部使用のためのその他のシステム* コレクションが含まれています。
コンフィギュレーションデータベースには、シャーディングされたクラスターのメタデータを含むコレクションが含まれています。MongoDB では、 チャンクの移行後やチャンクの分裂後など、メタデータに変更があった場合に、データが コンフィギュレーションデータベースに書き込まれます。
ユーザーは、通常の操作またはメンテナンスの過程でコンフィギュレーションデータベースに直接書き込むのを避ける必要があります。
コンフィギュレーションサーバーに書き込む場合、MongoDB は "majority" の書込み保証（write concern）を使用します。
コンフィギュレーションサーバーからの読み取り
MongoDB は、認証データおよび承認データやその他の内部使用のために admin データベースから読み取りを行います。
MongoDB は、mongos の開始時、またはチャンクの移行後などメタデータの変更後に、config データベースから読み取りを行います。シャードは、コンフィギュレーションサーバーからチャンクのメタデータも読み取ります。
レプリカセット コンフィギュレーションサーバーから読み取る場合、MongoDB は "majority" の読み取り保証（read concern）レベルを使用します。
コンフィギュレーションサーバーの可用性
コンフィギュレーションサーバーのレプリカセットがプライマリを失い、プライマリを選出できない場合、クラスターのメタデータは読み取り専用になります。シャードからのデータの読み取りと書き込みは引き続き可能ですが、レプリカセットがプライマリを選出できるようになるまで、チャンクの移行やチャンクの分裂は行われません。
シャーディングされたクラスターでは、 mongodおよびmongosインスタンスがシャーディングされたクラスター内のレプリカセットを監視します（例：シャード レプリカセット、コンフィギュレーションサーバー レプリカセット）。
すべてのコンフィギュレーションサーバーが使用できなくなると、クラスターが操作不能になる可能性があります。コンフィギュレーションサーバーが使用可能で完全であることを確保するには、コンフィギュレーションサーバーのバックアップが不可欠です。コンフィギュレーションサーバーのデータは、クラスターにストアされているデータに比べて小さく、コンフィギュレーションサーバーのアクティビティ負荷は比較的低くなっています。
詳細については、「コンフィギュレーションサーバーのレプリカセット ノードが使用できなくなる」を参照してください。
シャーディングされたクラスターのメタデータ
コンフィギュレーションサーバーは、コンフィギュレーションデータベースにメタデータを保存します。
重要
コンフィギュレーションサーバーのメンテナンスを行う前は、必ず config データベースをバックアップしてください。
configデータベースにアクセスするには、 mongoshで次のコマンドを実行します。
use config
一般に、config データベースの内容は、直接編集しないでください。config データベースには以下のコレクションがあります。
これらのコレクションとシャーディングされたクラスターでのそのロールの詳細については、 コンフィギュレーションデータベースを参照してください。 メタデータの読み取りおよびアップデートの詳細については、「 コンフィギュレーションサーバーでの読み取りおよび書込み操作」を参照してください。
シャーディングされたクラスターのセキュリティ
自己管理型内部認証とメンバーシップ認証を使用してクラスター内のセキュリティを強化し、不正なクラスター コンポーネントがクラスターにアクセスするのを防ぎます。 内部認証を強制するには、クラスター内の各mongodを適切なセキュリティ設定で起動する必要があります。
MongoDB 5.3 以降では、クラスター内認証に SCRAM-SHA-1 は使用できません。SCRAM-SHA-256 のみがサポートされます。
前の MongoDB バージョンでは、SCRAM が明示的に有効になっていなくても、SCRAM-SHA-1 と SCRAM-SHA-256 の両方をクラスター内認証に使用できます。
安全なシャーディングされたクラスターの配置に関するチュートリアルについては、 「 キーファイル認証による自己管理型シャーディングされたクラスターの配置 」を参照してください。