Diskless Replication konfigurieren und ihre Grenzen kennen

1. Was Diskless Replication gegenüber dem klassischen Ansatz löst

In der klassischen, Disk-basierten Replikation schreibt der Master beim Aufbau einer neuen Replica-Verbindung zunächst einen vollständigen RDB-Snapshot auf die lokale Disk, bevor diese Datei anschließend über das Netzwerk an die Replica übertragen wird. Bei großen Datensätzen bedeutet das zwei sequenzielle, potenziell langsame Schritte: erst der komplette Schreibvorgang auf Disk, dann der komplette Lesevorgang von Disk für die Übertragung. Genau diesen doppelten I/O-Aufwand eliminiert Diskless Replication, indem der Snapshot direkt aus dem Speicher über den Netzwerk-Socket an die Replica gestreamt wird, ohne den Umweg über eine temporäre Datei.

Der Nutzen von Diskless Replication ist besonders spürbar auf Systemen mit langsamer oder stark ausgelasteter Disk, etwa bei Netzwerkspeicher-Backends in Cloud-Umgebungen oder bei Instanzen, die gleichzeitig noch reguläre AOF- oder RDB-Persistence-Operationen ausführen müssen. Ohne Diskless Replication konkurriert der Sync-Prozess mit anderen I/O-Operationen um dieselbe Diskbandbreite, was gerade bei initialer Synchronisation großer Datensätze zu erheblichen Verzögerungen führen kann.

Wichtig ist von Anfang an: Diskless Replication betrifft ausschließlich den initialen Full-Sync-Prozess, bei dem ein vollständiger Snapshot an eine neue oder weit zurückliegende Replica übertragen wird. Die laufende Replikation nach erfolgreichem Sync über den Replication-Backlog und Command-Propagation ist davon unberührt und funktioniert unabhängig von dieser Einstellung identisch.

2. repl-diskless-sync und der Socket-Direct-Transfer

Die zentrale Einstellung repl-diskless-sync yes aktiviert Diskless Replication für den Full-Sync-Prozess. Technisch fork Redis dabei denselben Kindprozess wie bei einem regulären BGSAVE, aber statt die serialisierten RDB-Daten in eine Datei zu schreiben, schreibt der Kindprozess sie direkt in den Netzwerk-Socket der wartenden Replica-Verbindung. Der Fork-Aufwand selbst bleibt identisch zu regulärem BGSAVE, weil auch hier der gesamte Datensatz konsistent eingefroren werden muss, aber der anschließende I/O-Pfad verändert sich fundamental.

Ein entscheidender praktischer Unterschied: Bei Disk-basierter Synchronisation kann dieselbe RDB-Datei für mehrere gleichzeitig anfragende Replicas wiederverwendet werden, weil sie einmal geschrieben und mehrfach gelesen wird. Bei Diskless Replication ist das ohne Weiteres nicht möglich, weil der Datenstrom direkt an einen einzelnen Socket gebunden ist. Fordern mehrere Replicas gleichzeitig einen Full Sync an, muss Redis entweder mehrere parallele Streams erzeugen oder die Anfragen bündeln, was über den Parameter repl-diskless-sync-delay gesteuert wird.

Der Kindprozess, der die Daten serialisiert, arbeitet dabei unabhängig davon, ob das Ziel eine Datei oder ein Socket ist. Die eigentliche RDB-Serialisierungslogik, die Reihenfolge und das Format der geschriebenen Daten, bleibt bei Diskless Replication identisch zur Disk-basierten Variante. Nur der Ausgabekanal unterscheidet sich, was Diskless Replication zu einer vergleichsweise risikoarmen Änderung am Datenformat macht.

# redis.conf: Diskless Replication grundlegend aktivieren
repl-diskless-sync yes
repl-diskless-sync-delay 5
repl-diskless-load disabled

# repl-diskless-load steuert das Verhalten auf der Replica-Seite:
# disabled: RDB wird auf der Replica-Disk zwischengespeichert (Standard, sicherer)
# on-empty-db: Diskless-Laden nur bei leerer Replica-Datenbank
# swapdb: Diskless-Laden mit atomarem Swap gegen den alten Datenbestand

