-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: 5.0.3, 6.0.0-rc11, 7.0.0-rc8
-
Component/s: Sharding
-
Sharding EMEA
-
Fully Compatible
-
ALL
-
v7.0, v6.0, v5.0
-
Sharding EMEA 2022-08-22, Sharding EMEA 2022-09-05, Sharding EMEA 2022-11-14, Sharding EMEA 2022-11-28, Sharding EMEA 2022-12-12, Sharding EMEA 2022-12-26, Sharding EMEA 2023-01-09, Sharding EMEA 2023-07-24, Sharding EMEA 2023-08-07
-
2
The $_internalReshardingOwnershipMatch aggregation stage is used by resharding to efficiently determine whether or not a document belongs to a particular shard under the new shard key pattern. It uses ChunkManager::keyBelongsToShard() to make this determination. However, findIntersectingChunk() will return nullptr and cause keyBelongsToShard() to always return false for a document {newKey1: MaxKey, newKey2: MaxKey} and a new shard key pattern {newKey1: 1, newKey2: 1}. This leads to no shard receiving the document and it being entirely lost as part of the resharding operation.
Note that once the resharding operation has started, the participant shards won't allow inserting more documents or updating existing documents to have all MaxKey values for its fields under the new shard key pattern.
{
"nMatched" : 0,
"nUpserted" : 0,
"nModified" : 0,
"writeError" : {
"code" : 61,
"errmsg" : "Cannot target single shard using key { newKey: MaxKey } for namespace reshardingDb.system.resharding.0407a566-91d8-4152-aa4a-6014f161680f"
}
}
- depends on
-
SERVER-71627 Refreshed cached collection route info will severely block all client request when a cluster with 1 million chunks
-
- Closed
-
- is related to
-
-
- Backlog
-
-
-
- Closed
-
- related to
-
SERVER-79549 Audit and perhaps consolidate the multiple implementations of ChunkRange::containsKey()
-
- In Progress
-