Operational Restrictions in Sharded Clusters
On this page
Sharding Operational Restrictions
Operations Unavailable in Sharded Environments
$where
does not permit references to the db
object
from the $where
function. This is uncommon in
un-sharded collections.
The geoSearch
command is not supported in sharded
environments.
In MongoDB 5.0 and earlier, you cannot specify sharded collections in the from
parameter of $lookup
stages.
Single Document Modification Operations in Sharded Collections
To use updateOne()
and deleteOne()
operations for a sharded
collection that specify the multi: false
or justOne
option:
If you only target one shard, you can use a partial shard key in the query specification or,
You can provide the shard key or the
_id
field in the query specification.
To use findOneAndUpdate()
with a sharded
collection, your query filter must include an equality condition on the
shard key to compare the key and value in either of these
formats:
{ key: value } { key: { $eq: value } }
Unique Indexes in Sharded Collections
MongoDB does not support unique indexes across shards, except when the unique index contains the full shard key as a prefix of the index. In these situations MongoDB will enforce uniqueness across the full key, not a single field.
Consistent Indexes
MongoDB does not guarantee consistent indexes across shards. Index creation
during addShard
operations or chunk migrations may not propagate
to new shards.
To check a sharded cluster for consistent indexes, use the
checkMetadataConsistency
command:
db.runCommand( { checkMetadataConsistency: 1, checkIndexes: true } )