[SERVER-65535] Ensure consistent orphaned documents count across sharded rename Created: 13/Apr/22  Updated: 06/Feb/24

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: 6.0.0-rc0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: Pierlauro Sciarelli
Resolution: Unresolved Votes: 0
Labels: 7.0UpDown
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-65540 Build range deleter service Closed
Assigned Teams:
Sharding EMEA
Sprint: Sharding EMEA 2023-09-18, Sharding EMEA 2023-10-02, Sharding EMEA 2023-10-16, Sharding EMEA 2023-10-30, CAR Team 2023-11-13, CAR Team 2023-11-27, CAR Team 2023-12-11, CAR Team 2023-12-25, CAR Team 2024-01-08, CAR Team 2024-01-22, CAR Team 2024-02-05, CAR Team 2024-02-19
Participants:

 Description   

Between the moment a rename collection participant snapshots range deletion task documents and the moment they are restored, the range-deleter could potentially process some deletions.

If that happens, it would mean that:

  • The count of orphaned documents for the target collection on disk after the rename may be off for a while
  • The BalancerStatsRegistry may track wrong statistics for a while

 

PS: "a while" means until existing range deletions are drained.


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