[SERVER-71609] `splitOrMarkJumbo` must not over-split chunks Created: 24/Nov/22  Updated: 29/Oct/23  Resolved: 21/Dec/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0.4, 6.3.0-rc0

Type: Bug Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: Pierlauro Sciarelli
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v6.2, v6.0
Sprint: Sharding EMEA 2022-12-12, Sharding EMEA 2022-12-26
Participants:

 Description   

Now that balancing is based on data size, chunks are by default of heterogeneous sizes and it is not needed anymore to over-split them (better to keep the routing table as small as possible).

When a migration fails because of a frequent shard key, the splitOrMarkJumbo method is called and currently takes care of dividing the chunk based on the list of split points [potentially multiple].

This method should be simplified in order to split only on the first available point because it is only needed to mark as jumbo the chunk containing the frequent shard key. This can be achieved by passing a vector only containing the first split point as argument to the splitChunkAtMultiplePoints function.



 Comments   
Comment by Githook User [ 09/Jan/23 ]

Author:

{'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}

Message: SERVER-71609 `splitOrMarkJumbo` must not over-split chunks
Branch: v6.0
https://github.com/mongodb/mongo/commit/4a948883cdff5003b215857244251179334c6ef7

Comment by Githook User [ 21/Dec/22 ]

Author:

{'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}

Message: SERVER-71609 `splitOrMarkJumbo` must not over-split chunks
Branch: master
https://github.com/mongodb/mongo/commit/7ac8ffa47bfe83e12c361f083fdd96a721ffae60

Generated at Thu Feb 08 06:19:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.