Dieser Artikel führt Sie in die Master-Slave-Replikation in Redis ein, stellt die grundlegende Master-Slave-Konfiguration sowie die Funktionen und Prinzipien der Master-Slave-Konfiguration vor. Ich hoffe, er wird Ihnen hilfreich sein!
Redis unterstützt die Master-Slave-Replikationsfunktion. Sie können die Replikationsfunktion aktivieren, indem Sie „slaveof“ (nach Redis5-Version in „replicaof“ geändert) ausführen oder „slaveof“ in der Konfigurationsdatei festlegen (nach Redis5-Version in „replicaof“ geändert). [Verwandte Empfehlungen: Redis-Video-Tutorial]
- Ein Master und zwei Cluster
- Ein Master und mehrere Slaves
Master-Slave-Grundkonfiguration
Master-Redis.-Konfiguration
Master-Redis-Konfiguration Es besteht grundsätzlich keine Notwendigkeit, Änderungen vorzunehmen.
Konfigurieren Sie von Redis aus
3. Konfigurieren Sie die Master-Slave-Replikation
# salve的端口号
port 6380
#把pid进程号写入pidfile配置的文件
pidfile /var/run/redis_6380.pid
logfile "6380.log"
#指定数据存放目录
dir /usr/local/redis‐5.0.3/data/6380
#需要注释掉bind
#bind127.0.0.1(bind绑定的是自己机器网卡的ip,如果有多块网卡可以配多个ip,代表允许客户端通过机器的哪些网卡ip去访问,内网一般可以不配置bind,注释掉即可)
5. Verbinden Sie den Slave-Knoten
#从本机master6379的redis实例复制数据,Redis5.0之前使用slaveof
replicaof 192.168.0.60 6379
#配置从节点只读
replica‐read‐only yes
6 Die Instanz kann die neu geänderten Daten rechtzeitig synchronisieren , und der Slave ist für das Lesen verantwortlich.
Verbessern Sie die Leistung und den Durchsatz von Redis , der Slave kann lesen, aber nicht schreiben
Standardmäßig kann der Slave nach dem Ausfall des Hosts nicht mehr vom Host verwendet werden
Sentinel kann Master-Slave-Switching realisieren, um eine hohe Verfügbarkeit zu erreichen
Das Funktionsprinzip des Redis-Masters -Slave
Vollständige Kopie der Master-Slave-Replikation
Nur wenn das Slave-Redis zum ersten Mal eine Verbindung zum Master-Redis herstellt, erfolgt die vollständige Kopie. Wenn es sich um eine kurzfristige fortgesetzte Übertragung handelt, handelt es sich möglicherweise um eine vollständige Kopie . Kopie, möglicherweise Teilkopie.
Flowchart
-
-
- 1. Erstellen Sie eine lange Sockker -Verbindung mit dem Master Redis
- slaver eine Socket -Verbindung mit dem zugeordneten Master
slaver -Associal -Ereignisprozessor. Dateien (vollständige Kopie), empfangen Sie den vom Master übertragenen Schreibbefehl (inkrementelle Kopie)
-
- Nachdem der Master-Server die Socket-Verbindung des Slave-Servers akzeptiert hat, erstellt er den entsprechenden Client-Status. Dies entspricht der Tatsache, dass der Slave-Server der Client des Master-Servers ist.
-
-
Ping-Befehl senden
Slaver sendet Ping-Befehl an Master
- 1. Überprüfen Sie den Lese- und Schreibstatus des Sockets
2. Überprüfen Sie, ob der Master damit normal umgehen kann
Master-Antwort:
1. Senden Sie „Pong“, was auf „Normal“ hinweist
- 2. Geben Sie einen Fehler zurück, was darauf hinweist, dass der Master abnormal ist
3. Zeitüberschreitung, was auf eine Netzwerk-Zeitüberschreitung hinweist
Berechtigungsüberprüfung-
Nachdem Master und Slave normal verbunden sind, führen Sie eine Berechtigungsüberprüfung durch
- Der Master hat kein Passwort festgelegt (requirepass="") und es besteht keine Notwendigkeit, ein Passwort festzulegen (masterauth="")Der Master legt ein Passwort fest (requirepass! =""), von der Notwendigkeit, ein Passwort festzulegen (masterauth=der Wert des requirepass des Masters)
- oder vom Senden eines Passworts an den Master über die Authentifizierung Befehl
-
2 Der Master-Redis empfängt den Befehl bgsave, nachdem der PSYNC-Befehl den neuesten RDB-Snapshot generiert an den Slave-Redis. Wenn der Master-Redis den RDB-Snapshot an den Slave-Redis sendet, empfängt der Master weiterhin die Anforderungen des Clients, die den Datensatz im Speicher ändern können, und speichert sie im Relp-Puffer-Cache
- Synchronisierungs-Snapshot-Phase: Master erstellt und sendet Snapshot-RDB an Slave, und Slave lädt und analysiert den Snapshot. Der Master speichert auch die in dieser Phase neu generierten Schreibbefehle im Puffer.
4. Der Slave-Knoten empfängt den RDB-Snapshot. Nachdem der Slave-Knoten den RDB-Snapshot empfangen hat, löscht er die alten Daten und lädt die RDB-Datei Slave Redis
Schreibpuffer synchronisieren Stufe: Der Master synchronisiert den im Puffer gespeicherten Schreibvorgangsbefehl mit dem Slave.
6. Der Slave-Knoten empfängt die Puffer-Cache-Datei
Der Slave-Knoten empfängt die Puffer-Cache-Datei und lädt die Puffer-Cache-Datei in den Speicher
7 Der Master-Redis sendet kontinuierlich Befehle an den Slave-Knoten Socker lange Verbindung
Empfangen Sie den vom Master-Redis gesendeten Befehl von Redis und führen Sie den aktuellen Befehl aus
Übersicht
Wenn Sie einen Slave für den Master konfigurieren, unabhängig davon, ob der Slave zum ersten Mal mit dem Master verbunden ist Gleichzeitig wird ein PSYNC-Befehl an den Master gesendet, der zum Kopieren von Daten auffordert. Nachdem der Master den PSYNC-Befehl empfangen hat, führt er eine Datenpersistenz im Hintergrund durch und generiert die neueste RDB-Snapshot-Datei über bgsave. Während des Persistenzzeitraums empfängt der Master weiterhin Clientanforderungen und speichert diese Anforderungen, die möglicherweise geändert werden Datensatz im Speicher. Wenn die Persistenz abgeschlossen ist, sendet der Master den RDB-Dateidatensatz an den Slave, und der Slave speichert die empfangenen Daten, um RDB zu generieren, und lädt sie dann in den Speicher. Anschließend sendet der Master den zuvor im Speicher zwischengespeicherten Befehl an den Slave. Wenn die Verbindung zwischen dem Master und dem Slave aus irgendeinem Grund getrennt wird, kann der Slave automatisch wieder eine Verbindung zum Master herstellen. Wenn der Master mehrere gleichzeitige Verbindungsanforderungen des Slaves empfängt, bleibt er nur einmal bestehen, nicht einmal für jede Verbindung, und sendet sie dann diese persistenten Daten an mehrere gleichzeitig verbundene Slaves weiter.
Teilkopie der Master-Slave-Kopie
Der allgemeine Vorgang ähnelt der vollständigen Kopie, daher werde ich ihn nicht im Detail erklären
Kurze Beschreibung
Wenn Master und Slave getrennt werden und Bei erneuter Verbindung werden in der Regel die gesamten Daten kopiert. Ab Redis-Version 2.8 verwendet Redis jedoch den Befehl PSYNC, der eine teilweise Datenreplikation unterstützen kann, um Daten mit dem Master zu synchronisieren. Der Slave und der Master können nur eine teilweise Datenreplikation (wiederaufnahme der Übertragung) durchführen, nachdem die Netzwerkverbindung getrennt und wieder hergestellt wurde. Der Master erstellt eine Cache-Warteschlange zum Kopieren von Daten in seinem Speicher, um die Daten für den letzten Zeitraum zwischenzuspeichern. Der Master und alle seine Slaves behalten den Index-Offset der kopierten Daten und die Prozess-ID des Masters bei. Anschließend fordert der Slave den Master auf, die noch nicht abgeschlossene Replikation beginnend mit dem aufgezeichneten Datenindex fortzusetzen. Wenn sich die Master-Prozess-ID ändert oder der Datenoffset des Slave-Knotens zu alt ist und sich nicht mehr in der Cache-Warteschlange des Masters befindet, wird eine vollständige Datenkopie durchgeführt. Flussdiagramm der Master-Slave-Replikation (teilweise Replikation, Haltepunkt-Wiederaufnahme):
Inkrementelle Synchronisierung der Master-Slave-Replikation
Die inkrementelle Redis-Synchronisation bezieht sich hauptsächlich auf die Schreibvorgänge, die auf dem Master ausgeführt werden, wenn der Slave die Initialisierung abschließt und startet Der Prozess der Synchronisierung mit dem Slave funktioniert normal.
Normalerweise sendet der Master jedes Mal, wenn er einen Schreibbefehl ausführt, denselben Schreibbefehl an den Slave, und der Slave empfängt ihn dann und führt ihn aus.
- Heartbeat-Erkennung der Master-Slave-Replikation
1. Ermitteln Sie den Verbindungsstatus des Master-Slave-Servers. Ermitteln Sie den Netzwerkverbindungsstatus des Master-Slave-Servers Beim Master-Server können Sie die Liste der Slave-Server auflisten. Sie können sehen, wie viele Sekunden vergangen sind, seit der letzte Befehl an den Master gesendet wurde. Der Wert von Lag sollte zwischen 0 und 1 springen. Wenn er 1 überschreitet, bedeutet dies, dass die Verbindung zwischen Master und Slave fehlerhaft ist.
2. Hilfsimplementierung von Min-Slaves
Redis kann so konfiguriert werden, dass der Hauptserver den Schreibbefehl min-slaves-to-write 3 (min-replicas-to-write 3) unter min-slaves ausführt unsichere Bedingungen -max-lag 10 (min-replicas-max-lag 10) Die obige Konfiguration bedeutet: wenn die Anzahl der Slave-Server weniger als 3 beträgt oder der Verzögerungswert (Lag) der drei Slave-Server größer oder gleich ist Auf 10 Sekunden wird dem Master-Server die Ausführung des Schreibbefehls verweigert. Der Verzögerungswert ist hier der Verzögerungswert des obigen INForeplication-Befehls.
3. Befehlsverlust erkennen
Wenn der vom Master-Server an den Slave-Server übertragene Schreibbefehl aufgrund eines Netzwerkfehlers auf halbem Weg verloren geht, sendet der Slave-Server den REPLCONF ACK-Befehl an den Master-Server Der Server erkennt den aktuellen Status des Slave-Servers. Wenn der Replikations-Offset kleiner als sein eigener Replikations-Offset ist, findet der Master-Server die fehlenden Daten vom Slave-Server im Replikations-Backlog-Puffer basierend auf dem vom Slave übermittelten Replikations-Offset Server und senden Sie die Daten erneut an den Slave-Server. (Neuauflage) Das Netzwerk wird kontinuierlich inkrementell synchronisiert: Die Netzwerkverbindung wird getrennt und bei erneuter Verbindung wieder hergestelltSo beurteilen Sie die vollständige oder teilweise Kopie
Nachdem der Client „saveof“ gesendet hat, beurteilt der Masterknoten, ob er zum ersten Mal kopiert wird. Wenn ja, führt er eine vollständige Kopie durch , es wird anhand des Runid-Offsets beurteilt. Wenn sie konsistent sind, wird eine Teilkopie erstellt, andernfalls wird eine vollständige Kopie erstellt.
Weitere Kenntnisse zum Thema Programmierung finden Sie unter: Programmiervideos! !
Das obige ist der detaillierte Inhalt vonErfahren Sie mehr über die Master-Slave-Replikation in Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!