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
All updateOne()
and deleteOne()
operations for a sharded
collection that specify the multi: false
or justOne
option must include the shard key or the _id
field in
the query specification.
updateOne()
and deleteOne()
operations specifying
multi: false
or justOne
in a sharded collection which do
not contain either the shard key or the _id
field return an
error.
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.
Tip
See:
Unique Constraints on Arbitrary Fields for an alternate approach.
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 } )