Reshard to the same key for adding and removing shards
Parent: Shard Key Design and Resharding as Cost Levers · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Reshard to the same key for adding and removing shards. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- MongoDB 8.0 introduced resharding with the existing shard key; use reshardCollection with that key and forceRedistribution: true to redistribute data when adding or removing shards. (medium confidence) (verified as of 2026-10-14) [source]
- Online resharding still requires applications to tolerate approximately two seconds of blocked writes at cutover. MongoDB recommends chunk migrations when this interruption is unacceptable. (medium confidence) (verified as of 2026-10-14) [source]
Measurements and reference values
- MongoDB's planning guidance requires available storage per recipient shard of 2 × (collection size + index size) / recipient shard count, a minimum 24-hour oplog window, I/O capacity utilization below 50%, and CPU load below 80%. These requirements can necessitate temporary capacity increases. (medium confidence) (verified as of 2026-10-14) [source]
Comparisons and alternatives
- Percona reports about three minutes on MongoDB 7.0.18 versus under one minute on 8.0.8 for a 3.5 GB collection on idle two-shard clusters with 4 CPUs and 16 GB RAM per node. That test changes the key from name to email; it does not benchmark same-key shard addition or removal. (low confidence) (verified as of 2025-06-26) [source]
- SERVER-111411 records a time-series same-key resharding bug involving translation of the metadata field name and an InvalidOptions response despite supplying the correct key. Its July 20, 2026 update lists resolution Fixed and fix versions 8.3.0-rc0, 8.2.10, and 8.0.28; this is patch-specific history rather than evidence of a defect in every current version. (low confidence) (verified as of 2026-07-20) [source]
Facts and statements
- The documented procedure changes cluster membership first, then reshards sharded collections one at a time. forceRedistribution rewrites data across shards that are not draining; removing a shard therefore requires keeping its servers running while data drains. (medium confidence) (verified as of 2026-10-14) [source]
- Same-key resharding writes to recipient shards in parallel and drops the original collection at completion. It avoids the orphan-document range cleanup of incremental migrations; a shard can participate in at most one range migration at a time. (medium confidence) [source]
- Plan for a brief commit-phase write block and increased latency: MongoDB requires applications to tolerate approximately two seconds. Describing same-key resharding as having no workload impact omits this operational constraint. (medium confidence) [source]
- Monitor the operation with $currentOp, including totalOperationTimeElapsedSecs and remainingOperationTimeEstimatedSecs; also monitor replication lag, CPU, disk I/O, network activity and oplog growth during the rewrite. (medium confidence) [source]
- MongoDB 8.0 resharding scans in natural order and clones documents before building indexes. Genex describes the same clone-then-index sequence; these optimizations explain improved bulk redistribution without establishing a universal speedup factor. (medium confidence) [source]
- Cost-planning inference: budget temporary storage and resource headroom before treating faster redistribution as a cost saving. Percona warns that large resharding jobs can still take hours or days, and Genex identifies increased CPU, I/O, network, storage and oplog activity. Neither provides measured net savings for same-key shard removal. (medium confidence) [source]
- The operation clones data, builds indexes, applies pending writes, then replaces the original collection at commit. MongoDB attributes faster redistribution than chunk migrations to parallel writes across shards; each shard can participate in only one chunk migration at a time. (medium confidence) [source]
- Monitor resharding with $currentOp and track replication lag, CPU, disk I/O, and oplog activity. MongoDB's tutorial warns that remainingOperationTimeEstimatedSecs is pessimistic and initially reports -1. (medium confidence) (verified as of 2026-10-14) [source]
- Faster resharding remains a resource-intensive maintenance operation. Percona cautions against extrapolating its small idle-cluster experiment to terabyte-scale busy deployments, and GenexDBS advises scheduling low-traffic periods and validating cluster health and data distribution afterward. (medium confidence) [source]
Children
- Same-key resharding resource sizing (frontier)
- Resharding during shard draining (frontier)
- Same-key resharding patch compatibility (frontier)
Frontier under this node: Resharding during shard draining, Same-key resharding patch compatibility, Same-key resharding resource sizing