Einführung in die Redis-Persistenz und den Master-Slave-Replikationsmechanismus

Der Inhalt dieses Artikels besteht darin, den Persistenz- und Master-Slave-Replikationsmechanismus von Redis vorzustellen. Er hat einen gewissen Referenzwert. Ich hoffe, er wird für Sie hilfreich sein.

Redis-Persistenz

Redis bietet eine Vielzahl von Persistenzmethoden auf verschiedenen Ebenen:

RDB-Persistenz kann Punkt generieren- In-Time-Snapshot des Datensatzes innerhalb des angegebenen Zeitintervalls

AOF zeichnet dauerhaft alle vom Server ausgeführten Schreiboperationsbefehle auf und führt diese Befehle erneut aus, wenn der Server startet. Alle Befehle in der AOF-Datei werden im Redis-Protokollformat gespeichert und neue Befehle werden am Ende der Datei angehängt. Redis kann die AOF-Datei auch im Hintergrund neu schreiben, sodass die Größe der AOF-Datei nicht die tatsächliche Größe überschreitet, die zum Speichern des Datensatzstatus erforderlich ist.

Redis kann auch gleichzeitig AOF-Persistenz und RDB-Persistenz verwenden. In diesem Fall wird beim Neustart von Redis der Verwendung der AOF-Datei zum Wiederherstellen des Datensatzes Vorrang eingeräumt, da der von der AOF-Datei gespeicherte Datensatz normalerweise vollständiger ist als der von der RDB-Datei gespeicherte Datensatz.
Sie können die Persistenz sogar deaktivieren, sodass die Daten nur vorhanden sind, während der Server läuft.

RDB (Redis DataBase)

Rdb: Schreiben Sie innerhalb eines bestimmten Zeitintervalls einen Snapshot des In-Memory-Datensatzes auf die Festplatte Im Fachjargon ist ein Snapshot ein Snapshot. Beim Wiederherstellen wird die Snapshot-Datei direkt in den Speicher eingelesen.

Redis erstellt (Fork) einen separaten Unterprozess für die Persistenz. Es schreibt die Daten zunächst in eine temporäre Datei. Wenn der Persistenzprozess abgeschlossen ist, wird diese temporäre Datei verwendet, um die letzte Persistenz zu ersetzen. Zurückgegebene Dokumente. Während des gesamten Prozesses führt der Hauptprozess keine E/A-Vorgänge aus, was eine extrem hohe Leistung gewährleistet. Wenn eine Datenwiederherstellung in großem Umfang erforderlich ist und die Integrität der Datenwiederherstellung nicht sehr empfindlich ist, ist die RDB-Methode effizienter als die AOF-Methode . von hoher Effizienz. Der Nachteil von RDB besteht darin, dass Daten nach der letzten Persistenz verloren gehen können.

Die Funktion von Fork besteht darin, einen Prozess zu kopieren, der mit dem aktuellen Prozess identisch ist. Alle Daten (Variablen, Umgebungsvariablen, Programmzähler usw.) des neuen Prozesses haben die gleichen Werte wie der ursprüngliche Prozess, aber es ist ein brandneuer Prozess und dient als Unterprozess des ursprünglichen Prozesses

Versteckte Gefahren: Wenn der aktuelle Prozess eine große Datenmenge hat, dann ist die Datenmenge nach der Verzweigung * 2 Dies führt zu einer starken Belastung des Servers und verringert die Betriebsleistung.

Rdb speichert die dump.rdb-Datei

Im Test: Befehl „flushAll“ ausführen, Shutdown verwenden Wenn der Prozess direkt geschlossen wird, liest Redis die Datei dump.rdb automatisch, wenn sie zum zweiten Mal geöffnet wird. Bei der Wiederherstellung ist jedoch alles leer. (Der Grund dafür: Zum Zeitpunkt des Herunterfahrens speichert das Redis-System die leere dump.rdb, um die ursprüngliche Cache-Datei zu ersetzen. Wenn das Redis-System zum zweiten Mal geöffnet wird, wird daher automatisch die leere Wertedatei gelesen.)

RDB-Speichervorgang

Rdb ist ein komprimierter Snapshot des gesamten Speichers. Die Datenstruktur von RDB kann so konfiguriert werden, dass sie der Snapshot-Auslösung entspricht Der Standardwert ist 1 Änderung innerhalb von 1 Minute oder 10 Änderungen in 5 Minuten oder einmal in 15 Minuten. Wenn Sie die RDB-Persistenzstrategie deaktivieren möchten, legen Sie einfach keine Speicherung fest Anweisungen, oder übergeben Sie zum Speichern einen leeren String-Parameter. Das ist auch in Ordnung.

