Replica Set Read and Write Semantics¶
From the perspective of a client application, whether a MongoDB instance is running as a single server (i.e. “standalone”) or a replica set is transparent.
Users may configure read preference on a per-connection basis to prefer that the read operations return on the secondary members. If clients configure the read preference to permit secondary reads, read operations cannot return from secondary members that have not replicated more recent updates or operations. When reading from a secondary, a query may return data that reflects a previous state.
This behavior is sometimes characterized as eventual consistency because the secondary member’s state will eventually reflect the primary’s state and MongoDB cannot guarantee strict consistency for read operations from secondary members.
To guarantee consistency for reads from secondary members, you can configure the client and driver to ensure that write operations succeed on all members before completing successfully. See Write Concern for more information. Additionally, such configuration can help prevent Rollbacks During Replica Set Failover during a failover.
Sharded clusters where the shards are also replica sets provide the same operational semantics with regards to write and read operations.
- Write Concern for Replica Sets
- Write concern is the guarantee an application requires from MongoDB to consider a write operation successful.
- Read Preference
- Applications specify read preference to control how drivers direct read operations to members of the replica set.
- Read Preference Processes
- With replica sets, read operations may have additional semantics and behavior.