Datenverlust-Szenarien in Redis und wie man sich absichert

1. Warum Redis unter bestimmten Bedingungen Daten verliert

Datenverlust in Redis ist selten das Ergebnis eines einzelnen katastrophalen Fehlers, sondern meist die Konsequenz einer Kombination aus asynchronen Mechanismen, die im Normalbetrieb unauffällig funktionieren, aber unter Stressbedingungen wie Absturz, Netzwerkpartition oder Failover an ihre Grenzen stoßen. Redis ist bewusst auf Geschwindigkeit optimiert, und praktisch jede Performance-Optimierung, von asynchronem fsync bis zu asynchroner Replikation, erkauft sich diese Geschwindigkeit mit einem klar definierten, aber oft unterschätzten Datenverlust-Fenster.

Dieser Artikel führt die wichtigsten Datenverlust-Szenarien aus den Bereichen Persistence, Eviction und Replikation zusammen und ordnet sie in ein gemeinsames Risikomodell ein. Statt jedes Thema isoliert zu betrachten, geht es hier darum, zu verstehen, wie sich verschiedene Fehlerquellen gegenseitig verstärken können und welche konkreten Absicherungsmaßnahmen das jeweilige Risiko wirksam reduzieren. Am Ende steht eine praktische Checkliste, die sich direkt auf produktive Redis-Deployments anwenden lässt.

2. Szenario 1: Absturz vor dem nächsten fsync

Das klassischste Datenverlust-Szenario betrifft die AOF-Persistence: Bei appendfsync everysec, dem Standardwert, wird fsync höchstens einmal pro Sekunde ausgeführt. Stürzt der Redis-Prozess oder die zugrunde liegende Hardware zwischen zwei fsync-Aufrufen ab, gehen alle Schreibbefehle verloren, die in dieser letzten Sekunde im Betriebssystem-Puffer, aber noch nicht physisch auf Disk lagen. Bei hohem Schreibdurchsatz können das durchaus tausende einzelne Operationen sein.

Noch kritischer wird dieses Szenario bei appendfsync no, wo der Zeitpunkt des fsync vollständig dem Betriebssystem-Kernel überlassen wird. Abhängig von den Dirty-Page-Einstellungen des Kernels kann dieses Fenster mehrere Minuten betragen. Wer diese Einstellung ohne bewusste Risikoabwägung nutzt, unterschätzt häufig das tatsächliche Datenverlust-Potenzial erheblich, insbesondere bei Instanzen, die als Primary Store für nicht anderweitig gesicherte Daten dienen.

3. Szenario 2: Replica-Promotion und ungesicherte Writes

Redis-Replikation ist standardmäßig asynchron: Der Master bestätigt einen Schreibbefehl an den Client, sobald er lokal verarbeitet wurde, unabhängig davon, ob eine Replica die Änderung bereits empfangen hat. Fällt der Master unmittelbar nach dieser Bestätigung aus, bevor die Änderung die Replica erreicht hat, und wird die Replica anschließend zum neuen Master befördert, ist dieser bereits bestätigte Schreibvorgang unwiderruflich verloren. Dieses Szenario ist besonders tückisch, weil der Client bereits eine erfolgreiche Bestätigung erhalten hat und keinen Grund hat, an einem Problem zu zweifeln.

Der Befehl WAIT numreplicas timeout reduziert dieses Datenverlust-Risiko, indem er den Client explizit warten lässt, bis eine definierte Anzahl Replicas die Änderung bestätigt hat, bevor die Anwendung fortfährt. Das verwandelt einen Teil der asynchronen Replikation in eine semi-synchrone Bestätigung, kostet aber zusätzliche Latenz pro Schreibvorgang. Für Daten, bei denen jeder Verlust inakzeptabel ist, ist WAIT in Kombination mit ausreichend vielen Replicas eine der wirksamsten Absicherungen gegen Datenverlust durch Replica-Promotion.

# WAIT-Befehl zur Risikominimierung bei kritischen Schreibvorgängen
redis-cli SET account:balance:8842 "1500.00"
redis-cli WAIT 1 1000
# Wartet bis zu 1000ms auf Bestätigung von mindestens 1 Replica
# Rückgabewert: Anzahl der Replicas, die tatsächlich bestätigt haben

