MongoDB mongos インスタンスは、シャーディングされたクラスター内のシャードにクエリと書込み操作をルーティングします。mongos は、アプリケーションの観点から見ると、シャーディングされたクラスターへの唯一のインターフェースを提供します。アプリケーションはシャードに直接接続したり通信したりすることはありません。
mongos はコンフィギュレーションサーバーからメタデータをキャッシュすることで、どのデータがどのシャードにあるかを追跡します。mongos はメタデータを使用して、アプリケーションとクライアントからの操作を mongod インスタンスにルーティングします。mongos には永続的な状態がなく、最小限のシステム リソースを消費します。
最も一般的な方法は、アプリケーション サーバーと同じシステムで mongos インスタンスを実行することですが、mongos インスタンスはシャードやその他の専用リソースで管理できます。「mongos の数とディストリビューション」も参照してください。
ルーティングと結果プロセス
mongos インスタンスは、次の方法でクエリをクラスターにルーティングします。
クエリを受信する必要があるシャードのリストを決定します。
対象となるすべてのシャードにカーソルを確立します。
The mongos then merges the data from each of the targeted shards and returns the result document. Certain query modifiers, such as sorting, are performed on each shard before mongos retrieves the results.
複数のシャードで実行中の集計操作では、データベースのプライマリ シャードで実行する必要がない場合、結果を mongos にルーティングして結果をマージできます。
パイプラインが mongos で実行できない場合が 2 つあります。
最初のケースは、分裂パイプラインのマージ部分に、プライマリ シャードで実行する必要があるステージが含まれている場合です。たとえば、$lookup が、集計が実行されているシャーディングされたコレクションと同じデータベース内でシャーディングされていないコレクションにアクセスする必要がある場合、マージはプライマリ シャードで実行する必要があります。
2 つ目のケースは、分裂パイプラインのマージ部分に $group などの一時データをディスクに書き込む可能性のあるステージがあり、クライアントが allowDiskUse:true を指定している場合です。この場合、マージ パイプラインにプライマリ シャードを必要とするステージが他にないと仮定すると、マージは、集計の対象となるシャードのセットからランダムに選択されたシャードで実行されます。
シャーディングされたクラスター クエリのコンポーネント間で集計作業がどのように分裂されるかについての詳細は、aggregate() 呼び出しのパラメーター explain:true を使用してください。リターンには3つの json オブジェクトが含まれます。mergeType はマージのステージがどこで行われるかを示します（"primaryShard"、"anyShard"、または "mongos"）。splitPipeline には、パイプライン内のどの操作が個々のシャードで実行されたかが示されます。shards は、各シャードが行った作業を示します。
シャードキー、またはシャードキーのプレフィックスがクエリの一部になっている場合は、mongosでターゲット操作が実行され、クエリをクラスター内のシャードのサブセットにルーティングします。
mongos performs a broadcast operation for queries that do not include the shard key, routing queries to all shards in the cluster. Some queries that do include the shard key may still result in a broadcast operation depending on the distribution of data in the cluster and the selectivity of the query.
ターゲット操作とブロードキャスト操作の詳細については、「ターゲット操作とブロードキャスト操作」を参照してください。
mongos レイテンシを最小限に抑えるためにヘッジされた読み取りをサポートできます。詳細については、「ヘッジされた読み取り」を参照してください。
mongos のクエリ修飾子の処理方法
ソート
クエリの結果がソートされていない場合、mongos インスタンスは、シャード上のすべてのカーソルから "round robins" の結果を示す結果カーソルを開きます。
制限
クエリで limit() カーソル メソッドを使用して結果セットのサイズを制限する場合、mongos インスタンスはその制限をシャードに渡し、結果をクライアントに返す前に、制限を結果に再適用します。
スキップ
クエリが skip() カーソル メソッドを使用してスキップするレコードの数を指定する場合、mongos はスキップをシャードに渡すことができませんが、シャードからスキップされていない結果を検索し、完全な結果を組み立てるときに適切な数のドキュメントをスキップします。
limit() と組み合わせて使用すると、mongos は制限と skip() の値をシャードに渡し、これらの操作の効率を向上させます。
読み込み設定（read preference）とシャード
シャーディングされたクラスターの場合、mongos はシャードから読み取るときに読み込み設定（read preference）を適用します。選択されたノードは、読み込み設定（read preference）と replication.localPingThresholdMs 設定の両方によって制御され、操作ごとに再評価されます。
読み込み設定（read preference）とシャーディングされたクラスターの詳細については、「読み込み設定（read preference）とシャード」を参照してください。
ヘッジされた読み取り
mongosインスタンスは、 primaryの 読み込み設定（ read preference ） を使用する読み取りをヘッジできます。 ヘッジされた読み取りでは、 mongosインスタンスは読み取り操作をクエリされたシャードごとに 2 つのレプリカセット ノードにルーティングし、シャードごとに最初の応答のある から結果を返します。 読み取り操作をヘッジする ために送信される追加の読み取りでは、 maxTimeMSForHedgedReads のmaxTimeMS値が使用され 。
ヘッジされた読み取りは、以下の操作でサポートされています。
ヘッジされた読み取りと読み込み設定（read preference）
ヘッジされた読み取りは、読み込み設定（read preference）の一部として操作ごとに指定されます。primary 以外の読み込み設定（read preference）では、ヘッジされた読み取りがサポートされます。ヘッジされた読み込み設定（read preference）オプションを参照してください。
primary以外の読み込み設定（read preference）でヘッジされた読み取りを指定するには、「 ドライバーの読み込み設定（ read preference）API ドキュメント 」を参照してください。読み込み設定（read preference）の
nearestでは、デフォルトでヘッジされた読み取りオプションが有効になります。
読み込み設定（read preference）、シャーディングされたクラスター、およびノード選択の詳細については、「読み込み設定（read preference）とシャード」を参照してください。
ヘッジされた読み取りのサポートの有効化と無効化
デフォルトでは、mongos インスタンスはヘッジされた読み取りの使用をサポートしています。mongos インスタンスのヘッジされた読み取りのサポートをオフにするには、readHedgingMode パラメーターを参照してください。ヘッジされた読み取りのサポートが off の場合、読み込み設定（read preference）に指定された hedge オプションに関係なく、mongos はヘッジされた読み取りを使用しません。
ヘッジされた読み取りの診断
The command serverStatus and its corresponding mongosh method db.serverStatus() return hedgingMetrics.
mongos インスタンスへの接続を確認
クライアントが接続している MongoDB インスタンスが mongos であるかどうかを検出するには、hello コマンドを使用します。クライアントが mongos に接続すると、hello は 文字列isdbgrid を保持する msg フィールドのあるドキュメントを返します。例:
{ "isWritablePrimary" : true, "msg" : "isdbgrid", "maxBsonObjectSize" : 16777216, "ok" : 1, ... }
アプリケーションが、代わりに mongod に接続されている場合、返されるドキュメントには isdbgrid 文字列が含まれません。
ターゲットを絞った操作とブロードキャスト操作
一般的に、シャーディングされた環境で最速のクエリは、mongos シャードキー と コンフィギュレーション サーバー からのクラスター メタデータを使用して、 が単一のシャードにルーティングするクエリです。これらのターゲット操作では、シャードキー値を使用して、クエリ ドキュメントを満たすシャードまたはシャードのサブセットを検索します。
シャードキーを含まないクエリでは、mongos はすべてのシャードをクエリし、その応答を待ってから、結果をアプリケーションに返す必要があります。これらの "スキャッター ギャザー" クエリは、長時間実行される操作になる可能性があります。
ブロードキャスト操作
mongos インスタンスは、このデータをストアしているシャードまたはシャードのサブセットを mongos が特定できる場合を除き、コレクションのすべてのシャードにクエリをブロードキャストします。
mongosがすべてのシャードから応答を受け取った後、データがマージされ、結果ドキュメントが返されます。ブロードキャスト操作のパフォーマンスは、クラスターにかかる全体的な負荷のほか、ネットワークレイテンシ、個々のシャードの負荷、シャードごとに返されるドキュメントの数などの変数によって異なります。可能な限り、ブロードキャスト操作につながる操作よりもターゲット操作につながるものを優先してください。
マルチ アップデート操作は、常にブロードキャスト操作です。
クエリ ドキュメントでシャードキーが完全に指定されている場合を除き、updateMany() メソッドと deleteMany() メソッドはブロードキャスト操作です。
対象とする操作
mongos は、シャードキーまたは複合シャードキーのプレフィックスを含むクエリを、特定のシャードまたはシャードのセットにルーティングできます。mongos はシャードキー値を使用して、その範囲にシャードキー値が含まれるチャンクを見つけ、そのチャンクを含むシャードにクエリを送信します。
たとえば、シャードキーが次の場合:
{ a: 1, b: 1, c: 1 }
mongos プログラムは、特定のシャードまたはシャードのセットで、完全なシャードキーまたは次のいずれかのシャードキー プレフィックスを含むクエリをルーティングできます。
{ a: 1 } { a: 1, b: 1 }
すべての insertOne() 操作は 1 つのシャードを対象とします。insertMany() 配列の各ドキュメントは 1 つのシャードを対象としていますが、配列内のすべてのドキュメントが 1 つのシャードに挿入される保証はありません。
すべての updateOne()、replaceOne()、および deleteOne() 操作には、クエリ ドキュメントにシャードキーまたは _id を含める必要があります。これらのメソッドを、シャードキーまたは _id なしで使用すると、MongoDB はエラーを返します。
クラスター内のデータの分散とクエリの選択性によっては、mongosではこれらのクエリを実行するためにブロードキャスト操作が実行される場合があります。
インデックスの使用
シャードはクエリを受け取ると、利用可能で最も効率的なインデックスを使用してそのクエリを実行します。使用されるインデックスは、シャードキー インデックスか、シャードに存在する別の適格なインデックスのいずれかです。
シャーディングされたクラスターのセキュリティ
自己管理型内部認証とメンバーシップ認証を使用してクラスター内のセキュリティを強化し、不正なクラスター コンポーネントがクラスターにアクセスするのを防ぎます。 内部認証を強制するには、クラスター内の各mongodまたはmongosを適切なセキュリティ設定で起動する必要があります。
MongoDB 5.3 以降では、クラスター内認証に SCRAM-SHA-1 は使用できません。SCRAM-SHA-256 のみがサポートされます。
前の MongoDB バージョンでは、SCRAM が明示的に有効になっていなくても、SCRAM-SHA-1 と SCRAM-SHA-256 の両方をクラスター内認証に使用できます。
セキュアなシャーディングされたクラスターの配置に関するチュートリアルについては、自己管理型シャーディングされたクラスターのキーファイル認証を参照してください。
クラスター ユーザー
シャーディングされたクラスターは、クラスター データおよび操作への不正アクセスを制限するための 自己管理型配置のロールベース アクセス制御（RBAC）をサポートしています。 RBAC--auth を強制するには、 コンフィギュレーションサーバーmongod を含むクラスター内の各 を、 オプションで起動する必要があります。あるいは、クラスター間のセキュリティのために自己管理型内部認証とメンバーシップ認証を強制すると、RBAC を介したユーザー アクセス制御も可能になります。
With RBAC enforced, clients must specify a --username, --password, and --authenticationDatabase when connecting to the mongos in order to access cluster resources.
各クラスターには、独自のクラスター ユーザーがいます。これらのユーザーを、個々のシャードにアクセスするために使用することはできません。
RBAC 対応の MongoDB 配置にユーザーを追加できるようにするチュートリアルについては、 「 自己管理型配置でアクセス制御を有効にする 」を参照してください。
メタデータ操作
mongos では、シャーディングされたクラスターのメタデータに影響する次の操作に対して "majority" 書き込み保証（write concern）を使用します。
詳細情報
fCV 互換性
mongosmongodバイナリは、機能の互換性バージョン（FCV）が よりも大きいmongos インスタンスに接続できません。例、 MongoDB 4 は接続できません。0 バージョンmongos 4から.2FCV 4が. に設定されているシャーディングされたクラスター。2ただし、 MongoDB 4 を接続することは可能です。0 バージョンmongos 4から.2FCV 4が. に設定されているシャーディングされたクラスター。0
フルタイムの診断データキャプチャ要件
mongod は、デプロイに関するトラブルシューティングを行う MongoDB エンジニアを支援するために、フルタイム診断データ取得メカニズムを備えています。このスレッドが失敗すると、元のプロセスが終了します。特に一般的な障害を回避するには、プロセスを実行しているユーザーに FTDC diagnostic.data ディレクトリを作成する権限があることを確認します。mongod の場合、このディレクトリは storage.dbPath 内にあります。mongos の場合は、systemLog.path と同じ階層にあります。
接続プール
MongoDB 4.2 以降では、MongoDB にパラメーター ShardingTaskExecutorPoolReplicaSetMatching が追加されました。このパラメーターは、シャーディングされたクラスターの各ノードに対する mongod インスタンスと mongos インスタンスの接続プールの最小サイズを決定します。この値は、実行中に変化する可能性があります。
mongod と mongos は、シャーディングされたクラスター内の各レプリカセットに対して、各レプリカセット セカンダリへの接続プールを維持します。デフォルトでは、これらのプールはプライマリへの接続数以上の接続数を保持します。
変更するには、「ShardingTaskExecutorPoolReplicaSetMatching」を参照してください。
クラスターでの集計パイプラインの使用
シャーディングと集計の連携方法に関する詳細については、『Practical MongoDB Aggregations』（電子書籍）のシャーディングの章をお読みください。