コンフィギュレーションサーバー
項目一覧
コンフィギュレーションサーバーは、 のシャーディングされたクラスターのメタデータを保存します。 メタデータは、シャーディングされたクラスター内のすべてのデータとコンポーネントの状態と組織を反映します。 メタデータには、各シャード上のチャンクのリストと、チャンクを定義する範囲が含まれます。
mongosインスタンスはこのデータをキャッシュし、それを使用して読み取りおよび書込み操作を正しいシャードにルーティングします。 mongosは、 シャードの追加など、クラスターのメタデータが変更されたときにキャッシュをアップデートします。 シャードは、コンフィギュレーションサーバーからチャンクのメタデータも読み取ります。
コンフィギュレーションサーバーには、 ロールベースのアクセス制御 やクラスターの 内部認証 設定など の 自己管理型配置の認証 構成情報も保存されます。
MongoDB は、分散されたロックの管理にもコンフィギュレーションサーバーを使用します。
各シャーディングされたクラスターには独自のコンフィギュレーションサーバーが必要です。異なるシャーディングされたクラスターに、同じコンフィギュレーションサーバーを使用しないでください。
警告
コンフィギュレーションサーバーで実行される管理操作は、シャーディングされたクラスターのパフォーマンスと可用性に大きな影響を与える可能性があります。影響を受けるコンフィギュレーションサーバーの数に応じて、クラスターは一定期間読み取り専用になるか、オフラインになる場合があります。
MongoDB 8.0 以降では、通常のシャーディングされたクラスターのメタデータに加えて、アプリケーションデータを保存するようにコンフィギュレーションサーバーを構成できます。また、コンフィギュレーションサーバーはコンフィギュレーションシャードと呼ばれます。詳細については、このページの「 コンフィギュレーションシャード」セクションで後ほど説明します。
レプリカセットのコンフィギュレーションサーバー
次の制限は、コンフィギュレーションサーバーに使用するレプリカセット構成に適用されます。
インデックスを構築する必要があります（つまり、どのノードも
members[n].buildIndexes設定を false に設定しないでください。）
コンフィギュレーションサーバーでの読み取りおよび書き込み操作
adminデータベースとconfigデータベースはコンフィギュレーションサーバーにあります。
コンフィギュレーションサーバーへの書き込み
admin データベースには、認証と承認に関連するコレクションと、内部使用のためのその他のシステム* コレクションが含まれています。
configデータベースには、シャーディングされたクラスターのメタデータを含むコレクションが含まれています。 MongoDB では、チャンクの移行後やチャンクの分裂後など、メタデータに変更があった場合に、データがconfigデータベースに書き込まれます。
ユーザーは、通常の操作またはメンテナンスの過程でコンフィギュレーションデータベースに直接書き込むのを避ける必要があります。
コンフィギュレーションサーバーに書き込む場合、MongoDB は "majority" の書込み保証（write concern）を使用します。
コンフィギュレーションサーバーからの読み取り
MongoDB は、認証データおよび承認データやその他の内部使用のために admin データベースから読み取りを行います。
MongoDB は、mongos の開始時、またはチャンクの移行後などメタデータの変更後に、config データベースから読み取りを行います。シャードは、コンフィギュレーションサーバーからチャンクのメタデータも読み取ります。
レプリカセット コンフィギュレーションサーバーから読み取る場合、MongoDB は "majority" の読み取り保証（read concern）レベルを使用します。
メタデータビューは最新である必要があります
操作を成功させるには、特定のシャード ノードのメタデータのビューが最新である必要があります。 シャードとリクエストを発行する ルーターは、同じバージョンのチャンク メタデータを持っている必要があります。
メタデータが最新でない場合、操作はStaleConfigエラーで失敗し、メタデータ更新プロセスがトリガーされます。 メタデータを更新すると、運用レイテンシが増加する可能性があります。
セカンダリでは、レプリケーションの遅延が大きい場合、メタデータの更新に長い時間がかかることがあります。 セカンダリ読み取りの場合は、レプリケーションラグの影響を最小限に抑えるためにmaxStalenessSecondsを設定します。
コンフィギュレーションサーバーの可用性
コンフィギュレーションサーバーのレプリカセットがプライマリを失い、プライマリを選出できない場合、クラスターのメタデータは読み取り専用になります。シャードからのデータの読み取りと書き込みは引き続き可能ですが、レプリカセットがプライマリを選出できるようになるまで、チャンクの移行やチャンクの分裂は行われません。
シャーディングされたクラスターでは、 mongodおよびmongosインスタンスがシャーディングされたクラスター内のレプリカセットを監視します（例：シャード レプリカセット、コンフィギュレーションサーバー レプリカセット）。
すべてのコンフィギュレーションサーバーが使用できなくなると、クラスターが操作不能になる可能性があります。コンフィギュレーションサーバーが使用可能で完全であることを確保するには、コンフィギュレーションサーバーのバックアップが不可欠です。コンフィギュレーションサーバーのデータは、クラスターにストアされているデータに比べて小さく、コンフィギュレーションサーバーのアクティビティ負荷は比較的低くなっています。
詳細については、「コンフィギュレーションサーバーのレプリカセット ノードが使用できなくなる」を参照してください。
シャーディングされたクラスターのメタデータ
コンフィギュレーションサーバーはconfigデータベースにメタデータを保存します。
重要
コンフィギュレーションサーバーのメンテナンスを行う前は、必ず 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 の両方をクラスター内認証に使用できます。
安全なシャーディングされたクラスターの配置に関するチュートリアルについては、 「 キーファイル認証による自己管理型シャーディングされたクラスターの配置 」を参照してください。
コンフィギュレーションシャード
バージョン8.0の新機能。
MongoDB 8.0以降では、次のことが可能です。
通常のシャーディングされたクラスターのメタデータに加えてアプリケーションデータを保存するようにコンフィギュレーションサーバーを設定する。アプリケーションデータを保存するコンフィギュレーションサーバーをコンフィギュレーションシャードと呼ぶ。
コンフィギュレーコンフィギュレーションサーバーの間で変換しコンフィギュレーションサーバー。
クラスターにはコンフィギュレーションサーバーが必要ですが、専用のコンフィギュレーションサーバーでなく、 コンフィギュレーションシャード にすることもできます。 コンフィギュレーションシャードを使用すると、必要なノードの数が減り、配置が簡素化されます。
アプリケーションに可用性と回復力の要件がある場合は、専用のコンフィギュレーションサーバーの配置を検討してください。 専用のコンフィギュレーションサーバーは、重要なクラスター操作に対して分離、専用リソース、一貫したパフォーマンスを提供します。
複数のシャーディングされたクラスターに同じコンフィギュレーションシャードを使用することはできません。
コマンド
専用のコンフィギュレーションコンフィギュレーションサーバーをコンフィギュレーションシャードとして実行するように構成するには、 transitionFromDedicatedConfigServerコマンドを実行します。
コンフィギュレーションシャードを専用のコンフィギュレーションコンフィギュレーションサーバーとして実行するように構成するには、 transitionToDedicatedConfigServerコマンドを実行します。
ユーザー
コンフィギュレーションシャード上に作成されたユーザーは、専用のコンフィギュレーションサーバー上に作成されたユーザーと同じ動作をします。
コンフィギュレーションシャード ID ドキュメント
コンフィギュレーションサーバーをコンフィギュレーションシャードとして識別するには、admin.system.version コレクションのドキュメントを調べます。この例では、shardName が 'config' に設定されています。
{ _id: 'shardIdentity', shardName: 'config', clusterId: ObjectId("<objectID>"), configsvrConnectionString: '<config server replica set connection string>', }
次の例では、管理データベース内の admin.system.version からシャード ID ドキュメントを取得します。
use admin db.system.version.find()
出力の抽出:
{ _id: 'shardIdentity', shardName: 'config', clusterId: ObjectId("6441bdd6779584849dcac095"), configsvrConnectionString: 'configRepl/localhost:27007' }
ダウングレード機能互換性バージョン
クラスタにコンフィギュレーションシャードがあり、機能互換性バージョンを 8.0 より前にダウングレードする必要がある場合は、mongos に接続してこの手順を実行します：
専用のコンフィギュレーションサーバーとして実行するようにコンフィギュレーションシャードを構成します。
コンフィギュレーションシャードを専用のコンフィギュレーションサーバーとして動作するように設定するには、transitionToDedicatedConfigServer を実行してください。
db.adminCommand( { transitionToDedicatedConfigServer: 1 } )
クラスタ内のすべてのデータベースを一覧表示する。
クラスター内のすべてのデータベースを一覧表示するには、listDatabases を実行してください。
db.adminCommand( { listDatabases: 1, nameOnly: true } )
admin データベースと config データベースを除外します。
データベースごとに、次の操作を行います。
データベース内のすべてのコレクションを一覧表示する。
データベース内のすべてのコレクションを一覧表示するには、listCollections を実行します。
db.adminCommand( { listCollections: 1, nameOnly: true, filter: { type: { $ne: "view" } } } )
system 以降のコレクションを除外します。
残りの各コレクションについて、次の操作を行います。
コレクションを新しいシャードに移動する。
コレクションを新しいシャードに移動するには、moveCollection を実行します。
db.adminCommand( { moveCollection: "<database>.<collection>", toShard: "<new shard>", } )
バランサーがシャーディングされたコレクションのデータをコンフィギュレーションサーバーから移動するのを待つ。
バランサーがシャーディングされたコレクションのデータをコンフィギュレーションサーバーから移動したことを確認するには、transitionToDedicatedConfigServer をもう一度実行します。
db.adminCommand( { transitionToDedicatedConfigServer: 1 } )
データ移動に成功した後の応答には state:
"completed" が含まれます。応答に state: "pendingDataCleanup" が含まれている場合は、少し待ってから、コマンド応答に state: "completed" が含まれるまで transitionToDedicatedConfigServer を呼び出し続けます。回答の総合的な詳細は、removeShard を参照してください。
機能の互換性バージョンを設定します。
機能の互換性バージョンを設定するには、setFeatureCompatibilityVersion を実行してください。
db.adminCommand( { setFeatureCompatibilityVersion: "7.0" } )