MongoDB Documentation, Release 3.0.4 Example Assume you have the following shard without a maxSize field: Run the following sequence of commands in the mongo shell to insert a maxSize of 125 megabytes: To later increase the maxSize setting to 250 megabytes, run the following: { "_id" : "shard0000", "host" : "example.net:34001" } use config db.shards.update( { _id : "shard0000" }, { $set : { maxSize : 125 } } ) use config db.shards.update( { _id : "shard0000" }, { $set : { maxSize : 250 } } ) Change Replication Behavior for Chunk Migration Secondary Throttle Changed in version 3.0.0: The balancer configuration document added configurable writeConcern to control the semantics of the _secondaryThrottle option. The _secondaryThrottle parameter of the balancer and the moveChunk command affects the replication be- havior during chunk migration (page 687). By default, _secondaryThrottle is true , which means each doc- ument move during chunk migration propagates to at least one secondary before the balancer proceeds with the next document: this is equivalent to a write concern of { w: 2 } . You can also configure the writeConcern for the _secondaryThrottle operation, to configure how migra- tions will wait for replication to complete. For more information on the replication behavior during various steps of chunk migration, see Chunk Migration and Replication (page 687). To change the balancer’s _secondaryThrottle and writeConcern values, connect to a mongos instance and directly update the _secondaryThrottle value in the settings (page 741) collection of the config database (page 737). For example, from a mongo shell connected to a mongos , issue the following command: use config db.settings.update( { "_id" : "balancer" }, { $set : { "_secondaryThrottle" : false , "writeConcern": { "w": "majority" } } }, { upsert : true } ) The effects of changing the _secondaryThrottle and writeConcern value may not be immediate. To ensure an immediate effect, stop and restart the balancer to enable the selected value of _secondaryThrottle . See Manage Sharded Cluster Balancer (page 715) for details. Wait for Delete The _waitForDelete setting of the balancer and the moveChunk command affects how the balancer migrates multiple chunks from a shard. By default, the balancer does not wait for the on-going migration’s delete phase to complete before starting the next chunk migration. To have the delete phase block the start of the next chunk migration, you can set the _waitForDelete to true. For details on chunk migration, see Chunk Migration (page 685). For details on the chunk migration queuing behavior, see Chunk Migration Queuing (page 686). The _waitForDelete is generally for internal testing purposes. To change the balancer’s _waitForDelete value: 1. Connect to a mongos instance. 714 Chapter 10. Sharding