# Prüfen, wie weit eine Replica hinter dem Master liegt
redis-cli --no-raw INFO replication | grep -E "slave0|master_repl_offset"
# slave0:ip=10.0.1.12,port=6379,state=online,offset=48213021,lag=0

4. Szenario 3: Split-Brain und doppelte Writes nach Failover

Split-Brain entsteht, wenn durch eine Netzwerkpartition der alte Master weiterhin Schreibbefehle akzeptiert, während gleichzeitig Sentinel oder eine Cluster-Mehrheit bereits eine Replica zum neuen Master befördert hat. Beide Instanzen akzeptieren nun parallel Schreibvorgänge, ohne voneinander zu wissen. Wird die Netzwerkpartition später aufgehoben, muss sich der alte Master der Konfiguration des neuen Masters unterordnen und wird zu dessen Replica. Alle Schreibvorgänge, die der alte Master während der Partition angenommen hatte, gehen dabei verloren, weil er seinen Datenbestand komplett durch den des neuen Masters ersetzt.

Dieser Datenverlust durch Split-Brain lässt sich nicht vollständig eliminieren, aber deutlich eindämmen: min-replicas-to-write und min-replicas-max-lag konfigurieren den Master so, dass er Schreibvorgänge verweigert, sobald weniger als die definierte Anzahl Replicas mit akzeptabler Verzögerung verbunden ist. Ein isolierter alter Master, der keine Verbindung mehr zu seinen ehemaligen Replicas hat, akzeptiert unter dieser Konfiguration also von selbst keine neuen Schreibvorgänge mehr, was das Zeitfenster für widersprüchliche Writes drastisch verkürzt.

In Redis Cluster übernimmt zusätzlich der Cluster-eigene Gossip-Mechanismus einen Teil dieser Absicherung, weil ein Knoten, der die Mehrheit der anderen Master-Knoten nicht mehr erreicht, den Cluster-Status automatisch als fail markiert und Schreibvorgänge verweigert. Diese eingebaute Mehrheitslogik ist ein struktureller Vorteil gegenüber reiner Sentinel-Überwachung, ersetzt aber nicht die explizite Konfiguration von min-replicas-to-write auf Node-Ebene.

# redis.conf: Split-Brain-Fenster durch Schreibverweigerung begrenzen
min-replicas-to-write 1
min-replicas-max-lag 10

# Aktuelle Konfiguration und verbundene Replicas prüfen
redis-cli CONFIG GET min-replicas-to-write
redis-cli INFO replication | grep connected_slaves

5. Szenario 4: Diskless-Sync-Abbruch und unvollständige Replicas

Ein weiteres, oft übersehenes Datenverlust-Risiko entsteht während des initialen Full Sync einer neuen Replica, insbesondere bei aktivierter Diskless Replication und repl-diskless-load swapdb. Bricht die Netzwerkverbindung während der Übertragung ab, nachdem der Master bereits mit dem atomaren Austausch des Replica-Datenbestands begonnen hat, kann die Replica temporär ohne vollständig funktionsfähigen Datenbestand zurückbleiben. Wird diese unvollständige Replica in diesem Moment fälschlicherweise zum Master befördert, etwa durch einen fehlerhaft konfigurierten Sentinel, entsteht ein erheblicher Datenverlust, der weit über das übliche Replikationsfenster hinausgeht.

Die Absicherung gegen dieses Szenario liegt vor allem im Monitoring des Sync-Zustands: Eine Replica sollte niemals als Failover-Kandidat infrage kommen, solange master_sync_in_progress aktiv ist oder master_link_status nicht seit ausreichender Zeit auf up steht. Sentinel berücksichtigt diesen Zustand grundsätzlich, aber nur bei korrekt konfigurierten Timeout-Werten, die zur tatsächlichen Sync-Dauer der eigenen Umgebung passen.

6. Szenario 5: Eviction von Primary-Store-Daten durch falsche Policy

