-
Type: Bug
-
Resolution: Incomplete
-
Priority: Major - P3
-
None
-
Affects Version/s: 4.0.10
-
Component/s: None
-
None
-
ALL
We have a somewhat large and hot MongoDB cluster. Size of each shard is ~400GiB. Autosplitter is configured to split chunks when they exceed 64 MB (default value). However, I see a lot of much larger chunks. Some chunks are as large as 400 MB. The chunks are in a hot collection that is constantly being inserted and updated. Distribution of hot and cold documents across chunks is even (we use hashed sharding on _id with auto generated ObjectId).
As far as I can see, autosplitter is throttled by getting a token from the token pool with 5 tokens in it. I suspect that in a large shard with unevenly hot collections autosplitter activity is unfairly distributed in favor of hotter collections with a possibility of never getting autosplitter attention for colder collections.
We've hit hard into this issue when added new shards to our cluster and balancer started moving chunks. When balancer spots chunk that is too big, it splits the chunk and balances smaller chunk to new shards. As a result, with evenly distributed chunks across the cluster we have 3x documents in older shards and 1x documents in newer shards.
- is related to
-
SERVER-13806 Need better detection and reporting of the existence of jumbo chunks
- Closed
-
SERVER-9287 Decision to split chunk should happen on shard mongod, not on mongos
- Closed
-
SERVER-10024 cluster can end up with large chunks that did not get split and will time out on migration
- Closed