[SERVER-76973] Customers still able to drop shard key index in older server versions Created: 10/May/23  Updated: 09/Jun/23  Resolved: 09/Jun/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.4.18
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Simon Jacobs Assignee: [DO NOT USE] Backlog - Sharding NYC
Resolution: Won't Do Votes: 0
Labels: indexes, shard-key
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-6491 Prevent dropping shard key index when... Closed
Assigned Teams:
Sharding NYC
Participants:

 Description   

After discussing this issue with garaudy.etienne@mongodb.com, I'm opening this ticket to request a backport of SERVER-6491 to older versions of Mongo, 4.4 and up if possible, considering there may be a number of customers with extensions as we go through the EOL process for these versions.

My customer was able to drop a shard key in production on Shard-0 causing a long queue of deletion tasks resulting in performance degradation. The customer eventually scaled up to allow for additional headroom for the deletions to catch up once the index was rebuilt. Additional context is available in the ticket linked. Their server version at the time was 4.4.18. 



 Comments   
Comment by Max Hirschhorn [ 09/Jun/23 ]

simon.jacobs@mongodb.com, safely backporting the work to MongoDB 5.0 depended on the work in PM-1965 to adding certain synchronization for DDL operations in sharded clusters. It isn't possible to do the same on the 4.4 branch for that reason.

Comment by Simon Jacobs [ 09/Jun/23 ]

Thanks r.scott@mongodb.com, feasible that it will be backported to 4.4 eventually or not given that EOL is approaching?

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