[SERVER-34776] dropDatabase should respect user provided writeConcern Created: 01/May/18  Updated: 29/Oct/23  Resolved: 22/May/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.0.0-rc1, 4.1.1

Type: Bug Priority: Major - P3
Reporter: Shane Harvey Assignee: Louis Williams
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by TOOLS-2035 mongofiles_write_concern_mongos.js fa... Closed
Related
related to SERVER-33317 3.7 sharded clusters ignore create co... Closed
related to SERVER-40712 Clarify the behaviour of `db.dropData... Closed
related to SERVER-46668 createIndexes command does not honor ... Closed
related to SERVER-53254 increase writeConcern timeout for dro... Closed
is related to SERVER-34922 mongofiles sharded cluster write conc... Closed
is related to SERVER-47194 dropDatabase command does not honor w... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0
Steps To Reproduce:

1) disable replication on secondaries
2) run dropDatabase command with writeConcern:

{w:'majority', wtimeout:1}

3) dropDatabase hangs (forever?) instead of raising a wtimeout error

Sprint: Storage NYC 2018-05-21, Storage NYC 2018-06-04
Participants:
Linked BF Score: 0

 Description   

It looks like the dropDatabase command ignores write concern wtimeout on 3.7 replica sets. Is this intentional?



 Comments   
Comment by Githook User [ 23/May/18 ]

Author:

{'username': 'louiswilliams', 'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com'}

Message: SERVER-34776 dropDatabase should respect user provided writeConcern

(cherry picked from commit 416d82de9360f821c431b24f591cb3a0c777835f)
Branch: v4.0
https://github.com/mongodb/mongo/commit/7c1d8edae557be6c135e5f60720c116c0fef7433

Comment by Githook User [ 22/May/18 ]

Author:

{'username': 'louiswilliams', 'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com'}

Message: SERVER-34776 dropDatabase should respect user provided writeConcern
Branch: master
https://github.com/mongodb/mongo/commit/416d82de9360f821c431b24f591cb3a0c777835f

Comment by Eric Milkie [ 17/May/18 ]

I wouldn't ignore what the user provides. Instead, I would wait for "majority" and then wait for what the user provided; it will be a no-op unless the user provided something stronger than "majority".

Comment by Louis Williams [ 17/May/18 ]

Does anybody have any input as to whether dropDatabase should also respect the user's "w" parameter? At the moment waiting for the collection drops to be replicated defaults to "majority", but anything a user provides is ignored. milkie?

Comment by Louis Williams [ 16/May/18 ]

It looks like dropDatabases uses a hardcoded wTimeout of 10 minutes when waiting for the collection drops to replicate. We should should just use the user-supplied wtimeout if it is provided.

Comment by Esha Maharishi (Inactive) [ 09/May/18 ]

Yeah, actually that code in appendMajorityWriteConcern() is correct anyway (I realized when trying to repro) - passing the entire writeConcern object preserves the client's wtimeout.

Handing this off to storage (it may need to be passed to repl) to investigate the issue on non-sharded replica sets.

Comment by Esha Maharishi (Inactive) [ 09/May/18 ]

Oh, hm, I just assumed it was about mongos since Kal assigned it to me... Ok, this may be a storage issue (in addition to the sharding one), then.

Comment by Shane Harvey [ 09/May/18 ]

I don't understand. This issue is about dropDatabase on replica sets but your comment only talks about mongos. Will fixing the appendMajorityWriteConcern() method also fix the replica sets issue?

Comment by Esha Maharishi (Inactive) [ 09/May/18 ]

This seems like a legitimate and minor/easily fixable bug - mongos passes the user's writeConcern to the config server (which runs the business logic for dropping the database from the cluster) by calling appendMajorityWriteConcern(). However, appendMajorityWriteConcern() only propagates the wTimeout if the 'w' was something other than 'majority' (if it was majority, the user's wTimeout is ignored).

I'll fix the method to propagate the wTimeout even if 'w' is 'majority', and ensure we have jstest coverage of propagating writeConcern for all commands mongos forwards to the config server.

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