Comment by mjs | Hacker News Reader

Comment by mjs | Hacker News Reader

There's a blog post where the MongoDB people explain why they haven't prioritised single server durability:

http://blog.mongodb.org/post/381927266/what-about-durability

Basically: (a) for real single server durability you need to turn off hardware buffering or have a battery-backed RAID controller to ensure your write really hit disk; (b) this won't help you if your disks fail, and this failure mode is as likely as any other; and (c) for some applications, the delay required to replay a transaction log in unacceptable--you need 100% uptime.

I am thinking though, that the fact that MongoDB writes to files at all is somewhat misleading, and that they may as well say that all your data is loaded into virtual memory. (Since they make no guarantees that the database files will be consistent except in the case of a controlled shutdown. Neither does MySQL, they point out, but I think in practice MySQL database files will be easier to recover from, since their structure is presumably more regular.)

We run MongoDB on development machines, and they're frequently shut down unexpectedly. But some our development databases take an hour or two to regenerate from scratch, so we prefer to run recovery.

In our experience, MongoDB single-node recovery is very robust. It makes no guarantees of transactional integrity _between_ objects, but in our experience the individual objects have always been recovered intact. According to the MongoDB documentation, recovery will occasionally fail to rebuild objects that span disk pages which were flushed in an inconvenient order, but this will not prevent it from recovering other objects.

So even though MongoDB doesn't have single node durability, and you _really_ ought to run it in replicated mode, it actually manages to have a robust recovery tool.

Just a thought here… there might be a difference between a development box that's mostly idle shutting down unexpectedly and a production server that's under heavy load, maybe starting to fall behind on some writes, freezing and crashing.

Just saying that you might want to test it in a ways that simulates an overwhelming workload, before you trust it.

It's more interesting to see how they recover in case of failure, rather than how write is completely on disk. Machine failure will happen. Writes will not be fully flushed to disk. It's how one recovers from failure that defines how robust the system is.

Gotta say, as a database developer, this is what interests me as well. Let's assume you've had a datacenter-wide power failure, and you're running the repair process on your master and slaves -- what does that look like? How long does it take? What are the factors that influence whether or not it will complete successfully?

Reply on news.ycombinator.com