- Administration >
- Administration Tutorials >
- Backup and Recovery >
- 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 Backup a Sharded Cluster with Filesystem 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.
mongod --configsvr --replSet <CSRS name> --dbpath <config dbpath> --port 27019
Or, if restoring to a three mirrored mongod instances, start exactly three mongod config server instances.
mongod --configsvr --dbpath <config dbpath> --port 27019
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 to false. Include additional options as required for your specific configuration.
mongod --setParameter=recoverShardingState=false --replSet <replSetName>
Connect mongo shell to the primary of the replica set and delete from the admin.system.version collection the document where _id equals minOpTimeRecovery id. Use write concern "majority".
use admin db.system.version.remove( { _id: "minOpTimeRecovery" }, { writeConcern: { w: "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. All mongos 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.
db.printShardingStatus()
show collections
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 Backup 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 the mongod
instances. In the mongo shell:
- Run rs.initiate().
- Use rs.add() to add the other members of the replica set.
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 Deploy the Config Server Replica Set.
To deploy config servers as 3 mirrored mongod instances, see Start 3 Mirrored Config Servers (Deprecated).
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 Start the mongos Instances.
For sharded clusters with 3 mirrored config servers, see Start the mongos Instances (Deprecated).
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.
mongorestore --drop --oplogReplay /data/dump/shardA
After you have finished restoring all the shards, shut down all shard instances.
Restore the config server data.¶
mongorestore --drop --oplogReplay /data/dump/configData
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. All mongos 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.
db.printShardingStatus()
show collections