[SERVER-7246] Mongos cannot do slaveOk queries when primary is down Created: 03/Oct/12 Updated: 11/Jul/16 Resolved: 21/Dec/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Client, Sharding |
| Affects Version/s: | 2.3.0 |
| Fix Version/s: | 2.4.9, 2.5.5 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Greg Studer |
| Resolution: | Done | Votes: | 6 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Issue Status as of January 8th, 2014 ISSUE SUMMARY This issue is part of 4 related issues which impact cluster availability when there is no primary available for a shard. See USER IMPACT It is present in versions of MongoDB prior to and including v2.4.8. SOLUTION In v2.4.9 only (this is set by default in v2.6.0 and later), it is necessary to use the following two startup parameters for mongos:
These parameters can also be set on a MongoS after launch with the following commands
WORKAROUNDS PATCHES Original DescriptionThis issue is fixed, but depending on the type of connectivity issue between a mongos and the down primary, connection and query performance can be severely degraded in this scenario. Results of testing different primary down scenarios latencies: With killed processes, but functioning network: With iptables DROP: With iptables REJECT: |
| Comments |
| Comment by Asya Kamsky [ 04/Nov/15 ] |
|
This is an old issue that's been fixed for over a year. If your question is not specifically about this issue please ask it on MongoDB-user mailing list. |
| Comment by Edik Mkoyan [ 04/Nov/15 ] |
|
If I have network star topology, and if I need the rs members in spokes always be in master state then I should not use mongoldb? |
| Comment by waterbull [ 01/May/14 ] |
|
Greg Studer, Oh, I got it. And test it using commands "use <db>;db.<collection>.find()", it works. |
| Comment by Greg Studer [ 28/Apr/14 ] |
|
w.b The listDatabases command (which is what "show databases" invokes) isn't a standard query. It uses a different codepath - a primary being down will still prevent it from completing. I suspect 2.4.x has similar behavior here. Opened |
| Comment by waterbull [ 25/Apr/14 ] |
|
I download mongodb.2.6.0 to test high available. then I run the follow command: ) ) it reports: then, run command: ); it reports: \nsupported:\n _forceLegacyShardWriteMode\n authSchemaVersion\n clusterAuthMode\n connPoolMaxConnsPerHost\n connPoolMaxShardedConnsPerHost\n enableLocalhostAuthBypass\n enableTestCommands\n internalQueryCacheFeedbacksStored\n internalQueryCacheSize\n internalQueryCacheStdDeviations\n internalQueryCacheWriteOpsBetweenFlush\n internalQueryEnumerationMaxIntersectPerAnd\n internalQueryEnumerationMaxOrSolutions\n internalQueryForceIntersectionPlans\n internalQueryPlanEvaluationCollFraction\n internalQueryPlanEvaluationMaxResults\n internalQueryPlanEvaluationWorks\n internalQueryPlanOrChildrenIndependently\n internalQueryPlannerEnableIndexIntersection\n internalQueryPlannerMaxIndexedSolutions\n logLevel\n logUserIds\n quiet\n releaseConnectionsAfterResponse\n sslMode\n supportCompatibilityFormPrivilegeDocuments\n textSearchEnabled\n userCacheInvalidationIntervalSecs\n verboseQueryLogging\n", no options "ignoreInitialVersionFailure", "authOnPrimaryOnly" found. |
| Comment by Githook User [ 11/Dec/13 ] |
|
Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by Githook User [ 11/Dec/13 ] |
|
Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by Githook User [ 11/Dec/13 ] |
|
Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by Githook User [ 04/Dec/13 ] |
|
Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by Githook User [ 04/Dec/13 ] |
|
Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by Greg Studer [ 04/Dec/13 ] |
|
Mixup on commit SERVER slug. Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |
| Comment by Spencer Brody (Inactive) [ 27/Aug/13 ] |
|
From a simple test using the shell, this seems to affect the C++ driver as well. |
| Comment by Randolph Tan [ 23/Aug/13 ] |
|
Attached another alternative procedure to demonstrate this issue. |
| Comment by Randolph Tan [ 22/Aug/13 ] |
|
Attaching crude test script that demonstrates the issue. |
| Comment by peanutgyz [ 29/Jan/13 ] |
|
is there any plan to fix this ?? |