MongoDB Documentation, Release 3.0.4 Auto-Retry Read Preference in Sharded Clusters Changed in version 3.0.0: mongos instances take a slightly different approach. mongos instances return connections to secondaries to the connection pool after every request. As a result, the mongos reevaluates read preference for every operation. Changed in version 2.2: Before version 2.2, mongos did not support the read preference mode semantics (page 657). In most sharded clusters , each shard consists of a replica set . As such, read preferences are also applicable. With regard to read preference, read operations in a sharded cluster are identical to unsharded replica sets. Unlike simple replica sets, in sharded clusters, all interactions with the shards pass from the clients to the mongos instances that are actually connected to the set members. mongos is then responsible for the application of read preferences, which is transparent to applications. There are no configuration changes required for full support of read preference modes in sharded environments, as long as the mongos is at least version 2.2. All mongos maintain their own connection pool to the replica set members. As a result: To prevent confusion, always explicitly set your read preference mode. • A request without a specified preference has primary (page 657), the default, unless, the mongos reuses an existing connection that has a different mode set. • After detecting a failover situation, 16 the driver attempts to refresh the state of the replica set as quickly as possible. • Return an error only after attempting to connect to three members of the set that match the read preference mode (page 657) and tag set (page 590). If there are fewer than three members of the set, the client will error after connecting to all existing members of the set. • Attempt to reconnect to a new member, obeying existing read preference modes (page 657), if the connection to mongod is lost. • Reuse a connection to a specific mongod for as long as possible after establishing a connection to that instance. This connection is pinned to this mongod . 2. The client should minimize the amount of time that the database is inaccessible as the result of a connection issue, networking problem, or failover in a replica set. 1. The client should attempt to prefer current results, and any connection should read from the same member of the replica set as much as possible. Requests should prefer request association (page 591) (e.g. pinning ). Connections between MongoDB drivers and mongod instances in a replica set must balance two concerns: As a result, MongoDB drivers: Reconnections are transparent to the application itself. If the connection permits reads from secondary mem- bers, after reconnecting, the application can receive two sequential reads returning from different secondaries. Depending on the state of the individual secondary member’s replication, the documents can reflect the state of your database at different moments. After this error, the driver selects a new member using the specified read preference mode. In the absence of a specified read preference, the driver uses primary (page 657). 16 When a failover occurs, all members of the set close all client connections that produce a socket error in the driver. This behavior prevents or minimizes rollback . Chapter 9. Replication 592