Split-Brain-Szenarien in Redis-Clustern vermeiden

1. Was Split-Brain in Redis-Clustern konkret bedeutet

Ein Split-Brain entsteht, wenn ein Redis-Setup mit Replikation durch eine Netzwerkpartition in zwei oder mehr Teile zerfaellt und mehrere Knoten gleichzeitig glauben, der gueltige Master zu sein. Beide Seiten der Partition akzeptieren dann eigenstaendig Schreibzugriffe, ohne voneinander zu wissen. Sobald das Netzwerk sich wieder verbindet, existieren zwei divergierende Datenstaende, und Redis muss sich fuer einen entscheiden, wobei der andere verworfen wird.

Das Gefaehrliche an einem Split-Brain ist nicht der Ausfall selbst, sondern die Zeitspanne, in der beide Seiten fuer sich genommen vollkommen funktionsfaehig erscheinen. Anwendungen auf beiden Seiten der Partition schreiben weiter, ohne Fehler zu sehen, und erst beim Zusammenfuehren der Partition wird sichtbar, dass ein Teil dieser Schreibzugriffe verloren geht. Fuer zustandsbehaftete Systeme wie Warenkoerbe, Zaehler oder Sessions kann das zu inkonsistenten oder verschwundenen Daten fuehren, die im Nachhinein kaum rekonstruierbar sind.

2. Wie Netzwerkpartitionen entstehen und wirken

Netzwerkpartitionen entstehen selten durch einen kompletten Totalausfall, sondern haeufiger durch partielle Stoerungen: ein Switch-Firmware-Update, eine fehlerhafte Firewall-Regel, eine überlastete Cross-AZ-Verbindung in der Cloud oder ein Routing-Fehler nach einem Deployment. Aus Sicht eines einzelnen Redis-Knotens ist ein Split-Brain-ausloesender Netzwerkfehler nicht von einem simplen Prozessabsturz des Partners zu unterscheiden. Beide Symptome sehen fuer den beobachtenden Knoten gleich aus: Der andere antwortet nicht mehr.

Besonders tückisch sind asymmetrische Partitionen, bei denen Knoten A Knoten B nicht mehr erreicht, Knoten B aber Knoten A durchaus noch erreichen kann. In einem solchen Szenario koennen unterschiedliche Beobachter im Cluster zu widerspruechlichen Einschaetzungen kommen, welcher Knoten tatsaechlich ausgefallen ist. Genau dieses Szenario ist der Grund, warum Redis-Hochverfuegbarkeit niemals auf der Meinung eines einzelnen Beobachters beruhen darf, sondern immer auf einer Mehrheitsentscheidung mehrerer unabhaengiger Instanzen.

3. Sentinel-Architektur und Quorum-Mechanismus

Redis Sentinel loest das Problem der einzelnen fehleranfaelligen Beobachtung durch mehrere unabhaengige Sentinel-Prozesse, die typischerweise auf getrennten Hosts laufen und sich gegenseitig sowie den Master ueberwachen. Erst wenn eine konfigurierte Mindestanzahl von Sentinels, das sogenannte Quorum, unabhaengig voneinander feststellt, dass der Master nicht erreichbar ist, wird der Master offiziell als subjektiv down (SDOWN) und anschliessend als objektiv down (ODOWN) markiert. Erst danach beginnt der Failover-Prozess.

Das Quorum wird in der Sentinel-Konfiguration mit sentinel monitor mymaster 10.0.0.1 6379 2 festgelegt, wobei die letzte Zahl die Mindestanzahl zustimmender Sentinels angibt. Bei drei Sentinels und Quorum 2 muessen mindestens zwei unabhaengige Sentinels den Ausfall bestaetigen, bevor ein Failover ausgeloest wird. Diese Mehrheitsanforderung ist der zentrale Schutzmechanismus gegen Split-Brain: Ein einzelner Sentinel, der durch eine eigene Netzwerkstoerung isoliert ist, kann keinen Failover allein herbeifuehren.

