Redis-Persistenzoptionen: RDB vs. AOF erklärt

Die Redis-Persistenz entscheidet darüber, wie viele Daten Ihr Redis-Server nach einem Neustart oder Absturz wiederherstellen kann. Die beiden Hauptoptionen sind RDB-Snapshots und AOF-Protokolle, und die richtige Wahl hängt davon ab, wie viele aktuelle Daten Ihre Anwendung verlieren kann.

Redis speichert Daten im Arbeitsspeicher für Geschwindigkeit. Die Persistenz schreibt ausreichend Zustand auf die Festplatte, damit Redis diese Daten später wieder aufbauen kann. Sie können RDB, AOF, beide oder keines verwenden, aber Produktionssysteme sollten diese Wahl bewusst treffen.

Redis-Persistenz verstehen

Persistenz in Redis bezieht sich auf den Prozess des Schreibens des aktuellen Zustands des In-Memory-Datensatzes auf die Festplatte. Dies ermöglicht Redis, die Daten beim Neustart des Servers neu zu laden. Ohne aktivierte Persistenz gehen alle Daten beim Herunterfahren verloren.

Redis unterstützt sowohl RDB als auch AOF gleichzeitig und bietet einen hybriden Ansatz, der die besten Eigenschaften beider kombiniert.

RDB-Snapshots

RDB erstellt punktgenaue Snapshots Ihres Datensatzes und schreibt sie in eine kompakte Binärdatei, die normalerweise dump.rdb heißt.

Wie RDB funktioniert

RDB funktioniert normalerweise durch Forken des Redis-Prozesses. Der untergeordnete Prozess schreibt den Datensatz auf die Festplatte, während der übergeordnete Prozess weiterhin Clients bedient. Da RDB ein Snapshot ist, erfasst es Daten, wie sie zu einem bestimmten Zeitpunkt existierten.

Konfiguration und Snapshot-Erstellung

Die RDB-Konfiguration wird mit save-Direktiven in redis.conf verwaltet. Diese Direktiven legen fest, wann Redis einen automatischen Snapshot erstellen soll:

# Datenbank speichern, wenn 1000 Schlüssel in 1 Minute geändert wurden
save 600 1000
# Datenbank speichern, wenn 10 Schlüssel in 10 Minuten geändert wurden
save 300 10
# Datenbank speichern, wenn 10000 Schlüssel in 1 Sekunde geändert wurden
save 1 10000

Um automatische RDB-Snapshots zu deaktivieren, entfernen Sie die save-Direktiven oder setzen Sie:

save ""

Sie können jederzeit einen manuellen Hintergrund-Snapshot mit BGSAVE auslösen, wenn Sie einen benötigen.

Vorteile von RDB

Kompakte Dateien: RDB-Dateien sind effizient für Backups, Kopien und Notfallwiederherstellungsarchive.
Schnelle Wiederherstellung: Das Laden eines Snapshots ist normalerweise schneller als das Abspielen eines langen Befehlsprotokolls.
Geringerer stetiger Schreibaufwand: Redis schreibt nicht jeden Befehl in die Persistenzdatei.

Nachteile von RDB

Datenverlustrisiko: Wenn Redis zwischen Snapshots abstürzt, gehen Schreibvorgänge nach dem letzten erfolgreichen Snapshot verloren.
Fork-Overhead: Große Datensätze können fork() teuer machen und zu Latenzspitzen führen.
Kein vollständiges Prüfprotokoll: RDB speichert den Endzustand, nicht jeden Schreibvorgang, der dazu geführt hat.

AOF-Protokolle

AOF (Append-Only File) bietet ein höheres Maß an Datenhaltbarkeit. Anstelle von Snapshots protokolliert AOF jeden vom Server empfangenen Schreibvorgang in einem Append-Only-Format.

Wie AOF funktioniert

Wenn AOF aktiviert ist, zeichnet Redis Schreibbefehle wie SET, HSET und LPUSH in einer Append-Only-Datei auf. Beim Neustart spielt Redis diese Datei ab, um den Datensatz neu aufzubauen.

AOF-Konfiguration

Die AOF-Persistenz ist standardmäßig deaktiviert und muss explizit in redis.conf aktiviert werden:

appendonly yes

Entscheidend ist, dass AOF die Konfiguration der fsync-Richtlinie ermöglicht, die bestimmt, wie oft Schreibvorgänge auf die Festplatte erzwungen werden:

