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.了解MongoDB如何处理副本集和分片集群中的读写操作。本页解释了集群架构在查询路由和数据一致性方面的重要性。
Read Operations to Replica Sets对副本集的读取操作
By default, clients read from a replica set's primary. However, you can specify a read preference to direct read operations to other members. For example, configure read preferences to read from secondaries or from the nearest member to:默认情况下，客户端从副本集的primary读取数据。但是，您可以指定读取首选项，以将读取操作定向到其他成员。例如，将读取首选项配置为从secondary或最近的成员读取：
Reduce latency in deployments with multiple data centers.减少多个数据中心部署中的延迟。Perform backup operations.执行备份操作。Allow reads until a new primary is elected.允许读取，直到选出新的primary。
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 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 and Read Preference Modes.您可以根据每个连接或每个操作配置读取首选项。有关读取偏好或读取偏好模式的更多信息，请参阅读取偏好和读取偏好模式。
Write Operations on Replica Sets对副本集的写入操作
In replica sets, all write operations go to the set's primary. 在副本集中，所有写入操作都将转到该集的主副本。The primary applies the write operation and records the operations on the primary's operation log or oplog. 主服务器应用写入操作，并将操作记录在主服务器的操作日志或oplog上。The oplog is a reproducible sequence of operations to the data set. secondary members of the set continuously replicate the oplog and apply the operations to themselves in an asynchronous process.oplog是对数据集的可重复操作序列。集合的secondary成员不断复制oplog，并在异步过程中将操作应用于自己。
For more information on replica sets and write operations, see Replication and Write Concern.有关复制副本集和写入操作的更多信息，请参阅复制和写入关注。
Read Operations to Sharded Clusters
Sharded clusters allow you to partition a data set among a cluster of mongod instances in a way that is nearly transparent to the application. For an overview of sharded clusters, see the Sharding section of this manual.
For a sharded cluster, applications issue operations to one of the mongos instances associated with the cluster.
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. When a query includes a shard key, the mongos can use cluster metadata from the config database to route the queries to shards.
If a query does not include the shard key, the 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.
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 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 if not using read concern
"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 and Shard Keys sections.
Write Operations on Sharded Clusters
For sharded collections in a sharded cluster, the mongos directs write operations from applications to the shards that are responsible for the specific portion of the data set. The mongos uses the cluster metadata from the config database to route the write operation to the appropriate shards.
MongoDB partitions data in a sharded collection into ranges based on the values of the 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.
Important
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 and Bulk Write Operations.
Tip
Change Streams and Orphan Documents更改流和孤立文档
Starting in MongoDB 5.3, during range migration, change stream events are not generated for updates to orphaned documents.