[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: |
|
||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v4.0
|
||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: | 1) disable replication on secondaries 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: (cherry picked from commit 416d82de9360f821c431b24f591cb3a0c777835f) |
| Comment by Githook User [ 22/May/18 ] |
|
Author: {'username': 'louiswilliams', 'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com'}Message: |
| 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. |