Question

This mongodb guide: http://www.mongodb.org/pages/viewpage.action?pageId=19562846 says that if your data is mapped to multiple EBS volumes, then you need to lock the database before snapshotting it. I am using RAID 10 across 4 EBS volumes, but my database is on just one instance (no replica sets), and I would like to keep it that way for now. Since I would like to snapshot my data every hour, I'm worried about having to lock the database every time - I can't afford to have downtime every hour, nor can I afford to have write requests refused every hour. Is there a way to get around this lock?

Was it helpful?

Solution

If you do not lock the database, you cannot guarantee the consistency of the data across the multiple RAID volumes when you take the snapshot. This is basically a limitation of the RAID config, not MongoDB - the lock is just a way of ensuring that the database data does not change while you take a snapshot and hence gets around the RAID limitation (for the MongoDB data at least).

If you want to avoid downtime caused by locking the DB, then you are going to have to have a secondary to use to take the snapshots (you can make it hidden so that it never takes over or serves reads). With a single node, as you describe you can't do it - it's downtime (because of the lock) for consistency, or backup using another node, otherwise your snapshots are essentially worthless.

Note: if the secondary can keep up with replication on a single EBS volume and you are running journaling, then you can just snapshot as needed, no need to lock the DB at all. A hidden secondary does not need to be identically spec'ed to the primary, it just needs to be good enough to keep up.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top