Wichtig ist die ungerade Anzahl an Sentinel-Instanzen, meist drei oder fuenf, verteilt ueber unterschiedliche Ausfallzonen. Eine gerade Anzahl von Sentinels kann bei einer exakten Halbierung des Netzwerks zu einer Pattsituation fuehren, in der keine Seite eine Mehrheit erreicht und der Failover blockiert bleibt, was zwar keinen Split-Brain erzeugt, aber die Verfuegbarkeit unnoetig einschraenkt.

# sentinel.conf , quorum-based monitoring across 3 independent hosts
port 26379
sentinel monitor mymaster 10.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

# Deploy one sentinel per availability zone, odd total count (3 or 5)
# so a network split can never produce two equal-sized quorum groups

4. min-replicas-to-write und min-replicas-max-lag konfigurieren

Ein Master, der von seinen Replicas isoliert wird, kann weiter Schreibzugriffe annehmen, obwohl niemand diese Aenderungen mehr repliziert. Genau hier setzt min-replicas-to-write an: Diese Einstellung verweigert Schreibzugriffe, sobald weniger als die konfigurierte Anzahl an Replicas innerhalb einer akzeptablen Verzoegerung erreichbar ist. Ein isolierter Master, der keine Replica-Bestaetigung mehr erhaelt, wird dadurch effektiv read-only, statt unkontrolliert weiterzuschreiben und spaeter zu kollidierende Datenstaende zu produzieren.

Die begleitende Einstellung min-replicas-max-lag definiert, wie viele Sekunden Verzoegerung eine Replica maximal haben darf, um noch als verfuegbar zu zaehlen. Eine Replica, die seit 15 Sekunden kein ACK mehr gesendet hat, wird bei min-replicas-max-lag 10 nicht mehr mitgezaehlt. Diese Kombination reduziert, wie viele Schreibzugriffe im schlimmsten Fall auf einem isolierten Master akkumulieren koennen, bevor er selbst zu schreiben aufhoert.

Wichtig ist die Erkenntnis, dass min-replicas-to-write Split-Brain nicht vollstaendig verhindert, sondern das Zeitfenster und die Menge der potenziell verlorenen Schreibzugriffe begrenzt. Ohne aktive Replicas schreibt ein derart konfigurierter Master gar nicht mehr, was fuer viele Anwendungen ein akzeptabler Kompromiss zwischen Verfuegbarkeit und Konsistenz ist, fuer andere jedoch als zu restriktiv gilt.

# redis.conf on the master node
min-replicas-to-write 1
min-replicas-max-lag 10

# Verify current replica ACK status
redis-cli -h master.internal INFO replication
# role:master
# connected_slaves:2
# slave0:ip=10.0.0.2,port=6379,state=online,offset=910234,lag=0
# slave1:ip=10.0.0.3,port=6379,state=online,offset=910234,lag=1

# Simulate isolation: after losing both replicas, writes are refused
redis-cli -h master.internal SET orders:1042 "paid"
# (error) NOREPLICAS Not enough good replicas to write.

5. Mehrheitsbeschluss in Redis Cluster: cluster-require-full-coverage

Redis Cluster nutzt keine Sentinel-Instanzen, sondern die Master-Knoten selbst als verteiltes Voting-Gremium. Erkennt eine Mehrheit der Master-Knoten, dass ein anderer Master fuer eine bestimmte Zeit nicht erreichbar ist, wird dessen bester Replica automatisch zum neuen Master befoerdert. Diese Mehrheitsanforderung, mindestens die Haelfte plus eins aller Master-Knoten, verhindert, dass eine Minderheitspartition eigenmaechtig einen Failover ausloest und damit einen zweiten, konkurrierenden Master fuer denselben Slot-Bereich erzeugt.

Bei einer klassischen Netzwerkpartition, die einen Cluster in eine Mehrheits- und eine Minderheitshaelfte teilt, bleibt nur die Mehrheitsseite schreibfaehig. Die Minderheitsseite erkennt, dass sie keine Cluster-Mehrheit mehr bilden kann, und stellt bei aktivem cluster-require-full-coverage ebenfalls Schreibzugriffe ein. Das ist der entscheidende strukturelle Unterschied zu einer schlecht konfigurierten Sentinel-Umgebung: Redis Cluster verweigert der Minderheit aktiv das Weiterschreiben, statt zwei gleichberechtigte Master zuzulassen.

