Manage Sharded Cluster Balancer

Check the Balancer State

sh.getBalancerState() checks if the balancer is enabled (i.e. that the balancer is permitted to run). sh.getBalancerState() does not check if the balancer is actively migrating data.

To see if the balancer is enabled in your sharded cluster, issue the following command, which returns a boolean:

sh.getBalancerState()

You can also see if the balancer is enabled using sh.status(). The currently-enabled field indicates whether the balancer is enabled, while the currently-running field indicates if the balancer is currently running.

Check if Balancer is Running

To see if the balancer process is active in your cluster:

1. Connect to any mongos in the cluster using the mongosh shell.

2. Use the following operation to determine if the balancer is running:

   sh.isBalancerRunning()

Configure Default Range Size

The default range size for a sharded cluster is 128 megabytes. In most situations, the default size is appropriate for splitting and migrating chunks. For information on how range size affects deployments, see details, see Range Size.

Changing the default range size affects ranges that are processes during migrations and auto-splits but does not retroactively affect all ranges.

Starting in MongoDB 6.1, automatic chunk splitting is not performed. This is because of balancing policy improvements. Auto-splitting commands still exist, but do not perform an operation. For details, see Balancing Policy Changes.

To configure default range size, see Modify Range Size in a Sharded Cluster.

Schedule the Balancing Window

In some situations, particularly when your data set grows slowly and a migration can impact performance, it is useful to ensure that the balancer is active only at certain times. The following procedure specifies the activeWindow, which is the timeframe during which the balancer will be able to migrate chunks:

use config

sh.startBalancer()

db.settings.updateOne(
   { _id: "balancer" },
   { $set: { activeWindow : { start : "<start-time>", stop : "<stop-time>" } } },
   { upsert: true }
)

Remove a Balancing Window Schedule

If you have set the balancing window and wish to remove the schedule so that the balancer is always running, use $unset to clear the activeWindow, as in the following:

use config
db.settings.updateOne( { _id : "balancer" }, { $unset : { activeWindow : true } } )

Disable the Balancer

By default, the balancer may run at any time and only moves chunks as needed. To disable the balancer for a short period of time and prevent all migration, use the following procedure:

1. Connect to any mongos in the cluster using the mongosh shell.

2. Issue the following operation to disable the balancer:

   sh.stopBalancer()

   If a migration is in progress, the system will complete the in-progress migration before stopping.

   Starting in MongoDB 6.1, automatic chunk splitting is not performed. This is because of balancing policy improvements. Auto-splitting commands still exist, but do not perform an operation. For details, see Balancing Policy Changes.

   In MongoDB versions earlier than 6.1, sh.stopBalancer() also disables auto-splitting for the sharded cluster.

3. To verify that the balancer will not start, issue the following command, which returns false if the balancer is disabled:

   sh.getBalancerState()

   Optionally, to verify no migrations are in progress after disabling, issue the following operation in the mongosh shell:

   use config
   while( sh.isBalancerRunning() ) {
             print("waiting...");
             sleep(1000);
   }

db.adminCommand( { balancerStop: 1 } )

Enable the Balancer

Use this procedure if you have disabled the balancer and are ready to re-enable it:

1. Connect to any mongos in the cluster using the mongosh shell.

2. Issue one of the following operations to enable the balancer:

   From the mongosh shell, issue:

   sh.startBalancer()

   Note

   To enable the balancer from a driver, use the balancerStart command against the admin database, as in the following:

   db.adminCommand( { balancerStart: 1 } )

   Starting in MongoDB 6.1, automatic chunk splitting is not performed. This is because of balancing policy improvements. Auto-splitting commands still exist, but do not perform an operation. For details, see Balancing Policy Changes.

   In MongoDB versions earlier than 6.1, sh.startBalancer() also enables auto-splitting for the sharded cluster.

Disable Balancing During Backups

If MongoDB migrates a chunk during a backup, you can end with an inconsistent snapshot of your sharded cluster. Never run a backup while the balancer is active. To ensure that the balancer is inactive during your backup operation:

• Set the balancing window so that the balancer is inactive during the backup. Ensure that the backup can complete while you have the balancer disabled.

• manually disable the balancer for the duration of the backup procedure.

If you turn the balancer off while it is in the middle of a balancing round, the shut down is not instantaneous. The balancer completes the chunk move in-progress and then ceases all further balancing rounds.

Before starting a backup operation, confirm that the balancer is not active. You can use the following command to determine if the balancer is active:

!sh.getBalancerState() && !sh.isBalancerRunning()

When the backup procedure is complete you can reactivate the balancer process.

Disable Balancing on a Collection

You can disable balancing for a specific collection with the sh.disableBalancing() method. You may want to disable the balancer for a specific collection to support maintenance operations or atypical workloads, for example, during data ingestions or data exports.

When you disable balancing on a collection, MongoDB will not interrupt in progress migrations.

To disable balancing on a collection, connect to a mongos with the mongosh shell and call the sh.disableBalancing() method.

For example:

sh.disableBalancing("students.grades")

The sh.disableBalancing() method accepts as its parameter the full namespace of the collection.

Enable Balancing on a Collection

You can enable balancing for a specific collection with the sh.enableBalancing() method.

When you enable balancing for a collection, MongoDB will not immediately begin balancing data. However, if the data in your sharded collection is not balanced, MongoDB will be able to begin distributing the data more evenly.

To enable balancing on a collection, connect to a mongos with the mongosh shell and call the sh.enableBalancing() method.

For example:

sh.enableBalancing("students.grades")

The sh.enableBalancing() method accepts as its parameter the full namespace of the collection.

Confirm Balancing is Enabled or Disabled

To confirm whether balancing for a collection is enabled or disabled, query the collections collection in the config database for the collection namespace and check the noBalance field. For example:

db.getSiblingDB("config").collections.findOne({_id : "students.grades"}).noBalance;

This operation will return a null error, true, false, or no output:

• A null error indicates the collection namespace is incorrect.

• If the result is true, balancing is disabled.

• If the result is false, balancing is enabled currently but has been disabled in the past for the collection. Balancing of this collection will begin the next time the balancer runs.

• If the operation returns no output, balancing is enabled currently and has never been disabled in the past for this collection. Balancing of this collection will begin the next time the balancer runs.

You can also see if the balancer is enabled using sh.status(). The currently-enabled field indicates if the balancer is enabled.

Change Replication Behavior for Chunk Migration

use config
db.settings.updateOne(
   { "_id" : "balancer" },
   { $set : { "_secondaryThrottle" : { "w": "majority" }  } },
   { upsert : true }
)

db.getSiblingDB("config").settings.updateOne(
   { _id: "balancer" },
   { $set: { attemptToBalanceJumboChunks : true } },
   { upsert: true }
)

Change the Maximum Storage Size for a Given Shard

Changing a shard's maximum storage size is deprecated. Starting in version 4.2, MongoDB uses the WiredTiger Storage Engine to manage how data is stored. WiredTiger compresses data to minimize storage use. To learn more, see Compression.

For MongoDB versions 6.1 and earlier, you can still set a maximum storage size for a given shard in the sharded cluster by using the maxSize field. You can find configuration data related to shards in the config.shards collection.

Starting in version 6.2, MongoDB removes the maxSize field from the addShard command. As a result:

• Running addShard with the maxSize field returns an InvalidOptions error.

• New documents in the shards collection no longer include the maxSize field.

• Any pre-existing maxSize field entries are ignored.