# Anzahl gleichzeitig anhängbarer Replicas an denselben Diskless-Stream
repl-diskless-sync-max-replicas 0

3. repl-diskless-sync-delay: Timing gegen mehrere Replicas

Der Parameter repl-diskless-sync-delay definiert, wie viele Sekunden Redis nach der ersten eingehenden Replica-Anfrage wartet, bevor der Sync-Prozess tatsächlich startet. Dieser Delay existiert, weil Diskless Replication keinen wiederverwendbaren Snapshot auf Disk hinterlässt. Trifft während dieser Wartezeit eine zweite Replica-Anfrage ein, kann Redis beide Replicas mit demselben, gerade erst gestarteten Sync-Vorgang bedienen, statt zwei komplett separate Fork-Prozesse mit doppeltem CPU- und Speicheraufwand zu starten.

Der Standardwert von 5 Sekunden ist ein Kompromiss zwischen schneller Reaktion auf eine einzelne Replica-Anfrage und effizienter Bündelung bei mehreren gleichzeitig verbindenden Replicas, etwa nach einem Rolling Restart eines gesamten Replica-Sets. In Umgebungen, in denen Replicas typischerweise gestaffelt statt gleichzeitig verbinden, kann ein niedrigerer Wert die Latenz bis zum Start des Full Sync verkürzen. In Umgebungen mit häufigen Batch-Neustarts mehrerer Replicas gleichzeitig ist ein höherer Wert sinnvoll, um Ressourcenverschwendung durch mehrfache parallele Forks zu vermeiden.

Der Wert 0 deaktiviert die Wartezeit vollständig und startet den Sync sofort bei der ersten Anfrage. Das minimiert die Latenz für die einzelne, zuerst anfragende Replica, verhindert aber jede Bündelung nachfolgender Anfragen und kann bei einem gleichzeitigen Verbindungsaufbau vieler Replicas zu mehreren parallelen, ressourcenintensiven Fork-Vorgängen führen. Dieser Wert eignet sich deshalb nur für Umgebungen mit maximal einer erwarteten neuen Replica pro Zeitfenster.

# repl-diskless-sync-delay je nach Verbindungsmuster der Replicas anpassen

# Gestaffelt verbindende Replicas: kurzer Delay für schnellen Start
repl-diskless-sync-delay 2

# Häufige Batch-Neustarts mehrerer Replicas gleichzeitig: längerer Delay
repl-diskless-sync-delay 10

# Delay live prüfen und anpassen
redis-cli CONFIG GET repl-diskless-sync-delay
redis-cli CONFIG SET repl-diskless-sync-delay 5

4. repl-diskless-sync-max-replicas: paralleler Transfer

Sobald der Sync-Prozess für Diskless Replication gestartet ist, definiert repl-diskless-sync-max-replicas, wie viele Replicas maximal noch nachträglich in denselben laufenden Stream aufgenommen werden, ohne dass ein neuer Fork nötig wird. Der Standardwert 0 bedeutet unbegrenzt, was für die meisten Setups sinnvoll ist. In Umgebungen mit sehr vielen Replicas pro Master kann eine bewusste Begrenzung sinnvoll sein, um den Speicher- und CPU-Overhead durch das gleichzeitige Bedienen vieler Socket-Streams aus einem einzigen Fork-Prozess zu begrenzen.

Die praktische Konsequenz: Jede zusätzliche, an denselben Diskless-Stream angehängte Replica erhöht den Netzwerkdurchsatz-Bedarf des Master-Prozesses proportional, weil dieselben seriellisierten Daten an mehrere Sockets gleichzeitig geschrieben werden müssen. Bei Master-Instanzen mit begrenzter Netzwerkbandbreite und vielen Replicas kann diese Eigenschaft von Diskless Replication paradoxerweise zu einem Flaschenhals werden, der bei Disk-basierter Replikation durch die Wiederverwendbarkeit der RDB-Datei nicht in gleicher Form auftritt.

In der Praxis empfiehlt sich deshalb, die tatsächlich verfügbare Netzwerkbandbreite des Masters vorab zu kalkulieren: Bei einer Datensatzgröße von 10 GB und fünf gleichzeitig anzuhängenden Replicas müssen theoretisch 50 GB in kurzer Zeit über die Netzwerkkarte des Masters fließen. Reicht die verfügbare Bandbreite dafür nicht aus, verlängert sich der Sync für alle beteiligten Replicas gleichermaßen, statt dass einzelne Replicas bevorzugt bedient werden.

