RDB Snapshotting Practice

It should not appear in that snapshot; copy-on-write lets the child keep the fork-time view while the parent changes later pages.

It appears in the snapshot, because the child reads live memory and the write happened before the file was finished.

It appears only if the write landed on a memory page the child had not yet serialized to disk.

It should not appear, and copy-on-write enforces that by blocking the parent's writes until the child finishes writing the temporary file to disk.

Rename is mainly about visibility speed; protection of the old file actually comes from advisory file locks.

Rename automatically preserves the old snapshot under a backup suffix in the same directory.

Writing directly into the final filename would be equally safe, provided fsync is called once at the end.

Atomic rename keeps the old valid snapshot in place until the new temporary file is fully written.

Only the raw field-value bytes, since the loader can infer the type from the shape of the data.

The snapshot must store logical type, value data, encoding-relevant information, and expiration metadata needed to restore behavior.

The memory addresses of the hash table's buckets, so the structure can be mapped back to its original location.

The field-value pairs plus the list of clients that created them, so ownership can be re-established after loading and replay of any transactions that were in flight.

RDB files are memory-mapped and used in place, so loading costs almost nothing regardless of size.

RDB load skips expiration handling entirely, while AOF replay must evaluate the TTL of every command, which RDB postpones until the dataset is fully resident.

RDB can load faster because it reads a compact serialized dataset instead of replaying every historical write command.

AOF replay is slower only because it fsyncs after each replayed command for safety.

Only writes made while a snapshot is actively in progress can be lost; the gaps between snapshots are safe.

No loss window exists as long as snapshots are scheduled more frequently than the eviction cycle runs.

Writes after the last completed snapshot can be lost if the process crashes before the next snapshot succeeds.

The window is a single event-loop tick, namely the replies that had not yet been flushed to client sockets.