Der Redis Replication Backlog entscheidet mit darüber, ob eine Replica nach einem Verbindungsabbruch nur fehlende Änderungen nachholt oder den gesamten Datenbestand neu übertragen bekommt. Wer den Puffer nach dem tatsächlichen Replikationsvolumen dimensioniert, kann unnötige vollständige Synchronisierungen vermeiden. Dafür müssen jedoch auch Replikationshistorie, Speicherbudget und Betriebsabläufe zusammenpassen: Ein großer Backlog ersetzt weder Persistenz noch ein belastbares Failover-Konzept.
Was der Backlog tatsächlich speichert
Bei Redis Replication verarbeitet der Primary Änderungen am Datenbestand und übermittelt einen fortlaufenden Befehlsstrom an seine Replicas. Dazu gehören nicht nur unmittelbar von Clients geschriebene Werte. Auch abgelaufene oder verdrängte Schlüssel können Änderungen auslösen, die weitergegeben werden müssen. Der Backlog hält einen begrenzten jüngeren Ausschnitt dieses Replikationsstroms im Arbeitsspeicher vor. Er enthält deshalb keine zusätzliche vollständige Kopie der Datenbank und ist auch kein Archiv beliebig alter Schreibvorgänge.
Im störungsfreien Betrieb folgen die Replicas dem laufenden Strom. Wird eine Verbindung unterbrochen, wächst die Historie auf dem Primary weiter. Nach der Wiederverbindung versucht die Replica, an ihren bisherigen Stand anzuschließen. Entscheidend ist dann, ob die benötigten Bytes noch vorgehalten werden. Ist das der Fall und passt die Replikationshistorie, kann Redis die Lücke nachliefern. Die bereits vorhandenen Daten der Replica müssen dafür nicht vollständig ersetzt werden.
Der Nutzen liegt besonders bei kurzen Netzwerkstörungen, Verbindungswechseln und geplanten Wartungsarbeiten. Ein vollständiger Abgleich eines großen Datenbestands beansprucht Übertragungskapazität und Rechenleistung; je nach Konfiguration kommen weitere Speicher- und Datenträgerbelastungen hinzu. Der Backlog kann diesen Aufwand reduzieren, aber nicht jede Form einer Unterbrechung auffangen. Ein Prozessneustart oder eine geänderte Historie verlangt eine andere Betrachtung als eine kurz getrennte TCP-Verbindung.
Wann PSYNC genügt und wann ein Full Resync nötig ist
Eine partielle Resynchronisierung mit PSYNC benötigt zwei zusammengehörige Angaben: die Replikations-ID und den Offset. Die ID kennzeichnet eine bestimmte Datenhistorie. Der Offset beschreibt eine Byteposition innerhalb des Replikationsstroms. Zwei gleich große Offsets aus unterschiedlichen Historien sind deshalb nicht automatisch vergleichbar. Umgekehrt kann ein kleiner Rückstand in derselben Historie bereits außerhalb des verfügbaren Backlogs liegen, wenn dessen Kapazität knapp bemessen ist.
Vereinfacht meldet die Replica bei der Wiederverbindung, bis zu welchem Stand sie gekommen ist. Der Primary prüft, ob er die anschließend benötigten Daten liefern kann. Ist die Historie unbekannt oder fehlt der erforderliche Abschnitt, wird ein Full Resync notwendig. Dabei erhält die Replica einen vollständigen Datenbestand und anschließend die während des Abgleichs angefallenen Änderungen. Die Übertragung kann abhängig von der Konfiguration mit einem RDB-Zwischenschritt auf Datenträger oder ohne diesen Zwischenschritt erfolgen.
Nach einem Failover ist ein Full Resync nicht in jedem Fall unvermeidbar. Eine beförderte Replica kann sich zusätzlich die vorherige Replikations-ID und deren gültigen Offsetbereich merken. Dadurch können weitere Replicas unter passenden Voraussetzungen an die bekannte Historie anschließen. Für die Planung folgt daraus aber keine Garantie: Der relevante Bereich muss weiterhin verfügbar sein, und die konkrete Wiederanbindung muss zu den gespeicherten IDs passen.
| Situation | Voraussetzung | Ergebnis |
|---|---|---|
| Kurze Unterbrechung | Passende Historie; benötigte Bytes noch vorhanden | PSYNC kann nur die fehlenden Replikationsdaten nachliefern. |
| Älteste benötigte Bytes überschrieben | Der angeforderte Bereich liegt außerhalb der vorgehaltenen Historie | Vollständiger Neuabgleich statt partieller Wiederaufnahme. |
| Unbekannte Replikationshistorie | Die Replikations-ID wird nicht als gültig erkannt | Ein größerer Backlog allein löst das Problem nicht. |
| Failover mit bekannter Vorgänger-ID | Gespeicherte sekundäre ID, gültiger Offsetbereich und genügend Historie | Eine partielle Resynchronisierung kann weiterhin möglich sein. |
| Backlog nach Trennung aller Replicas freigegeben | TTL ist abgelaufen; keine verwendbare Historie bleibt | Die spätere Wiederanbindung benötigt einen vollständigen Abgleich. |
Replikationsrate messen statt Datenbankgröße schätzen
Die reine Größe des Datenbestands reicht zur Backlog-Dimensionierung nicht aus. Eine große, überwiegend gelesene Datenbank kann wenig Replikationsverkehr erzeugen. Ein kleiner Cache mit häufig wechselnden Werten und vielen Ablaufereignissen kann dagegen laufend erhebliche Datenmengen übertragen. Auch eine feste Zahl von Operationen pro Sekunde beschreibt den benötigten Speicher nur unzureichend: Kleine Schlüsseländerungen und große Wertüberschreibungen verursachen nicht denselben Byteumfang.
Eine praktisch nutzbare Näherung ergibt sich aus dem zeitlichen Zuwachs von master_repl_offset. Erfasse den Wert zweimal am selben Primary und teile die Differenz durch die verstrichenen Sekunden. Prüfe dabei auch die Replikations-ID. Nach einem Rollenwechsel oder einem Neustart darfst du zwei nicht zusammengehörige Messpunkte nicht einfach voneinander abziehen. Ein einzelnes Messintervall liefert zudem nur eine durchschnittliche Rate innerhalb dieses Intervalls, keine dauerhaft garantierte Obergrenze.
Die folgende Abfrage liest Diagnoseinformationen. Sie verändert keine Redis-Konfiguration. Führe sie mit den in deiner Umgebung erforderlichen Verbindungs- und Authentifizierungsoptionen aus. Der unten gezeigte Aufruf verwendet die Standardverbindung von redis-cli; ein anderer Host, Port oder TLS-Zugang muss ausdrücklich eingestellt werden.
Miss über unterschiedliche Lastphasen hinweg, etwa beim normalen Tagesgeschäft, bei Importen und während größerer Cache-Erneuerungen. Dokumentiere sowohl typische Raten als auch kurze Spitzen. Treten viele Änderungen durch ablaufende Schlüssel auf, hilft als thematische Vertiefung der interne Beitrag Redis Key Expiration analysieren. Der Zusammenhang ist für die Planung wichtig, weil nicht jeder relevante Schreibimpuls unmittelbar aus einer neuen Benutzeranfrage entsteht.
Die Backlog-Größe nachvollziehbar berechnen
Als Planungsnäherung kannst du die relevante Replikationsrate mit der zu überbrückenden Unterbrechungsdauer multiplizieren und anschließend eine begründete Reserve ergänzen. Die Dauer sollte nicht nur die eigentliche Netzwerkunterbrechung berücksichtigen. Auch Erkennung, Wiederverbindungsversuche und die Wiederherstellung des Verbindungswegs können Zeit beanspruchen. Welche Reserve angemessen ist, hängt von beobachteten Schwankungen und dem gewünschten Betriebsziel ab, nicht von einer universellen Prozentzahl.
Ein bewusst vereinfachtes Rechenbeispiel: Für eine betrachtete Lastphase setzt du 12 MiB pro Sekunde an. Die Verbindung könnte 90 Sekunden fehlen; weitere 30 Sekunden werden als zeitliche Reserve eingeplant. Daraus folgen 12 MiB/s × 120 s = 1.440 MiB, also rund 1,41 GiB. Diese Zahlen sind Annahmen zur Erläuterung und kein Redis-Benchmark. Vor einer produktiven Einstellung müssen sie durch Messwerte deiner Anwendung ersetzt werden.
MiB
Illustratives Rechenbeispiel, keine Messung: Bedarf = angenommene 12 MiB/s × gewählte Gesamtdauer. 120 Sekunden enthalten im Textbeispiel 90 Sekunden Unterbrechung und 30 Sekunden Zeitreserve. Weitere Reserven sind hier nicht enthalten.
Datentabelle zur Grafik
| Eintrag | MiB |
|---|---|
| 30 Sekunden | 360 |
| 60 Sekunden | 720 |
| 120 Sekunden | 1440 |
| 180 Sekunden | 2160 |
Die umgekehrte Rechnung hilft beim Einordnen eines vorhandenen Puffers. Ein vollständig gefüllter Backlog mit 256 MiB entspricht bei gleichbleibenden 12 MiB pro Sekunde rechnerisch ungefähr 21 Sekunden Historie. Bei 2 MiB pro Sekunde wären es ungefähr 128 Sekunden. In einer realen Anwendung wechseln die Raten jedoch. Eine solche Reichweite ist deshalb eine Momentaufnahme und keine Zusage, dass jede Störung dieser Dauer partiell synchronisiert werden kann.
Prüfe außerdem, ob die Replica nach dem Wiederverbinden schneller aufholen kann, als neue Änderungen entstehen. Mehr Historie beseitigt weder ein dauerhaft zu langsames Netzwerk noch einen dauerhaft überlasteten Empfänger. Bleibt der Rückstand bestehen oder wächst er weiter, muss die Ursache untersucht werden. Immer mehr Speicher einzuplanen verschiebt das Problem sonst lediglich und kann das gesamte System unter Speicherdruck setzen.
Redis-Konfiguration verständlich und kontrolliert ändern
Die Parameter repl-backlog-size und repl-backlog-ttl steuern unterschiedliche Dinge. Der erste beschreibt die vorgesehene Backlog-Größe. Der zweite bestimmt auf dem Primary, nach welcher Zeit ohne verbundene Replicas der Backlog freigegeben werden kann. Er ist keine maximale Unterbrechungsdauer für PSYNC. Solange der Puffer überschrieben wird oder eine andere Voraussetzung fehlt, hilft eine lange TTL allein nicht weiter.
Die folgenden Zeilen stammen als auskommentierte Vorgaben aus der Konfigurationsvorlage von Redis 7.2.0. Die Kommentarzeichen sind absichtlich erhalten. Beim bloßen Kopieren dieser Zeilen werden keine Einstellungen aktiviert; außerdem sind die genannten Werte keine allgemeine Kapazitätsempfehlung für produktive Systeme.
Mit repl-backlog-ttl 0 wird die zeitgesteuerte Freigabe nach dem Trennen aller Replicas deaktiviert. Das konserviert keine unbegrenzte Historie: Der vorhandene Puffer kann weiterhin durch neue Replikationsdaten überschrieben werden. Auch entsteht dadurch keine Persistenz über beliebige Prozessneustarts. Bewerte daher bewusst, ob der zusätzliche Speicherverbrauch zum erwarteten Wiederverbindungsverhalten passt.
Vor einer Änderung solltest du die tatsächlich wirksamen Werte abfragen und das Deployment-Verfahren klären. Eine Container-Umgebungsvariable, eine verwaltete Konfigurationsdatei und eine zur Laufzeit geänderte Einstellung sind nicht dasselbe. Wird eine Instanz später neu erstellt, können ausschließlich zur Laufzeit vorgenommene Anpassungen verloren gehen. Die folgenden Abfragen sind lesend; sie benötigen trotzdem passende Zugriffsrechte.
Bei Managed Redis kann der Anbieter den Zugriff auf CONFIG einschränken oder Einstellungen über eine eigene Oberfläche verwalten. Das ist kein Grund, Schutzmechanismen zu umgehen. Verwende dann die freigegebenen Verwaltungswege und dokumentiere die gewählte Größe zusammen mit dem zugrunde liegenden Replikationsvolumen. Im Änderungsplan sollten außerdem die bisherigen Werte und ein realistischer Rückweg festgehalten werden.
Monitoring: Welche Werte zusammengehören
Für die Überwachung der Redis-Replikation ist ein einzelner grüner Verbindungsstatus zu wenig. Ein Link kann wieder verbunden sein, während die Replica noch Rückstand aufholt oder gerade einen vollständigen Datenbestand lädt. Umgekehrt muss ein kurzer Verbindungsabbruch nicht sofort kritisch sein, wenn Historie und Nachholkapazität ausreichend sind. Bewerte deshalb Verbindung, Synchronisierungszustand, Offsetentwicklung und verfügbare Historie gemeinsam.
| Feld | Bedeutung | Worauf du achtest |
|---|---|---|
| master_replid / master_repl_offset | Identität der Historie und aktueller Byte-Offset auf dem Primary | Messpunkte nur innerhalb derselben Historie vergleichen. |
| repl_backlog_active | Ob der Replication Backlog aktuell aktiv ist | Ein konfigurierter Wert allein bedeutet noch keine verfügbare Historie. |
| repl_backlog_first_byte_offset | Offset des ersten noch gespeicherten Bytes | Die für die Replica benötigten Daten müssen zum verfügbaren Bereich passen. |
| repl_backlog_histlen / repl_backlog_size | Vorhandene Historienlänge und konfigurierte Größe | Ein frisch angelegter Puffer muss noch nicht vollständig gefüllt sein. |
| master_link_status / master_sync_in_progress | Verbindung und laufende Synchronisierung aus Sicht der Replica | Ein wieder vorhandener Link allein belegt noch keinen abgeschlossenen Abgleich. |
| slave_repl_offset | Replikationsfortschritt auf einer Replica | Den zeitlichen Verlauf und die zugehörige Historie beachten. |
Die Felder einer INFO-Antwort können sich zwischen Redis-Versionen und zwischen Primary und Replica unterscheiden. Eine Auswertung sollte fehlende Felder deshalb ausdrücklich behandeln, anstatt sie stillschweigend als null oder als fehlerfreien Zustand zu interpretieren. Auch die Bezeichnungen master und slave kommen aus Gründen der Kompatibilität weiterhin in Feldnamen vor; sie dürfen im ausführbaren Code nicht frei übersetzt werden.
Für die Interpretation des Rückstands ist der interne Leitfaden Redis Replication Offset analysieren eine passende Ergänzung. Im laufenden Monitoring solltest du historische Verläufe betrachten, nicht nur zwei manuell abgelesene Zahlen. Eine wachsende Distanz verlangt eine andere Reaktion als eine nach einem kurzen Ausfall stetig schrumpfende Lücke.
Sinnvolle Alarme orientieren sich an deinen Betriebszielen: Wie lange darf eine Replica nicht erreichbar sein? Wie schnell muss sie wieder aufholen? Welche Häufung vollständiger Synchronisierungen ist ungewöhnlich? Starre Grenzwerte ohne Bezug zu Lastprofil und Datenmenge führen häufig zu unnötigen Meldungen oder übersehen echte Verschlechterungen. Behalte neben Replikationsmetriken auch RAM-Auslastung, Netzwerkauslastung und Hinweise auf Prozessneustarts im Blick.
Speicherbudget und langsame Replicas richtig einordnen
Der Backlog ist nur ein Teil des gesamten Redis-Speicherbedarfs. Hinzu kommen Datenbestand, Verwaltungsstrukturen, Client-Puffer und je nach Betriebszustand zusätzlicher Speicher während der Persistenz- oder Synchronisierungsarbeiten. Plane deshalb nicht den gesamten verfügbaren Arbeitsspeicher für Nutzdaten plus exakt berechnetem Backlog ein. Die nötige Reserve muss aus der konkreten Umgebung und den dort auftretenden Lastspitzen abgeleitet werden.
Seit Redis 7.0 teilen sich Replica-Buffer und Replication Backlog Speicher. Die INFO-Dokumentation weist deshalb unter anderem darauf hin, dass mem_clients_slaves null sein kann, wenn die Replica-Buffer die Backlog-Belegung nicht überschreiten. Daraus folgt nicht, dass Replikation keinen Speicher beansprucht. Betrachte die dafür vorgesehenen Werte wie mem_replication_backlog und mem_total_replication_buffers im Zusammenhang und addiere sich überlappende Größen nicht blind.
Ein häufiger Diagnosefehler besteht darin, jede abgebrochene Synchronisierung mit einem größeren Backlog behandeln zu wollen. Langsame Replicas, begrenzte Netzwerkbandbreite oder überschrittene Output-Buffer-Limits können eine andere Ursache haben. Der Parameter client-output-buffer-limit replica betrifft die betreffende Client-Klasse und darf nicht mit repl-backlog-size gleichgesetzt werden. Bevor du Limits veränderst, prüfe Protokolle, Versionsdokumentation und die erwartbaren Auswirkungen auf andere Verbindungen.
Warum ein großer Backlog noch keine Hochverfügbarkeit garantiert
Der Backlog verbessert die Wiederanbindung, macht die standardmäßig asynchrone Replikation aber nicht verlustfrei. Ein Primary kann einen Schreibvorgang bereits gegenüber dem Client bestätigt haben, bevor eine Replica ihn verarbeitet hat. Fällt der Primary in diesem Zeitraum aus, ist der betreffende Vorgang auf dem später ausgewählten Ersatzsystem möglicherweise nicht vorhanden. Die Puffergröße allein beseitigt dieses Datenverlustrisiko beim Failover nicht.
Auch WAIT verwandelt eine Redis-Topologie nicht in ein System mit garantierter starker Konsistenz. Der Befehl kann Bestätigungen von Replicas abwarten; die tatsächliche Datensicherheit hängt weiterhin von weiteren Umständen ab, insbesondere vom Persistenz- und Failover-Verhalten. Ebenso begrenzen min-replicas-to-write und min-replicas-max-lag unter ihren jeweiligen Bedingungen die Annahme neuer Schreibvorgänge, ohne jeden einzelnen Vorgang automatisch dauerhaft auf mehreren Instanzen zu sichern.
Für High Availability brauchst du daher eine zusammenhängende Entscheidung: tolerierter Datenverlust, zulässige Ausfallzeit, Persistenz, Erkennung von Störungen, Auswahl des neuen Primary und Wiederherstellung. Sentinel oder Redis Cluster können dabei andere Aufgaben übernehmen als der Backlog. Wer lediglich die Größe eines Puffers erhöht und alle übrigen Annahmen unverändert lässt, hat noch keinen belastbaren Wiederanlaufplan.
Änderungen testen und wiederkehrende Probleme eingrenzen
Beginne einen kontrollierten Test in einer isolierten Umgebung mit vergleichbarer Redis-Version und nachvollziehbarer Schreiblast. Halte vor der Unterbrechung Replikations-IDs, Offsets, Backlog-Belegung und Speicherverbrauch fest. Simuliere anschließend eine begrenzte Verbindungsunterbrechung, ohne ungeprüft produktive Firewalls oder Prozesse zu verändern. Nach der Wiederverbindung beobachtest du, ob eine partielle oder vollständige Synchronisierung stattfindet und wie lange das Aufholen dauert.
Verändere pro Versuch möglichst nur eine relevante Größe. Wenn gleichzeitig Backlog, Schreiblast und Netzwerkbedingungen wechseln, lässt sich die Wirkung kaum zuordnen. Wiederhole den Versuch mit unterschiedlicher Unterbrechungsdauer und verschiedenen Lastphasen. So wird aus einer einzelnen erfolgreichen Wiederverbindung eine nachvollziehbare Einschätzung des Verhaltens. Die beobachteten Grenzen sollten dokumentiert werden, ohne daraus eine Garantie für jede zukünftige Störung abzuleiten.
Bei wiederholten Full Resyncs prüfst du zuerst, ob die Historie überhaupt kompatibel ist. Danach folgen die noch vorhandenen Bytes, die Zeit ohne Replica, Hinweise auf Neustarts und die tatsächliche Nachholgeschwindigkeit. Ein zu kleiner Puffer ist eine mögliche Ursache, aber nicht die einzige. Besonders wichtig ist die Unterscheidung zwischen einer zu langen einmaligen Lücke und einer Replica, die selbst bei bestehender Verbindung dauerhaft zurückfällt.
Die richtige Einstellung ist am Ende diejenige, die dein definiertes Ausfallfenster bei realistischer Last abdeckt und genügend Speicher für den übrigen Betrieb lässt. Halte Messgrundlage, Konfigurationsquelle und Prüfdatum zusammen fest. Nach größeren Änderungen am Schreibverhalten, an der Topologie oder an der Redis-Version gehört die Dimensionierung erneut auf den Prüfstand. Dadurch bleibt der Backlog eine begründete Betriebsentscheidung statt einer einmal übernommenen Zahl.
Quellen und fachlicher Stand
Recherche-Stand:
Konfigurationsbeispiele sind anhand des stabilen Redis-Tags 7.2.0 eingeordnet, nicht anhand des Entwicklungszweigs unstable. Die beschriebene gemeinsame Speicherbelegung gilt laut INFO-Dokumentation ab Redis 7.0. Die allgemeinen Mechanismen beziehen sich auf Redis Open Source; es werden keine Redis-Software-/Cloud-Defaultwerte übertragen. Dokumentationsabgleich: 21.09.2026. Keine selbst durchgeführten Redis-Labortests.