# Check cluster-wide majority state on any node
redis-cli -c CLUSTER INFO
# cluster_state:ok
# cluster_slots_assigned:16384
# cluster_slots_ok:16384
# cluster_known_nodes:6
# cluster_size:3

# During a minority-side partition, the isolated nodes report:
# cluster_state:fail
# cluster_slots_assigned:5461   <- only the locally known range
redis-cli -c SET orders:9001 "paid"
# (error) CLUSTERDOWN Hash slot not served

6. Failover-Ablauf im Detail: Timeout, Voting, Promotion

Der Failover-Ablauf folgt einer festen Sequenz. Zunaechst markiert jeder beobachtende Sentinel einen nicht erreichbaren Master lokal als SDOWN, sobald down-after-milliseconds ueberschritten ist. Danach fragen sich die Sentinels gegenseitig ab, ob sie dieselbe Einschaetzung teilen. Erreicht die Anzahl zustimmender Sentinels das konfigurierte Quorum, wird der Zustand auf ODOWN erhoeht und ein Sentinel als Leader fuer den Failover gewaehlt, ueber ein eigenes Raft-aehnliches Wahlverfahren mit Epochen-Nummern.

Der gewaehlte Leader-Sentinel identifiziert dann die Replica mit dem aktuellsten Replikationsoffset, promotet sie mit REPLICAOF NO ONE zum neuen Master und konfiguriert die uebrigen Replicas um, ueber parallel-syncs gesteuert, um die Netzwerklast beim Neusynchronisieren zu begrenzen. Der gesamte Prozess dauert typischerweise wenige Sekunden bis zu failover-timeout, abhaengig von Netzwerklatenz und Datenmenge, die neu synchronisiert werden muss.

# Sentinel log excerpt during a real failover sequence
+sdown master mymaster 10.0.0.1 6379
+odown master mymaster 10.0.0.1 6379 #quorum 2/2
+new-epoch 1
+try-failover master mymaster 10.0.0.1 6379
+vote-for-leader 7d3e2f1a sentinel-2 1
+elected-leader master mymaster 10.0.0.1 6379
+selected-slave slave 10.0.0.3 6379
+failover-state-send-slaveof-noone slave 10.0.0.3 6379
+failover-state-reconf-slaves master mymaster 10.0.0.1 6379
+switch-master mymaster 10.0.0.1 6379 10.0.0.3 6379

7. Datenverlust bei asynchroner Replikation trotz Schutzmassnahmen

Selbst mit korrekt konfiguriertem Quorum, min-replicas-to-write und Cluster-Mehrheitspruefung bleibt ein strukturelles Restrisiko bestehen: Redis repliziert standardmaessig asynchron. Ein Schreibzugriff gilt als erfolgreich, sobald der Master ihn lokal verarbeitet hat, unabhaengig davon, ob eine Replica ihn bereits empfangen hat. Faellt der Master exakt in diesem kurzen Fenster aus, gehen die letzten, noch nicht replizierten Schreibzugriffe beim Failover verloren, selbst wenn kein einziger Split-Brain-Moment im klassischen Sinn auftrat.

Dieses Verhalten wird oft mit Split-Brain verwechselt, ist aber ein eigenstaendiges Problem: Es handelt sich nicht um zwei konkurrierende Master, sondern um normalen Datenverlust durch asynchrone Replikation im Failover-Moment. min-replicas-to-write reduziert dieses Fenster, indem es Schreibzugriffe ohne Replica-Bestaetigung von vornherein verweigert, aber vollstaendig eliminieren laesst es sich nur durch synchrones WAIT vor kritischen Schreibzugriffen, was Latenz kostet.

8. Split-Brain gezielt simulieren und testen

Wer sich auf Failover-Verhalten verlassen will, sollte es unter kontrollierten Bedingungen getestet haben, statt erst im echten Ausfall die Konfiguration zu pruefen. Mit iptables lassen sich gezielt Pakete zwischen zwei Knoten blockieren, um eine echte Netzwerkpartition zu simulieren, ohne den Prozess selbst zu beenden. Mit tc (Traffic Control) laesst sich zusaetzlich erhoehte Latenz oder Paketverlust einbauen, um realistischere, partielle Netzwerkstoerungen statt eines harten Cutoffs nachzubilden.

