[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:
Related
related to SERVER-25357 Expose connection level read concern ... Closed
is related to SERVER-24738 Config servers incorrectly allow w:1 ... Closed
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 ]

I propose to close this ticket "Works as Designed", henrik.ingo

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.

Generated at Thu Feb 08 03:54:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.