- Administration >
- MongoDB Backup Methods >
- Backup and Restore Sharded Clusters >
- Restore a Sharded Cluster
Restore a Sharded Cluster¶
On this page
Overview¶
You can restore a sharded cluster either from snapshots or from BSON
database dumps created by the
mongodump
tool. This document describes procedures to
Procedures¶
Restore a Sharded Cluster with Filesystem Snapshots¶
The following procedure outlines the steps to restore a sharded cluster from filesystem snapshots. To create filesystem snapshots of sharded clusters, see Back Up a Sharded Cluster with File System Snapshots.
Restore the data files.¶
On each server, extract the data files to the location where the
mongod
instance will access them and restore the following:
Data files for each server in each shard.
For each shard replica set, restore all the members of the replica set. See Restore a Replica Set from MongoDB Backups.
Data files for each config server.
Changed in version 3.2: If restoring to a config server replica set (CSRS), restore the members of the replica set. See Restore a Replica Set from MongoDB Backups.
Else, if restoring to 3 mirrored config servers, restore the files on each config server
mongod
instance as you would a standalone node.
See also
Restart the config servers.¶
If restoring to a config server replica set, restart each member of the CSRS.
Or, if restoring to a three mirrored
mongod
instances, start exactly threemongod
config server instances.
Start one mongos
instance.¶
- If using a CSRS deployment, start
mongos
with the--configdb
option set to the replica set name and seed list of the CSRS started in the step Restart the config servers. - Or, if using three mirrored config servers, start
mongos
with the--configdb
option set to the hostnames (and port numbers) of the config servers started in the step Restart the config servers.
If shard hostnames have changed, update the config database.¶
If shard hostnames have changed, connect a mongo
shell to
the mongos
instance and update the shards
collection in the Config Database to reflect the new
hostnames.
Clear per-shard sharding recovery information.¶
If the backup data was from a deployment using CSRS, clear out the no longer applicable recovery information on each shard. For each shard:
Restart the replica set members for the shard with the
recoverShardingState
parameter set tofalse
. Include additional options as required for your specific configuration.Connect
mongo
shell to the primary of the replica set and delete from theadmin.system.version
collection the document where_id
equalsminOpTimeRecovery
id. Use write concern"majority"
.Shut down the replica set members for the shard.
Restart all the shard mongod
instances.¶
Do not include the recoverShardingState
parameter.
Restart the other mongos
instances.¶
- If using a CSRS deployment, specify for
--configdb
the config server replica set name and a seed list of the CSRS started in the step Restart the config servers. - Or, if using three mirrored config servers, specify for
--configdb
the hostnames (and port numbers) of the config servers started in the step Restart the config servers. Allmongos
must specify the same--configdb
string.
Verify that the cluster is operational.¶
Connect to a mongos
instance from a mongo
shell
and use the db.printShardingStatus()
method to ensure that
the cluster is operational.
Restore a Sharded Cluster with Database Dumps¶
The following procedure outlines the steps to restore a sharded cluster
from the BSON database dumps created by mongodump
. For
information on using mongodump
to backup sharded clusters,
see Back Up a Sharded Cluster with Database Dumps.
Changed in version 3.0: mongorestore
requires a running MongoDB instances.
Earlier versions of mongorestore
did not require a
running MongoDB instances and instead used the --dbpath
option.
For instructions specific to your version of
mongorestore
, refer to the appropriate version of the
manual.
Deploy a new replica set for each shard.¶
For each shard, deploy a new replica set:
- Start a new
mongod
for each member of the replica set. Include any other configuration as appropriate. - Connect a
mongo
to one of themongod
instances. In themongo
shell:- Run
rs.initiate()
. - Use
rs.add()
to add the other members of the replica set.
- Run
For detailed instructions on deploying a replica set, see Deploy a Replica Set.
Deploy new config servers.¶
To deploy config servers as replica set (CSRS), see Create the Config Server Replica Set.
Start the mongos
instances.¶
Start the mongos
instances, specifying the new config
servers with --configdb
. Include any other configuration as
appropriate.
For sharded clusters with CSRS, see Connect a mongos to the Sharded Cluster.
Add shards to the cluster.¶
Connect a mongo
shell to a mongos
instance.
Use sh.addShard()
to add each replica sets as a shard.
For detailed instructions in adding shards to the cluster, see Add Shards to the Cluster.
Restore the shard data.¶
For each shard, use mongorestore
to restore the data dump
to the primary’s data directory. Include the --drop
option to
drop the collections before restoring and, because the backup
procedure
included the --oplog
option, include the
--oplogReplay
option for mongorestore
.
For example, on the primary for ShardA, run the
mongorestore
. Specify any other configuration as
appropriate.
After you have finished restoring all the shards, shut down all shard instances.
Restore the config server data.¶
Start one mongos
instance.¶
- If using a CSRS deployment, start
mongos
with the--configdb
option set to the replica set name and seed list of the CSRS started in the step Deploy new config servers. - Or, if using three mirrored config servers, start
mongos
with the--configdb
option set to the hostnames (and port numbers) of the config servers started in the step Deploy new config servers.
If shard hostnames have changed, update the config database.¶
If shard hostnames have changed, connect a mongo
shell to
the mongos
instance and update the shards
collection in the Config Database to reflect the new
hostnames.
Restart all the shard mongod
instances.¶
Do not include the recoverShardingState
parameter.
Restart the other mongos
instances.¶
- If using a CSRS deployment, specify for
--configdb
the config server replica set name and a seed list of the CSRS started in the step Deploy new config servers. - Or, if using three mirrored config servers, specify for
--configdb
the hostnames (and port numbers) of the config servers started in the step Deploy new config servers. Allmongos
must specify the same--configdb
string.
Verify that the cluster is operational.¶
Connect to a mongos
instance from a mongo
shell
and use the db.printShardingStatus()
method to ensure that
the cluster is operational.