In Redis zijn er twee manieren om gegevens permanent op te slaan: AOF (Append-Only File) en RDB (Redis Database Snapshot). In productieomgevingen worden meestal beide instellingen samen gebruikt, maar veel ontwikkelaars kunnen de volgende vragen hebben.

"AOF registreert gegevens in real-time, heeft RDB-instelling dan nog zin?" "AOF heeft toch de prioriteit voor herstel, is RDB dan niet overbodig?"

Echter, in echte productieomgevingen is RDB ook absoluut noodzakelijk. Laten we de redenen bekijken.

Redis RDB vs AOF Infographic

1. AOF-bestand kan beschadigd raken

AOF registreert alle wijzigingen, maar er is een risico op bestandscorruptie. Als het AOF-bestand beschadigd raakt door een schijffout, een storing tijdens werking of een verkeerde bestandsverplaatsing, kan herstel moeilijk zijn.

redis-server --appendonly yes

Als het AOF-bestand beschadigd is bij het opnieuw opstarten van Redis, kan het onmogelijk zijn om gegevens te herstellen. In dat geval kan een RDB-backup helpen om minimaal gegevens te herstellen.

✅ Wat als je alleen AOF gebruikt en het bestand beschadigt? Verhoogd risico op gegevensverlies

✅ Wat als je een RDB hebt? Mogelijk om minimaal gegevens te herstellen

2. Herstelsnelheid van AOF is traag

AOF moet alle wijzigingen een voor een opnieuw uitvoeren om te herstellen. Hoe meer data er is, hoe langer het kan duren om te herstellen bij een herstart van Redis.

Bijvoorbeeld, als het AOF-bestand 2GB groot is, moet Redis miljoenen SET-opdrachten uitvoeren. RDB daarentegen kan veel sneller herstellen omdat het simpelweg een dumpbestand laadt.

✅ Wat als je alleen AOF gebruikt? Verhoogd risico op lange hersteltijden

✅ Wat als je RDB samen gebruikt? Sneller herstel mogelijk

3. RDB is gunstig voor backups en servermigratie

Bij het maken van databackups in productieomgevingen is AOF moeilijk te gebruiken vanwege de grote bestandsgrootte en logformaat. RDB daarentegen is kleiner in bestandsgrootte en kan gegevens op een specifiek tijdstip volledig behouden, waardoor backups veel gemakkelijker zijn.

✔ Voorbeeld van backup met RDB:

cp /var/lib/redis/dump.rdb /backup/dump-2025-02-17.rdb

✔ Voorbeeld van gegevensoverdracht naar een andere server:

scp /var/lib/redis/dump.rdb new-server:/var/lib/redis/

✅ AOF is moeilijker te backuppen naarmate er meer data is

✅ RDB is gunstig voor snelle backup en herstel van gegevens op specifieke tijdstippen

4. Vermindering van schijf I/O belasting

AOF moet alle wijzigingen op de schijf registreren, wat zorgt voor een grote schijf I/O belasting. RDB daarentegen slaat slechts één keer per bepaalde periode op, waardoor de belasting op de schijf lager is.

✅ Wat als je alleen AOF gebruikt? Verhoogde schijfbelasting mogelijk

✅ Wat als je RDB samen gebruikt? Prestatie-optimalisatie mogelijk

5. Aanbevolen RDB + AOF instellingen voor productieomgevingen

In productieomgevingen wordt de volgende configuratie aanbevolen.

# RDB snapshot instellingen (gegevens opslaan als aan bepaalde voorwaarden wordt voldaan)
# save <seconds> <changes> [<seconds> <changes> ...]
save 900 1 300 10 60 10000 
# sla op als er meer dan 1 key is veranderd in 900 seconden (15 minuten), of meer dan 10 keys in 300 seconden (5 minuten), of meer dan 10.000 keys in 60 seconden (1 minuut)

# AOF inschakelen
appendonly yes
appendfsync everysec  # elke seconde naar de schijf schrijven voor een balans tussen prestaties en stabiliteit

# Automatische optimalisatie van AOF-bestandsgrootte (rewrite)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

🔍 Hoe worden meerdere save voorwaarden geëvalueerd?

In Redis werken alle save voorwaarden als OR voorwaarden. Dit betekent dat een enkele voorwaarde al voldoende is om een snapshot op te slaan.

✔ Voorbeeld 1: Ingesteld met save 900 1 en save 60 10000 - als er in 900 seconden meer dan 1 key is veranderd of - als er in 60 seconden meer dan 10.000 keys zijn veranderd, - wordt een RDB snapshot opgeslagen.

✔ Voorbeeld 2: Bij het toevoegen van de save 300 10 voorwaarde - als er in 300 seconden meer dan 10 keys zijn veranderd of - als er in 900 seconden meer dan 1 wijziging is geweest of - als er in 60 seconden meer dan 10.000 wijzigingen zijn, - wordt een RDB snapshot opgeslagen.

✅ Alle save opties worden geëvalueerd als OR voorwaarden

✅ Als één voorwaarde wordt voldaan, wordt RDB onmiddellijk opgeslagen

Conclusie: RDB is noodzakelijk, zelfs met AOF

✅ AOF alleen biedt geen volledige gegevensbescherming

✅ Als AOF beschadigt, speelt RDB de ultieme backuprol

✅ De herstelsnelheid van AOF kan traag zijn, dus door RDB te gebruiken kan snel worden hersteld

✅ RDB is gunstig voor backups en servermigratie

✅ Kan de schijf I/O belasting verlagen en prestaties optimaliseren

✅ save instellingen werken als OR voorwaarden, zodat zodra aan één voorwaarde is voldaan, RDB wordt opgeslagen

Daarom is het in productieomgevingen het veiligste en optimale om RDB + AOF samen in te stellen.

Zoek `Redis` in de zoekbalk rechts! Er zijn meer berichten gerelateerd aan Redis beschikbaar. 

Bekijk ook het vorige bericht met een analyse van de AOF Rewrite functie.

Redis AOF Rewrite: Prestatieoptimalisatie en Gegevensbehoud