Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Strategies for Backing Up MongoDB

6,501 views

Published on

For the first time this year, 10gen will be offering a track completely dedicated to Operations at MongoSV, 10gen's annual MongoDB user conference on December 4. Learn more at MongoSV.com

Come learn about the different ways to back up your single servers, replica sets, and sharded clusters

  • Login to see the comments

Strategies for Backing Up MongoDB

  1. 1. #MongoBostonStrategies for Backing UpMongoDBJeff YeminEngineering Manager, 10gen
  2. 2. File and Directory Layout• A set of files per database
  3. 3. Insert with write concern of {fsync :true}
  4. 4. Archive the data directory
  5. 5. Restore the data directory
  6. 6. Start mongod on restored datadirectory
  7. 7. Everything is fine, right?• No, its not• But you cant tell until you look
  8. 8. Try validating the collection• In the shell, run the validate command
  9. 9. How can we get a cleanbackup?• kill mongod• fsyncLock / fsyncUnlock
  10. 10. How can we get a cleanbackup?• mongodump
  11. 11. mongodump• Snapshot of each collection – Does NOT represent a point in time, even for a single collection• Can NOT be combined with fsyncLock – Remember, you cant read…• You CAN dump directly from data files to get a point in time backup – mongodump –dbpath• Can be costlier than archiving as FS level
  12. 12. Snaphot Query 5 2 71 3 4 6 8 9
  13. 13. How can we get a cleanbackup?• journaling
  14. 14. Journaling• Write-ahead log• Guarantees a consistent view even after a hard crash• Default behavior as of 2.0• Journal stored in –dbpath /journal folder• --journalCommitInterval* (2ms - 300ms)
  15. 15. Journaling implications forbackup• Logical Volume Manager (LVM)• LVM snapshots to the rescue – lvcreate –size 100M –snapshot –name mdb-snap01 /dev/vg0/mongodb• No shutdown or fsyncLock needed• True point in time backup for a single instance
  16. 16. Replica Sets
  17. 17. Backing up a replica set• Back up a (hidden) secondary – kill mongod – fsyncLock – mongodump – LVM snapshot
  18. 18. Mongodump for replica sets• True point in time – mongodump –oplog – mongorestore –-oplogreplay• Snapshot query of each collection, then replay the oplog at the end – Similar to how a new secondary does an initial sync
  19. 19. mongos configChunks! balancer config config 1 2 3 4 13 14 15 16 25 26 27 28 37 38 39 40 5 6 7 8 17 18 19 20 29 30 31 32 41 42 43 44 9 10 11 12 21 22 23 24 33 34 35 36 45 46 47 48 Shard 1 Shard 2 Shard 3 Shard 4Sharded clusters
  20. 20. Backing up a sharded cluster• mongodump through mongos – (but no –oplog)• mongorestore through mongos
  21. 21. Backup a Sharded Cluster1. Stop Balancer, and wait till inactive (state:0) db.settings.update( { _id: "balancer" }, { $set : { stopped: true } } , true )2. Stop a config server Backup Data – Each shard – Config server (mongodump --db config)3. Restart config server4. Resume balancer
  22. 22. #MongoBostonThank YouJeff YeminEngineering Manager, 10gen

×