[SERVER-11971] slaveok versioning logic in mongos should also apply to read prefs Created: 05/Dec/13 Updated: 11/Jul/16 Resolved: 20/Dec/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.4.8 |
| Fix Version/s: | 2.4.9, 2.5.5 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Greg Studer | Assignee: | Greg Studer |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| 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 SOLUTION WORKAROUNDS PATCHES Original DescriptionWhen 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. |
| Comments |
| 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 [ 07/Dec/13 ] |
|
Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: |