Balancer tuning and chunk migration cost
Parent: Shard Key Design and Resharding as Cost Levers · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Balancer tuning and chunk migration cost. 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
- Mydbops reported migrations failing after a 4.0.28-to-4.2.24 upgrade because corresponding indexes had different names despite matching keys. This is a historical incident, not proof of a current-version defect. (low confidence) (verified as of 2023-10-03) [source]
- For large redistribution, MongoDB documents same-key resharding from version 8.0 as an alternative to repeated migrations when its requirements are met; avoiding per-range donor cleanup can reduce cluster stress, but this is not a universal cost or speed guarantee. (high confidence) (verified as of 2026-10-14) [source]
How-to and procedures
- To reduce cleanup spikes, lower rangeDeleterBatchSize or increase rangeDeleterBatchDelayMS after confirming deletion is the bottleneck. Alibaba warns that excessive delay accumulates orphan cleanup and can cause overlapping migrations to time out. (high confidence) (verified as of 2026-10-27) [source]
Measurements and reference values
- Data-size balancing triggers at a per-collection difference of three times the configured range size: 384 MB at the 128 MB default. Changing range size also changes that threshold. (medium confidence) (verified as of 2026-03-28) [source]
- For ordinary size-based balancing, the per-collection imbalance threshold is three times configured range size: the documented 128 MB default implies 384 MB. Alibaba identifies community 6.0.3 as the policy boundary; chunk-count equality is not the target. (high confidence) (verified as of 2026-03-28) [source]
Problems, failure modes and limitations
- Shard-key and collection design influence ongoing migration demand. Balancer tuning can manage that work, but cannot guarantee that migration throughput keeps pace with a poorly distributed workload. (medium confidence) [source]
- A chunk containing one repeated shard-key value cannot be split further by the balancer. High-frequency keys can form indivisible jumbo chunks, so balancer tuning cannot replace sufficient shard-key cardinality. (high confidence) [source]
Comparisons and alternatives
- Schedule balancing during off-peak hours only if the window can keep up with required daily migration; too little available time leaves growing imbalance rather than eliminating migration work. (high confidence) [source]
Facts and statements
- Chunk migration reads documents on the donor, copies them to the recipient, and consumes disk, network and processing resources; frequent migrations can compete with application traffic. (medium confidence) [source]
- Each shard can participate in at most one migration at a time, limiting cluster concurrency to floor(n/2) for n shards; this constrains how quickly added capacity absorbs existing data. (high confidence) (verified as of 2026-10-14) [source]
- Leaving the balancer disabled for extended periods can degrade performance through shard imbalance; temporary suspension needs an explicit restart plan. (low confidence) [source]
- Secondary throttling can require per-document replication acknowledgment; disabling it does not remove majority-acknowledgment requirements around migration commit. (medium confidence) (verified as of 2026-10-14) [source]
- Cleanup normally overlaps subsequent migrations. Setting _waitForDelete=true serializes cleanup before the next migration, bypasses orphanCleanupDelaySecs, and can terminate secondary reads. (medium confidence) (verified as of 2026-10-14) [source]
- rangeDeleterBatchSize and rangeDeleterBatchDelayMS tune deletion pressure; smaller batches or longer delays can spread cleanup work over time. (low confidence) (verified as of 2026-10-14) [source]
- Using forceJumbo=true can block collection writes for a long period during migration; it is not a harmless balancing accelerator. (low confidence) (verified as of 2026-10-14) [source]
- Many small chunks increase routing metadata overhead. Merging adjacent eligible chunks reduces metadata volume; shrinking chunk size is therefore not a universally beneficial tuning choice. (medium confidence) [source]
- SERVER-22233 investigated replacing per-document w:2 waits with majority waits at stage boundaries. The historical ticket explains why secondary throttling deserves scrutiny, but supplies no current benchmark. (low confidence) [source]
- Range migration reads donor documents and writes recipient copies; donor cleanup adds cache and I/O pressure. These mechanisms explain resource cost, but do not establish a fixed monetary cost per migrated GB. (high confidence) [source]
- Smaller ranges improve distribution granularity but increase migration frequency and mongos overhead; larger ranges reduce those costs while tolerating more uneven data. Lowering chunkSize solely to force perfect balance therefore has a cost. (high confidence) [source]
- By default, another outgoing migration can begin before prior donor deletion finishes. Setting _waitForDelete=true makes cleanup block the next migration, trading migration throughput for serialized cleanup. (high confidence) (verified as of 2026-10-14) [source]
- An unset _secondaryThrottle skips per-document secondary acknowledgement waits, but migration commit still requires majority acknowledgement at specified phases. Disabling this throttle does not remove all replication waits. (high confidence) (verified as of 2026-10-14) [source]
- Data-volume balance and application-workload balance are separate goals. The balancer targets data distribution; evaluate CPU, memory and disk demand as well before treating equal bytes as evidence that the shard key uses capacity efficiently. (medium confidence) [source]
Children
- Balancer scheduling windows and migration backlog (frontier)
- Range-size thresholds and routing metadata (frontier)
- Secondary throttling and migration commit waits (frontier)
- Orphan cleanup pacing and secondary-read interruption (frontier)
- Jumbo ranges and migration failures (frontier)
Frontier under this node: Balancer scheduling windows and migration backlog, Jumbo ranges and migration failures, Orphan cleanup pacing and secondary-read interruption, Range-size thresholds and routing metadata, Secondary throttling and migration commit waits