[SERVER-40099] Add server side write concern option Created: 13/Mar/19  Updated: 04/May/20  Resolved: 07/Feb/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Dmitry Agranat Assignee: Dmitry Agranat
Resolution: Won't Do Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Sprint: Sharding 2019-09-23
Participants:
Case:

 Description   

Feature request: Add write concern option on the server side which will overwrite write concern options sent by a driver



 Comments   
Comment by Sheeri Cabral (Inactive) [ 08/Apr/19 ]

It's a HUGE anti-pattern to have a server-side default override a client-side parameter. I understand that many operators use the defaults out of the box and get behavior they do not want. I think having a specific flag would work for people already embroiled in this problem, but it does nothing to solve the root cause - whether the cause is not enough education on our part, bad defaults, etc.

I worry about a MongoDB server where different drivers are used against the same MongoDB - if there's a server-wide "yes, override" flag that gets turned on, there could be different parts of the org that override on purpose, and then they would have an unexpected behavior change if a centralized DBA team decides to turn the flag on.

Is this intended as a stopgap or workaround so that there is enough time/capacity to continue operations while the proper writeConcern is implemented at the driver level? Or will this be put in place permanently - which can be a problem down the line for a heterogeneous environment, as stated in the previous paragraph.

Also I'm not understanding why getLastErrorDefaults] is not sufficient - it is server-side on the replica-set level, and allows explicit driver overrides but not if the driver is using the default, which seems to be what is desired?

 

 

Comment by Andy Schwerin [ 18/Mar/19 ]

Sure. If those were the only behaviors you could force, it would make sense. I guess I could imagine requiring a union or supplied write concerns. It depends on how sophisticated application developers are. Sometimes setting the write concern stronger than requested can break an application's behavior, but I'd expect that only for fairly sophisticated apps.

 

dmitry.agranat, you said

But we force users to do this anyway when write concern majority is set to less than majority and it causes clusters crush/unresponsiveness/unavailability.

But I don't know what you mean about "when write concern majority is set to less than majority". Can you give a specific example or clarify?

Comment by Kaloian Manassiev [ 15/Mar/19 ]

When you add these secondary dimensions, yes I agree they are not ordered. I was referring to the ordering between {w:majority} and {w:local}.

Comment by Andy Schwerin [ 14/Mar/19 ]

Write concerns are not totally ordered. Is { j: true } stronger or weaker than { w: 1 }? How does { w: "myTag1" } compare to { w: "myTag2" } or { w: 2 }?

Comment by Danny Hatcher (Inactive) [ 14/Mar/19 ]

An alternative that accomplishes the same goal would be to set a "minimum" write concern on the server and outright reject writes that do not match it. But I think the overriding is a more elegant process.

Comment by Kaloian Manassiev [ 14/Mar/19 ]

schwerin, I couldn't think of how overriding the write concern from lower (local) to anything higher could impact the correctness of the application. What did you have in mind?

Comment by Dmitry Agranat [ 14/Mar/19 ]

But we force users to do this anyway when write concern majority is set to less than majority and it causes clusters crush/unresponsiveness/unavailability. So in assents, we are just helping developers to save a lot of their time on doing something that we can do instead, in an instant. Remember, this feature will be off by default. Only when required / agreed upon by a user, we will turn it on.

Comment by Andy Schwerin [ 14/Mar/19 ]

I’d like alyson.cabral’s feedback on this request. I worry that overriding the user-supplied write concern could affect the correctness of an application. Perhaps we could prohibit some users from supplying their own read and write concerns, instead?

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