mongos

MongoDB mongos instances route queries and write operationsto shards in a sharded cluster. mongos provide theonly interface to a sharded cluster from the perspective ofapplications. Applications never connect or communicate directly withthe shards.

The mongos tracks what data is on which shard by cachingthe metadata from the config servers. The mongos uses themetadata to route operations from applications and clients to themongod instances. A mongos has no _persistent_state and consumes minimal system resources.

The most common practice is to run mongos instances on thesame systems as your application servers, but you can maintainmongos instances on the shards or on other dedicatedresources.

Routing And Results Process

A mongos instance routes a query to a cluster by:

• Determining the list of shards that must receive thequery.
• Establishing a cursor on all targeted shards.The mongos then merges the data from each of thetargeted shards and returns the result document. Certainquery modifiers, such as sorting,are performed on a shard such as the primary shard beforemongos retrieves the results.

Changed in version 3.6: For aggregation operations thatrun on multiple shards, if the operations do not require running onthe database’s primary shard, these operations may route theresults back to the mongos where the results are thenmerged.

There are two cases in which a pipeline is ineligible to run onmongos.

The first case occurs when the merge part of the split pipelinecontains a stage which must run on a primary shard. For instance,if $lookup requires access to an unsharded collection in the samedatabase 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 pipelinecontains a stage which may write temporary data to disk, such as$group, and the client has specified allowDiskUse:true. In thiscase, assuming that there are no other stages in the merge pipelinewhich require the primary shard, the merge will run on arandomly-selected shard in the set of shards targeted by theaggregation.

For more information on how the work of aggregation is split amongcomponents of a sharded cluster query, use explain:true as aparameter to the aggregation() call. Thereturn will include three json objects. mergeType shows where thestage of the merge happens (“primaryShard”, “anyShard”, or “mongos”).splitPipeline shows which operations in your pipeline have run onindividual shards. shards shows the work each shard has done.

In some cases, when the shard key or a prefix of the shard keyis a part of the query, the mongos performs atargeted operation, routing queries toa subset of shards in the cluster.

mongos performs a broadcastoperation for queries that do not include theshard key, routing queries to all shards in the cluster. Somequeries that do include the shard key may still result in a broadcastoperation depending on the distribution of data in the cluster and theselectivity of the query.

See Targeted Operations vs. Broadcast Operations for more on targeted andbroadcast operations.

How mongos Handles Query Modifiers

Sorting

If the result of the query is not sorted, the mongosinstance opens a result cursor that “round robins” results from allcursors on the shards.

Limits

If the query limits the size of the result set using thelimit() cursor method, the mongosinstance passes that limit to the shards and then re-applies the limitto the result before returning the result to the client.

Skips

If the query specifies a number of records to skip using theskip() cursor method, the mongos_cannot_pass the skip to the shards, but rather retrieves unskipped resultsfrom the shards and skips the appropriate number of documents when assemblingthe complete result.

When used in conjunction with a limit(), themongos will pass the limit plus the value of theskip() to the shards to improve the efficiency of theseoperations.

Confirm Connection to mongos Instances

To detect if the MongoDB instance that your client is connectedto is mongos, use the isMaster command. When aclient connects to a mongos, isMaster returnsa document with a msg field that holds the stringisdbgrid. For example:

{
   "ismaster" : true,
   "msg" : "isdbgrid",
   "maxBsonObjectSize" : 16777216,
   "ok" : 1,
   ...
}

If the application is instead connected to a mongod, thereturned document does not include the isdbgrid string.

Targeted Operations vs. Broadcast Operations

Generally, the fastest queries in a sharded environment are those thatmongos route to a single shard, using the shard key and thecluster meta data from the config server.These targeted operations use theshard key value to locate the shard or subset of shards that satisfy thequery document.

For queries that don’t include the shard key, mongos must query allshards, wait for their responses and then return the result to theapplication. These “scatter/gather” queries can be long running operations.

