By default, all writes and reads go/come from the primary server. Secondary servers replicate data, but are not used for querying.
In some cases, it may be beneficial to change this and start to take reads from secondaries.
The MongoDB official drivers support five levels of read preference:
|
Read Preference Mode |
Description |
|
primary |
This is the default mode, where reads come from the primary server of the replica set. |
|
primaryPreferred |
With this mode, applications will read from the primary, unless it is unavailable, in which case reads will come from secondary members. |
|
secondary |
Reads come exclusively from secondary servers. |
|
secondaryPreferred |
With this mode, applications will read from secondary members, unless they are unavailable, in which case reads will come from the primary member. |
|
nearest |
Applications will read from the member of the replica set that is nearest in terms of network latency, not taking into account the member's type. |
Using any read preference other than primary can be beneficial for asynchronous operations that are not extremely time-sensitive. For example, reporting servers can take reads from secondaries instead of the primary, as we may be fine with a small delay in our aggregation data, with the benefit of incurring more read load on our primary server.
Geographically distributed applications will also benefit from reading from secondaries, as these will have significantly lower latency. Although it's probably counter-intuitive, just changing the read preference from primary to secondary will not significantly increase the total read capacity of our cluster. This is because all of the members of our cluster are taking the same write load from clients' writes, and replication for the primary and secondaries, respectively.
More importantly, however, reading from a secondary may return stale data, which has to be dealt with at the application level. Reading from different secondaries that may have variable replication lag (compared to our primary writes) may result in reading documents out of their insertion order (non-monotonic reads).
With all of the preceding caveats, it is still a good idea to test reading from secondaries if our application design supports it. An additional configuration option that can help us to avoid reading stale data is maxStalenessSeconds.
Based on a coarse estimation from each secondary as to how far behind the primary it is, we can set this to a value of 90 (seconds) or more to avoid reading stale data. Given that secondaries know how far behind they are from the primary (but don't accurately or aggressively estimate it), this should be treated as an approximation, rather than something we base our design o.