[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: |
|
||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||
| Backport Requested: |
v4.2
|
||||||||||||||||||
| Steps To Reproduce: |
|
||||||||||||||||||
| 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, |
| 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: (cherry picked from commit 02dbec04bad4a6b138a204a29644a0524e5c3123) |
| Comment by Githook User [ 09/Sep/19 ] |
|
Author: {'username': 'EshaMaharishi', 'email': 'esha.maharishi@mongodb.com', 'name': 'Esha Maharishi'}Message: |
| 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 For the admin database, the config server is the primary shard. With 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. |
| 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. |