[SERVER-33973] Force cleanup of possibly remaining partial data (from failed collection/database drop) when rerunning dropCollection command Created: 19/Mar/18 Updated: 29/Oct/23 Resolved: 01/Aug/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.1, 4.3.1 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Blake Oler |
| Resolution: | Fixed | Votes: | 5 |
| Labels: | ShardingAutomationSupport, former-quick-wins, gm-ack | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v4.2, v4.0, v3.6
|
||||||||||||||||||||||||||||||||||||
| Sprint: | Sharding 2019-05-06, Sharding 2019-06-17, Sharding 2019-07-15, Sharding 2019-07-29, Sharding 2019-08-12 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 15 | ||||||||||||||||||||||||||||||||||||
| Description |
|
As described in We should implement `cleanupOrphanedCollection`/`cleanupOrphanedDatabase` commands, which perform this cleanup and do proper checking and synchronization. The code for these manual commands will eventually become the basis for implementing consistent drops using a resumable task queue. |
| Comments |
| Comment by Blake Oler [ 26/Aug/19 ] |
|
Requesting backport to v3.6 as part of the solution for |
| Comment by Githook User [ 15/Aug/19 ] |
|
Author: {'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}Message: (cherry picked from commit 5c13fd19fab91e0aca666269129c51edab3380e2) |
| Comment by Githook User [ 01/Aug/19 ] |
|
Author: {'name': 'Blake Oler', 'username': 'BlakeIsBlake', 'email': 'blake.oler@mongodb.com'}Message: |
| Comment by Blake Oler [ 02/Jul/19 ] |
|
Ran into issues with the new dropCollection approach not working with the kill_aggregation and kill_rooted_or FSM workloads. A solution will be to allow dropCollection on the config server to pass up shard error codes. Running this by the downstream-changes email list. |
| Comment by Kaloian Manassiev [ 10/Jul/18 ] |
|
Instead of implementing a cleanupOrphanedCollection command, I would instead prefer that we tighten the dropCollection command to always try to perform a full cleanup. This would make the command slower for the unsharded case, but it is guaranteed that it will always make forward progress and there will not be a need to introduce a separate "cleanup" command. The way it would work is:
alyson.cabral, schwerin - what are your thoughts about the customer impact of making the dropCollection operation in sharded clusters slower? I suspect that this will impact the cases where customers drop and create collections frequently, but since it is only the drop which will be slower, it would only matter if they recreate a collection with the same name. |
| Comment by Esha Maharishi (Inactive) [ 19/Mar/18 ] |
|
Nice! |