This version of the documentation is archived and no longer supported.

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]


  • 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.
[1]In some circumstances, two nodes in a replica set may transiently believe that they are the primary, but at most, one of them will be able to complete writes with {w: majority} write concern. The node that can complete {w: majority} writes is the current primary, and the other node is a former primary that has not yet recognized its demotion, typically due to a network partition. When this occurs, clients that connect to the former primary may observe stale data despite having requested read preference primary.