MongoDB Documentation, Release 3.0.4 In most situations, operations read from the primary member of the set. However, if the primary is unavailable, as is the case during failover situations, operations read from secondary members. When the read preference includes a tag set (page 590), the client reads first from the primary, if available, and then from secondaries that match the specified tags. If no secondaries have matching tags, the read operation produces an error. Since the application may receive data from a secondary, read operations using the primaryPreferred (page 657) mode may return stale data in some situations. Warning: Changed in version 2.2: mongos added full support for read preferences. When connecting to a mongos instance older than 2.2, using a client that supports read preference modes, primaryPreferred (page 657) will send queries to secondaries. Operations read only from the secondary members of the set. If no secondaries are available, then this read operation produces an error or exception. Most sets have at least one secondary, but there are situations where there may be no available secondary. For example, a set with a primary, a secondary, and an arbiter may not have any secondaries if a member is in recovering state or unavailable. When the read preference includes a tag set (page 590), the client attempts to find secondary members that match the specified tag set and directs reads to a random secondary from among the nearest group (page 591). If no secondaries have matching tags, the read operation produces an error. 26 Read operations using the secondary (page 658) mode may return stale data. In most situations, operations read from secondary members, but in situations where the set consists of a single primary (and no other members), the read operation will use the set’s primary. When the read preference includes a tag set (page 590), the client attempts to find a secondary member that matches the specified tag set and directs reads to a random secondary from among the nearest group (page 591). If no secondaries have matching tags, the client ignores tags and reads from the primary. Read operations using the secondaryPreferred (page 658) mode may return stale data. The driver reads from the nearest member of the set according to the member selection (page 591) process. Reads in the nearest (page 658) mode do not consider the member’s type . Reads in nearest (page 658) mode may read from both primaries and secondaries. Set this mode to minimize the effect of network latency on read operations without preference for current or stale data. If you specify a tag set (page 590), the client attempts to find a replica set member that matches the specified tag set and directs reads to an arbitrary member from among the nearest group (page 591). Read operations using the nearest (page 658) mode may return stale data. nearest secondaryPreferred secondary Note: All operations read from a member of the nearest group of the replica set that matches the specified read preference mode. The nearest (page 658) mode prefers low latency reads over a member’s primary or secondary status. 26 If your set has more than one secondary, and you use the secondary (page 658) read preference mode, consider the following effect. If you have a three member replica set (page 574) with a primary and two secondaries, and one secondary becomes unavailable, all secondary (page 658) queries must target the remaining secondary. This will double the load on this secondary. Plan and provide capacity to support this as needed. Chapter 9. Replication 658