
MongoDB 1.7.5 Released with single server durability - princeverma
http://groups.google.com/group/mongodb-user/browse_thread/thread/4b94744f1f709048
======
xal
I think making this an opt in feature is poor strategy. This should be opt out
for the people who know what they are doing.

~~~
ehwizard
Durability is a new feature, and should be treated as such. While it is
currently not the default, that may change in a later release.

~~~
jacques_chester
Durability is the new web scale.

------
cheald
It's worth noting that this is not a "stable" release. MongoDB releases with
an odd minor version number (1.3, 1.5, 1.7) are unstable development releases,
and should be treated as such. 1.8 will be the first official "stable" release
with single-server durability.

------
e1ven
This is great news, thank you!

Until 1.7.5, the advice seems to have been that ANY single server is
vulnerable, always use replication sets to prevent losing data.

While I appreciate that point, and we do use ReplSets for every DB, in the
real world problems happen.

    
    
        A circuit might explode in a DC, causing all the machines to go down. (Happened to me at ThePlanet)
        Our Secondary machine might go down, and while fixing it, the primary might fail. (Happened two weeks ago on dev machines)
        Our devs might run a test database on their Macbooks; While this isn't mission critical to stay up, potentially losing records means they need to restart all tests after an event, rather than resuming.
    

There's a million other places that this will be helpful. Yes, we should
always spread things out as much as possible.. But I still use redundant
power, RAID arrays, a journaled filesystem and in ideal times a ACID DB.

Here's hoping 1.8.0 will be out soon! ;)

------
lazyjeff
I've always thought the MongoDB database was really good, but has poor drivers
for node.js. I've been using node-mongodb-native, and it has basically no
documentation. If you want to use a relatively new feature, you have to figure
out how to convert from the MongoDB command line syntax in the MongoDB docs,
to some syntax that the driver understands (which may sometimes be
impossible). If you have poor drivers, even an awesome database won't make up
for it.

~~~
mnutt
It also requires way more nesting than it should, in my opinion. It would be
nice to have a synchronous connect method so that I don't have to wrap my
entire app in a connect callback.

And I don't see why 'collection' should take a callback either, unless you're
in strict mode and querying mongo to see if it exists.

Some people have written higher level APIs on top of node-mongodb-native, two
that I have seen are mongoose and mongous. I'm still evaluating them to see
what their performance characteristics look like.

------
johngalt
Forgive my ignorance, but I had no idea what single server durability was. So
I had to look it up. I couldn't find any direct definitions, but from what I
read it sounds like it does this:

Single server durability is a disk buffered list of pending writes so if the
server reboots while in operation it can just resume where it left off. In
larger deployments this risk is handled by having multiple servers running
concurrently.

Does this sound right?

~~~
rit
Take a look at the documentation for Journaling:
<http://www.mongodb.org/display/DOCS/Journaling>

This covers what MongoDB is doing for durability.

~~~
johngalt
Thanks that is exactly what I was looking for.

------
mike_esspe
Anyone did write benchmarks with durability enabled?

~~~
rst
This is a situation where the physical disk configuration may make a real
difference. If the journal and the data files are on the same disk, a write-
heavy load will be continually seeking between them. If they're on different
disks, there's a lot less seeking, and that may reduce the performance penalty
quite a bit (at the cost of extra hardware).

And of course, if you're on SSDs, this is all a non-issue, but that also still
comes at a premium.

