By default, all writes and reads go/come from the primary server. Secondary servers are replicating data but not used for querying.
In some cases, it may be beneficial to change this and start taking reads from secondaries.
MongoDB official drivers support five levels of read preference:
|
Read preference mode |
Description |
|
primary |
Default mode. All operations read from the current replica set primary. |
|
primaryPreferred |
In most situations, operations read from the primary but if it is unavailable, operations read from secondary members. |
|
secondary |
All operations read from the secondary members of the replica set. |
|
secondaryPreferred |
In most situations, operations read from secondary members but if no secondary members are available, operations read from the primary. |
|
nearest |
Operations read from member of the replica set with the least network latency, irrespective of the member's type. |
Using any read preference other than primary can be beneficial for asynchronous operations that are not extremely time sensitive. Reporting servers, for example, can take reads from secondaries instead of the primary as we may be fine with a small delay in our aggregations data at the benefit of incurring more read load on our primary server.
Geographically distributed applications will also benefit by reading from secondaries as these will have significantly lower latency.
Although 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 members of our cluster are taking roughly the same write load from clients' writes and replication for primary and secondaries respectively.
More importantly though, 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 as compared to our primary writes may result in reading documents out of their insertion order (non-monotonic reads).
With all 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 avoid reading stale data is as follows:
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 basing our design on this setting.