Performing a Manual MongoDB Restore Operation for a Replica Set

After a restore-only operation completes on the destination nodes, you can manually start the MongoDB servers and initiate the replica set.

If you restore files only to the additional secondary members from the Command Center, then perform steps 1 through 4 on the secondary members, before adding them to the replica set or a shard.

Procedure

  1. Copy the config file from the source node or you can use the config file restored in the destination data directory with the name cv_mongod_bkp.conf, and then edit the config file to comment out the authentication security, sharding, and replication parameters.

    If the source shard has encryption enabled, copy the encryption key files to the restored client.

    If mongod is configured to run as a system service, then start it by using the system service manager. For example, complete the following steps to start mongod by using the systemctl service manager:

    1. Identify the config file path used by the mongod.service.

      systemctl cat mongod.service

      Make sure to place the updated config file in that path.

    2. Start the mongod.service using systemctl.

      systemctl start mongod.service
  2. Start the standalone mongod by using the config file from step 1.

    mongod --config <path-to-config-file>
  3. Drop the local database in the mongod server. Connect to the mongod from the mongo shell, and run the following command:

    use local
    db.dropDatabase()
  4. Restart the mongod. Connect to the mongod from the mongo shell, and run the following commands:

    1. Shut down the mongod instance.

      use admin 
      db.shutdownServer()
    2. Uncomment the replication parameters in the config file.

    3. Start mongod with the updated config file.

      mongod --config <path-to-config-file>
  5. Initiate the single-node replica set. Connect to the mongod from the mongo shell, and run the following command:

    use rs.initiate()

    After completing this step, this node becomes the primary, and the replica set is initiated as a single-node replica set.

  6. On the primary, apply the restored Oplog dumps (if any) on the mongod. By default, the restored oplog dumps are present under <Install Path>/iDataAgent/jobResults/CV_JobResults/2/0/<restorejobid>/local folder. Rename the restored dumps oplog_<repsetname>_<timestamp>.bson to oplog.bson one-by-one, and then run the mongorestore command to apply the restored dumps, in the timestamp order.

    mongorestore --port <mongod port#>  --oplogReplay <installpath>/iDataAgent/jobResults/CV_JobResults/2/0/<restorejobid>/local
  7. Optional: Enable authentication. To enable authentication on the restored nodes, add the authentication security settings to the mongod config files, and then restart the servers.

  8. On the primary, add additional members (if any) to the replica set.

    rs.add({host:<>, votes:0, priority:0})

    This command performs an initial sync with the data on the primary node.

  9. On the primary, to re-configure any node information such as priority votes and so on, use rs.reconfig().

    For example, to configure the priorities of nodes after a restore operation, connect to the primary node's mongo shell and run the following commands.

    Note

    Wait till the secondaries change to the secondary state.

    cfg = rs.conf();
    cfg.members[2].priority = 1;
    rs.reconfig(cfg);
    cfg = rs.conf();
    cfg.members[3].priority = 1;
    rs.reconfig(cfg);
    cfg = rs.conf();
    cfg.members[4].priority = 1;
    rs.reconfig(cfg);

Loading...