Reshard a MongoDB sharded collection with reshardCollection
domain: mongodb · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Verify you are running MongoDB 5.0 or later (reshardCollection was introduced in 5.0); connect to mongos with mongosh
Stop or pause the balancer before resharding: sh.stopBalancer(); confirm with sh.getBalancerState()
Issue the reshard command with the new shard key: db.adminCommand({ reshardCollection: 'mydb.orders', key: { customerId: 1 } }); MongoDB sets a default max-write-block duration of 2 seconds during cut-over
Monitor resharding progress: db.adminCommand({ currentOp: true, type: 'op', desc: /reshard/ }) and watch for the oplogSize and remainingOperationTimeEstimated fields
The operation runs in the background and completes with a brief write block for the final cut-over; the minimum total duration is 5 minutes regardless of data size
After completion, re-enable the balancer: sh.startBalancer(); verify chunk distribution with sh.status()
Known gotchas
Retryable writes initiated before or during resharding can be retried for up to 5 minutes after completion; ensure your driver's retryWrites setting is compatible with your application's idempotency guarantees
The shard key chosen for resharding must be immutable for each document for the lifetime of that document; picking a key that applications update will cause orphaned documents after resharding
In MongoDB 8.0+ you can reshard a collection on the same shard key with forceRedistribution: true to redistribute data to newly added shards without changing the key schema
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?