Leitfaden zur Einrichtung der Redis Primary-Replica-Replikation

Redis-Replikation ist ein grundlegendes Muster zur Erreichung hoher Verfügbarkeit, Datenredundanz und Leseskalierbarkeit. Durch die Einrichtung eines Primärservers (früher Master genannt) und eines oder mehrerer Replikate (früher Slaves genannt) stellen Sie sicher, dass in den Primärserver geschriebene Daten automatisch auf alle verbundenen Replikate kopiert werden.

Diese Anleitung zeigt, wie Sie die Redis Primary-Replica-Replikation konfigurieren, überprüfen, ob die Synchronisation funktioniert, und die häufigen Fehler vermeiden, die Redis exponieren oder Replikate stillschweigend veralten lassen.

Grundlagen der Redis-Replikation verstehen

Die Redis-Replikation ist asynchron (d.h. der Primärserver wartet nicht auf die Bestätigung des Replikats für Schreibvorgänge), was eine hohe Leistung ermöglicht. Sie erfolgt hauptsächlich in zwei Phasen: anfängliche Synchronisation und kontinuierliche Synchronisation.

Vollständige Synchronisation (SYNC)

Wenn ein Replikat zum ersten Mal eine Verbindung zu einem Primärserver herstellt oder nach einer Netzwerkunterbrechung, die eine partielle Resynchronisation verhindert, findet eine vollständige Synchronisation statt:

Das Replikat sendet einen PSYNC-Befehl an den Primärserver.
Der Primärserver startet einen Hintergrund-Speicherprozess, um eine RDB-Snapshot-Datei (.rdb) zu erstellen.
Der Primärserver puffert alle neuen Schreibbefehle, die während der Erstellung des RDB eingehen.
Sobald die RDB-Datei vollständig ist, sendet der Primärserver sie an das Replikat.
Das Replikat lädt die RDB-Datei in den Speicher.
Schließlich sendet der Primärserver alle gepufferten Schreibbefehle an das Replikat, um es auf den neuesten Stand zu bringen.

Partielle Resynchronisation (PSYNC)

Redis 2.8+ unterstützt partielle Resynchronisation. Wenn die Verbindung zwischen Primärserver und Replikat kurzzeitig unterbrochen wird, kann das Replikat nur die fehlenden Befehle seit der Unterbrechung anfordern, indem es den Replikations-Backlog-Puffer (einen konfigurierbaren Ringpuffer auf dem Primärserver) verwendet.

Voraussetzungen und Einrichtung

Stellen Sie vor der Konfiguration der Replikation sicher, dass Sie mindestens zwei separate Redis-Instanzen ausführen (oder separate Konfigurationen auf verschiedenen Ports auf demselben Server zu Testzwecken).

Für diese Anleitung gehen wir von folgendem Setup aus:

Instanz	Rolle	IP-Adresse	Port	Konfigurationsdatei
Primärserver	Primär	192.168.1.100	6379	`redis-primary.conf`
Replikat 1	Replikat	192.168.1.101	6380	`redis-replica-1.conf`

Schritt 2.1: Konfigurieren der Primärinstanz

Stellen Sie sicher, dass Ihre Primärinstanz bereit ist, Verbindungen von den Replikaten zu akzeptieren, und für die Verwaltung der Persistenz (RDB oder AOF) konfiguriert ist, falls dies für die Stabilität des Primärservers erforderlich ist.

Wichtige Primäreinstellungen:

Binding: Stellen Sie sicher, dass der Primärserver an eine öffentliche IP-Adresse oder 0.0.0.0 gebunden ist, wenn er über mehrere Maschinen hinweg läuft. Wenn Sie Firewalls verwenden, stellen Sie sicher, dass Port 6379 für die Replikat-IPs geöffnet ist.
Persistenz: Obwohl nicht streng erforderlich für die Replikation selbst, wird die Aktivierung von RDB/AOF für die Datenpersistenz des Primärservers dringend empfohlen.

