MongoDB Documentation, Release 3.0.4 Note: The read preference does not affect the visibility of data; i.e, clients can see the results of writes before they are made durable: Indications The following are common use cases for using non- primary (page 657) read preference modes: Note: Read preferences aren’t relevant to direct connections to a single mongod instance. However, in order to perform read operations on a direct connection to a secondary member of a replica set, you must set a read preference, such as secondary . If you have application servers in multiple data centers, you may consider having a geographically distributed replica set (page 579) and using a non primary read preference or the nearest (page 658). This allows the client to read from the lowest-latency members, rather than always reading from the primary. Use primaryPreferred (page 657) if you want an application to read from the primary under normal circumstances, but to allow stale reads from secondaries when the primary is unavailable. This provides a “read-only mode” for your application during a failover. Counter-Indications In general, do not use secondary (page 658) and secondaryPreferred (page 658) to provide extra capacity for reads, because: Sharding (page 661) increases read and write capacity by distributing read and write operations across a group of machines, and is often a better strategy for adding capacity. See Read Preference Processes (page 591) for more information about the internal application of read preferences. Important: All read preference modes except primary (page 657) may return stale data because secondaries replicate operations from the primary with some delay. 1 Ensure that your application can tolerate stale data if you choose to use a non- primary (page 657) mode. 589 9.2. Replication Concepts Read Preference Modes Use Cases • Regardless of write concern (page 130), 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 (page 584). • Running systems operations that do not affect the front-end application. • Providing local reads for geographically distributed applications. • Maintaining availability during a failover. • All members of a replica have roughly equivalent write traffic; as a result, secondaries will service reads at roughly the same rate as the primary. • Replication is asynchronous and there is some amount of delay between a successful write operation and its replication to secondaries; reading from a secondary can return out-of-date data. • Distributing read operations to secondaries can compromise availability if any members of the set become unavailable because the remaining members of the set will need to be able to handle all application requests. • For queries of sharded collections, for clusters with the balancer (page 684) active, secondaries may return stale results with missing or duplicated data because of incomplete or terminated chunk migrations.