fsync-Richtlinie	Beschreibung	Haltbarkeit vs. Leistung
`no`	Betriebssystem übernimmt Synchronisation (am seltensten).	Am schnellsten, höchstes Verlustrisiko.
`everysec`	Etwa einmal pro Sekunde synchronisieren.	Gute Balance. Begrenzt Verluste bei Serverabsturz normalerweise auf etwa eine Sekunde.
`always`	Nach jedem Befehl synchronisieren.	Höchste Haltbarkeit, potenziell erhebliche Leistungseinbußen.

Vorteile von AOF

Höhere Haltbarkeit: appendfsync everysec ist ein üblicher Produktionskompromiss; always ist strenger, aber langsamer.
Lesbare Absicht: AOF speichert Schreibbefehle, daher kann es einfacher zu überprüfen sein als eine RDB-Binärdatei.
Automatische Komprimierung: AOF-Rewrite kann ein großes Protokoll auf die minimalen Befehle reduzieren, die zum Wiederaufbau des aktuellen Zustands erforderlich sind.

Nachteile von AOF

Größere Dateien: AOF-Dateien sind oft größer als RDB-Snapshots, da sie Befehle speichern.
Langsamerer Neustart: Das Abspielen eines langen AOF kann länger dauern als das Laden eines RDB-Snapshots.
Höherer Schreibaufwand: Redis muss Schreibbefehle anhängen und gemäß Ihrer appendfsync-Einstellung synchronisieren.

AOF-Rewriting

Um dem Dateigrößenwachstum entgegenzuwirken, implementiert Redis das AOF-Rewriting. Dieser Prozess erstellt asynchron eine neue, optimierte AOF-Datei, die nur die Befehle enthält, die zum Erreichen des aktuellen Zustands erforderlich sind, und verwirft effektiv redundante oder veraltete Befehle (wie mehrere Aktualisierungen desselben Schlüssels).

RDB vs. AOF: Direkter Vergleich

Die Wahl zwischen RDB, AOF oder beiden hängt vollständig von den Anforderungen Ihrer Anwendung an Wiederherstellungszeit und Datenverlusttoleranz ab.

Merkmal	RDB (Snapshotting)	AOF (Append-Only File)
Haltbarkeit/Datenverlust	Höherer potenzieller Datenverlust (seit letztem Speichern).	Minimaler Datenverlust (bis zu 1 Sekunde oder null mit `fsync=always`).
Dateigröße	Sehr kompakt und optimiert.	Größer aufgrund der Befehlsprotokollierung.
Neustartzeit	Sehr schnelles Laden des Snapshots.	Langsamer, erfordert Befehlsabspielung.
Komplexität	Einfach, durch Zeitintervalle konfiguriert.	Erfordert sorgfältige Konfiguration der `fsync`-Richtlinie.
Anwendungsfall	Backups, Notfallwiederherstellung, wenn aktueller Datenverlust tolerierbar ist.	Primärer Persistenzmechanismus, der hohe Haltbarkeit erfordert.

Best Practice: Kombinieren von RDB und AOF

Für viele Produktionsbereitstellungen bietet die Aktivierung sowohl von RDB als auch von AOF ein nützliches Sicherheitsnetz.

Wenn beide aktiviert sind:

AOF stellt das primäre, hochhaltbare Protokoll bereit.
RDB bietet einen schnellen, kompakten Backup-Snapshot.

Wenn beide aktiviert sind, lädt Redis beim Neustart das AOF, da es normalerweise vollständiger ist als der letzte RDB-Snapshot. RDB liefert Ihnen dennoch kompakte Backup-Dateien, die einfach zu kopieren, zu testen und zu archivieren sind.

So aktivieren Sie beide

Stellen Sie sicher, dass beide Konfigurationen in redis.conf gesetzt sind:

# AOF aktivieren
appendonly yes

# RDB-Konfiguration beibehalten (z. B. automatisches Speichern jede Stunde)
save 3600 1

# Empfohlene fsync-Richtlinie für AOF
appendfsync everysec

Tipp zum AOF-Rewriting: Sie können jederzeit manuell ein AOF-Rewrite mit dem Befehl BGREWRITEAOF auslösen. Dies ist besonders nützlich nach großen Bulk-Datenladungen oder erheblichen Löschvorgängen, um die AOF-Dateigröße sofort zu verkleinern.

Fazit

Verwenden Sie RDB, wenn Sie kompakte Backups wünschen und tolerieren können, seit dem letzten Snapshot aktuelle Schreibvorgänge zu verlieren. Verwenden Sie AOF, wenn Redis Daten speichert, die Abstürze mit minimalen Verlusten überstehen sollen. Für wichtige Produktionsdaten aktivieren Sie AOF mit appendfsync everysec, behalten Sie RDB-Snapshots für Backups bei und testen Sie die Wiederherstellungszeit, bevor ein Ausfall die Frage erzwingt.