Mongos does not treat non-primary only read preferences the same as slaveOk.
This issue is part of 4 related issues which impact cluster availability when there is no primary available for a shard. See
SERVER-7246, SERVER-5625, SERVER-11971 and SERVER-12041 for more details.
Non-primary read preferences (without slaveOk set) are not tolerant of the primary being down after splits or migrations have occurred. This will cause existing connections to fail in the event that the primary is unavailable.
It is present in versions of MongoDB prior to and including v2.4.8.
Treat non-primary only read preferences the same as if slaveOk is set.
Set the slaveOk bit as well as the non-primary only read preference in the client application.
Production release v2.4.9 contains the fix for this issue, and production release v2.6.0 will contain the fix as well.
When running a slaveok query on mongos which (potentially) talks to secondary nodes, we attempt to set the shard version on the connection but tolerate failure. The slaveok flag is not necessarily set when read preferences are used, but the same logic should apply.
Not a regression, but needs improvement.
- is related to
SERVER-12041 retry logic for read preferences should also apply on lazy recv() network failure