# redis-primary.conf
port 6379
bind 0.0.0.0 # Bindet an alle Schnittstellen (notwendig für externe Replikate)
# RDB-Persistenz aktivieren
save 900 1
save 300 10
save 60 10000

Schritt 2.2: Konfigurieren der Replikatinstanz

Der Kern der Einrichtung eines Replikats liegt in der replicaof-Direktive. Diese teilt der Instanz mit, mit welchem Primärserver sie ihre Daten synchronisieren soll.

Wichtige Replikateinstellungen:

Port: Verwenden Sie einen anderen Port, wenn Sie auf derselben Maschine laufen.
Replikationsdirektive: Verwenden Sie replicaof oder slaveof (der veraltete Name).

# redis-replica-1.conf
port 6380

# *** Wesentliche Replikationskonfiguration ***
replicaof 192.168.1.100 6379

# Sicherstellen, dass Replikate schreibgeschützt sind (Standard seit Redis 5)
replica-read-only yes

# Empfehlung: Persistenz auf Replikaten deaktivieren, wenn HA von Sentinel/Cluster verwaltet wird
# Wenn Persistenz für schnelle Neustarts benötigt wird, lassen Sie sie aktiviert.
save ""

Hinweis: Wenn der Primärserver ein Passwort erfordert, konfigurieren Sie das Replikat mit masterauth <password>. In Redis 6 und späteren ACL-Setups konfigurieren Sie auch masteruser, wenn der Replikationsbenutzer nicht der Standardbenutzer ist.

Implementierungsmethoden

Sie können die Replikation implementieren, indem Sie die Konfigurationsdatei bearbeiten und den Server neu starten, oder dynamisch, indem Sie den Befehl REPLICAOF von redis-cli aus ausführen.

Methode 3.1: Konfigurationsdatei (Empfohlen für die Produktion)

Nachdem Sie redis-replica-1.conf wie oben gezeigt aktualisiert haben, starten Sie beide Instanzen:

# Primärserver starten
redis-server redis-primary.conf

# Replikat 1 starten
redis-server redis-replica-1.conf

Beim Start wird Replikat 1 sofort versuchen, eine Verbindung zum Primärserver unter 192.168.1.100:6379 herzustellen und den Synchronisationsprozess zu beginnen.

Methode 3.2: Dynamische Konfiguration

Wenn eine Redis-Instanz bereits läuft und Sie sie ohne Neustart in ein Replikat umwandeln möchten, führen Sie REPLICAOF über redis-cli aus.

Stellen Sie eine Verbindung zu der Instanz her, die Sie in ein Replikat umwandeln möchten (in unserem Beispiel läuft sie auf Port 6380):
```
redis-cli -p 6380
```

Führen Sie den Replikationsbefehl aus:

127.0.0.1:6380> replicaof 192.168.1.100 6379
OK

Die Instanz auf Port 6380 wird alle vorherigen Daten verwerfen und eine vollständige Synchronisation (SYNC) mit dem neuen Primärserver initiieren.

⚠️ Warnung: Deaktivieren der Replikation

Um ein Replikat wieder in eine eigenständige Primärinstanz umzuwandeln, führen Sie auf dieser Instanz replicaof no one aus.

4. Überwachung des Replikationsstatus

Die Überwachung des Verbindungsstatus ist entscheidend, um Datenkonsistenz sicherzustellen. Verwenden Sie den Befehl INFO replication über redis-cli sowohl auf dem Primärserver als auch auf dem Replikat.

4.1 Überprüfen des Primärstatus

Stellen Sie eine Verbindung zum Primärserver (6379) her und überprüfen Sie, wie viele Replikate verbunden sind und deren Status:

redis-cli -p 6379 INFO replication

Erwarteter Ausgabeausschnitt (Primärserver):

# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.101,port=6380,state=online,offset=2048,lag=0
master_replid:a9b1c2...
master_replid2:000000...
master_repl_offset:2048

