Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
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.
esha.maharishi@10gen.com commented on Tue, 10 Sep 2019 15:50:31 +0000: jeff.yemin, SERVER-33973 was backported after 4.2.0, so it would have shown up in 4.2.1 jeff.yemin commented on Tue, 10 Sep 2019 15:43:28 +0000: esha.maharishi ok, I was surprised by the need to backport because I never saw the failure on 4.2.0. esha.maharishi@10gen.com commented on Tue, 10 Sep 2019 15:20:33 +0000: 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. xgen-internal-githook commented on Tue, 10 Sep 2019 01:59:05 +0000: 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 xgen-internal-githook commented on Mon, 9 Sep 2019 14:32:25 +0000: 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 esha.maharishi@10gen.com commented on Thu, 29 Aug 2019 19:17:04 +0000: 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. esha.maharishi@10gen.com commented on Tue, 27 Aug 2019 21:59:46 +0000: 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 kaloian.manassiev commented on Fri, 16 Aug 2019 12:53:24 +0000: 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.
~$ 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 }