> If DB updates are not atomically visible, then no sync'ing strategy will protect you from corruption during a crash.
Who said anything about them not being atomically visible? Not being ACID doesn't mean "none of the above", and atomicity in an embedded database is practically a footnote in a distributed system anyway, because you're looking for atomicity on a much grander scale. You can impose whatever locking strategy you want around the memory to ensure updates are atomically visible. It's an embedded DB so consistency is in the hands of the application logic. Traditional ACID terms for isolation and durability aren't there, but for say a distributed system you'd do that in the network layer.
If you have multiple replicas, if one node dies you don't try to recover its data (oddly, storage corruption and node failure have a high co-occurrence rate ;-), you just wipe and pull from the other nodes. If you can't get a clean, consistent state from a node that hasn't failed, you've got bigger problems than your embedded database. As I pointed out, pulling from other nodes is often faster and more reliable than pulling from disk anyway.
In general, with a high performance network application, it is often preferable address these issues somewhere other than in your embedded database.
So what is the corruption you are envisioning?
