Simple Automated Backups for MongoDB Replica Sets

There are a bunch of different methods you can use to back up your MongoDB data, but if you want to avoid downtime and/or potential
performance degradation, the most common advice seems to be that you should simply do all your backups on a slave. This makes sense, since most of your queries will be hitting the primary server anyway. Unfortunately, picking a slave isn’t so simple when dealing
with replica sets, because (due to automated failover) you can never really be sure which servers in the set are slaves. My workaround is to simply pick any server and then force it to be a slave before running a backup.

I do this by sticking all my backup commands in a JavaScript file (e.g. /etc/mongodb-backup.js) which starts with something like this:

1 2 3 4 5 6 7

if (rs.status()['myState'] == 1) {   print('Host is master (stepping down)');   rs.stepDown();   while (rs.status()['myState'] != 2) {     sleep(1000);   } }

This snippet uses the rs.status() replica set command to check the current state of the local machine.
If the myStatefield is “1,” then we know the machine is a primary, so we execute rs.stepDown() and wait until myState is “2” (which means the server has successfully made the transition from primary to secondary).

Next come the actual backup commands. For mongodump, something like this will work:

1	runProgram("mongodump", "-o", "/mnt/backups/mongodb/");

Alternatively, it’s possible to take backups of the raw data files. Notice that in this case, we need to sync the files to disk and disable writes first, then re-enable writes once the backup completes:

1 2 3

db.runCommand({fsync:1,lock:1}); // sync and lock runProgram("rsync", "-avz", "--delete", "/var/lib/mongodb/", "/mnt/backups/mongodb/"); db.$cmd.sys.unlock.findOne(); //unlock

And finally, the whole thing can be automated by calling /usr/bin/mongo admin /etc/mongodb-backup.js from a cron job.

版权声明：本文博客原创文章，博客，未经同意，不得转载。