-----> Speicherbefehl: Speichern Sie das Operationsobjekt sofort

So lösen Sie einen RDB-Snapshot aus

Speichern: Beim Speichern nur speichern, andere Dinge ignorieren und alles blockieren.

Bgsave: Redis führt Snapshot-Vorgänge im Hintergrund aus. Während des Snapshot-Vorgangs kann es auch auf Client-Anfragen reagieren. Sie können den Zeitpunkt der letzten erfolgreichen Snapshot-Ausführung abrufen.

Durch die Ausführung des Fluhall-Befehls wird auch eine dump.rdb-Datei generiert, die jedoch leer ist.

So stellen Sie wieder her:

Verschieben Sie die Sicherungsdatei (dump.rdb) in das Redis-Installationsverzeichnis und starten Sie den Dienst.

Der Befehl Config get dir kann das abrufen Verzeichnis

So stoppen Sie

Methode zum dynamischen Stoppen von RDB-Speicherregeln: redis -cli config set save „“

AOF (Append Only File)

Zeichnen Sie jeden Schreibvorgang in Form eines Protokolls auf und zeichnen Sie alle von Redis ausgeführten Schreibanweisungen auf (Lesevorgänge werden nicht aufgezeichnet). Es können nur Dateien angehängt, aber nicht neu geschrieben werden. Die Datei wird gelesen, um die Daten zu rekonstruieren. Mit anderen Worten, wenn Redis neu gestartet wird, werden die Schreibanweisungen von vorne nach hinten entsprechend dem Inhalt des Protokolls ausgeführt Datei, um die Datenwiederherstellungsarbeiten abzuschließen.

======APPEND-NUR-MODUS=====

Aof aktivieren: appendonly ja (Standard ist nein)

Hinweis:

Bei der tatsächlichen Arbeit und Produktion kommt es häufig zu einer Dateibeschädigung (aof Dateibeschädigung, die durch Netzwerkübertragung oder andere Probleme verursacht wird)

Beim Serverstart tritt ein Fehler auf (aber die Datei dump.rdb ist vollständig), was darauf hinweist, dass die aof-Datei beim Start zuerst geladen wird

Lösung: Führen Sie die aus Befehl redis-check-aof --fix aof file [Felder automatisch prüfen und löschen, die nicht mit der aof-Syntax übereinstimmen]

Aof-Richtlinie

Appendfsync-Parameter:

Immer synchrone Persistenz wird bei jeder Datenänderung sofort auf der Festplatte aufgezeichnet, was zu einer schlechten Leistung, aber einer besseren Datenintegrität führt.
Everysec: Werkseinstellungsempfehlung, asynchroner Betrieb, Aufzeichnung jede Sekunde, Ausfallzeit nach einer Sekunde, Datenverlust
Nein: Niemals fsync: Daten zur Verarbeitung an das Betriebssystem übergeben. Schnellere und weniger sichere Option.

Umschreiben

Konzept: AOF verwendet die Methode zum Anhängen von Dateien, und die Dateien werden immer größer Wenn die Größe der AOF-Datei den festgelegten Schwellenwert überschreitet, komprimiert Redis automatisch den Inhalt der AOF-Datei und behält den minimalen Befehlssatz bei, der die Daten wiederherstellen kann. Sie können den Befehl bgrewirteaof verwenden.

Prinzip des Umschreibens: Wenn die AOF-Datei weiter wächst und groß wird, wird ein neuer Prozess gegabelt, um die Datei neu zu schreiben (d. h.
schreibt zuerst die temporäre Datei und benennt sie dann um) und durchläuft sie Der Speicher des neuen Prozesses verfügt über eine Set-Anweisung. Beim Umschreiben der AOF-Datei wird nicht der gesamte Inhalt der Speicherdatenbank mithilfe von Befehlen neu geschrieben Schnappschüsse.

Auslösemechanismus: Redis zeichnet die Größe der zuletzt neu geschriebenen AOF-Datei auf. Die Standardkonfiguration wird ausgelöst, wenn die AOF-Dateigröße nach der letzten Neuschreibung verdoppelt wird und die Datei größer als 64 MB (3G) ist

