Could someone with Mongo experience help me gut-check this?
I want my data store to be durable and unsurprising -- barring a hardware failure or such, if I submit data it should either tell me that it failed to commit or it should be stored durably and without surprises (e.g., it should not truncate a long string to fit).
I've read some of the Mongo docco, and it's pretty exciting, but the lack of ACID -- primarily the Durability -- has kept me from really using it.
With a WAL journal, it sounds like maybe the durability issue is fixed. Is it? Could I use Mongo with relatively out-of-the-box settings plus --journal and count on a level of durability equivalent to a traditional RDBMS?
Yes, if you combine journaling with safe write operations. This allows you to call the appropriate driver method to confirm that the data has been written. You can also wait for it to be written to n slaves in replication. I believe that "written" means either to the data files or the journal. In the case of the journal, a hard crash would result in the journal being replayed so that the data is then written to disk and you don't get corruption.
"If safe is an integer, will replicate the insert to that many machines before returning success (or throw an exception if the replication times out, see wtimeout)."
Don't know, I'm going to be testing this tomorrow, but came to work today to a server that was grinding to a halt due to wild running node.js processes. Restarted the server, but that doesn't cleanly shutdown Mongo, and spent an hour repairing everything and setting permissions right (somehow they had gotten reset). This exact problem, so hope the --journal switch in the init file makes the difference.
Added "journal = true" to the config and it certainly stops and starts the service nicely now. No more repairs and such, my data is currently query only, so it's mainly "optical", cleaning up locks and such.
Journaling should give you the crash-safety you're looking for. You should combine it with safe writes to get the commit safety you want (not the default, but is easy to choose, see your driver's documentation).
My understanding is this release is the first stable with single node durability available as an option, which is why I'm considering picking Mongo back up.
I want my data store to be durable and unsurprising -- barring a hardware failure or such, if I submit data it should either tell me that it failed to commit or it should be stored durably and without surprises (e.g., it should not truncate a long string to fit).
I've read some of the Mongo docco, and it's pretty exciting, but the lack of ACID -- primarily the Durability -- has kept me from really using it.
With a WAL journal, it sounds like maybe the durability issue is fixed. Is it? Could I use Mongo with relatively out-of-the-box settings plus --journal and count on a level of durability equivalent to a traditional RDBMS?