content_image/664035.jpg
<img src='content_image/664035.jpg'>

Chunk Migration Procedure All chunk migrations use the following procedure: 

1. The balancer process sends the moveChunk command to the source shard. 

2. The source starts the move with an internal moveChunk command. During the migration process, operations to the chunk route to the source shard. The source shard is responsible for incoming write operations for the chunk. 

3. The destination shard builds any indexes required by the source that do not exist on the destination. 

4. The destination shard begins requesting documents in the chunk and starts receiving copies of the data. 

5. After receiving the final document in the chunk, the destination shard starts a synchronization process to ensure that it has the changes to the migrated documents that occurred during the migration. 

6. When fully synchronized, the destination shard connects to the config database and updates the cluster metadata with the new location for the chunk. 

7. After the destination shard completes the update of the metadata, and once there are no open cursors on the chunk, the source shard deletes its copy of the documents. 

Changed in version 2.6: The source shard automatically archives the migrated documents by default. For more information, see moveChunk directory (page 687). 

Changed in version 2.4: If the balancer needs to perform additional chunk migrations from the source shard, the balancer can start the next chunk migration without waiting for the current migration process to finish this deletion step. See Chunk Migration Queuing (page 686). 

The migration process ensures consistency and maximizes the availability of chunks during balancing. 

Chunk Migration Queuing Changed in version 2.4. 

To migrate multiple chunks from a shard, the balancer migrates the chunks one at a time. However, the balancer does not wait for the current migration’s delete phase to complete before starting the next chunk migration. See Chunk Migration (page 685) for the chunk migration process and the delete phase. 

This queuing behavior allows shards to unload chunks more quickly in cases of heavily imbalanced cluster, such as when performing initial data loads without pre-splitting and when adding new shards. 

This behavior also affect the moveChunk command, and migration scripts that use the moveChunk command may proceed more quickly. 

In some cases, the delete phases may persist longer. If multiple delete phases are queued but not yet complete, a crash of the replica set’s primary can orphan data from multiple migrations. 