no-appendfsync-on-rewrite no: Ob Appendfsync während des Umschreibens verwendet werden kann. Verwenden Sie einfach die Standardeinstellung „no“, um die Datensicherheit zu gewährleisten.
auto-aof-rewrite-percentage-Mehrfacheinstellungsbasis value
auto-aof-rewrite-min-size Legen Sie die Basiswertgröße fest

Vorteile von AOF

Die Verwendung von AOF-Persistenz wird es ermöglichen Redis ist sehr langlebig: Sie können verschiedene Fsync-Strategien festlegen, z. B. kein Fsync, fsync jede Sekunde oder fsync jedes Mal, wenn ein Schreibbefehl ausgeführt wird. Die Standardrichtlinie von AOF besteht darin, einmal pro Sekunde zu fsyncen. Unter dieser Konfiguration kann Redis immer noch eine gute Leistung aufrechterhalten, und selbst wenn ein Fehler auftritt, geht höchstens eine Sekunde an Daten verloren (fsync wird in einem Hintergrundthread ausgeführt). so Der Hauptthread kann weiterhin hart daran arbeiten, Befehlsanfragen zu verarbeiten.

Bei der AOF-Datei handelt es sich um eine Protokolldatei, die nur zum Anhängen verwendet werden kann. Das Schreiben in die AOF-Datei erfordert daher keine Suche, auch wenn das Protokoll aus bestimmten Gründen unvollständige Befehle enthält (z. B. wenn die Festplatte beim Schreiben voll ist). Wenn das Schreiben auf halbem Weg stoppt usw.), kann das Tool redis-check-aof dieses Problem ebenfalls leicht beheben.

Redis kann die AOF automatisch im Hintergrund neu schreiben, wenn die AOF-Datei zu groß wird: Die neue AOF-Datei enthält nach dem Umschreiben den Mindestsatz an Befehlen, der zum Wiederherstellen des aktuellen Datensatzes erforderlich ist. Der gesamte Umschreibvorgang ist absolut sicher, da Redis während des Erstellungsprozesses einer neuen AOF-Datei weiterhin Befehle an die vorhandene AOF-Datei anhängt. Selbst wenn es während des Umschreibvorgangs zu einem Herunterfahren kommt, geht die vorhandene AOF-Datei nicht verloren. . Sobald die neue AOF-Datei erstellt wurde, wechselt Redis von der alten AOF-Datei zur neuen AOF-Datei und beginnt mit dem Anhängen an die neue AOF-Datei.

Die AOF-Datei speichert alle in der Datenbank ausgeführten Schreibvorgänge in geordneter Weise. Diese Schreibvorgänge werden im Format des Redis-Protokolls gespeichert, sodass der Inhalt der AOF-Datei sehr einfach zu lesen und zu analysieren ist Datei (Parse) ist auch sehr einfach. Das Exportieren (Exportieren) von AOF-Dateien ist ebenfalls sehr einfach: Wenn Sie beispielsweise versehentlich den FLUSHALL-Befehl ausführen, die AOF-Datei jedoch nicht überschrieben wurde, stoppen Sie einfach den Server und entfernen Sie den FLUSHALL-Befehl am Ende der AOF Datei und starten Sie Redis neu. Sie können den Datensatz in den Zustand vor der Ausführung von FLUSHALL zurückversetzen.

Nachteile von AOF

Bei demselben Datensatz ist die Größe von AOF-Dateien normalerweise größer als die von RDB-Dateien.

AOF kann je nach verwendeter Fsync-Strategie langsamer als RDB sein. Unter normalen Umständen ist die Fsync-Leistung pro Sekunde immer noch sehr hoch, und durch Deaktivieren von Fsync kann AOF selbst unter hoher Last so schnell wie RDB werden. Allerdings kann RDB bei der Verarbeitung großer Schreiblasten eine garantiertere maximale Latenz bieten.

Bei AOF gab es in der Vergangenheit einen solchen Fehler: Aufgrund bestimmter Befehle konnte beim erneuten Laden der AOF-Datei der Datensatz nicht in den ursprünglichen Zustand beim Speichern zurückversetzt werden. (Zum Beispiel hat der Blockierungsbefehl BRPOPLPUSH einmal einen solchen Fehler verursacht.)

Für diese Situation wurden der Testsuite Tests hinzugefügt: Sie generieren automatisch zufällige, komplexe Datensätze und laden sie neu, um sicherzustellen, dass alles funktioniert. Obwohl diese Art von Fehler in AOF-Dateien nicht häufig vorkommt, ist es im Vergleich dazu bei RDB fast unmöglich, einen solchen Fehler zu haben.

