-
Type: Task
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
Sharding EMEA
-
Sharding EMEA 2023-02-20, Sharding EMEA 2023-03-06, Sharding EMEA 2023-03-20
-
3
The top chunk migration was thought as a way to distribute the write load for applications inserting a lot of documents with non-hashed incremental shard keys.
It turns out that for heavy workloads it could cause more harm than good:
- Trying to move the right-most chunk while writing on it could result in very long migrations that can't reach the catch-up phase and eventually fail after hours.
- In a balanced environment, it results in ping-pong (moving continuously the top chunk on another shard, then split, then move back) that can bring to increased migrations unavailability due to the waiting for overlapping range deletions to finish on the receiver.
- depends on
-
SERVER-66652 Remove NoMoreAutoSplitter feature flag
- Closed
- duplicates
-
SERVER-66652 Remove NoMoreAutoSplitter feature flag
- Closed
- is depended on by
-
SERVER-65322 Get rid of legacy `moveChunk` path once NOMAS milestone 1 is completed
- Closed
- is duplicated by
-
SERVER-44193 Remove Top Chunk Optimisation
- Closed
- related to
-
SERVER-75065 Complete TODO listed in SERVER-61557
- Closed
-
SERVER-44192 Introduce metrics to measure the usefulness of the Top Chunk Optimisation
- Closed