Restore a Sharded Cluster

Note

The following procedure applies to 3.6 sharded clusters. For earlier versions of MongoDB, refer to the corresponding version of the MongoDB Manual.

This procedure restores a sharded cluster from an existing backup, such as LVM snapshots or database dumps. The source and target sharded cluster must have the same number of shards. For complete documentation on sharded cluster backups, see Back Up a Sharded Cluster with Database Dumps and Back Up a Sharded Cluster with File System Snapshots.

MongoDB Cloud Backups

MongoDB Cloud Services provides built-in backup and restoration features for automatically restore sharded cluster backups.

For more information, see MongoDB Atlas , MongoDB Cloud Manager , and MongoDB Ops Manager .

A. (Optional) Review Replica Set Configurations

This procedure initiates a new replica set for the Config Server Replica Set (CSRS) and each shard replica set using the default configuration. To use a different replica set configuration for your restored CSRS and shards, you must reconfigure the replica set(s).

If your source cluster is healthy and accessible, connect a mongo shell to the primary replica set member in each replica set and run rs.conf() to view the replica configuration document.

If you cannot access one or more components of the source sharded cluster, please reference any existing internal documentation to reconstruct the configuration requirements for each shard replica set and the config server replica set.

B. Prepare the Target Host for Restoration

Storage Space Requirements
Ensure the target host hardware has sufficient open storage space for the restored data. If the target host contains existing sharded cluster data that you want to keep, ensure that you have enough storage space for both the existing data and the restored data.
LVM Requirements
For LVM snapshots, you must have at least one LVM managed volume group and an a logical volume with enough free space for the extracted snapshot data.
MongoDB Version Requirements

Ensure the target host and source host have the same MongoDB Server version. To check the version of MongoDB available on a host machine, run mongod --version from the terminal or shell.

For complete documentation on installation, see Install MongoDB.

Shut Down Running MongoDB Processes

If restoring to an existing cluster, shut down the mongod or mongos process on the target host.

For hosts running mongos, connect a mongo shell to the mongos and run db.shutdownServer() from the admin database:

use admin
db.shutdownServer()

For hosts running a mongod, connect a mongo shell to the mongod and run db.isMaster():

  • If ismaster is false, the mongod is a secondary member of a replica set. You can shut it down by running db.shutdownServer() from the admin database.

  • If ismaster is true, the mongod is the primary member of a replica set. Shut down the secondary members of the replica set first. Use rs.status() to identify the other members of the replica set.

    The primary automatically steps down after it detects a majority of members are offline. After it steps down (db.isMaster returns ismaster: false), you can safely shut down the mongod

Prepare Data Directory

Create a directory on the target host for the restored database files. Ensure that the user that runs the mongod has read, write, and execute permissions for all files and subfolders in that directory:

sudo mkdir /path/to/mongodb
sudo chown -R mongodb:mongodb /path/to/mongodb
sudo chmod -R 770 /path/to/mongodb

Substitute /path/to/mongodb with the path to the data directory you created. On RHEL / CentOS, Amazon Linux, and SUSE, the default username is mongod.

Prepare Log Directory

Create a directory on the target host for the mongod log files. Ensure that the user that runs the mongod has read, write, and execute permissions for all files and subfolders in that directory:

sudo mkdir /path/to/mongodb/logs
sudo chown -R mongodb:mongodb /path/to/mongodb/logs
sudo chmod -R 770 /path/to/mongodb/logs

Substitute /path/to/mongodb/logs with the path to the log directory you created. On RHEL / CentOS, Amazon Linux, and SUSE, the default username is mongod.

Create Configuration File

This procedure assumes starting a mongod with a configuration file.

Create the configuration file in your preferred location. Ensure that the user that runs the mongod has read and write permissions on the configuration file:

sudo touch /path/to/mongod.conf
sudo chown mongodb:mongodb /path/to/mongodb/mongod.conf
sudo chmod 644 /path/to/mongodb/mongod.conf

On RHEL / CentOS, Amazon Linux, and SUSE, the default username is mongod.

Open the configuration file in your preferred text editor and modify at it as required by your deployment. Alternatively, if you have access to the original configuration file for the mongod, copy it to your preferred location on the target host.

Important

Validate that your configuration file includes the following settings:

C. Restore Config Server Replica Set

1

Restore the CSRS primary mongod data files.

Select the tab that corresponds to your preferred backup method:

  1. Mount the LVM snapshot on the target host machine. The specific steps for mounting an LVM snapshot depends on your LVM configuration.

    The following example assumes an LVM snapshot created using the Create a Snapshot step in the Back Up and Restore with Filesystem Snapshots procedure.

    lvcreate --size 250GB --name mongod-datafiles-snapshot vg0
    gzip -d -c mongod-datafiles-snapshot.gz | dd o/dev/vg0/mongod-datafiles-snapshot
    mount /dev/vg0/mongod-datafiles-snapshot /snap/mongodb
    

    This example may not apply to all possible LVM configurations. Refer to the LVM documentation for your system for more complete guidance on LVM restoration.

  2. Copy the mongod data files from the snapshot mount to the data directory created in B. Prepare the Target Host for Restoration:

    cp -a /snap/mongodb/path/to/mongodb /path/to/mongodb
    

    The -a option recursively copies the contents of the source path to the destination path while preserving folder and file permissions.

  3. Comment out or omit the following configuration file settings:

    #replication
    #  replSetName: myCSRSName
    #sharding
    #  clusterRole: configsvr
    

    To start the mongod using a configuration file, specify the --config option in the command line specifying the full path to the configuration file:

    mongod --config /path/to/mongodb/mongod.conf
    

    If you have mongod configured to run as a system service, start it using the recommended process for your system service manager.

    After the mongod starts, connect to it using the mongo shell.

  1. Comment out or omit the following configuration file settings:

    #replication
    #  replSetName: myCSRSName
    #sharding
    #  clusterRole: configsvr
    

    To start the mongod using a configuration file, specify the --config option in the command line specifying the full path to the configuration file:

    mongod --config /path/to/mongodb/mongod.conf