[SERVER-42842] Unable to drop collection in admin database of sharded cluster Created: 16/Aug/19  Updated: 29/Oct/23  Resolved: 10/Sep/19

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.2.1, 4.3.1

Type: Bug Priority: Major - P3
Reporter: Jeffrey Yemin Assignee: Esha Maharishi (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
is related to SERVER-43144 _configsvrDropCollection should handl... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.2
Steps To Reproduce:

~$ mlaunch init --sharded 1 --replicaset --binarypath ./Downloads/mongodb-macos-x86_64-enterprise-4.3.0-824-g12c28db/bin
~$ mongo
MongoDB shell version v4.2.0
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("b1e26e37-36d6-4f3f-a0d5-ff9c1abff5dd") }
MongoDB server version: 4.3.0-824-g12c28db
MongoDB Enterprise mongos> use admin
switched to db admin
MongoDB Enterprise mongos> db.test.insert({_id: 1})
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise mongos> db.test.drop()
true
MongoDB Enterprise mongos> show collections
system.keys
system.version
test
MongoDB Enterprise mongos> db.test.find()
{ "_id" : 1 }

Sprint: Sharding 2019-08-26, Sharding 2019-09-09, Sharding 2019-09-23
Participants:

 Description   

I'm unable to drop a collection in the admin database of a sharded cluster. This is affecting the ability to execute some driver tests which write to this database.

The behavioral change occurred between v4.3.0-769-g81bb59c and v4.3.0-814-gb92fbdf.



 Comments   
Comment by Esha Maharishi (Inactive) [ 10/Sep/19 ]

jeff.yemin, SERVER-33973 was backported after 4.2.0, so it would have shown up in 4.2.1

Comment by Jeffrey Yemin [ 10/Sep/19 ]

esha.maharishi ok, I was surprised by the need to backport because I never saw the failure on 4.2.0.

Comment by Esha Maharishi (Inactive) [ 10/Sep/19 ]

jeff.yemin, it should be fixed on the affected branches now that I backported this to 4.2. Closing, let me know if you have any further issues.

Comment by Githook User [ 10/Sep/19 ]

Author:

{'name': 'Esha Maharishi', 'username': 'EshaMaharishi', 'email': 'esha.maharishi@mongodb.com'}

Message: SERVER-42842 Unable to drop collection in admin database of sharded cluster

(cherry picked from commit 02dbec04bad4a6b138a204a29644a0524e5c3123)
Branch: v4.2
https://github.com/mongodb/mongo/commit/17174308e001e0ed3095a4599830636570f791e3

Comment by Githook User [ 09/Sep/19 ]

Author:

{'username': 'EshaMaharishi', 'email': 'esha.maharishi@mongodb.com', 'name': 'Esha Maharishi'}

Message: SERVER-42842 Unable to drop collection in admin database of sharded cluster
Branch: master
https://github.com/mongodb/mongo/commit/02dbec04bad4a6b138a204a29644a0524e5c3123

Comment by Esha Maharishi (Inactive) [ 29/Aug/19 ]

To avoid any other unintended side effects, I'd like to maintain the previous behavior of having drops in the admin and config databases for a namespace not in the sharding catalog only execute on the config server (my second suggestion above).

I'm working on a patch for this now.

Comment by Esha Maharishi (Inactive) [ 27/Aug/19 ]

jeff.yemin, this started failing with SERVER-33973. Before, if the config server did not find the collection in the sharding catalog but did find the database, the config server used to forward the drop to the primary shard for the database.

For the admin database, the config server is the primary shard.

With SERVER-33973, if the config server does not find the collection in the sharding catalog, the config serverĀ  runs ShardingCatalogManager::ensureDropCollectionCompleted, which forwards the drop to all shards returned by ShardingCatalogClient::getAllShards, which does not include the config server shard since the config shard is not listed in config.shards.

I'm not sure what the best recourse is yet, and will think about it tomorrow. We could make the config server also forward the drop to the config shard, or we could do a check earlier to make the config server run the drop against itself for the admin (and config, which has the same issue) database.

CC blake.oler, kaloian.manassiev

Comment by Kaloian Manassiev [ 16/Aug/19 ]

I am able to reproduce it on the latest master in a sharded cluster and it doesn't happen in an unsharded cluster. Probably due to some changes made for the Tracking Unsharded Collections project.

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