Navigation
This version of the documentation is archived and no longer supported.

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. For information on using filesystem snapshots to backup sharded clusters, see Backup a Sharded Cluster with Filesystem Snapshots.

1

Shut down the entire cluster.

Stop all mongos and mongod processes, including all shards and all config servers. To stop all members, connect to each member and issue following operations:

copy 
use admin
db.shutdownServer()

For version 2.4 or earlier, use db.shutdownServer({force:true}).

2

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:

See also

Restore a Snapshot

3

Restart the config servers.

Restart each config server mongod instance by issuing a command similar to the following for each, using values appropriate to your configuration:

copy 
mongod --configsvr --dbpath /data/configdb --port 27019
4

Start one mongos instance.

Start one mongos instance. For the --configdb, specify the hostnames (and port numbers) of the config servers started in the step Restart the config servers.

5

If shard hostnames have changed, update the config database.

If shard hostnames have changed, update the shards collection in the Config Database to reflect the new hostnames.

6

Restart all the shard mongod instances.

7

Restart the other mongos instances.

Restart the remaining two mongos instances. For the --configdb, specify the hostnames (and port numbers) of the config servers started in the step Restart the config servers.

8

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, as follows:

copy 
db.printShardingStatus()
show collections

Restore 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.

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

The procedure deploys a new sharded cluster and restores data from database dumps.

1

Deploy a new replica set for each shard.

For each shard, deploy a new replica set:

  1. Start a new mongod for each member of the replica set. Include any other configuration as appropriate.
  2. Connect a mongo to one of the mongod instances. In the mongo shell:
    1. Run rs.initiate().
    2. 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.

2

Deploy three new config servers.

Start three mongod instances for the config servers (i.e. mongod --configsvr). Include any other configuration as appropriate.

For detailed instructions on setting up the config servers, see Start the Config Server Database Instances.

3

Start the mongos instances.

Start the mongos instances, specifying the new config servers with --configdb. Include any other configuration as appropriate.

For detailed instructions on starting the mongos instances for a sharded cluster, see Start the mongos Instances.

4

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.

5

Shut down the mongos instances.

Once the new sharded cluster is up, shut down all mongos instances.

6

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.

copy 
mongorestore --drop --oplogReplay /data/dump/shardA

After you have finished restoring all the shards, shut down all shard instances.

7

Restore the config server data.

For each config server, use mongorestore to restore the data dump to each config server’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.

copy 
mongorestore --drop --oplogReplay /data/dump/configData
8

Start one mongos instance.

Start one mongos instance. For the --configdb, specify the hostnames (and port numbers) of the config servers started in the step Deploy three new config servers.

9

If shard hostnames have changed, update the config database.

If shard hostnames have changed, update the shards collection in the Config Database to reflect the new hostnames.

10

Restart all the shard mongod instances.

11

Restart the other mongos instances.

Restart the remaining two mongos instances. For the --configdb, specify the hostnames (and port numbers) of the config servers started in the step Deploy three new config servers.

12

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, as follows:

copy 
db.printShardingStatus()
show collections

See also

MongoDB Backup Methods, Backup and Restore Sharded Clusters

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.