Redis-Daten sichern

Sichern Sie unbedingt Ihre Datenbank!

Festplattenfehler, Knotenfehler und andere Probleme können dazu führen, dass Ihre Daten verschwinden.

Redis ist sehr benutzerfreundlich für die Datensicherung, da Sie die RDB-Datei kopieren können, während der Server läuft: Sobald die RDB-Datei erstellt ist, werden keine Änderungen vorgenommen. Wenn der Server eine neue RDB-Datei erstellen möchte, speichert er zunächst den Inhalt der Datei in einer temporären Datei. Wenn die temporäre Datei geschrieben wird, verwendet das Programm rename(2), um die ursprüngliche RDB-Datei atomar durch die temporäre Datei zu ersetzen.

Das bedeutet, dass das Kopieren von RDB-Dateien jederzeit absolut sicher ist.

Empfehlung:

Erstellen Sie eine reguläre Aufgabe (Cron-Job), sichern Sie jede Stunde eine RDB-Datei in einem Ordner und sichern Sie sie alle Tag Sichern Sie eine RDB-Datei in einem anderen Ordner.

Stellen Sie sicher, dass die Snapshot-Backups über entsprechende Datums- und Uhrzeitinformationen verfügen. Verwenden Sie jedes Mal, wenn Sie das reguläre Aufgabenskript ausführen, den Befehl „find“, um abgelaufene Snapshots zu löschen: Sie können beispielsweise jede Stunde der letzten 48 Stunden behalten Snapshots: Sie können auch tägliche Snapshots für die letzten ein oder zwei Monate aufbewahren.

Sichern Sie die RDB mindestens einmal am Tag außerhalb Ihres Rechenzentrums oder zumindest außerhalb der physischen Maschine, auf der Sie den Redis-Server ausführen.

Disaster-Recovery-Backup

Das Disaster-Recovery-Backup von Redis bedeutet im Wesentlichen das Sichern von Daten und das Übertragen dieser Backups auf mehrere verschiedene externe Rechenzentren.

Disaster-Recovery-Backups können die Daten in einem sicheren Zustand halten, selbst wenn im Hauptrechenzentrum, in dem Redis ausgeführt wird und Snapshots generiert, ein schwerwiegendes Problem auftritt.

Einige Redis-Benutzer haben nicht viel Geld zu verschwenden, daher sind die folgenden einige praktische und kostengünstige Disaster-Recovery-Backup-Methoden:

Amazon S3 und andere Dienste wie S3 ist ein guter Ort, um ein Notfall-Backup-System aufzubauen. Der einfachste Weg besteht darin, Ihre stündlichen oder täglichen RDB-Backups zu verschlüsseln und nach S3 zu übertragen. Die Verschlüsselung der Daten kann mit dem Befehl gpg -c (symmetrischer Verschlüsselungsmodus) erfolgen. Denken Sie daran, Ihre Passwörter an verschiedenen, sicheren Orten aufzubewahren (Sie können sie beispielsweise an die wichtigsten Personen in Ihrer Organisation kopieren). Die gleichzeitige Verwendung mehrerer Speicherdienste zum Speichern von Datendateien kann die Datensicherheit verbessern.

Die Übertragung von Snapshots kann über SCP (Komponente von SSH) erfolgen. Das Folgende ist eine einfache und sichere Übertragungsmethode: Kaufen Sie einen VPS (Virtual Private Server) weit entfernt von Ihrem Rechenzentrum, installieren Sie SSH, erstellen Sie einen passwortlosen SSH-Client-Schlüssel und fügen Sie diesen Schlüssel zur Datei „authorized_keys“ des VPS hinzu, damit die Snapshot-Sicherung erfolgt Die Datei kann auf diesen VPS übertragen werden. Um die beste Datensicherheit zu gewährleisten, kaufen Sie für die Notfallwiederherstellung einen VPS von mindestens zwei verschiedenen Anbietern.

Es ist zu beachten, dass diese Art von Disaster-Recovery-System leicht scheitern kann, wenn es nicht sorgfältig gehandhabt wird.

Nach Abschluss der Dateiübertragung sollten Sie mindestens prüfen, ob die Größe der übertragenen Sicherungsdatei mit der Größe der ursprünglichen Snapshot-Datei übereinstimmt. Wenn Sie einen VPS verwenden, können Sie auch überprüfen, ob die Datei vollständig übertragen wurde, indem Sie die SHA1-Prüfsumme der Datei vergleichen.

