What if your data vanished just because you waited too long to save it?
Why Combined RDB + AOF in Redis? - Purpose & Use Cases
Imagine you run a busy store and keep track of sales on paper. Every hour, you copy all sales into a big book. But if the store closes suddenly, you lose all sales since the last copy.
Copying all sales manually every hour is slow and misses recent sales if a sudden event happens. Also, writing every sale on paper takes time and can cause mistakes or lost data.
Combined RDB + AOF in Redis saves a full snapshot occasionally (RDB) and logs every change (AOF). This way, you get fast recovery from snapshots and no lost data from recent changes.
save_every_hour() log_changes_manually()
redis.conf: save snapshots + appendonly yes
You can recover your data quickly and safely without losing recent updates, even if the system crashes unexpectedly.
An online game saves player scores every few minutes (RDB) and records every move instantly (AOF), so no progress is lost if the server restarts.
Manual backups miss recent changes and are slow.
RDB snapshots save full data fast but can lose recent updates.
AOF logs every change to prevent data loss.
Practice
Solution
Step 1: Understand RDB persistence
RDB creates snapshots periodically, allowing Redis to start quickly by loading a compact file.Step 2: Understand AOF persistence
AOF logs every write operation, ensuring data durability by replaying commands after a restart.Final Answer:
It combines fast startup with high data durability. -> Option BQuick Check:
Combined RDB + AOF = Fast startup + durability [OK]
- Thinking combined persistence disables data saving
- Confusing RDB with AOF roles
- Assuming combined persistence reduces memory usage
Solution
Step 1: Identify RDB snapshot setting
The 'save 900 1' means save snapshot if at least 1 change in 900 seconds.Step 2: Identify AOF setting
'appendonly yes' enables AOF persistence logging every write.Final Answer:
appendonly yes and save 900 1 -> Option DQuick Check:
Enable both RDB and AOF with save + appendonly yes [OK]
- Setting appendonly no disables AOF
- Empty save disables RDB snapshots
- Confusing syntax for save option
Solution
Step 1: Understand RDB snapshot timing
RDB snapshots happen periodically, so recent writes after last snapshot are not saved there.Step 2: Understand AOF recovery
AOF logs every write, so Redis replays AOF to restore all writes including recent ones.Final Answer:
Data is restored from AOF log, including recent writes after last snapshot. -> Option AQuick Check:
AOF recovers recent writes missed by RDB [OK]
- Assuming only RDB restores data
- Thinking Redis starts empty after crash
- Believing Redis merges snapshot and AOF causing duplicates
Solution
Step 1: Check AOF role in recovery
AOF logs all writes and is used to restore recent data after restart.Step 2: Identify cause of missing recent data
If AOF is corrupted or disabled, recent writes after last snapshot are lost.Final Answer:
AOF file was corrupted or disabled during restart. -> Option CQuick Check:
Missing recent data usually means AOF problem [OK]
- Assuming Redis can't combine RDB and AOF
- Ignoring AOF file corruption possibility
- Blaming wrong port for data loss
Solution
Step 1: Understand RDB snapshot interval
Snapshots every 15 minutes reduce blocking frequency and provide periodic backups.Step 2: Understand AOF 'everysec' fsync
'everysec' fsync writes AOF to disk every second asynchronously, balancing durability and performance.Step 3: Combine effects
This combination offers fast recovery from snapshots and durability from AOF with low performance cost.Final Answer:
This setup balances fast recovery and durability with minimal performance impact. -> Option AQuick Check:
RDB + AOF everysec = balanced durability and speed [OK]
- Thinking 'everysec' fsync is synchronous after every command
- Assuming RDB snapshots block Redis for long every time
- Believing this setup disables AOF durability
Ready to prove it?
Pass the test and this pattern moves unknown
