> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

# Distributed Queries

Learn how MongoDB handles read and write operations in replica sets and sharded clusters. This page explains the importance of cluster architecture on query routing and data consistency.

## Read Operations to Replica Sets

By default, clients read from a replica set's [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary). However, you can specify a [read preference](https://www.mongodb.com/docs/manual/core/read-preference.md) to direct read operations to other members. For example, configure read preferences to read from secondaries or from the nearest member to:

- Reduce latency in deployments with multiple data centers.

- Perform backup operations.

- Allow reads until a [new primary is elected.](https://www.mongodb.com/docs/manual/core/replica-set-high-availability.md#std-label-replica-set-failover)

![Default read preference routes to primary; \`\`nearest\`\` routes to closest member.](/images/replica-set-read-preference.bakedsvg.svg)

Read operations from secondary members of replica sets may not reflect the current state of the primary. Read preferences that direct read operations to different servers may result in non-monotonic reads.

Clients can use [causally consistent](https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency.md#std-label-causal-consistency) sessions, which provides various guarantees including monotonic reads.

You can configure the read preference on a per-connection or per-operation basis. For more information on read preference or on the read preference modes, see [Read Preference](https://www.mongodb.com/docs/manual/core/read-preference.md) and [Read Preference Modes.](https://www.mongodb.com/docs/manual/core/read-preference.md#std-label-replica-set-read-preference-modes)

## Write Operations on Replica Sets

In [replica sets](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-replica-set), all write operations go to the set's [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary). The primary applies the write operation and records the operations on the primary's operation log or [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog). The oplog is a reproducible sequence of operations to the data set. [secondary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-secondary) members of the set continuously replicate the oplog and apply the operations to themselves in an asynchronous process.

![Diagram of default routing of reads and writes to the primary.](/images/replica-set-read-write-operations-primary.bakedsvg.svg)

For more information on replica sets and write operations, see [Replication](https://www.mongodb.com/docs/manual/replication.md#std-label-replication) and [Write Concern.](https://www.mongodb.com/docs/manual/reference/write-concern.md)

## Read Operations to Sharded Clusters

[Sharded clusters](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-sharded-cluster) allow you to partition a data set among a cluster of [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) instances in a way that is nearly transparent to the application. For an overview of sharded clusters, see the [Sharding](https://www.mongodb.com/docs/manual/sharding.md) section of this manual.

For a sharded cluster, applications issue operations to one of the [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instances associated with the cluster.

![Diagram of a sharded cluster.](/images/sharded-cluster.bakedsvg.svg)

Read operations on sharded clusters are most efficient when directed to a specific shard. Queries to sharded collections should include the collection's [shard key](https://www.mongodb.com/docs/manual/core/sharding-shard-key.md#std-label-sharding-shard-key). When a query includes a shard key, the [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) can use cluster metadata from the [config database](https://www.mongodb.com/docs/manual/core/sharded-cluster-config-servers.md#std-label-sharding-config-server) to route the queries to shards.

![Targeted query: \`\`mongos\`\` routes to specific shards when the shard key is included.](/images/sharded-cluster-targeted-query.bakedsvg.svg)

If a query does not include the shard key, the [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) must direct the query to *all* shards in the cluster. These *scatter
gather* queries can be inefficient. On larger clusters, scatter gather queries are unfeasible for routine operations.

![Scatter-gather query: \`\`mongos\`\` broadcasts to all shards when no shard key is specified.](/images/sharded-cluster-scatter-gather-query.bakedsvg.svg)

For replica set shards, read operations from secondary members of replica sets may not reflect the current state of the primary. Read preferences that direct read operations to different servers may result in non-monotonic reads.

**Note:**

- Clients can use [causally consistent](https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency.md#std-label-causal-consistency) sessions, which provides various guarantees, including monotonic reads.

- All members of a shard replica set, not just the primary, maintain the metadata regarding chunk metadata. This prevents reads from the secondaries from returning [orphaned data](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-orphaned-document) if not using read concern [`"available"`](https://www.mongodb.com/docs/manual/reference/read-concern-available.md#mongodb-readconcern-readconcern.-available-). In earlier versions, reads from secondaries, regardless of the read concern, could return orphaned documents.

For more information on read operations in sharded clusters, see the [Routing with mongos](https://www.mongodb.com/docs/manual/core/sharded-cluster-query-router.md) and [Shard Keys](https://www.mongodb.com/docs/manual/core/sharding-shard-key.md#std-label-sharding-shard-key) sections.

## Write Operations on Sharded Clusters

For sharded collections in a [sharded cluster](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-sharded-cluster), the [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) directs write operations from applications to the shards that are responsible for the specific *portion* of the data set. The [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) uses the cluster metadata from the [config database](https://www.mongodb.com/docs/manual/core/sharded-cluster-config-servers.md#std-label-sharding-config-server) to route the write operation to the appropriate shards.

![Diagram of a sharded cluster.](/images/sharded-cluster.bakedsvg.svg)

MongoDB partitions data in a sharded collection into *ranges* based on the values of the [shard key](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-shard-key). Then, MongoDB distributes these chunks to shards. The shard key determines the distribution of chunks to shards. This can affect the performance of write operations in the cluster.

![Diagram of the shard key value space segmented into smaller ranges or chunks.](/images/sharding-range-based.bakedsvg.svg)

**Important:**

Update operations that affect a *single* document **must** include the [shard key](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-shard-key) or the `_id` field. Updates that affect multiple documents are more efficient in some situations if they have the [shard key](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-shard-key), but can be broadcast to all shards.

If the value of the shard key increases or decreases with every insert, all insert operations target a single shard. As a result, the capacity of a single shard becomes the limit for the insert capacity of the sharded cluster.

For more information, see [Sharding](https://www.mongodb.com/docs/manual/sharding.md) and [Bulk Write Operations.](https://www.mongodb.com/docs/manual/core/bulk-write-operations.md)

**See also:**

[Retryable Writes](https://www.mongodb.com/docs/manual/core/retryable-writes.md#std-label-retryable-writes)

## Change Streams and Orphan Documents

Starting in MongoDB 5.3, during [range migration](https://www.mongodb.com/docs/manual/core/sharding-balancer-administration.md#std-label-range-migration-procedure), [change stream](https://www.mongodb.com/docs/manual/changestreams.md#std-label-changeStreams) events are not generated for updates to [orphaned documents.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-orphaned-document)