Anleitung zur Einrichtung der Redis Primary-Replica-Replikation
Die Redis-Replikation ist ein grundlegendes Muster zur Erreichung von Hochverfü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 Daten, die auf den Primärserver geschrieben werden, automatisch auf alle verbundenen Replikate kopiert werden.
Dieser Leitfaden bietet eine umfassende Schritt-für-Schritt-Anleitung zur Konfiguration der Redis Primary-Replica-Replikation. Wir werden die wesentlichen Konfigurationsanweisungen, dynamischen Konfigurationsmethoden und kritischen Überwachungsschritte behandeln, die für den Aufbau einer robusten und zuverlässigen Redis-Bereitstellung erforderlich sind.
1. Grundlagen der Redis-Replikation verstehen
Die Redis-Replikation ist asynchron (was bedeutet, dass der Primärserver nicht darauf wartet, dass das Replikat Schreibvorgänge bestätigt), was eine hohe Leistung ermöglicht. Sie arbeitet hauptsächlich in zwei Phasen: initiale 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, erfolgt eine vollständige Synchronisation:
- Das Replikat sendet einen
PSYNC-Befehl an den Primärserver. - Der Primärserver startet einen Hintergrund-Speicherprozess, um eine RDB-Snapshot-Datei (
.rdb) zu generieren. - Der Primärserver puffert alle neuen Schreibbefehle, die während der Erstellung der RDB-Datei empfangen werden.
- 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 den Rückstand aufzuholen.
Partielle Resynchronisation (PSYNC)
Redis 2.8+ unterstützt die partielle Resynchronisation. Wenn die Verbindung zwischen dem Primärserver und dem Replikat kurzzeitig abbricht, kann das Replikat nur die fehlenden Befehle seit dem Abbruch der Verbindung anfordern, indem es den Replikations-Backlog-Puffer (einen konfigurierbaren zirkulären Puffer auf dem Primärserver) verwendet.
2. Voraussetzungen und Einrichtung
Bevor Sie die Replikation konfigurieren, stellen Sie sicher, dass Sie mindestens zwei separate Redis-Instanzen am Laufen haben (oder separate Konfigurationen, die auf verschiedenen Ports auf demselben Server (zu Testzwecken) laufen).
Für diesen Leitfaden nehmen wir die folgende Einrichtung an:
| Instanz | Rolle | IP-Adresse | Port | Konfigurationsdatei |
|---|---|---|---|---|
| Primary | Primärserver | 192.168.1.100 | 6379 | redis-primary.conf |
| Replica 1 | Replikat | 192.168.1.101 | 6380 | redis-replica-1.conf |
Schritt 2.1: Primärserver-Instanz konfigurieren
Stellen Sie sicher, dass Ihre Primärserver-Instanz bereit ist, Verbindungen von den Replikas zu akzeptieren und so konfiguriert ist, dass sie die Persistenz (RDB oder AOF) verwaltet, falls dies für die eigene Stabilität des Primärservers erforderlich ist.
Wichtige Primärserver-Einstellungen:
- Bindung: Stellen Sie sicher, dass der Primärserver an eine öffentliche IP-Adresse oder
0.0.0.0gebunden ist, wenn er auf mehreren Maschinen läuft. Bei Verwendung von Firewalls stellen Sie sicher, dass Port 6379 für die IP-Adressen der Replikate geöffnet ist. - Persistenz: Obwohl nicht strikt für die Replikation selbst erforderlich, 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: Replikat-Instanz konfigurieren
Der Kern der Einrichtung eines Replikats liegt in der replicaof-Anweisung. Diese teilt der Instanz mit, mit welchem Primärserver sie ihre Daten synchronisieren soll.
Wichtige Replikat-Einstellungen:
- Port: Verwenden Sie einen anderen Port, wenn Sie auf derselben Maschine laufen.
- Replikationsanweisung: Verwenden Sie
replicaofoderslaveof(den veralteten Namen).
# redis-replica-1.conf
port 6380
# *** Essentielle Replikationskonfiguration ***
replicaof 192.168.1.100 6379
# Sicherstellen, dass Replikate schreibgeschützt sind (Standard seit Redis 5)
replica-read-only yes
# Es wird empfohlen, die Persistenz auf Replikaten zu deaktivieren, wenn HA von Sentinel/Cluster gehandhabt wird.
# Wenn Persistenz für schnelle Neustarts benötigt wird, lassen Sie sie aktiviert.
save ""
Hinweis: Wenn der Primärserver mit einem Passwort gesichert ist (mittels
requirepass), muss das Replikat mitmasterauth <password>konfiguriert werden, um sich erfolgreich authentifizieren zu können.
3. Implementierungsmethoden
Sie können die Replikationskonfiguration entweder durch Bearbeiten der Konfigurationsdatei (redis.conf) und Neustarten des Servers oder dynamisch mittels des CONFIG SET-Befehls implementieren.
Methode 3.1: Konfigurationsdatei (für die Produktion empfohlen)
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 beginnen.
Methode 3.2: Dynamische Konfiguration
Wenn eine Redis-Instanz bereits läuft und Sie sie ohne Neustart als Replikat konfigurieren möchten, verwenden Sie CONFIG SET über redis-cli.
-
Verbinden Sie sich mit der Instanz, die Sie in ein Replikat umwandeln möchten (in unserem Beispiel auf Port 6380 laufend):
bash redis-cli -p 6380 -
Führen Sie den Replikationsbefehl aus:
bash 127.0.0.1:6380> replicaof 192.168.1.100 6379 OK
Die Instanz auf Port 6380 löscht alle vorherigen Daten und initiiert eine vollständige Synchronisation (SYNC) mit dem neuen Primärserver.
⚠️ Warnung: Replikation deaktivieren
Um ein Replikat wieder in eine eigenständige Primärserver-Instanz umzuwandeln, führen Sie
replicaof no oneauf dieser Instanz aus.
4. Replikationsstatus überwachen
Die Überwachung des Verbindungsstatus ist entscheidend, um die Datenkonsistenz zu gewährleisten. Verwenden Sie den Befehl INFO replication über redis-cli sowohl auf dem Primärserver als auch auf dem Replikat.
4.1 Primärserver-Status überprüfen
Verbinden Sie sich mit dem Primärserver (6379) und überprüfen Sie, wie viele Replikate verbunden sind und deren Status:
redis-cli -p 6379 INFO replication
Erwarteter Auszug der Ausgabe (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:masterbestätigt seine Rolle.connected_slaves:1bestätigt, dass das Replikat erkannt wird.state=onlineist der gewünschte stabile Zustand.lag=0(oder eine sehr niedrige Zahl) zeigt eine erfolgreiche synchrone Datenübertragungsleistung an.
4.2 Replikat-Status überprüfen
Verbinden Sie sich mit dem Replikat (6380) und überprüfen Sie den Status der Primärserver-Verbindung:
redis-cli -p 6380 INFO replication
Erwarteter Auszug der Ausgabe (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:slavebestätigt seine Rolle.master_link_status:upbestätigt, dass die Verbindung aktiv und fehlerfrei ist.master_sync_in_progress:0bedeutet, dass die initiale Synchronisation abgeschlossen ist.
5. Best Practices und Optimierung der Replikation
5.1 Replikations-Read-Only-Modus
Standardmäßig sind Replikate schreibgeschützt (replica-read-only yes). Dies ist ein kritischer Sicherheitsmechanismus. Der Versuch, auf ein Replikat zu schreiben, führt zu einem Fehler, was die Datenkonsistenz im gesamten Cluster gewährleistet.
Wenn Sie den Read-Only-Modus deaktivieren, sind alle Schreibvorgänge auf das Replikat lokal und werden überschrieben, wenn die Replikationsverbindung abbricht und eine vollständige Synchronisation stattfindet.
5.2 Synchronisationszeit optimieren
Wenn Ihr Datensatz sehr groß ist, kann der initiale SYNC-Prozess langsam sein. Berücksichtigen Sie diese Faktoren:
- Netzwerkbandbreite: Stellen Sie eine ausreichende Bandbreite zwischen dem Primärserver und den Replikaten für die RDB-Übertragung sicher.
- RDB-Generierung: Der Primärserver benötigt CPU- und Festplatten-I/O, um die RDB-Datei zu generieren. Stellen Sie sicher, dass der Server während der Synchronisation über verfügbare Ressourcen verfügt.
- Festplattenpersistenz auf Replikaten deaktivieren (Optional): Wenn der Primärserver die gesamte Persistenz verwaltet und das Replikat nur zur Leseskalierung dient, vermeidet das Setzen von
save ""auf dem Replikat den I/O-Overhead beim Schreiben von RDB-Dateien und beschleunigt Neustarts.
5.3 Sicherheit und Netzwerkkonfiguration
Es ist entscheidend, dass der Primärserver seinen Replikationsport (6379 oder andere) nicht öffentlich dem Internet aussetzt. Konfigurieren Sie Firewall-Regeln, um Replikationsverkehr nur von den dafür vorgesehenen IP-Adressen der Replikatserver zuzulassen.
5.4 Replikate für die Leseskalierung nutzen
Der Hauptvorteil der Replikation ist die Verteilung der Leselast. Leiten Sie Anwendungen, die hauptsächlich Leseoperationen durchführen, auf die Replikatinstanzen um, und reservieren Sie den Primärserver für Schreiboperationen, um den Gesamtdurchsatz des Systems zu verbessern.
Fazit
Die Einrichtung der Redis Primary-Replica-Replikation ist unerlässlich für den Aufbau robuster, hochleistungsfähiger Anwendungen. Durch die korrekte Konfiguration der replicaof-Anweisung und die regelmäßige Überwachung des Verbindungsstatus mittels INFO replication schaffen Sie eine Grundlage für Hochverfügbarkeit und effektive Leseskalierung.
Während sich dieser Leitfaden auf die grundlegende Einrichtung konzentriert, integrieren Produktionsumgebungen oft weitere Automatisierungsschichten, wie z.B. Redis Sentinel für die automatische Primärserver-Promotion und Fehlererkennung, oder Redis Cluster für die automatische Partitionierung und Verteilung von Daten über mehrere Knoten.