ISSUE SUMMARY
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.
USER IMPACT
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.
SOLUTION
Treat non-primary only read preferences the same as if slaveOk is set.
WORKAROUNDS
Set the slaveOk bit as well as the non-primary only read preference in the client application.
PATCHES
Production release v2.4.9 contains the fix for this issue, and production release v2.6.0 will contain the fix as well.
Original Description
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
-
- Closed
-