Resharding redistributes a sharded collection by creating an implicitly empty collection with a new shard key and copying data chunk by chunk. It addresses uneven distribution and query-performance problems caused by an inadequate shard key. section 9.3.7 section 9.3.3
Plan the operation around these practical conditions:
- Check every shard for at least 1.2 times the collection size in available disk space, I/O below 50%, and CPU below 80%. section 9.3.7
- Expect the copy duration to grow with collection size; applications can continue reading and modifying the collection during copying, although the balancer requires a two-second lock to determine the new arrangement. section 9.3.7
- Filter queries by both the existing and new shard keys until resharding completes, then remove the old-key filters. section 9.3.7
- Avoid starting resharding while an index is being built, and schedule the operation during lower application traffic when possible. section 9.3.7
Force redistribution in MongoDB 8.0
When the desired shard key is unchanged, MongoDB 8.0 permits redistribution with forceRedistribution: true; zones can also direct data to specific locations. section 9.4.4
db.adminCommand({
reshardCollection: "<database>.<collection>",
key: <new shardkey>
})
Start a resharding operation by naming the collection and supplying its new shard key. section 9.3.7
db.getSiblingDB("admin").aggregate([
{ $currentOp: { allUsers: true, localOps: false } },
{
$match: {
type: "op",
"originatingCommand.reshardCollection": "<database>.<collection>"
}
}
])
Inspect the current operation output for an active reshardCollection operation. section 9.3.7