Broadcast Operations

mongos instances broadcast queries to all shards for thecollection unless the mongos candetermine which shard or subset of shards stores this data.

After the mongos receives responses from all shards, it mergesthe data and returns the result document. The performance of a broadcastoperation depends on the overall load of the cluster, as well as variableslike network latency, individual shard load, and number of documents returnedper shard. Whenever possible, favor operations that result in targetedoperation over those that result in a broadcastoperation.

Multi-update operations are always broadcast operations.

The updateMany() anddeleteMany() methods are broadcastoperations, unless the query document specifies the shard key in full.

Targeted Operations

mongos can route queries that include the shard key or the prefixof a compound shard key a specific shard or set ofshards. mongos uses the shard key value to locate thechunk whose range includes the shard key value and directs thequery at the shard containing that chunk.

For example, if the shard key is:

{ a: 1, b: 1, c: 1 }

The mongos program can route queries that include the fullshard key or either of the following shard key prefixes at aspecific shard or set of shards:

{ a: 1 }
{ a: 1, b: 1 }

All insertOne() operations target to one shard. Eachdocument in the insertMany() array targets to asingle shard, but there is no guarantee all documents in the array insert intoa single shard.

All updateOne(),replaceOne() and deleteOne()operations must include the shard key or _id in the querydocument. MongoDB returns an error if these methods are used withoutthe shard key or _id.

Depending on the distribution of data in the cluster and the selectivity ofthe query, mongos may still perform a broadcastoperation to fulfill these queries.

Index Use

If the query does not include the shard key, themongos must send the query to all shards as a“scatter/gather” operation. Each shard will, in turn, use either theshard key index or another more efficient index to fulfill the query.

If the query includes multiple sub-expressions that reference thefields indexed by the shard key and the secondary index, themongos can route the queries to a specific shard and theshard will use the index that will allow it to fulfill mostefficiently.

Sharded Cluster Security

Use Internal/Membership Authentication to enforce intra-clustersecurity and prevent unauthorized cluster components from accessing thecluster. You must start each mongod or mongos in thecluster with the appropriate security settings in order to enforce internalauthentication.

See Deploy Sharded Cluster with Keyfile Authentication for atutorial on deploying a secured sharded cluster.

Cluster Users

Sharded clusters support Role-Based Access Control(RBAC) for restrictingunauthorized access to cluster data and operations. You must start eachmongod in the cluster, including the config servers, with the —auth option in order to enforce RBAC.Alternatively, enforcing Internal/Membership Authentication forinter-cluster security also enables user access controls via RBAC.

With RBAC enforced, clients must specify a —username,—password, and—authenticationDatabase whenconnecting to the mongos in order to access cluster resources.

Each cluster has its own cluster users. These users cannot be usedto access individual shards.

See Enable Access Control for a tutorial on enablingadding users to an RBAC-enabled MongoDB deployment.

Metadata Operations

mongos uses "majority" for thefollowing operations that affect the sharded cluster metadata:

Additional Information

FCV Compatibility

Starting in MongoDB 4.0, the mongos binary will crash whenattempting to connect to mongod instances whosefeature compatibility version (fCV) is greater thanthat of the mongos. For example, you cannot connecta MongoDB 4.0 version mongos to a 4.2sharded cluster with fCV set to 4.2. Youcan, however, connect a MongoDB 4.0 versionmongos to a 4.2 sharded cluster with fCV set to 4.0.

Connection Pools

Starting in MongoDB 4.2, MongoDB adds the parameterShardingTaskExecutorPoolReplicaSetMatching thatdetermines the minimum size (can vary during runtime) of themongos instance’s connection pools to each member ofthe sharded cluster.

By default, for each replica set in the sharded cluster (i.e. shardreplica set and config servers), mongos maintainsconnection pools to each replica set secondary that are at leastequal to the size of its connection pool to the primary.

To modify, see ShardingTaskExecutorPoolReplicaSetMatching.