Howard Chu writes:
In the default mode (fully synchronous) you can only lose the in-progress transaction.
Oh duh, I forgot the sync filehandle.
With dbnosync you can lose whatever hasn't been checkpointed yet.
I thought dbnosync could cause database corruption: Data and metadata writes can get flushed out of order to the disk, leaving the meta page temporarily pointing at garbage - at which time an OS crash or hardware failure can make the inconsistency permanent. Frequent checkpoints merely reduce the chance such a crash has of catching the DB in an inconsistent state. (OTOH a mere slapd crash is no problem.)
There is another mode (recently added, not yet exposed in back-mdb) that only flushes the data, not the metadata. With that mode, you might lose the in-progress transaction and the immediately preceding commit. This mode is slightly faster than fully-synchronous, and slightly slower than fully asynch.
That's like if we compiled with -DMDB_DSYNC=0?