role:master bestätigt seine Rolle.
connected_slaves:1 bestätigt, dass das Replikat gesehen wird.
state=online ist der gewünschte stabile Zustand.
lag=0 oder ein niedriger Wert bedeutet, dass das Replikat schnell antwortet. Die Redis-Replikation ist immer noch asynchron, daher ist dies keine Garantie für keinen Datenverlust.

4.2 Überprüfen des Replikatstatus

Stellen Sie eine Verbindung zum Replikat (6380) her und überprüfen Sie den Status der Primärverbindung:

redis-cli -p 6380 INFO replication

Erwarteter Ausgabeausschnitt (Replikat):

# Replication
role:slave
master_host:192.168.1.100
master_port:6379
master_link_status:up
master_sync_in_progress:0
slave_priority:100
slave_read_only:1

role:slave bestätigt seine Rolle.
master_link_status:up bestätigt, dass die Verbindung aktiv und gesund ist.
master_sync_in_progress:0 bedeutet, dass die anfängliche Synchronisation abgeschlossen ist.

Best Practices und Optimierung der Replikation

5.1 Schreibgeschützter Modus für Replikate

Standardmäßig sind Replikate schreibgeschützt (replica-read-only yes). Dies ist ein kritischer Sicherheitsmechanismus. Der Versuch, in ein Replikat zu schreiben, führt zu einem Fehler, wodurch die Datenkonsistenz im gesamten Cluster sichergestellt wird.

Wenn Sie den schreibgeschützten Modus deaktivieren, sind alle Schreibvorgänge auf dem Replikat lokal und werden überschrieben, wenn die Replikationsverbindung unterbrochen wird und eine vollständige Synchronisation erfolgt.

5.2 Optimierung der Synchronisationszeit

Wenn Ihr Datensatz sehr groß ist, kann der anfängliche SYNC-Prozess langsam sein. Berücksichtigen Sie diese Faktoren:

Netzwerkbandbreite: Stellen Sie sicher, dass zwischen Primärserver und Replikaten ausreichend Bandbreite für die RDB-Übertragung vorhanden ist.
RDB-Generierung: Der Primärserver benötigt CPU- und Festplatten-E/A, um die RDB-Datei zu erstellen. Stellen Sie sicher, dass der Server während der Synchronisation über ausreichende Ressourcen verfügt.
Festplattenpersistenz auf Replikaten deaktivieren (optional): Wenn der Primärserver die gesamte Persistenz übernimmt und das Replikat nur zur Leseskalierung dient, vermeidet die Einstellung save "" auf dem Replikat den E/A-Overhead beim Schreiben von RDB-Dateien und beschleunigt Neustarts.

5.3 Sicherheits- und Netzwerkkonfiguration

Es ist entscheidend, dass der Primärserver seinen Replikationsport (6379 oder einen anderen) nicht öffentlich im Internet freigibt. Konfigurieren Sie Firewall-Regeln, um Replikationsverkehr nur von den festgelegten IP-Adressen der Replikatserver zuzulassen.

5.4 Verwendung von Replikaten zur Leseskalierung

Der Hauptvorteil der Replikation ist die Verteilung der Leselast. Leiten Sie Anwendungen, die hauptsächlich Leseoperationen durchführen, an die Replikatinstanzen weiter, und reservieren Sie den Primärserver für Schreiboperationen, um den Gesamtdurchsatz des Systems zu verbessern.

Was als Nächstes zu tun ist

Die Einrichtung der Redis Primary-Replica-Replikation ist entscheidend für den Aufbau widerstandsfähiger, leistungsstarker Anwendungen. Durch die korrekte Konfiguration der replicaof-Direktive und die regelmäßige Überwachung des Verbindungsstatus mit INFO replication schaffen Sie eine Grundlage für hohe Verfügbarkeit und effektive Leseskalierung.

Während sich diese Anleitung auf die grundlegende Einrichtung konzentriert, integrieren Produktionsumgebungen oft weitere Automatisierungsebenen, wie Redis Sentinel für automatische Primärförderung und Fehlererkennung oder Redis Cluster für automatische Partitionierung und Verteilung von Daten über mehrere Knoten.