[SERVER-20577] Shell should default to read concern majority if connected to a config server replica set Created: 23/Sep/15 Updated: 06/Dec/22 Resolved: 15/Nov/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Shell |
| Affects Version/s: | 3.1.8 |
| Fix Version/s: | features we're not sure of |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Henrik Ingo (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding NYC |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
3.1.8 introduced majority read concern and therefore also config servers as replica sets. When using config servers as replica sets, a mongos will use majority read concern for all reads of the config servers. It is easy to imagine a scenario where a DBA connects with the shell to the config server replset, maybe to diagnose some problem that's occuring in the sharded cluster. If the DBA doesn't specifically remember to set the read concern, he will use the default read concern and see a different snapshot of the config database than what the mongoses are actually operating on. If there is some network problem that has prevented majority writes from succeeding for the past few minutes, this difference could be significant. Proposal is for the shell to recognize when it is connecting to a config server replica set, and automatically set read concern majority for the connection. The shell must print a notification to user about doing this. |
| Comments |
| Comment by Henrik Ingo (Inactive) [ 09/Aug/16 ] |
That looks like a question or request for feedback? My answer is that I don't strongly object. I filed this ticket as a "first reaction" kind of thing when CSRS were new, but it is true changing the default is not a straightforward thing to do. I think your comment and Scott's first comment are good examples of the "what about" questions that will arise. |
| Comment by Andy Schwerin [ 08/Aug/16 ] |
|
I do not think we should change the shell's behavior in this scenario, either for reads or writes. For one thing, the DBA should typically connect to a mongos when querying config data, and I do not believe it makes sense to have the read and write concern change based on the name of the database you're examining. For another, if you're running a CSRS with trouble committing majority writes, you might also be running one that has no committed snapshot available (say you just restarted it, in the 3.2 and 3.4 implementations, e.g.). I propose to close this ticket "Works as Designed", henrik.ingo. |
| Comment by Spencer Brody (Inactive) [ 29/Jul/16 ] |
|
I also wonder if it makes sense to do this server side rather than in the shell? ie if a config server gets a read that does not specify a read concern, default to using read concern majority? |
| Comment by Spencer Brody (Inactive) [ 29/Jul/16 ] |
|
I think if we do this, we need to also make the default for all writes to the config servers use w:majority write concern, otherwise a user who writes to the config server (to set a balancer window or change the chunk size, for example) then goes to read may not read their own writes. |
| Comment by Peter Krauss [ 24/Sep/15 ] |
|
Need `stdin`, see http://stackoverflow.com/q/11333248/287948 |
| Comment by Scott Hernandez (Inactive) [ 23/Sep/15 ] |
|
You might want to make the same argument for all clients/tools... like mongodump. |