5. RDB über Socket vs. Disk: interner Ablauf im Vergleich

Bei Disk-basierter Replikation folgt der Ablauf drei klar getrennten Phasen: Fork und Schreiben der RDB-Datei durch den Kindprozess, anschließendes Lesen dieser Datei und Übertragung an die Replica, meist durch den Elternprozess oder einen separaten Lesevorgang. Diese Trennung hat einen wichtigen Vorteil: Schlägt die Netzwerkübertragung fehl, existiert die RDB-Datei weiterhin auf Disk und kann für einen erneuten Übertragungsversuch wiederverwendet werden, ohne dass ein komplett neuer Fork nötig ist.

Bei Diskless Replication verschmelzen Schreiben und Übertragen zu einem einzigen Schritt: Der Kindprozess serialisiert die Daten und schreibt sie in einem Zug direkt in den Socket. Das eliminiert die doppelten I/O-Kosten, hat aber eine wichtige Kehrseite: Bricht die Netzwerkverbindung während der Übertragung ab, existiert kein wiederverwendbarer Zwischenzustand. Der gesamte Sync-Prozess muss von vorn beginnen, inklusive eines neuen, potenziell teuren Fork-Aufrufs. Dieser Unterschied im Fehlerverhalten ist der wichtigste praktische Kompromiss von Diskless Replication gegenüber dem klassischen Ansatz.

Aus Sicht der Systemarchitektur lässt sich dieser Unterschied als klassischer Tradeoff zwischen Durchsatz und Fehlertoleranz beschreiben: Der Disk-basierte Ansatz opfert etwas Durchsatz für einen wiederverwendbaren Checkpoint, während Diskless Replication maximalen Durchsatz auf Kosten der Fehlertoleranz bei Unterbrechungen liefert. Welche Seite dieses Tradeoffs überwiegt, hängt vollständig von der Stabilität der konkreten Netzwerkverbindung ab.

6. Wann Diskless Replication tatsächlich hilft

Diskless Replication zeigt den größten Nutzen auf Systemen, bei denen Disk-I/O der limitierende Faktor ist: Netzwerkspeicher-Backends wie EBS oder Azure Disk mit begrenztem IOPS-Budget, Instanzen mit gleichzeitig hoher AOF-Schreiblast, die um dieselbe Diskbandbreite konkurriert, oder Container-Umgebungen mit überlagertem, langsamem Copy-on-Write-Dateisystem. In all diesen Szenarien reduziert das Umgehen der Disk-Zwischenspeicherung die Gesamtdauer des Full Sync spürbar und verringert gleichzeitig die Belastung anderer Prozesse, die dieselbe Disk nutzen.

Ebenso profitieren Setups mit stabiler, latenzarmer Netzwerkverbindung zwischen Master und Replica besonders stark von Diskless Replication, weil das Hauptrisiko, ein Verbindungsabbruch während der Übertragung, in solchen Umgebungen selten auftritt. Bei Master und Replica im selben Rechenzentrum oder derselben Availability Zone mit redundanter Netzwerkanbindung ist das Risiko eines Übertragungsabbruchs meist deutlich geringer als der Nutzen durch den Wegfall der Disk-Zwischenspeicherung.

Auch bei Skalierungsereignissen, etwa dem automatisierten Hinzufügen neuer Replicas durch einen Orchestrator wie Kubernetes-Operatoren, zeigt sich der Vorteil von Diskless Replication deutlich: Da neue Pods typischerweise im selben Cluster-Netzwerk mit geringer Latenz starten, ist das Abbruchrisiko gering, während die Zeitersparnis durch den Wegfall der Disk-Zwischenspeicherung die Zeit bis zur vollen Verfügbarkeit der neuen Replica spürbar verkürzt.

7. Grenzen und Risiken von Diskless Replication

