[SERVER-49526] configsvrReshardCollection should calculate new initial split points Created: 15/Jul/20  Updated: 29/Oct/23  Resolved: 23/Mar/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 5.0.0-rc0

Type: Task Priority: Major - P3
Reporter: Janna Golden Assignee: Randolph Tan
Resolution: Fixed Votes: 0
Labels: PM-234-M3, PM-234-T-new-split
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-49524 Add functionality to pick new split p... Closed
Duplicate
is duplicated by SERVER-49524 Add functionality to pick new split p... Closed
Problem/Incident
causes SERVER-58048 Resharding's initial split points for... Closed
Related
is related to SERVER-53572 verifyTemporaryReshardingChunksMatchE... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2020-08-10, Sharding 2020-08-24, Sharding 2020-11-16, Sharding 2020-11-30, Sharding 2020-12-14, Sharding 2020-12-28, Sharding 2021-01-11, Sharding 2021-01-25, Sharding 2021-02-22, Sharding 2021-03-08, Sharding 2021-03-22, Sharding 2021-04-05
Participants:
Story Points: 2

 Description   

The config server needs to create new initial split points using the ReshardingSplitPolicy. There are two options:

1. configsvrReshardCollection does this and passes the generated chunks to the resharding coordinator using setInitialChunksAndZones. If we go this route we must avoid generating new initial chunks if we're retrying configsvrReshardCollection and a ReshardingCoordinatorService already exists on disk.
2. The coordinator does this as a part of _init(). This mean we only pass zones with setInitialChunksAndZones, unless we are in a test environment and need to pass the preset chunks.



 Comments   
Comment by Githook User [ 23/Mar/21 ]

Author:

{'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}

Message: SERVER-49526 configsvrReshardCollection should calculate new initial split points
Branch: master
https://github.com/mongodb/mongo/commit/38df2a19a17bd90c70ee0a490afb824977b655c8

Comment by Max Hirschhorn [ 17/Nov/20 ]

Note that there's a bug in the current implementation of the _configsvrReshardCollection command. The _configsvrReshardCollection command uses the chunks from the existing sharded collection as the definition for the chunks for the temporary resharding collection. This means omitting _presetReshardedChunks in reshardCollection causes the chunks to use the old shard key pattern.

resharding_clones_initial_data-configRS:PRIMARY> db.getSiblingDB("config").chunks.find({ns: /^reshardingDb.system.resharding/}).pretty()
{
    "_id" : ObjectId("5fb3e56ff30c2d5624d5ddf3"),
    "ns" : "reshardingDb.system.resharding.2a746ffa-c252-4d20-b101-270e2d08e22d",
    "min" : {
        "oldKey" : { "$minKey" : 1 }
    },
    "max" : {
        "oldKey" : 0
    },
    "shard" : "resharding_clones_initial_data-rs0",
    "lastmod" : Timestamp(2, 0),
    "lastmodEpoch" : ObjectId("5fb3e56ff30c2d5624d5dde7")
}
{
    "_id" : ObjectId("5fb3e56ff30c2d5624d5ddf2"),
    "ns" : "reshardingDb.system.resharding.2a746ffa-c252-4d20-b101-270e2d08e22d",
    "min" : {
        "oldKey" : 0
    },
    "max" : {
        "oldKey" : { "$maxKey" : 1 }
    },
    "shard" : "resharding_clones_initial_data-rs1",
    "lastmod" : Timestamp(2, 1),
    "lastmodEpoch" : ObjectId("5fb3e56ff30c2d5624d5dde7")
}

Generated at Thu Feb 08 05:20:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.