[SERVER-20743] Sharding code needs to set $secondaryOk on commands targeted at hosts via read preferences other than PrimaryOnly. Created: 02/Oct/15 Updated: 25/Jan/17 Resolved: 06/Oct/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.1.9 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andy Schwerin | Assignee: | Andy Schwerin |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Sprint: | Sharding A (10/09/15) | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
The runCommand methods on the ShardRegistry type that currently take a HostAndPort argument should actually take a ReadPreferenceSetting and either a Shard or a Targeter. The problem with the current form is that the targeter is given a read preference by code trying to run commands against shards in order to derive a HostAndPort. The code trying to run commands is not then obligated (or sometimes even enabled) to appropriately set the $secondaryOk metadata field. Given the uses, a better design would be for the runCommand-like methods to take a Shard or Targeter along with a read preference, and to do targeting and command dispatch together. Making this change will hopefully eliminate bugs where operations are targeted to secondary nodes without setting the $secondaryOk flag. |
| Comments |
| Comment by Githook User [ 06/Oct/15 ] |
|
Author: {u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}Message: Also, properly set the metadata field on all commands dispatched through ShardRegistry. |