Adding a new shard is the standard way to scale a MongoDB sharded cluster horizontally. But data doesn't always redistribute automatically — the new shard can sit idle while old shards stay under pressure. This article gives you a systematic process to diagnose why data isn't balancing and resolve the imbalance.
How balancing works
Data balance between shards depends entirely on the MongoDB built-in balancer. The balancer redistributes data by migrating chunks from overloaded shards to underloaded ones. If the balancer isn't running, is misconfigured, or is blocked by collection properties, chunks stay where they are.
The diagnostic process follows two layers:
Balancer state — Confirm the balancer is enabled, active, and running within a valid window.
Data migratability — Identify collection properties that prevent the balancer from moving data, such as unsharded collections, data volumes below the balancing threshold, or the presence of jumbo chunks.
Diagnose the balancer state
The balancer is the sole mechanism for chunk migration. Start here before investigating anything else.
Check if the balancer is enabled
In mongosh, run:
sh.getBalancerState()If the output is false, the balancer is disabled. Enable it by following Manage the MongoDB balancer.
Check the active window
The balancer only runs during its configured active window. If the current time falls outside that window, no migration occurs.
Run the following command to check the active window configuration:
db.getSiblingDB("config").settings.find({_id:"balancer"})Example output:
{ _id: 'balancer', activeWindow: { start: '02:00', stop: '04:00' } }If the window is too short or overlaps with peak traffic hours, extend it to cover a longer off-peak period. The following example sets the window to 02:00–06:00 daily:
db.getSiblingDB("config").settings.updateOne(
{ _id: "balancer" },
{ $set: { activeWindow: { start: "02:00", stop: "06:00" } } },
{ upsert: true }
)Check if balancing is already in progress
After adding a shard, the balancer needs time to migrate existing data. Imbalance during this period is expected.
Run the following command to check whether a migration task is active:
sh.isBalancerRunning()If the output is true, balancing is in progress. Wait for it to complete. To track progress, see How to check the progress of adding or removing a shard node.
Analyze data migratability
If the balancer is enabled and running but data still isn't moving, the problem is likely in the collection properties. The following conditions can block migration.
Check for large unsharded collections
A database can contain both sharded and unsharded collections. Unsharded collections store all their data on the database's primary shard — the balancer cannot migrate this data. If your largest collections aren't sharded, they'll never reach the new shard.
Check if sharded collections are below the migration threshold (MongoDB 6.0+)
Starting in MongoDB 6.0.3, the balancer only migrates chunks when the data volume difference between shards for a given collection reaches a threshold. The default threshold is three times the chunk size.
With the default chunk size of 128 MB, the data imbalance between two shards must reach at least 384 MB before the balancer triggers migration for that collection. Collections with total data smaller than this threshold are considered balanced and are left alone.
To check how a collection's data is distributed across shards, run:
db.<collection>.getShardDistribution()If most of a sharded collection's data is concentrated on one shard and the imbalance is below 384 MB (at default chunk size), the balancer won't act. Reduce the collection's chunkSize to lower the threshold and trigger migration:
// This example sets chunkSize to 16 MB for test_db.test_coll.
// Adjust chunkSize based on your collection's data volume and distribution.
db.adminCommand({
configureCollectionBalancing: "test_db.test_coll",
chunkSize: 16 // Unit: MB. Default for MongoDB 6.0+: 128 MB
})After the migration completes, verify the distribution improved:
db.<collection>.getShardDistribution()Performance and configuration considerations
Balancing performance overhead
Chunk migration (moveChunk) and the subsequent range deletion (RangeDeleter) consume CPU and disk I/O on both the source and destination shards. To avoid impacting online traffic, set the balancer's active window to off-peak hours.
`chunkSize` configuration risk (MongoDB versions earlier than 6.0)
In MongoDB versions earlier than 6.0, setting chunkSize too small can create an excessive number of chunks. This increases config server metadata overhead and causes the balancer to run too frequently. Set chunkSize based on the total data volume and expected growth rate of the collection.