[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: |
|
||||||||||||
| Assigned Teams: |
Sharding EMEA
|
||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| 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 |