On this page本页内容
To remove a shard you must ensure the shard’s data is migrated to the remaining shards in the cluster. This procedure describes how to safely migrate data and how to remove a shard.
When you remove a shard in a cluster with an uneven chunk distribution, the balancer first removes the chunks from the draining shard and then balances the remaining uneven chunk distribution.
This procedure describes how to remove a shard from a cluster. Do not use this procedure to migrate an entire cluster to new hardware. To migrate, see Migrate a Sharded Cluster to Different Hardware instead.
To remove a shard, first connect to one of the cluster’s mongos instances using mongo shell. Then use the sequence of tasks in this document to remove a shard from the cluster.
A shard removal may cause an open change stream cursor to close, and the closed change stream cursor may not be fully resumable.
To successfully migrate data from a shard, the balancer process must be enabled. Check the balancer state using the sh.getBalancerState() helper in the mongo shell. For more information, see the section on balancer operations.
To determine the name of the shard, connect to a mongos instance with the mongo shell and either:
listShards command, as in the following:
sh.status() or the db.printShardingStatus() method.The shards._id field lists the name of each shard.
From the admin database, run the removeShard command. This begins “draining” chunks from the shard you are removing to other shards in the cluster. For example, for a shard named mongodb0, run:
mongos converts the write concern of the removeShard command to "majority".
This operation returns with the following response:
The balancer begins migrating chunks from the shard named mongodb0 to other shards in the cluster. These migrations happens slowly to avoid placing undue load on the overall cluster. Depending on your network capacity and the amount of data, this operation can take from a few minutes to several days to complete.
Note
The output includes the field dbsToMove indicating the databases, if any, for which the shard is the primary shard. After all chunks have been drained from the shard, you must either movePrimary for the database(s) or alternatively, drop the databases (which deletes the associated data files).
To check the progress of the migration at any stage in the process, run removeShard from the admin database again. For example, for a shard named mongodb0, run:
mongos converts the write concern of the removeShard command to "majority".
The command returns output similar to the following:
In the output, the remaining field includes the following fields:
chunks |
Total number of chunks currently remaining on the shard. |
dbs |
Total number of databases whose primary shard is the shard. These databases are specified in the dbsToMove output field. |
jumboChunks |
Of the total number of If the After the Available starting in 4.2.2 (and 4.0.14) |
Continue checking the status of the removeShard command until the number of chunks remaining is 0.
If the shard is the primary shard for one or more databases in the cluster, then you must make that database use a different shard as its primary shard. removeShard lists any databases that you need to move in the dbsToMove field in the command output. If the shard is not the primary shard for any databases, skip to the next task, Finalize the Migration.
To move a database to another shard, use the movePrimary command.
Important
To ensure a smooth migration, refer to the considerations in the movePrimary command documentation before running movePrimary.
To migrate the fizz database from mongodb0 to mongodb1, issue the following command:
mongos uses "majority" write concern for movePrimary.
This command does not return until MongoDB completes moving all data. The response from this command will resemble the following:
movePrimary To Move Unsharded Collections¶For MongoDB 4.2 and previous, if using the movePrimary command on a database that contains an unsharded collection, you must perform the following additional steps.
Note
MongoDB 4.4 does not require these additional steps when moving databases that contain unsharded collections.
mongos instances and all mongod shard members (including the secondary members);flushRouterConfig command on all mongos instances and all mongod shard members (including the secondary members) before reading or writing any data to any unsharded collections that were moved.mongos instances;flushRouterConfig command on all mongos instances before reading or writing any data to any unsharded collections that were moved.These steps ensure that all cluster nodes refresh their metadata cache, which includes the location of the primary shard. Otherwise, you may miss data on reads, and may not write data to the correct shard. To recover, you must manually intervene.
To clean up all metadata information and finalize the removal, run removeShard again. For example, for a shard named mongodb0, run:
mongos converts the write concern of the removeShard command to "majority".
A success message appears at completion:
Once the value of the state field is “completed”, you may safely stop the instances comprising the mongodb0 shard.