MongoDB Documentation, Release 3.0.4 Always ensure that your operations have specified the required write concern for your application. See also: Write Concern (page 78) and connections-write-concern You can tag (page 635) the members of replica sets and use the resulting tag sets to create custom write concerns. See Configure Replica Set Tag Sets (page 635) for information on configuring custom write concerns using tag sets. Read preference describes how MongoDB clients route read operations to the members of a replica set . Custom Write Concerns Read Preference By default, an application directs its read operations to the primary member in a replica set . Because write operations are issued to the single primary, reading from the primary returns the latest version of a document $^{13}$. For an application that does not require fully up-to-date data, you can improve read throughput or reduce latency by distributing some or all reads to secondary members of the replica set. Important: Exercise care when specifying read preferences: Modes other than primary (page 657) may return stale data because with asynchronous replication (page 561), data in the secondary may not reflect the most recent write operations. 1 13 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 (page 130). The node that can complete {w: majority} (page 130) 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 (page 657). Chapter 9. Replication 588