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.