Redis hard
In a background AOF Rewrite, how does Redis ensure that new write commands arriving during the rewrite are not permanently lost?
- A It rejects incoming write requests with a specific 'Busy' error until the OS confirms the file swap is complete.
- B It stores new writes in a specialized Rewrite Buffer and appends them to the new AOF once the background task finishes.
- C It forces an immediate RDB snapshot to capture the delta changes and merges it with the finalized log file.
- D It relies on the client-side drivers to retry any failed commands until the server signals resonance with the disk.
Answer: B. It stores new writes in a specialized Rewrite Buffer and appends them to the new AOF once the background task finishes.
Rewriting a 10GB AOF takes time. The buffer bridges the gap. Once the new (small) file is ready, Redis 'catches up' by playing the buffer contents into it, then atomically swaps the new file into the primary role.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- If the Redis memory limit is reached, what specific behavior is exhibited by the `allkeys-lru` eviction policy?
- What is the defining characteristic of a Redis 'Set' data type compared to a standard Redis 'List'?
- In the context of Redis messaging, what is the functional definition of the 'Pub/Sub' feature?
- How does the Redis background snapshotting process (`BGSAVE`) leverage the operating system's `fork()` mechanism to minimize memory overhead?
- Why does Redis proactively disconnect a Pub/Sub client that exhibits high 'output buffer' usage relative to its ingestion rate?
- How does a 'Sorted Set' (ZSET) manage its internal membership and ordering differently from a plain Set?