Ein struktureller, aber häufig übersehener Weg zu Datenverlust ist die falsche maxmemory-policy für eine Instanz, die geschäftskritische Daten ohne Backup in einer Origin-Datenbank hält. Wird versehentlich allkeys-lru oder allkeys-lfu auf einer Instanz konfiguriert, die eigentlich als Primary Store dient, verdrängt Redis unter Speicherdruck aktiv Daten, die es eigentlich hätte behalten müssen, ohne dass ein Fehler oder eine Warnung ausgegeben wird. Dieser Datenverlust unterscheidet sich fundamental von den anderen Szenarien, weil er nicht durch einen Ausfall, sondern durch reguläres, korrekt funktionierendes Verhalten unter der falschen Konfiguration entsteht.

Die Absicherung ist eindeutig: Primary-Store-Instanzen sollten grundsätzlich noeviction verwenden, kombiniert mit ausreichender Speicherreserve und aktivem Alerting auf used_memory-Auslastung, statt sich auf eine der Verdrängungs-Policies zu verlassen. Regelmäßige Audits der aktiven maxmemory-policy pro Instanz, insbesondere nach Konfigurationsänderungen oder Migrationen, verhindern, dass eine Cache-Konfiguration versehentlich auf einer Primary-Store-Instanz landet.

# Audit-Skript: maxmemory-policy pro Instanz gegen erwartete Rolle prüfen
for instance in primary-store-1 primary-store-2 cache-1; do
  policy=$(redis-cli -h "$instance" CONFIG GET maxmemory-policy | tail -1)
  echo "$instance: $policy"
done
# Erwartung: primary-store-* meldet "noeviction", cache-* meldet allkeys-lru/lfu

7. Sentinel und Cluster: wie automatisches Failover das Risiko verändert

Automatisches Failover über Sentinel oder Redis Cluster reduziert die Ausfallzeit erheblich, verändert aber gleichzeitig das Datenverlust-Risikoprofil. Ohne automatisches Failover bleibt ein ausgefallener Master offline, bis ein Mensch manuell eingreift, was zwar die Verfügbarkeit verschlechtert, aber jedes der oben genannten Wettlauf-Szenarien zwischen altem und neuem Master ausschließt. Mit automatischem Failover sinkt die Ausfallzeit auf Sekunden, aber genau diese Geschwindigkeit erhöht das Risiko, dass eine Promotion stattfindet, bevor der letzte Schreibvorgang sicher repliziert wurde.

Sentinel bietet mit down-after-milliseconds, failover-timeout und der Quorum-Konfiguration mehrere Stellschrauben, um dieses Wettrennen zu entschärfen, aber keine davon eliminiert das Risiko vollständig, solange die zugrunde liegende Replikation asynchron bleibt. Wer maximale Konsistenz benötigt, muss WAIT und min-replicas-to-write zusätzlich zu Sentinel einsetzen, weil Sentinel selbst nur die Erkennung und Durchführung des Failovers steuert, nicht aber die Konsistenzgarantie einzelner Schreibvorgänge.

Ein oft unterschätzter Aspekt ist die Wahl des Quorum-Werts selbst: Ein zu niedriges Quorum erhöht das Risiko einer voreiligen, fälschlichen Failover-Entscheidung bei einer vorübergehenden Netzwerkstörung, ein zu hohes Quorum verzögert legitime Failover-Entscheidungen unnötig. Die richtige Balance hängt von der Anzahl der Sentinel-Instanzen und deren Verteilung über unabhängige Netzwerksegmente oder Availability Zones ab.

# sentinel.conf: Timeouts und Quorum aufeinander abstimmen
sentinel monitor mymaster 10.0.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

8. Eine praktische Datenverlust-Risiko-Checkliste

Für eine strukturierte Bewertung des Datenverlust-Risikos einer bestehenden Redis-Instanz empfiehlt sich eine systematische Prüfung entlang folgender Punkte: Erstens, welche appendfsync-Strategie ist aktiv und passt sie zur Kritikalität der Daten? Zweitens, existiert mindestens eine Replica, und wird WAIT bei kritischen Schreibvorgängen genutzt? Drittens, ist min-replicas-to-write konfiguriert, um Split-Brain-Writes zu begrenzen? Viertens, ist die maxmemory-policy korrekt auf die Rolle der Instanz abgestimmt, Cache oder Primary Store?

