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.

By default, in MongoDB, read operations to a replica set return results from the primary.

Users may configure read preference on a per-connection basis to prefer that the read operations return results from the secondary members. If clients configure the read preference to permit 许可证secondary reads, read operations can return data from secondary members that have not replicated more recent write operations 没有复制的最近的写操作.

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. [1]

NOTE

• In MongoDB, clients can see the results of writes before they are made durable:

• Regardless of write concern, other clients can see the result of the write operations

•  before the write operation is acknowledged to the issuing client.Clients can read data which may be subsequently rolled back.

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