Darüber hinaus benötigen Sie auch ein unabhängiges Alarmsystem, das Sie benachrichtigt, wenn die für die Übertragung von Sicherungsdateien verantwortliche Übertragung (Übertragung) fehlschlägt.

Redis Master-Slave-Replikation

Redis unterstützt die einfache und benutzerfreundliche Master-Slave-Replikationsfunktion, die den Slave-Server ermöglicht wird zu einer exakten Nachbildung des Master-Servers.

Hier sind einige wichtige Aspekte der Redis-Replikationsfunktionalität:

Redis verwendet asynchrone Replikation. Ab Redis 2.8 meldet der Slave-Server einmal pro Sekunde den Verarbeitungsfortschritt des Replikationsstreams an den Master-Server.

Ein Master-Server kann mehrere Slave-Server haben.

Nicht nur der Master-Server kann Slave-Server haben, sondern der Slave-Server kann auch einen eigenen Slave-Server haben, der eine Diagrammstruktur bilden kann.

Die Replikationsfunktion blockiert den Master-Server nicht: Auch wenn ein oder mehrere Slave-Server eine Erstsynchronisierung durchführen, kann der Master-Server weiterhin Befehlsanfragen verarbeiten.

Die Replikationsfunktion blockiert den Slave-Server nicht: Solange die entsprechenden Einstellungen in der Datei redis.conf vorgenommen werden, kann der Server die alte Version des Datensatzes verwenden, um Befehlsanfragen zu verarbeiten, auch wenn der Slave Der Server wird gerade initial synchronisiert.

Allerdings wird die Verbindungsanfrage während des Zeitraums blockiert, in dem die alte Version des Datensatzes vom Server gelöscht und die neue Version des Datensatzes geladen wird.

Sie können den Slave-Server auch so konfigurieren, dass er eine Fehlermeldung an den Client sendet, wenn die Verbindung zum Master-Server verloren geht.

Die Replikationsfunktion kann ausschließlich zur Datenredundanz verwendet werden oder die Skalierbarkeit verbessern, indem mehrere Slave-Server schreibgeschützte Befehlsanfragen verarbeiten: Beispielsweise kann der schwere SORT-Befehl die Ausführung dem untergeordneten Knoten überlassen .
Sie können die Replikationsfunktion verwenden, um dem Master-Server die Durchführung von Persistenzvorgängen zu ersparen: Schalten Sie einfach die Persistenzfunktion des Master-Servers aus und lassen Sie dann den Slave-Server Persistenzvorgänge durchführen.

Datensicherheit der Replikationsfunktion, wenn die Persistenz des Hauptservers deaktiviert ist.

Bei der Konfiguration der Redis-Replikationsfunktion wird dringend empfohlen, die Persistenzfunktion des Hauptservers zu aktivieren. Andernfalls sollte der bereitgestellte Dienst aufgrund von Latenz und anderen Problemen nicht automatisch aufgerufen werden.

Fall:

1. Angenommen, Knoten A ist der Hauptserver und die Persistenz ist deaktiviert. Und Knoten B und Knoten C kopieren Daten von Knoten A

2. Knoten A stürzt ab und startet dann Knoten A neu, indem er den Dienst automatisch hochzieht. Da die Persistenz von Knoten A deaktiviert ist, starten Sie neu Danach sind keine Daten mehr vorhanden

3. Knoten B und Knoten C kopieren Daten von Knoten A, aber die Daten von A sind leer, sodass die von ihnen gespeicherten Datenkopien gelöscht werden.

Wenn die Persistenz auf dem Hauptserver ausgeschaltet und gleichzeitig der automatische Pull-up-Prozess eingeschaltet ist, ist dies sehr gefährlich, selbst wenn Sentinel verwendet wird, um eine hohe Verfügbarkeit zu erreichen Redis. Da der Hauptserver möglicherweise so schnell hochgefahren wird, dass Sentinel nicht erkennt, dass der Hauptserver innerhalb des konfigurierten Heartbeat-Intervalls neu gestartet wurde, wird der oben beschriebene Datenverlustprozess trotzdem ausgeführt.

Datensicherheit ist jederzeit äußerst wichtig, daher sollte verhindert werden, dass der Hauptserver beim Ausschalten automatisch die Persistenz hochzieht.

Slave-Server-Konfiguration

