[SERVER-53463] Consider making the range-deleter synchronously wait for majority Created: 21/Dec/20  Updated: 27/Oct/23  Resolved: 08/Nov/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 4.9.0, 4.4.2
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Gone away Votes: 0
Labels: tommaso-triage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-53471 Set rangeDeleterBatchSize to 128 Closed
Assigned Teams:
Sharding EMEA
Participants:
Case:

 Description   

After a range is deleted, the collection lock is released and there is a wait for the deletion to become majority committed. Such wait is synchronous in 4.2 and asynchronous in 4.4.

As a side effect, a range deletion task can be scheduled right after the previous one causing long unavailability of the collection for any operation due to this lock being continuously acquired by the range-deleter thread.

While r/w/chunk operations and transactions can timeout waiting for the for the lock, there is no such constraint for the range-deleter and this makes it even more probable for it to get the precedence.



 Comments   
Comment by Tommaso Tocci [ 08/Nov/21 ]

 This problem have been solved by SERVER-47699 because we are now using yield auto policy for processing range deleter batches.

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