-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 5.3.0, 6.0.0, 6.1.0, 6.2.0-rc6
-
Component/s: None
-
Fully Compatible
-
ALL
-
v6.3, v6.0
-
Sharding EMEA 2023-02-06, Sharding EMEA 2023-02-20, Sharding EMEA 2023-03-06, Sharding EMEA 2023-03-20, Sharding EMEA 2023-04-03
-
5
It may happen that defragmentation start over right after finishing.
This is the flow that leads to a defragmentation undesired restart on collA:
1. The Balancer thread reads all the collection entries when collA defragmentation didn't finish yet.
2. Defragmentation on collA finishes and the BalancerSecondary thread removes the _defragmentationStates collection entry and clears the defragmentation flags on collA config.collections entry
3. The Balancer calls startCollectionDefragmentation using a stale config.collections entry for collA and an updated _defragmentationStates map
4. Due to point 3, on startCollectionDefragmentation function, we don't return on this condition and we init the collection defragmentation again.
Note that when defragmentation starts over unexpectedly, the defragmentCollection field for collA remains unset, while the defragmentationPhase field has a valid defragmentation phase other than null.
- is caused by
-
SERVER-61555 Link the defragmentation policy to ConfigureCollectionAutoSplit
- Closed
- is depended on by
-
SERVER-71917 Update defragmentation tests to use variable doc sizes
- Closed