Der wichtigste Nachteil von Diskless Replication wurde bereits angedeutet: Kein Wiederaufsetzen bei unterbrochener Übertragung. In instabilen Netzwerkumgebungen, etwa bei Replicas in einer anderen geografischen Region oder über eine VPN-Verbindung mit gelegentlichen Aussetzern, kann das dazu führen, dass ein großer Full Sync wiederholt neu startet, ohne jemals abzuschließen. Jeder Neustart bedeutet erneuten Fork-Aufwand und erneute vollständige Datenübertragung, was in solchen Umgebungen die Gesamtdauer bis zur erfolgreichen Synchronisation gegenüber Disk-basierter Replikation sogar verlängern kann.

Ein weiteres Risiko betrifft repl-diskless-load auf der Replica-Seite: Wird diese Einstellung auf swapdb gesetzt, tauscht die Replica den kompletten Datenbestand atomar gegen den neu empfangenen Stream aus. Bricht der Stream während dieses Vorgangs ab, bleibt die Replica ohne funktionsfähigen alten oder neuen Datenbestand zurück, bis ein erneuter Sync erfolgreich abgeschlossen ist. Für produktionskritische Replicas ist deshalb häufig die sicherere Voreinstellung disabled vorzuziehen, bei der die Replica den eingehenden Stream zunächst auf die eigene Disk schreibt, bevor sie ihn lädt, auch wenn das einen Teil des Diskless-Vorteils wieder aufhebt.

Ein dritter, subtilerer Risikofaktor betrifft die CPU-Last während des Forks: Weil bei Diskless Replication Serialisierung und Netzwerkübertragung stärker zeitlich überlappen können als beim Disk-basierten Ansatz, kann die Spitzenlast auf dem Master während eines gleichzeitigen Full Sync mehrerer Replicas kurzzeitig höher ausfallen. Ausreichend dimensionierte CPU-Reserven auf dem Master sind deshalb auch für diesen Aspekt von Diskless Replication relevant, nicht nur für den Netzwerkdurchsatz.

# redis.conf: konservative, produktionssichere Grundeinstellung
repl-diskless-sync yes
repl-diskless-sync-delay 5
repl-diskless-load disabled

# Für instabile Netzwerkverbindungen: Diskless Replication deaktivieren
# und stattdessen auf den robusten Disk-basierten Full Sync zurückfallen
repl-diskless-sync no

8. Full Sync vs. partielle Resync mit Diskless Replication

Wichtig für das Verständnis der praktischen Auswirkungen: Diskless Replication betrifft ausschließlich den Full-Sync-Fall, bei dem eine Replica keinen ausreichend aktuellen Replication-Backlog beim Master vorfindet und deshalb einen kompletten Snapshot benötigt. Eine partielle Resynchronisation, bei der die Replica nach einer kurzen Netzwerkunterbrechung lediglich die seit der Trennung fehlenden Befehle aus dem Backlog nachträgt, ist von dieser Einstellung überhaupt nicht betroffen und funktioniert unabhängig davon identisch schnell.

Diese Unterscheidung ist wichtig für die Risikobewertung: Ein ausreichend groß dimensionierter repl-backlog-size reduziert die Häufigkeit, mit der überhaupt ein Full Sync und damit Diskless Replication zum Einsatz kommt, weil kurze Netzwerkunterbrechungen dann über partielle Resync abgefangen werden, ohne einen neuen Full Sync auszulösen. Ein großzügig dimensionierter Backlog ist deshalb oft die wirksamere Maßnahme gegen die Risiken instabiler Netzwerke als die reine Wahl zwischen Diskless und Disk-basiertem Sync.

Die Backlog-Größe sollte sich am erwarteten Schreibdurchsatz und der maximal tolerierbaren Unterbrechungsdauer orientieren: Ein Backlog, der bei 10 MB/s Schreibrate für 60 Sekunden ausreicht, benötigt mindestens 600 MB. Wird der Backlog zu klein dimensioniert, laufen selbst kurze Netzwerkaussetzer regelmäßig in einen vollständigen Full Sync, was den vermeintlichen Vorteil einer knapp bemessenen Konfiguration durch häufigere, teure Diskless-Sync-Vorgänge wieder zunichtemacht.

# redis.conf: Replication-Backlog großzügig dimensionieren,
# um unnötige Full Syncs bei kurzen Netzwerkunterbrechungen zu vermeiden
repl-backlog-size 512mb
repl-backlog-ttl 3600

