AOF Persistence Practice

All three policies lose the write equally, because appending to the AOF buffer only happens after fsync has succeeded.

Both `always` and `everysec` guarantee zero loss because they involve fsync; only `no` can lose the write — the difference between them is only how much CPU the fsync calls cost.

Always minimizes that window by fsyncing each write, everysec can lose about the last second, and no depends on the operating system flush schedule.

Everysec is the safest because batching gives the OS time to flush, while `always` risks losing more writes under load.

GET is read-only and should not be replayed, while EXPIRE changes future state and may need to be recorded as a mutation.

Both should appear, because the AOF must record every command the server executed in order to reproduce the exact history.

EXPIRE is also excluded, because TTL metadata lives outside the keyspace and is restored separately from the command log.

GET is excluded because replaying it would overwrite the stored value with whatever the command returned at logging time.

It is valid because INCR commands are idempotent, so collapsing any number of them never changes the final result.

It is only valid if the original log contained exactly 42 increments; otherwise the rewrite must preserve the full history.

It is valid because rewrite scans the old log and keeps only the last command seen for each key, discarding the rest.

SET counter 42 is valid if 42 is the current state; rewrite stores an equivalent compact history rather than every increment.

Replaying a relative TTL makes the key expire too early, because replay runs much faster than real time.

A relative expiration can grant extra lifetime after downtime, so AOF should replay an absolute deadline or normalized command.

Relative expirations cannot be parsed during replay, because the original wall-clock time is not stored anywhere in the file, which is why the loader falls back to treating them as absolute deadlines.

The danger is double expiration, where the key is removed once at runtime and once again at replay, corrupting the keyspace.

The fsync policy is about file size, while rewrite is the correctness mechanism that repairs a corrupted log.

Appending and rewrite are both correctness mechanisms; file size is managed entirely by the operating system.

Appending and replaying the right mutations is correctness; rewrite is mainly about bounding file size while preserving equivalent state.

Rewrite is about correctness because it removes commands that failed, while appending controls file size through buffering.