MongoDB Documentation, Release 3.0.4 The _waitForDelete , available as a setting for the balancer as well as the moveChunk command, can alter the behavior so that the delete phase of the current migration blocks the start of the next chunk migration. The _waitForDelete is generally for internal testing purposes. For more information, see Wait for Delete (page 714). Chunk Migration and Replication Changed in version 3.0: The default value secondaryThrottle became true for all chunk migrations. New in version 3.0: The new writeConcern field in the balancer configuration document allows you to specify a write concern (page 78) semantics the _secondaryThrottle option. By default, each document operation during chunk migration propagates to at least one secondary before the bal- ancer proceeds with the next document, which is equivalent to a write concern of { w: 2 } . You can set the writeConcern option on the balancer configuration to set different write concern semantics. To override this behavior and allow the balancer to continue without waiting for replication to a secondary, set the _secondaryThrottle parameter to false . See Change Replication Behavior for Chunk Migration (page 714) to update the _secondaryThrottle parameter for the balancer. For the moveChunk command, the secondaryThrottle parameter is independent of the _secondaryThrottle parameter for the balancer. Independent of the secondaryThrottle setting, certain phases of the chunk migration have the following repli- cation policy: Changed in version 2.4: In previous versions, the balancer did not wait for the document move to replicate to a secondary. For details, see Secondary Throttle in the v2.2 Manual$^{16}$. Starting in MongoDB 2.6, sharding.archiveMovedChunks is enabled by default. With sharding.archiveMovedChunks enabled, the source shard archives the documents in the migrated chunks in a directory named after the collection namespace under the moveChunk directory in the storage.dbPath . During chunk migration, if the chunk exceeds the specified chunk size (page 688) or if the number of documents in the chunk exceeds Maximum Number of Documents Per Chunk to Migrate , MongoDB does not migrate the chunk. Instead, MongoDB attempts to split (page 687) the chunk. If the split is unsuccessful, MongoDB labels the chunk as jumbo to avoid repeated attempts to migrate the chunk. As chunks grow beyond the specified chunk size (page 688) a mongos instance will attempt to split the chunk in half. Splits may lead to an uneven distribution of the chunks for a collection across the shards. In such cases, the mongos instances will initiate a round of migrations to redistribute chunks across shards. See Sharded Collection Balancing (page 684) for more details on balancing chunks across shards. Jumbo Chunks moveChunk directory Chunk Splits in a Sharded Cluster • When an outgoing chunk migration finishes and cleanup occurs, all writes must be replicated to a majority of servers before further cleanup (from other outgoing migrations) or new incoming migrations can proceed. • MongoDB briefly pauses all application writes to the source shard before updating the config servers with the new location for the chunk, and resumes the application writes after the update. The chunk move requires all writes to be acknowledged by majority of the members of the replica set both before and after committing the chunk move to config servers. $^{16}$http://docs.mongodb.org/v2.2/tutorial/configure-sharded-cluster-balancer/#sharded-cluster-config-secondary-throttle 687 10.2. Sharding Concepts