[SERVER-76167] Optimize range deletions handling in rename participants Created: 17/Apr/23  Updated: 26/Oct/23

Status: Open
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: Backlog - Catalog and Routing
Resolution: Unresolved Votes: 0
Labels: oldshardingemea, shardingemea-qw
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Catalog and Routing
Participants:
Linked BF Score: 12
Story Points: 2

 Description   

Rename participants are snapshotting range deletions by namespace before restoring them. This results in:

  • Not using an index while scanning config.rangeDeletions that only has a {collectionUUID, min, max} secondary index
  • Snapshotting multiple times the same ranges when several renames are executed back and forth between the same namespaces (as in some FSMs)
    • This means exponentially incrementing the number of range deletion documents, making subsequent renames on the same collection slower over time

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