Operational Restrictions in Sharded Clusters

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

Write Concern for DDL Operations

On a sharded cluster, DDL (Data Definition Language) operations run with write concern "majority". If you specify a different write concern, the operation overrides the provided write concern with "majority".