# Backlog-Auslastung und Full-Sync-Häufigkeit im Verhältnis prüfen
redis-cli INFO replication | grep repl_backlog
redis-cli INFO stats | grep -E "sync_full|sync_partial_ok|sync_partial_err"

9. Konfiguration und Monitoring des Sync-Zustands

Um den Zustand von Diskless Replication im Betrieb zu überwachen, liefert INFO replication auf dem Master die Felder master_repl_offset, connected_slaves und pro Replica den Sync-Status. Während eines laufenden Diskless Full Sync zeigt das Feld sync_full in INFO stats die Gesamtzahl bisher durchgeführter vollständiger Synchronisationen, ein Vergleich vor und nach einem Netzwerkproblem zeigt direkt, ob wiederholte Full-Sync-Neustarts stattgefunden haben.

Auf der Replica-Seite liefert master_link_status in INFO replication den aktuellen Verbindungsstatus, und master_sync_in_progress zeigt an, ob gerade ein Full Sync läuft. Eine kontinuierliche Überwachung dieser Felder, kombiniert mit Alarmierung bei wiederholten Sync-Neustarts innerhalb kurzer Zeit, macht instabile Netzwerkverbindungen sichtbar, bevor sie zu einer dauerhaft unsynchronisierten Replica führen.

Für eine vollständige Beobachtbarkeit empfiehlt sich zusätzlich das Tracking von master_last_io_seconds_ago, das anzeigt, wie lange die letzte Kommunikation mit dem Master zurückliegt. Ein kontinuierlich steigender Wert deutet auf eine bereits abgebrochene, aber noch nicht als solche erkannte Verbindung hin, und sollte als eigenständiger Alarm neben dem reinen Sync-Status konfiguriert werden.

# Sync-Status auf dem Master prüfen
redis-cli INFO replication | grep -E "connected_slaves|master_repl_offset"
redis-cli INFO stats | grep sync_full
# sync_full:23

# Sync-Status auf der Replica prüfen
redis-cli INFO replication | grep -E "master_link_status|master_sync_in_progress"
# master_link_status:up
# master_sync_in_progress:0

# Diskless-Replication-Parameter live prüfen
redis-cli CONFIG GET "repl-diskless-*"

# Wie lange liegt die letzte Kommunikation mit dem Master zurück
redis-cli INFO replication | grep master_last_io_seconds_ago

# Anzahl Full Syncs seit Serverstart als Frühindikator für Instabilität
redis-cli INFO stats | grep sync_full

10. Zusammenfassung

Diskless Replication eliminiert den doppelten Disk-I/O beim initialen Full Sync, indem der RDB-Snapshot direkt über den Socket an die Replica gestreamt wird, statt zuerst auf Disk geschrieben zu werden. Der Nutzen ist am größten bei langsamer oder stark ausgelasteter Disk und bei stabilen Netzwerkverbindungen zwischen Master und Replica. Die Parameter repl-diskless-sync-delay und repl-diskless-sync-max-replicas steuern, wie effizient mehrere gleichzeitige Replica-Anfragen gebündelt werden.

Die zentrale Grenze von Diskless Replication ist der fehlende Wiederaufnahmepunkt bei Netzwerkabbrüchen: Anders als bei Disk-basierter Replikation muss ein unterbrochener Diskless Full Sync komplett neu starten, inklusive neuem Fork. In instabilen Netzwerkumgebungen kann das die Synchronisationsdauer gegenüber dem klassischen Ansatz sogar verlängern. Ein ausreichend dimensionierter Replication-Backlog reduziert die Häufigkeit von Full Syncs insgesamt und ist oft die wirksamere Maßnahme gegen instabile Netzwerke als die reine Wahl der Sync-Methode.

Wer über die Aktivierung von Diskless Replication entscheidet, sollte deshalb zuerst die Netzwerktopologie zwischen Master und Replicas bewerten und erst danach die Disk-Performance des Masters als zweites Kriterium heranziehen. Nur wenn beide Faktoren, stabiles Netzwerk und langsame Disk, tatsächlich zusammentreffen, entfaltet Diskless Replication ihren vollen Nutzen ohne nennenswertes Gegenrisiko.

11. FAQ: Diskless Replication in Redis