On this page
mongos instances route queries and write operations to shards in a sharded cluster.
mongos provide the only interface to a sharded cluster from the perspective of applications. Applications never connect or communicate directly with the shards.
mongos tracks what data is on which shard by caching the metadata from the config servers. The
mongos uses the metadata to route operations from applications and clients to the
mongod instances. A
mongos has no persistent state and consumes minimal system resources.
- Determining the list of shards that must receive the query.
- Establishing a cursor on all targeted shards.
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.
Changed in version 3.6: For aggregation operations that run on multiple shards, if the operations do not require running on the database’s primary shard, these operations may route the results back to the
mongos where the results are then merged.
There are two cases in which a pipeline is ineligible to run on
The first case occurs when the merge part of the split pipeline contains a stage which must run on a primary shard. For instance, if
$lookup requires access to an unsharded collection in the same database as the sharded collection on which the aggregation is running, the merge is obliged to run on the primary shard.
The second case occurs when the merge part of the split pipeline contains a stage which may write temporary data to disk, such as
$group, and the client has specified
allowDiskUse:true. In this case, assuming that there are no other stages in the merge pipeline which require the primary shard, the merge will run on a randomly-selected shard in the set of shards targeted by the aggregation.
For more information on how the work of aggregation is split among components of a sharded cluster query, use
explain:true as a parameter to the
aggregation() call. The return will include three json objects.
mergeType shows where the stage of the merge happens (“primaryShard”, “anyShard”, or “mongos”).
splitPipeline shows which operations in your pipeline have run on individual shards.
shards shows the work each shard has done.
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.
See Targeted Operations vs. Broadcast Operations for more on targeted and broadcast operations.
If the result of the query is not sorted, the
mongos instance opens a result cursor that “round robins” results from all cursors on the shards.
If the query limits the size of the result set using the
limit() cursor method, the
mongos instance passes that limit to the shards and then re-applies the limit to the result before returning the result to the client.
If the query specifies a number of records to skip using the
skip() cursor method, the
mongos cannot pass the skip to the shards, but rather retrieves unskipped results from the shards and skips the appropriate number of documents when assembling the complete result.
To detect if the MongoDB instance that your client is connected to is
mongos, use the
isMaster command. When a client connects to a
isMaster returns a document with a
msg field that holds the string
isdbgrid. For example:
If the application is instead connected to a
mongod, the returned document does not include the
Generally, the fastest queries in a sharded environment are those that
mongos route to a single shard, using the shard key and the cluster meta data from the config server. These targeted operations use the shard key value to locate the shard or subset of shards that satisfy the query document.
For queries that don’t include the shard key,
mongos must query all shards, wait for their responses and then return the result to the application. These “scatter/gather” queries can be long running operations.
mongos receives responses from all shards, it merges the data and returns the result document. The performance of a broadcast operation depends on the overall load of the cluster, as well as variables like network latency, individual shard load, and number of documents returned per shard. Whenever possible, favor operations that result in targeted operation over those that result in a broadcast operation.
Multi-update operations are always broadcast operations.
mongos can route queries that include the shard key or the prefix of a compound shard key a specific shard or set of shards.
mongos uses the shard key value to locate the chunk whose range includes the shard key value and directs the query at the shard containing that chunk.
For example, if the shard key is:
mongos program can route queries that include the full shard key or either of the following shard key prefixes at a specific shard or set of shards: