Details
Description
1. The new zone range can conflict with the old zone range. If a user reshards from a hashed shard key to the same shard key but unhashed, there could be extraneous conflicting documents in the config.tags collection. This could cause issues with the balancer.
To reproduce:
const existingZoneName = 'x1'; |
assert.commandWorked(
|
st.s.adminCommand({addShardToZone: st.shard1.shardName, zone: existingZoneName}));
|
|
|
assert.commandWorked(st.s.adminCommand({
|
updateZoneKeyRange: ns,
|
min: {oldKey: NumberLong("4470791281878691347")}, |
max: {oldKey: NumberLong("7766103514953448109")}, |
zone: existingZoneName
|
}));
|
|
|
assert.commandWorked(mongos.adminCommand({
|
reshardCollection: ns,
|
key: {oldKey: 1},
|
unique: false, |
collation: {locale: 'simple'}, |
zones: [{
|
zone: existingZoneName,
|
min: {oldKey: NumberLong("4470791281878691346")}, |
max: {oldKey: NumberLong("7766103514953448108")} |
}],
|
numInitialChunks: 2,
|
}));
|
^This will cause the old zone range and new zone range to both still exist post-resharding. We don't delete the previous zones because the hashed and unhashed shard key have the same shard key shape.
2. If the zone ranges are the same for the new and old shard key, we will see a duplicate key error like SERVER-73763
Attachments
Issue Links
- is related to
-
SERVER-53432 Ensure that comparing resharding requested zones with the authoritative tags is protected by concurrency control
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
SERVER-58433 ReshardingCoordinatorService Transaction In bumpCollectionVersionAndChangeMetadataInTxn Possibly Too Large
-
- Closed
-