- Sharding >
- Sharded Cluster Components >
- mongos
mongos¶
On this page
MongoDB 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.
The 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.
The most common practice is to run mongos
instances on the
same systems as your application servers, but you can maintain
mongos
instances on the shards or on other dedicated
resources.
Routing And Results Process¶
A mongos
instance routes a query to a cluster by:
- Determining the list of shards that must receive the query.
- Establishing a cursor on all targeted shards.
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 a shard such as the primary shard before
mongos
retrieves the results.
Changed in version 3.2: For aggregation operations that run on multiple shards, if the operations do not require running on the database’s primary shard, these operations can route the results to any shard to merge the results and avoid overloading the primary shard for that database.
In some cases, when the shard key or a prefix of the shard key is a
part of the query, the mongos
performs a targeted
operation, routing queries to a subset of
shards in the cluster.
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 Query Isolation for more on targeted and broadcast operations.
How mongos
Handles Query Modifiers¶
Sorting¶
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 specifies sorted results using the
sort()
cursor method, the mongos
instance
passes the $orderby
option to the shards. The primary
shard for the database receives and performs a merge sort for all
results before returning the data to the client via the
mongos
.
Limits¶
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.
Skips¶
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.
When used in conjunction with a limit()
, the
mongos
will pass the limit plus the value of the
skip()
to the shards to improve the efficiency of these
operations.
Confirm Connection to mongos
Instances¶
To detect if the MongoDB instance that your client is connected
to is mongos
, use the isMaster
command. When a
client connects to a mongos
, isMaster
returns
a document with a msg
field that holds the string
isdbgrid
. For example:
{
"ismaster" : true,
"msg" : "isdbgrid",
"maxBsonObjectSize" : 16777216,
"ok" : 1
}
If the application is instead connected to a mongod
, the
returned document does not include the isdbgrid
string.
Query Isolation¶
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.
Broadcast Operations¶
mongos
instances broadcast queries to all shards for the
collection unless the mongos
can
determine which shard or subset of shards stores this data.
After the 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.
The updateMany()
and
deleteMany()
methods are broadcast
operations, unless the query document specifies the shard key in full.
Targeted 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:
{ a: 1, b: 1, c: 1 }
The 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:
{ a: 1 }
{ a: 1, b: 1 }
All insertOne()
operations target to one shard. Each
document in the insertMany()
array targets to a
single shard, but there is no guarantee all documents in the array insert into
a single shard.
All updateOne()
,
replaceOne()
and deleteOne()
operations must include the shard key or _id
in the query
document. MongoDB returns an error if these methods are used without
the shard key or _id
.
Depending on the distribution of data in the cluster and the selectivity of
the query, mongos
may still perform a broadcast
operation to fulfill these queries.
Index Use¶
If the query does not include the shard key, the
mongos
must send the query to all shards as a
“scatter/gather” operation. Each shard will, in turn, use either the
shard key index or another more efficient index to fulfill the query.
If the query includes multiple sub-expressions that reference the
fields indexed by the shard key and the secondary index, the
mongos
can route the queries to a specific shard and the
shard will use the index that will allow it to fulfill most
efficiently.
Sharded Cluster Security¶
Use Internal Authentication to enforce intra-cluster
security and prevent unauthorized cluster components from accessing the
cluster. You must start each mongod
or mongos
in the
cluster with the appropriate security settings in order to enforce internal
authentication.
See Deploy Sharded Cluster with Keyfile Access Control for a tutorial on deploying a secured sharded cluster.
Cluster Users¶
Sharded clusters support Role-Based Access Control (RBAC) for restricting
unauthorized access to cluster data and operations. You must start each
mongod
in the cluster, including the config servers, with the --auth
option in order to enforce RBAC.
Alternatively, enforcing Internal Authentication for
inter-cluster security also enables user access controls via RBAC.
With RBAC enforced, clients must specify a --username
,
--password
, and
--authenticationDatabase
when
connecting to the mongos
in order to access cluster resources.
Each cluster has its own cluster users. These users cannot be used to access individual shards.
See Enable Auth for a tutorial on enabling adding users to an RBAC-enabled MongoDB deployment.