Purpose of this ticket is to simplify the scoped range deleter lock in order to solve all in once the problems listed in SERVER-70322, SERVER-70340 and SERVER-70408.
The idea is to get rid of the fine grained locking because it has provoked more race conditions than advantages and because using it does not result in relevant performance improvements.
We could provide a simple global scoped range deleter lock to be taken in different modes depending on the context.
- Initializing balancer stats registry: MODE_S
- Initializing range deleter service: MODE_S
- Updating the number of orphans: MODE_IX
Only v6.1+ versions (to synchronize with range deleter service initialization)
- Creating a new range deletion task document MODE_IX
- Unsetting the pending field MODE_IX
Only v6.0+ versions (to synchronize with upgrade/downgrade)
- Setting the number of orphans on upgrade MODE_X
- Unsetting the number of orphans on downgrade MODE_X
- is duplicated by
-
SERVER-70322 BalancerStatsRegistry inappropriately constructs ResourceId outside ResourceIdFactory
- Closed
-
SERVER-70340 Range deleter can cause migration lock acquisition timeouts
- Closed
-
SERVER-70408 Migrations for collection undergoing range deletion must not stall in v6.0
- Closed
- is related to
-
SERVER-70888 ScopedRangeDeleterLock might lead to a deadlock on stepdown
- Closed