MongoDB backups & corn on the cob in 10 minutes

Last night, I discovered that you can make corn on the cob in about 5 minutes, which is so cool. You can also backup your MongoDB database in about 5 minutes (depending on size!), so I figured I’d combine the two.

You’ll need:

  • 1 MongoDB server you want to back up
  • 1 external drive for the backup
  • 2 ears of unshucked corn
  • 2 tablespoons of butter
  • 4 tablespoons of grated Parmesan cheese
  • 1/2 teaspoon of cayenne pepper

Directions:

  1. Cook the ears of corn in the microwave for 4 minutes (in their husks) on a damp paper towel.
  2. Start a MongoDB shell and run:
    > use admin
    > db.runCommand({"fsync" : 1, "lock" : 1})
    {
            "info" : "now locked against writes, use db.$cmd.sys.unlock.findOne() to unlock",
            "ok" : 1
    }

    This flushes everything to disk and prevents more writes from happening. If you’re in production, you should do this on a slave (so you don’t prevent people from writing to the master). When you unlock it, the slave will start doing writes again and catch up with the master.

  3. Copy your database files to external storage:
    $ cp -R /data/db /mnt/usb/backup
  4. Your corn is probably done now. Take it out of the microwave and cover it in a towel to let it cool.
  5. In your database shell, run:
    > db.$cmd.sys.unlock.findOne()
    { "ok" : 1, "info" : "unlock requested" }
  6. If it’s cool enough, shuck your corn (the husks and silk should come off very easily, everything practically fell off for me).
  7. Roll the corn around in butter until it’s nice and coated. Then cover it with Parmesan cheese and sprinkle a little cayenne over it.
  8. Optional: eat corn over your laptop, safe in the knowledge that you have a recent backup.

I got this recipe from Tabla (the corn, not the database backup). There was a BBQ day at Madison Square Park and they’re too ritzy to serve BBQ, so they made this. It is really good.

  • Microwave mexican corn! Next time I see corn at the Journal Square farmers market I will make some for my coworkers.

    Personally I prefer text dumps for my database backups because they are more versatile, but this is a good alternative, and something I'll use when my mongo dbs get to big for the overhead of mongodump.

  • You've inspired me to write a blog post, Thanksgiving dinner and compiling mongo on a netbook in 4 hours.

  • kristina1

    Once you have the database locked up, you can pretty much do whatever type of dump you want on it (mongodump, mongoexport, etc), I just did cp -R because it's easy and everyone knows it 🙂

  • kristina1

    Yup, same with my MacBook Air. The last couple of days have been crazy, too — ~50 commits in the last 12 hours — so I have to keep recompiling!

  • Wait, if I do a mongodump without –dbpath, do I still have to issue the lock command or does mongodump do that for me?

    If I have to issue the locks, I gotta go modify some batch files, and more importantly file me some bugs and rouse some rabble.

  • kristina1

    Yes, you still have to issue the locks! Change those batch files and rouse the rabble!

  • Consider the rabble roused http://jira.mongodb.org/browse/SERVER-1588.

    Monday I shall update some batch files.

  • Does it work the same way with replica sets? Or would I need to shutdown the replica and copy the files before bringing it back up?

  • kristina1

    You can do the same thing with a replica set. Each member of a replica set is also an independent mongod, so connect to a secondary, fsync and lock it, and make a copy of the files.

  • Pingback: ehcache.net()

  • Harun Yardimci

    It wont work for the shards.. you need the backup for configs and for all shard members..

kristina chodorow's blog