Last Resort: How to Use a Backup to Start a Secondary Instance for MongoDB

In this blog post, I’ll look at how you can use a backup to start a secondary instance for MongoDB.

Although the documentation says it is not possible to use a backup to start a secondary, sometimes this is the only possible way to start a new instance. In this blog post, we will explain how to bypass this limitation and use a backup to start a secondary instance.

The initial sync/rsync or snapshot works fine when the instances are in the same data center, but it can fail or be really slow. Much slower than moving a compressed backup between data centers.

Not every backup can be used as a source for starting a replica set. The backup must have the oplog file. This means the backup must be done in a previously existent replica set using the
--oplog flag point in time backup when dumping the collections. The time spent to move and restore the backup file must be less than the oplog window.

Please follow the next steps to create a secondary from a backup:

Create a backup using the
--oplog command.

Shell

1

mongodump--oplog-o/tmp/backup/

Backup the replica set collection from the local database.

Shell

1

mongodump-dlocal-csystem.replset

After backup finishes please confirm the oplog.rs file is in the backup folder.

Use
bsondump to convert the oplog to JSON. We will use the last oplog entry as a starting point for the replica set.

Shell

1

bsondump oplog.rs>oplog.rs.txt

Initiate the new instance without the replica set parameter configured. At this point, the instance will act as a single instance.

Restore the database normally using
--oplogreplay to apply all the oplogs that have been recorded while the backup was running.

Shell

1

mongorestore/tmp/backup--oplogReplay

Connect to this server and use the local database to create the oplog.rs collection. Please use the same value as the other members (e.g., 20 GB).

Stop the service and edit the parameter replica set name to match the existing replica set.

Connect to the primary and add this new host. The new host must start catching up the oplog and get in sync after a few hours/minutes, depending on the number of operations the replica set handles. It is important to consider adding this new secondary as a hidden secondary, without votes if possible, to avoid triggering an election. When the secondary is added to the replica set drivers, it will start using this host to perform reads. If you don’t add the server with
hidden:true, the application will read inconsistent data (old data).

Please check the replication lag, and once the seconds behind master is near to zero, change the host parameters in the replica set to
hidden:false and priority or
votes.

Shell

1

2

mongo

PRIMARY>rs.printSlaveReplicationInfo()

We are considering a replica set with three members, where the new secondary has the ID 2 in the member’s array. Use the following command to unhide the secondary and make it available for reads. The priority and votes depend on your environment. Please notice you might need to change the member ID.

Shell

1

2

3

4

5

6

mongo

PRIMARY>cfg=rs.config()

cfg.members[2].hidden=false

cfg.members[2].votes=1

cfg.members[2].priority=1

PRIMARY>rs.reconfig(rs)

I hope this tutorial helps in an emergency situation. Please consider using initial sync, disk snapshots and hot backups before using this method.