|
The docs page at: https://docs.mongodb.org/manual/reference/read-preference/#reduce-load-on-the-primary
stated that:
To shift read load from the primary, use mode secondary. Although secondaryPreferred is tempting for this use case, it carries some risk: if all secondaries are unavailable and your set has enough arbiters to prevent the primary from stepping down, then the primary will receive all traffic from clients. If the primary is unable to handle this load, queries will compete with writes. For this reason, use secondary to distribute read load to replica sets, not secondaryPreferred.
Without a proper context regarding secondary read use cases, this is a misleading paragraph at best, and incorrect at worst. This is because:
- The secondaries are doing just as much writes as the primary. Shifting reads to the secondaries without a good reason compromises the replica set's high availability function.
- The replica set overall could be burdened with more reads than what it could actually handle. When one node fails, the rest of the set could be flooded with reads that could bring down the whole set.
- The secondaries are eventually consistent with the primary, so there is a chance that stale data is read.
To make matters worse, this page: https://docs.mongodb.org/manual/core/read-preference/#counter-indications stated:
In general, do not use secondary and secondaryPreferred to provide extra capacity for reads
thus we are giving users conflicting information.
|