Die Konfiguration eines Slave-Servers ist sehr einfach, fügen Sie einfach die folgende Zeile zur Konfigurationsdatei hinzu:
slaveof 192.168 .1.1 6379
Eine andere Methode besteht darin, den Befehl SLAVEOF aufzurufen, die IP und den Port des Hauptservers einzugeben und dann beginnt die Synchronisierung
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK

Schreibgeschützter Slave-Server

Ab Redis 2.6 unterstützt der Slave-Server den schreibgeschützten Modus, und dieser Modus ist der Standardmodus von der Slave-Server.
Der schreibgeschützte Modus wird durch die Option „slave-read-only“ in der Datei redis.conf gesteuert. Dieser Modus kann auch über den Befehl CONFIG SET aktiviert oder deaktiviert werden.

Der schreibgeschützte Slave-Server weigert sich, Schreibbefehle auszuführen, sodass Daten aufgrund von Betriebsfehlern nicht versehentlich auf den Slave-Server geschrieben werden.

Darüber hinaus führt die Ausführung des Befehls SLAVEOF NO ONE auf einem Slave-Server dazu, dass der Slave-Server die Replikationsfunktion deaktiviert und vom Slave-Server zurück zum Master-Server wechselt. Der ursprüngliche synchronisierte Datensatz wird nicht ausgeführt verworfen.

Mit der Funktion „SLAVEOF NO ONE wird den synchronisierten Datensatz nicht verwerfen“ kann bei einem Ausfall des Master-Servers der Slave-Server als neuer Master-Server verwendet werden, wodurch ein unterbrechungsfreier Betrieb gewährleistet wird.

Slave-Server-bezogene Konfiguration:

Wenn der Master-Server über die Option „requirepass“ ein Passwort festlegt, um den Synchronisierungsvorgang zu ermöglichen Damit der Slave-Server reibungslos funktioniert, müssen wir auch entsprechende Authentifizierungseinstellungen für den Slave-Server vornehmen.

Bei einem laufenden Server können Sie über den Client den folgenden Befehl eingeben:
config set masterauth
Um dieses Passwort dauerhaft festzulegen, können Sie es der Konfigurationsdatei hinzufügen:
masterauth

Der Master-Server führt nur Schreibvorgänge aus, wenn mindestens N Slave-Server vorhanden sind

Ab Redis 2.8 können Sie dies tun, um die Datensicherheit zu gewährleisten Konfigurieren Sie den Master-Server so, dass er den Schreibbefehl nur ausführt, wenn derzeit mindestens N Slave-Server verbunden sind.

Da Redis jedoch die asynchrone Replikation verwendet, werden die vom Master-Server gesendeten Schreibdaten möglicherweise nicht vom Slave-Server empfangen. Daher besteht weiterhin die Möglichkeit eines Datenverlusts.

So funktioniert diese Funktion:

Der Slave pingt den Master einmal pro Sekunde an und meldet den Replikationsfluss. Behandeln Sie die Situation.
Der Master-Server zeichnet auf, wann jeder Slave-Server das letzte Mal einen PING an ihn gesendet hat.

Benutzer können über die Konfiguration die maximale Netzwerklatenz (min-slaves-max-lag) und die minimale Anzahl von Slave-Servern festlegen, die zum Ausführen von Schreibvorgängen (min-slaves-to-write) erforderlich sind.

Wenn es mindestens Min-Slaves-to-Write-Slave-Server gibt und die Latenzwerte dieser Server weniger als Min-Slaves-Max-Lag-Sekunden betragen, führt der Master-Server den Schreibvorgang aus Vom Client angeforderter Vorgang.

Wenn andererseits die Bedingungen die durch min-slaves-to-write und min-slaves-max-lag angegebenen Bedingungen nicht erfüllen, wird der Schreibvorgang nicht ausgeführt und der Hauptserver wird ausgeführt Führen Sie die Anforderung aus. Der Client für den Schreibvorgang hat einen Fehler zurückgegeben.

Im Folgenden sind die beiden Optionen dieser Funktion und ihre erforderlichen Parameter aufgeführt:

min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>

Das Obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, dass er zum Lernen aller beiträgt. Weitere spannende Inhalte finden Sie in den entsprechenden Tutorial-Kolumnen auf der chinesischen PHP-Website! ! !

Das obige ist der detaillierte Inhalt vonEinführung in die Redis-Persistenz und den Master-Slave-Replikationsmechanismus. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!