-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 5.0.3, 5.1.0-rc0
-
Component/s: None
-
None
-
Sharding EMEA 2021-11-15
Starting from v5.0, sharding a non-empty collection results in writes being blocked for a time proportional to the number of documents in the collection. As a result, sharding a collection containing a lot of documents means being just able to read it for a very long time.
The relevant difference between v4.4 and v5.0 is the context in which selectChunkSplitPoints is called in UnoptimizedSplitPolicy::createFirstChunks: in the older version it doesn't happen under the critical section while in the new one it happens after it gets acquired. The invoked splitVector command is quite slow because it scans the whole index to search for the initial split points.
- duplicates
-
SERVER-60420 The slow 'shardCollection' path performs heavy work under the critical section
- Closed