MongoDB Documentation, Release 3.0.4 For nearest (page 658), the client assembles a list of acceptable hosts based on tag set and then narrows that list to the host with the shortest ping time and all other members of the set that are within the “local threshold,” or acceptable latency. See Member Selection (page 591) for more information. Depending on the requirements of an application, you can configure different applications to use different read prefer- ences, or use different read preferences for different queries in the same application. Consider the following applica- tions for different read preference strategies. Maximize Consistency To avoid stale reads, use primary (page 657) read preference. If the primary is unavail- able, e.g. during elections or when a majority of the replica set is not accessible, read operations produce an error or throw an exception. In some rare edge cases, it may be possible for a replica set to temporarily have two primaries. For example, To increase consistency, you can disable automatic failover ; however, disabling automatic failover sacrifices availabil- ity. Maximize Availability To permit read operations when possible, use primaryPreferred (page 657). When there’s a primary you will get consistent reads $^{5}$, but if there is no primary you can still query secondaries . However, when using this read mode, consider the situation described in Reduce load on the primary (page 660). Minimize Latency To always read from a low-latency node, use nearest (page 658). The driver or mongos will read from the nearest member and those no more than 15 milliseconds 27 further away than the nearest member. nearest (page 658) does not guarantee consistency. If the nearest member to your application server is a secondary with some replication lag, queries could return stale data. nearest (page 658) only reflects network distance and does not reflect I/O or CPU load. Query From Geographically Distributed Members If the members of a replica set are geographically distributed, you can create replica tags based that reflect the location of the instance and then configure your application to query the members nearby. For example, if members in “east” and “west” data centers are tagged (page 635) {’dc’: ’east’} and {’dc’: ’west’} , your application servers in the east data center can read from nearby members with the following read preference: db.collection.find().readPref( { mode: 'nearest', tags: [ {'dc': 'east'} ] } ) Use Cases • A partial network partition may segregate a primary ( p$_{old}$ ) into a partition with a minority of the nodes, while the other side of the partition contains a majority of nodes. The partition with the majority will elect a new primary ( P$_{new}$ ), but for a brief period, the old primary ( p$_{old}$ ) may still continue to serve reads and writes, as it has not yet detected that it can only see a minority of nodes in the replica set. During this period, if the old primary ( p$_{old}$ ) is still visible to clients as a primary, reads from this primary may reflect stale data. • A primary ( p$_{old}$ ) may become unresponsive, which will trigger an election and a new primary ( P$_{new}$ ) can be elected, serving reads and writes. If the unresponsive primary ( p$_{old}$ ) starts responding again, two primaries will be visible for a brief period. The brief period will end when p$_{old}$ steps down. However, during the brief period, clients might read from the old primary p$_{old}$ , which can provide stale data. 27 This threshold is configurable. See localPingThresholdMs for mongos or your driver documentation for the appropriate setting. 659 9.4. Replication Reference