Hvordan fungerer Redis persistering (RDB vs AOF)?

Question

Accepted Answer

Selv om Redis er in-memory, kan det **persistere data til disk** slik at data overlever omstarter. Det tilbyr to mekanismer — **RDB** (øyeblikksbilder på et bestemt tidspunkt) og **AOF** (logg over operasjoner som kun legges til) — med forskjellige avveininger mellom holdbarhet og ytelse.

## RDB — øyeblikksbilder på et bestemt tidspunkt

```text
RDB takes SNAPSHOTS of the dataset at intervals, saving a compact binary file.
  ✓ Compact single-file backups; fast restarts (load the snapshot)
  ✓ Good for backups and disaster recovery; less impact on performance
  ✗ You can LOSE data since the last snapshot (e.g. last few minutes) if Redis crashes
→ Configure save points: e.g. "save after 900s if ≥1 change, 300s if ≥10 changes"
```

RDB lagrer hele datasettet periodisk til en kompakt fil — effektivt og utmerket for sikkerhetskopier, men et krasj mister endringer gjort siden det siste øyeblikksbildet.

## AOF — logg som kun legger til

```text
AOF logs EVERY write operation to a file; on restart, Redis replays the log to rebuild data.
  ✓ More DURABLE — less data loss (can fsync every second, or every write)
  ✓ The log can be rewritten/compacted to stay manageable
  ✗ Larger files; can be slower than RDB; restart (replay) can be slower
→ fsync policies: always (safest, slowest), everysec (good balance), no (fastest, riskiest)
```

AOF registrerer hver skriving, gjenspiller den for å gjenoppbygge data ved omstart — mer holdbar (mindre datatap) men med større filer og potensielt langsommere ytelse/omstarter.

## RDB vs AOF — avveiningen

```text
RDB → better performance, compact backups, faster restart, BUT more potential data loss
AOF → better durability (minimal data loss), BUT larger files, slower

BEST PRACTICE: use BOTH together → RDB for backups + AOF for durability
  → Redis can use both; AOF for recovery, RDB for snapshots/backups
OR: pure cache use → you may DISABLE persistence entirely (data is recreatable)
```

## Hvorfor det er viktig

Å forstå Redis persistering er viktig for **å sikre dataholdbarhet** på passende måte når Redis inneholder data som er viktig, så det er verdifull kunnskap for å bruke Redis riktig.

Alv om Redis primært er in-memory, er det viktig å forstå at den **kan persistere til disk** (slik at data overlever omstarter og krasj), sammen med de to mekanismene og deres avveininger. **RDB** (øyeblikksbilder på et bestemt tidspunkt) tilbyr kompakte sikkerhetskopier, raske omstarter og lavt ytelsestrykk, men risikerer å **miste data siden siste øyeblikksbilder** ved et krasj — bra for sikkerhetskopier og akseptabelt når noe datatap er tolererbart. **AOF** (logging av hver skrivoperasjon, gjenspeilt ved omstart) tilbyr **bedre holdbarhet** (minimalt datatap, konfigurerbart via fsync-retningslinjer) men med større filer og potensielt langsommere ytelse/omstarter.

Å forstå **avveiningen** (RDB for ytelse og kompakte sikkerhetskopier vs AOF for holdbarhet) og den vanlige **beste praksisen med begge sammen** (RDB for øyeblikksbilder/sikkerhetskopier pluss AOF for holdbarhet) gjenspeiler solid konfigurasjonsjønn.

Det er også viktig å innse at for **ren caching-bruk** (der data er gjenopprettbar fra kilden), kan persistering deaktiveres helt — Redis trenger ikke alltid holdbarhet.

Å velge riktig persisteringskonfigurasjon basert på brukstilfelle (holdbarhetsbehov vs ytelse, eller ingen for ren cache) er den viktigste praktiske ferdigheten.

Ettersom dataholdbarhet er viktig når Redis inneholder viktige data (økter, køer, primære data), og ettersom forståelsen av RDB, AOF, deres avveininger og beste praksis (begge sammen, eller ingen for caching) er nødvendig for å konfigurere Redis på passende måte, er forståelse av Redis persistering verdifull, praktisk relevant kunnskap for å bruke Redis ansvarlig — sikring av riktig holdbarhetsnivå for data Redis inneholder, et emne som gjenspeiler forståelse av Redis utover enkel caching.