SYNC MODES

Detailed Description

Attention

Using any combination of MDBX_SAFE_NOSYNC, MDBX_NOMETASYNC and especially MDBX_UTTERLY_NOSYNC is always a deal to reduce durability for gain write performance. You must know exactly what you are doing and what risks you are taking!

Note

for LMDB users: MDBX_SAFE_NOSYNC is NOT similar to LMDB_NOSYNC, but MDBX_UTTERLY_NOSYNC is exactly match LMDB_NOSYNC. See details below.

TWO CLASSES OF FAILURES:

• Application failure, only the process crashes. Database integrity is not affected in such cases. When only the process crashes, data not yet written to storage remains in the OS kernel page cache. Therefore database integrity is not affected regardless of the operating mode: the data remains available to the kernel and survives the process crash.
• System-wide failure: OS kernel panic, power outage, etc. In a system-wide failure or power loss the kernel page cache is lost together with all data not yet written to storage. Therefore the database may be corrupted or lose the last transactions if an operating mode that does not provide full durability (for example, async-write) is chosen.

THE SCENE:

• The DAT-file contains several MVCC-snapshots of B-tree at same time, each of those B-tree has its own root page.
• Each of meta pages at the beginning of the DAT file contains a pointer to the root page of B-tree which is the result of the particular transaction, and a number of this transaction.
• For data durability, MDBX must first write all MVCC-snapshot data pages and ensure that are written to the disk, then update a meta page with the new transaction number and a pointer to the corresponding new root page, and flush any buffers yet again.
• Thus during commit a I/O buffers should be flushed to the disk twice; i.e. fdatasync(), FlushFileBuffers() or similar syscall should be called twice for each commit. This is very expensive for performance, but guaranteed durability even on unexpected system failure or power outage. Of course, provided that the operating system and the underlying hardware (e.g. disk) work correctly.

TRADE-OFF:

• By skipping some stages described above, you can significantly benefit in speed, while partially or completely losing in the guarantee of data durability and/or consistency in the event of system/kernel or power failure.
• Besides, if for any reason disk write order is not preserved, then at moment of a system crash, a meta-page with a pointer to the new B-tree may be written to disk, while the itself B-tree not yet. In that case, the database will be corrupted!

See also

MDBX_SYNC_DURABLE

MDBX_NOMETASYNC

MDBX_SAFE_NOSYNC

MDBX_UTTERLY_NOSYNC