Sample questions
Redis PersistenceDifficulty 1
What is RDB persistence in Redis?
- aA log of every write command appended to a file as it happens
- bA binary point-in-time snapshot of the dataset✓
- cA replication mechanism that copies data to a replica node in real time
- dAn in-memory-only mode where no data is ever written to disk
Explanation:RDB (Redis Database) persistence produces a compact, point-in-time binary snapshot of the whole dataset. It is not an append-only command log (that's AOF, option a), not replication (option c), and it does write to disk, so option d is wrong.
Redis PersistenceDifficulty 1
What is AOF (Append Only File) persistence in Redis?
- aA binary snapshot of the dataset taken every hour by default
- bA feature that keeps a replica's data in sync with the master
- cA replayable log of received write operations✓
- dA compression format applied to RDB files to reduce disk usage
Explanation:AOF logs every write operation as it is received; on restart, Redis replays that log to reconstruct the dataset. It is not a periodic snapshot (that's RDB, option a), not replication (option b), and not a compression scheme (option d).
Redis PersistenceDifficulty 2
A team runs SAVE directly on a production Redis instance with a large dataset and notices the whole server stops responding to any command for several seconds. What is the most likely explanation?
- a
SAVE writes the RDB synchronously on Redis's main thread, blocking command processing until it finishes✓ - b
SAVE always fails silently on large datasets and the freeze is caused by an unrelated network issue - c
SAVE triggers a full AOF rewrite, which is what actually blocks the server - d
SAVE is deprecated and no longer exists in modern Redis, so the command has no effect other than the observed delay
Explanation:SAVE runs in the main thread and blocks all other commands until the snapshot finishes writing. BGSAVE instead forks a child process to write the snapshot so the parent process keeps serving traffic. AOF rewrite (c) is a separate mechanism, and SAVE is a real, still-supported command (d).
Redis PersistenceDifficulty 2
Why does BGSAVE fork a child process instead of writing the snapshot from the main Redis process?
- aBecause forking is required by the operating system for any file write
- bBecause the child process runs on a different CPU core to guarantee parallelism on all platforms
- cBecause the parent process cannot access disk I/O at all
- dSo the parent process can keep serving client commands while the child writes the snapshot using a copy-on-write memory view of the dataset✓
Explanation:Forking lets the child process take a consistent, copy-on-write snapshot of memory while the parent keeps handling requests uninterrupted. It's not an OS requirement for writes in general (a), core placement isn't guaranteed (b), and the parent can absolutely do disk I/O (c) — that's exactly what SAVE does.
Redis PersistenceDifficulty 1
appendonly yes
appendfsync everysec
What does the
appendfsync everysec setting mean?
- aRedis calls
fsync() on the AOF file after every single write command - bRedis calls
fsync() on the AOF file at most once per second, batching writes in between✓ - cRedis never calls
fsync() and relies entirely on the operating system's own flush timing - dRedis rewrites the entire AOF file from scratch every second
Explanation:everysec batches disk syncs to roughly once per second, trading a small potential data-loss window (up to ~1 second of writes) for much better throughput than syncing on every write (always, option a) while still syncing far more predictably than leaving it entirely to the OS (no, option c). Rewriting the whole file every second (d) is not what fsync does — that's AOF rewrite, a separate operation.
Redis PersistenceDifficulty 2
A Redis instance is configured with appendonly yes and appendfsync everysec. The server process crashes due to a power failure. How much data is Redis likely to lose in the worst case?
- aAll data since the last RDB snapshot, potentially hours of writes
- bNothing at all —
everysec guarantees zero data loss under any failure - cUp to roughly one second of the latest writes✓
- dExactly the last single write command, regardless of write volume
Explanation:With everysec, writes are buffered and fsynced to disk about once per second, so a crash can lose whatever writes happened since the last fsync — up to ~1 second's worth, not zero (b) and not tied to RDB snapshot intervals (a, which would apply if AOF were disabled). It's not a fixed single command either (d) — it's a time window, not a command count.