Ein sinnvolles Testszenario isoliert den aktuellen Master vollstaendig von seinen Replicas und allen Sentinels, laesst die Anwendung waehrenddessen weiterschreiben und prueft anschliessend nach Wiederherstellung der Verbindung, wie viele Schreibzugriffe tatsaechlich verloren gingen. So laesst sich empirisch verifizieren, ob die konfigurierten Werte fuer min-replicas-to-write, Quorum und Timeout-Werte fuer die eigenen Anforderungen an Konsistenz tatsaechlich ausreichen.

# Simulate a network partition between master (10.0.0.1) and one replica (10.0.0.2)
iptables -A INPUT -s 10.0.0.2 -j DROP
iptables -A OUTPUT -d 10.0.0.2 -j DROP

# Add latency and packet loss for a softer partition instead of a hard cut
tc qdisc add dev eth0 root netem loss 30% delay 200ms 50ms

# Watch Sentinel react on the isolated side
redis-cli -p 26379 SENTINEL master mymaster
# ... check flags field for s_down / o_down / failover-in-progress

# After the test: always remove the simulated failure
iptables -D INPUT -s 10.0.0.2 -j DROP
iptables -D OUTPUT -d 10.0.0.2 -j DROP
tc qdisc del dev eth0 root netem

9. Monitoring und Alerting fuer Partitionierung

Ein Split-Brain, der stundenlang unbemerkt bleibt, verursacht deutlich mehr Schaden als einer, der binnen Sekunden erkannt wird. Sentinel selbst liefert dafuer Pub/Sub-Kanaele wie +sdown, +odown und +switch-master, die sich direkt in ein Monitoring-System einspeisen lassen, ohne dass Logdateien geparst werden muessen. Ergaenzend liefert INFO replication auf jedem Knoten den aktuellen role-Wert, sodass ein Alert ausgeloest werden kann, sobald mehr als ein Knoten gleichzeitig role:master fuer denselben logischen Datensatz meldet, was das eindeutigste Signal fuer einen tatsaechlichen Split-Brain ist.

Zusaetzlich lohnt sich ein Alert auf die Replikations-Lag-Werte aus INFO replication, da ein ploetzlich ansteigender Lag oft der erste sichtbare Vorbote einer beginnenden Netzwerkpartition ist, lange bevor Sentinel einen vollstaendigen Ausfall meldet. Wer connected_slaves auf dem Master kontinuierlich beobachtet und einen Abfall auf null als kritischen Alarm behandelt, erkennt eine Isolation des Masters oft schneller, als es der Sentinel-Failover-Timeout ohnehin vorsieht.

10. Zusammenfassung

Ein Split-Brain entsteht, wenn eine Netzwerkpartition mehrere Redis-Knoten gleichzeitig zu Schreibentscheidungen verleitet, ohne dass sie voneinander wissen. Sentinel begegnet diesem Risiko mit einem Quorum-Mechanismus, der Failover-Entscheidungen an eine Mehrheit unabhaengiger Beobachter bindet, statt sie einem einzelnen Knoten zu ueberlassen. min-replicas-to-write und min-replicas-max-lag begrenzen zusaetzlich, wie lange ein isolierter Master unkontrolliert weiterschreiben kann, indem sie ihn bei fehlender Replica-Bestaetigung read-only schalten.

Redis Cluster loest dasselbe Problem strukturell ueber Mehrheitsbeschluesse der Master-Knoten und cluster-require-full-coverage, das Schreibzugriffe auf einer Minderheitspartition aktiv unterbindet. Ein Restrisiko bleibt durch asynchrone Replikation dennoch bestehen, weshalb regelmaessige Failover-Tests mit iptables und tc sowie kontinuierliches Monitoring von Sentinel-Events und Replikations-Lag unverzichtbar sind, um ein Split-Brain-Szenario nicht erst im Ernstfall zu verstehen.

11. FAQ: Split-Brain-Szenarien in Redis-Clustern