[SERVER-25778] Provide a generic mechanism for commands to enforce that they must be run with w:majority write concern Created: 24/Aug/16  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Replication, Sharding
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: writeconcern
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-24738 Config servers incorrectly allow w:1 ... Closed
related to SERVER-25724 setFeatureCompatibilityVersion should... Closed
Assigned Teams:
Replication
Participants:

 Description   

Some commands (such as the _configsvr commands and the setFeatureCompatibilityVersion command) must always use w:majority write concern. Right now different commands take different approaches to enforcing this. We should decide on a single strategy for this, ideally one that leverages the existing write concern handling code in dbcommands.cpp and returns write concern errors as 'writeConcernError' fields in the command response, in line with how the batch write commands report write concern errors



 Comments   
Comment by Judah Schvimer [ 29/Aug/16 ]

I agree with the above proposed solution. It's inline with how the rest of writeConcern is implemented.

Comment by Spencer Brody (Inactive) [ 24/Aug/16 ]

I propose adding a static method to the Command interface, Command::enforceMajorityWC(OperationContext* txn) that checks that the write concern set on the txn either 'usedDefault' or was set to w:majority (and usasserts if not), then sets the write concern on the txn to w:majority.

Comment by Spencer Brody (Inactive) [ 24/Aug/16 ]

Actually looks like that latter part isn't difficult at all, we set a usedDefault field in the writeConcernOptions attached to the txn.

Comment by Spencer Brody (Inactive) [ 24/Aug/16 ]

An ideal implementation would error if the user provided any write concern other than w:majority, but if the user provided no write concern automatically upconvert it to w:majority. The difficult part is distinguishing between a command that was run with no write concern and one that explicitly specified the default (w:1) write concern.

Comment by Spencer Brody (Inactive) [ 24/Aug/16 ]

Current idea is to have the commands that require w:majority override the writeConcern set on the txn, and update the command processing system to use the write concern attached to the txn when waiting for write concern after running a command.

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