[SERVER-17355] Feature Request to override client's readPreference in mongos Created: 23/Feb/15 Updated: 05/Jan/18 Resolved: 17/Mar/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.6.7 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Neal Rigney | Assignee: | Andy Schwerin |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Participants: | |||||
| Case: | (copied to CRM) | ||||
| Description |
|
A customer would like to be able to override the client's read preference in mongos. They would like it to be a global setting – all requests coming in would have the readPreference overrided by a setting in mongos. Talking through the request, we also considered adding a flag that would allow the client to indicate willingness to let the server override the preference, perhaps as part of connect options. |
| Comments |
| Comment by Andy Schwerin [ 06/Mar/15 ] |
|
neal.rigney, would this default read preference be set on a single mongos or on a whole cluster? Letting mongos arbitrarily override the application's read preference is risky, because application behavior might depend on that read preference (particularly, if it depends on primary reads). I can imagine letting mongos further constrain read preferences in a way compatible with the application's request, but that gets complicated pretty fast. |
| Comment by Charlie Page [ 23/Feb/15 ] |
|
Having no read preference is more logical to signal that the cluster can choose to implement the request however it sees fit, rather than adding an "ignore flag". It would be desirable to keep the semantics as close as is feasible to how default write concerns are changed on replicas (where a flag to override isn't used). |