Persistence and performance trade-off in Redis - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Redis Persistence Options

Which Redis persistence method offers the best balance between data durability and write performance?

A RDB snapshots taken at intervals

B AOF with every write fsync

C AOF with fsync every second

D No persistence enabled

💡 Hint

Consider how often data is saved and the impact on write speed.

AOF with fsync every second provides a good trade-off by saving data frequently enough to avoid large data loss, while not slowing down writes as much as fsync on every write.

❓ query_result

intermediate

Result of Redis Command with Persistence Disabled

Assuming Redis is running with persistence disabled, what will be the result after a server restart if the following commands were executed before restart?

SET key1 value1
SET key2 value2

What will be the value of GET key1 after restart?

A nil

B "value1"

C Error: key not found

D "value2"

💡 Hint

Think about what happens to data when persistence is off and the server restarts.

With persistence disabled, all data is stored only in memory. After a restart, memory is cleared, so GET key1 returns nil.

📝 Syntax

advanced

Identify the Correct Redis Configuration for Minimal Data Loss

Which Redis configuration snippet ensures minimal data loss while maintaining reasonable performance?

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

Redis

appendonly yes
appendfsync everysec
save 900 1
save 300 10
save 60 10000

A

appendonly yes
appendfsync always
save 900 1
save 300 10
save 60 10000

B

appendonly yes
appendfsync everysec
save 900 1
save 300 10
save 60 10000

C

appendonly yes
appendfsync no
save 900 1
save 300 10
save 60 10000

D

appendonly no
save 900 1
save 300 10
save 60 10000

💡 Hint

Check which appendfsync option balances durability and performance.

Setting appendonly yes with appendfsync everysec enables AOF persistence with fsync every second, minimizing data loss and keeping performance reasonable.

❓ optimization

advanced

Optimizing Redis for High Write Throughput with Persistence

You want to optimize Redis for high write throughput but still keep data safe in case of crashes. Which approach is best?

A Enable RDB snapshots only with frequent saves

B Disable persistence and rely on replication only

C Enable AOF with appendfsync always

D Enable AOF with appendfsync everysec and tune RDB snapshot intervals

💡 Hint

Think about balancing disk writes frequency and snapshot overhead.

Using AOF with fsync every second reduces disk I/O overhead compared to always fsync, while RDB snapshots provide backups. This balances throughput and durability.

🔧 Debug

expert

Diagnosing Data Loss Despite Persistence Enabled

A Redis server has appendonly yes and appendfsync everysec set, but after a crash, some recent writes are lost. What is the most likely cause?

A appendfsync everysec allows up to 1 second of data loss on crash

B The AOF file was corrupted and Redis could not recover it

C RDB snapshots overwrite the AOF file causing data loss

D Redis was running without enough memory causing eviction

💡 Hint

Consider how appendfsync everysec works during crashes.

appendfsync everysec flushes data to disk every second, so up to one second of writes can be lost if a crash happens before the flush.

Practice

1. Which Redis persistence method saves data at specific time intervals, balancing durability and performance?

easy

A. No persistence

B. AOF logging

C. RDB snapshots

D. In-memory only

Solution

1. Step 1: Understand Redis persistence options

   Redis offers RDB snapshots and AOF logging for persistence.

2. Step 2: Identify method saving data at intervals

   RDB snapshots save data periodically, while AOF logs every write.

3. Final Answer:

   RDB snapshots -> Option C

4. Quick Check:

   Persistence by snapshots = RDB snapshots [OK]

Hint: Snapshots save periodically, logs save every write [OK]

Common Mistakes:

• Confusing AOF with snapshots
• Thinking no persistence saves data
• Assuming in-memory is persistent

2. Which Redis configuration option enables Append Only File (AOF) persistence?

easy

A. appendonly yes

B. appendonly no

C. save 900 1

D. stop-writes-on-bgsave-error no

Solution

1. Step 1: Identify AOF enabling option

   The option to enable AOF is 'appendonly yes'.

2. Step 2: Differentiate from snapshot options

   'save 900 1' relates to RDB snapshots, not AOF.

3. Final Answer:

   appendonly yes -> Option A

4. Quick Check:

   Enable AOF = appendonly yes [OK]

Hint: Enable AOF with 'appendonly yes' in config [OK]

Common Mistakes:

• Using 'appendonly no' disables AOF
• Confusing 'save' with AOF setting
• Misreading unrelated config options

3. Given Redis configured with RDB snapshots every 60 seconds and AOF enabled with 'appendfsync everysec', what is the maximum data loss if Redis crashes?

medium

A. Up to 1 second of data loss

B. Up to 60 seconds of data loss

C. No data loss

D. Up to 5 minutes of data loss

Solution

1. Step 1: Understand RDB snapshot interval

   Snapshots save every 60 seconds, so up to 60 seconds loss if using RDB only.

2. Step 2: Consider AOF 'appendfsync everysec'

   This setting syncs AOF every second, limiting loss to up to 1 second.

3. Step 3: Combine effects

   With both RDB and AOF enabled, Redis prioritizes AOF for recovery of recent writes, so maximum data loss is 1 second.

4. Final Answer:

   Up to 1 second of data loss -> Option A

5. Quick Check:

   AOF everysec = up to 1s loss [OK]

Hint: Max loss = AOF fsync interval when AOF enabled [OK]

Common Mistakes:

• Thinking RDB interval dominates with AOF enabled
• Ignoring AOF sync policy
• Confusing 'everysec' with immediate sync

4. You configured Redis with 'appendonly yes' but notice no AOF file is created. What is the most likely cause?

medium

A. AOF file is corrupted

B. RDB snapshots disabled

C. Disk is full

D. Redis was not restarted after config change

Solution

1. Step 1: Check if config changes take effect immediately

   Changing 'appendonly yes' requires Redis restart to activate.

2. Step 2: Rule out other causes

   Disk full or corruption would cause errors, snapshots don't affect AOF creation.

3. Final Answer:

   Redis was not restarted after config change -> Option D

4. Quick Check:

   Config changes need restart [OK]

Hint: Restart Redis after enabling AOF [OK]

Common Mistakes:

• Assuming snapshots affect AOF file
• Ignoring need to restart Redis
• Blaming disk issues without checking

5. You want Redis to minimize data loss but can tolerate some performance cost. Which configuration best fits this need?

hard

A. Enable RDB snapshots every 15 minutes and disable AOF

B. Enable AOF with 'appendfsync everysec' and RDB snapshots every 5 minutes

C. Enable AOF with 'appendfsync always' and disable RDB snapshots

D. Disable both AOF and RDB snapshots for max speed

Solution

1. Step 1: Understand data loss vs performance trade-off

   'appendfsync always' is safest but slowest; 'everysec' balances safety and speed.

2. Step 2: Combine AOF and snapshots for better durability

   Using both reduces data loss and improves recovery options.

3. Step 3: Evaluate options

   Enable AOF with 'appendfsync everysec' and RDB snapshots every 5 minutes balances minimal data loss with acceptable performance cost.

4. Final Answer:

   Enable AOF with 'appendfsync everysec' and RDB snapshots every 5 minutes -> Option B

5. Quick Check:

   Balanced persistence = AOF everysec + snapshots [OK]

Hint: Use AOF everysec plus snapshots for balance [OK]

Common Mistakes:

• Choosing 'appendfsync always' for performance
• Disabling persistence for safety
• Relying on snapshots alone for minimal loss