Enum SyncMode

pub enum SyncMode {
    Durable,
    NoMetaSync,
    SafeNoSync,
    UtterlyNoSync,
}

MDBX sync mode

Variants

Durable

Default robust and durable sync mode. Metadata is written and flushed to disk after a data is written and flushed, which guarantees the integrity of the database in the event of a crash at any time.

NoMetaSync

Don’t sync the meta-page after commit.

Flush system buffers to disk only once per transaction commit, omit the metadata flush. Defer that until the system flushes files to disk, or next non-read-only commit or Environment::sync(). Depending on the platform and hardware, with SyncMode::NoMetaSync you may get a doubling of write performance.

This trade-off maintains database integrity, but a system crash may undo the last committed transaction. I.e. it preserves the ACPI (atomicity, consistency, isolation) but not D (durability) database property.

SafeNoSync

Don’t sync anything but keep previous steady commits.

SyncMode::UtterlyNoSync the SyncMode::SafeNoSync flag disable similarly flush system buffers to disk when committing a transaction. But there is a huge difference in how are recycled the MVCC snapshots corresponding to previous “steady” transactions (see below).

With crate::EnvironmentKind::WriteMap the SyncMode::SafeNoSync instructs MDBX to use asynchronous mmap-flushes to disk. Asynchronous mmap-flushes means that actually all writes will scheduled and performed by operation system on it own manner, i.e. unordered. MDBX itself just notify operating system that it would be nice to write data to disk, but no more.

Depending on the platform and hardware, with SyncMode::SafeNoSync you may get a multiple increase of write performance, even 10 times or more.

In contrast to SyncMode::UtterlyNoSync mode, with SyncMode::SafeNoSync flag MDBX will keeps untouched pages within B-tree of the last transaction “steady” which was synced to disk completely. This has big implications for both data durability and (unfortunately) performance:

• A system crash can’t corrupt the database, but you will lose the last transactions; because MDBX will rollback to last steady commit since it kept explicitly.
• The last steady transaction makes an effect similar to “long-lived” read transaction since prevents reuse of pages freed by newer write transactions, thus the any data changes will be placed in newly allocated pages.
• To avoid rapid database growth, the system will sync data and issue a steady commit-point to resume reuse pages, each time there is insufficient space and before increasing the size of the file on disk.

In other words, with SyncMode::SafeNoSync flag MDBX protects you from the whole database corruption, at the cost increasing database size and/or number of disk IOPs. So, SyncMode::SafeNoSync flag could be used with Environment::sync() as alternatively for batch committing or nested transaction (in some cases).

The number and volume of disk IOPs with SyncMode::SafeNoSync flag will exactly the as without any no-sync flags. However, you should expect a larger process’s work set and significantly worse a locality of reference, due to the more intensive allocation of previously unused pages and increase the size of the database.

UtterlyNoSync

Don’t sync anything and wipe previous steady commits.

Don’t flush system buffers to disk when committing a transaction. This optimization means a system crash can corrupt the database, if buffers are not yet flushed to disk. Depending on the platform and hardware, with SyncMode::UtterlyNoSync you may get a multiple increase of write performance, even 100 times or more.

If the filesystem preserves write order (which is rare and never provided unless explicitly noted) and the WriteMap and EnvironmentFlags::liforeclaim flags are not used, then a system crash can’t corrupt the database, but you can lose the last transactions, if at least one buffer is not yet flushed to disk. The risk is governed by how often the system flushes dirty buffers to disk and how often Environment::sync() is called. So, transactions exhibit ACPI (atomicity, consistency, isolation) properties and only lose D (durability). I.e. database integrity is maintained, but a system crash may undo the final transactions.

Otherwise, if the filesystem not preserves write order (which is typically) or WriteMap or EnvironmentFlags::liforeclaim flags are used, you should expect the corrupted database after a system crash.

So, most important thing about SyncMode::UtterlyNoSync:

• A system crash immediately after commit the write transaction high likely lead to database corruption.
• Successful completion of Environment::sync(force=true) after one or more committed transactions guarantees consistency and durability.
• BUT by committing two or more transactions you back database into a weak state, in which a system crash may lead to database corruption! In case single transaction after Environment::sync(), you may lose transaction itself, but not a whole database.

Nevertheless, SyncMode::UtterlyNoSync provides “weak” durability in case of an application crash (but no durability on system failure), and therefore may be very useful in scenarios where data durability is not required over a system failure (e.g for short-lived data), or if you can take such risk.

Trait Implementations

impl Clone for SyncMode

fn clone(&self) -> SyncMode

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for SyncMode

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for SyncMode

fn default() -> Self

Returns the “default value” for a type.

impl Copy for SyncMode

Layout

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.

Size: 1 byte

Size for each variant:

• Durable: 0 bytes
• NoMetaSync: 0 bytes
• SafeNoSync: 0 bytes
• UtterlyNoSync: 0 bytes