Fünftens, wird der Sync-Zustand von Replicas kontinuierlich überwacht, und ist sichergestellt, dass unvollständig synchronisierte Replicas nicht als Failover-Kandidat infrage kommen? Sechstens, existieren regelmäßige, getestete Backups zusätzlich zu Replikation und Persistence, weil Replikation menschliche Fehler wie ein versehentliches FLUSHALL genauso propagiert wie legitime Schreibvorgänge? Diese sechs Punkte decken die häufigsten praktischen Datenverlust-Ursachen ab und sollten Teil jedes Redis-Produktions-Reviews sein.

# Automatisiertes Skript zur Risikobewertung (Auszug)
echo "=== Persistence ==="
redis-cli CONFIG GET appendfsync
redis-cli CONFIG GET maxmemory-policy

echo "=== Replikation ==="
redis-cli CONFIG GET min-replicas-to-write
redis-cli CONFIG GET min-replicas-max-lag
redis-cli INFO replication | grep -E "role|connected_slaves|slave[0-9]"

echo "=== Backup ==="
redis-cli CONFIG GET save
find /backup/redis -name "*.rdb" -mtime -1 | wc -l
# Erwartung: mindestens 1 aktuelles Backup der letzten 24 Stunden

echo "=== Eviction-Policy je Instanzrolle ==="
redis-cli CONFIG GET maxmemory-policy

9. Absicherungsmaßnahmen kombinieren

Keine einzelne Maßnahme eliminiert das Datenverlust-Risiko in Redis vollständig, weil jede Absicherung ihr eigenes Restrisiko mitbringt: appendfsync always schützt gegen Abstürze, aber nicht gegen Split-Brain. WAIT schützt gegen Replica-Promotion-Verlust, kostet aber Latenz und schützt nicht gegen einen fehlerhaften FLUSHALL. min-replicas-to-write begrenzt Split-Brain-Fenster, verhindert aber keinen Datenverlust durch falsche Eviction-Policy. Erst die Kombination mehrerer, sich ergänzender Maßnahmen entlang der in diesem Artikel beschriebenen Szenarien reduziert das Gesamtrisiko auf ein wirtschaftlich vertretbares Niveau.

Die wichtigste strukturelle Absicherung bleibt trotzdem klassisch: regelmäßige, getestete Backups außerhalb der Redis-Replikationskette. Replikation propagiert jeden Fehler, ob technisch oder menschlich verursacht, zuverlässig an alle verbundenen Instanzen. Ein isoliertes, zeitversetztes Backup ist die einzige Absicherung, die auch gegen Szenarien schützt, die keine der bisher genannten Datenverlust-Maßnahmen adressiert, etwa ein versehentlich ausgeführter destruktiver Befehl auf dem Master.

10. Zusammenfassung

Datenverlust in Redis entsteht typischerweise nicht durch einen einzelnen Fehler, sondern durch das Zusammenspiel aus asynchronem fsync-Timing, asynchroner Replikation und automatischem Failover unter Zeitdruck. Die fünf zentralen Szenarien, Absturz vor fsync, Replica-Promotion, Split-Brain, Diskless-Sync-Abbruch und falsche Eviction-Policy, lassen sich mit gezielten, kombinierten Maßnahmen deutlich eindämmen: appendfsync passend zur Kritikalität, WAIT für kritische Writes, min-replicas-to-write gegen Split-Brain, korrekte maxmemory-policy je nach Datenrolle und kontinuierliches Monitoring des Replikationszustands.

Die praktische Checkliste aus Abschnitt 8 bietet einen strukturierten Ausgangspunkt für ein Datenverlust-Risiko-Audit jeder produktiven Redis-Instanz. Am Ende bleibt festzuhalten: Jede Einzelmaßnahme reduziert ein spezifisches Risiko, aber nur unabhängige Backups außerhalb der Replikationskette schützen zuverlässig gegen die gesamte Bandbreite möglicher Datenverlust-Szenarien, inklusive menschlicher Fehler.

11. FAQ: Datenverlust-Szenarien in Redis