Docs Menu
Docs Home
/
MongoDB Manual
/ /

Operational Restrictions in Sharded Clusters

On this page

  • Sharding Operational Restrictions

$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.

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 } }

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.

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
} )

Back

ZonesRangeOverlap