Redis Cluster ist eine erweiterte Version von Redis, die verteilt ist und Single Points of Failure zulässt. Der Redis-Cluster verfügt nicht über den wichtigsten oder zentralen Knoten. Eines der Hauptziele dieser Version ist der Entwurf einer linear skalierbaren Funktion (Knoten können nach Belieben hinzugefügt und gelöscht werden).
Dieser Artikel stellt hauptsächlich den relevanten Inhalt einer detaillierten Analyse von Redis-Clusterfehlern vor. Ich hoffe, dass er allen helfen kann.
Fehlersymptome:
Anzeigeaufforderungen auf Geschäftsebene, dass die Redis-Abfrage fehlgeschlagen ist
Clusterzusammensetzung:
3 Master und 3 Slaves, jeder Knoten hat 8 GB Daten
Maschinenverteilung:
Im selben Rack,
xx.x.xxx.199
xx.x.xxx.200
xx.x.xxx.201
Redis-Server-Prozessstatus:
Durch den Befehl ps -eo pid,lstart | wurde
festgestellt, dass der Prozess erfolgreich war 3 Monate ununterbrochen ausgeführt
Der Knotenstatus des Clusters vor dem Ausfall:
xx.x.xxx.200:8371(bedab2c537fe94f8c0363ac4ae97d56832316e65) Master
xx.x.xxx.199:8373(792020fe66c00ae56e27cd7a048ba6bb2b67adb6) Slave
xx.x.xxx.201:8375(5ab4f85306da6d633e4834b4d3327f45af02171b) Master
xx.x.xxx.201:8372(826607654f5ec81c3756a4a21f357e644efe605a) Sklave
xx.x.xxx.199:8370(462cadcb41e635d460425430d318f2fe464665c5) Master
xx.x.xxx.200:8374(1238085b578390f3c8efa30824fd9a4baba10ddf) Slave
------- -------------------------Das Folgende ist die Protokollanalyse----------------- ---- ----------------
Schritt 1:
Masterknoten 8371 verliert die Verbindung mit Slave-Knoten 8373 :
46590:M 09 Sep 18:57:51.379 # Verbindung mit Slave xx.x.xxx.199:8373 verloren.
Schritt 2:
Der Masterknoten 8370/8375 stellt fest, dass 8371 verloren gegangen ist:
42645:M 09. September 18:57:50.117 * Markiert den Knoten bedab2c537fe94f8c0363ac4ae97d56832316e65 als fehlerhaft (Quorum. erreicht).
Schritt 3:
Slave-Knoten 8372/8373/8374 hat Master-Knoten 8375 mit der Meldung erhalten, dass 8371 den Kontakt verloren hat:
46986:S 09 Sep 18:57:50.120 * FAIL-Meldung empfangen von. 5ab4f85306da6d633e4834b4d3327f45af 02171b über bedab2c 537fe94f8c0363ac4ae97d56832316e65
Schritt 4:
Masterknoten 8370/8375 autorisiert 8373 zum Upgrade auf Masterknotenübertragung:
42645:M 09 Sep 18:57:51.055 # Failover-Authentifizierung gewährt bis 792020fe66c00ae56e27cd7a048ba6bb2b67adb6 für Epoche 16
Schritt 5:
Der ursprüngliche Masterknoten 8371 ändert seine Konfiguration und wird zum Slaveknoten von 8373:
46590:M. 09 Sept 18:57:51.488 # Konfigurationsänderung erkannt. Ich werde als Replikat von 792020fe66c00ae56e27cd7a048ba6bb2b67adb6 neu konfiguriert :
42645:M 09 Sep 18:57:51.522 * FAIL-Status für Knoten bedab2c537fe94f8c0363ac4ae97d56832316e65 löschen: Master ohne Slots ist wieder erreichbar. , die ersten vollständigen Synchronisationsdaten:
4255:M 09 Sep 18:57:51.906 * Vollständige Neusynchronisierung vom Slave xx.x.xxx.200:83714255:M 09. Sep. angefordert 18:57:51.906 * BGSAVE für SYNC mit Ziel gestartet: Festplatte4255:M 09. Sep 18:57:51.941 * Hintergrundspeicherung gestartet durch PID 5230
8371 Log::
46590:S 09. September 18:57:51.948 * Vollständige Neusynchronisierung vom Master: d7751c4ebf1e63d3baebea1ed409e0e7243a4423:44072182699 3
Schritt 8:
Masterknoten 8370/8375 Entscheidung 8 373 (neuer Besitzer) Kontakt verloren:
42645:M 09 Sep 18:58:00.320 * Knoten 792020fe66c00ae56e27cd7a048ba6bb2b67adb6 als fehlerhaft markieren ( Quorum erreicht) .
Schritt 9:
Masterknoten 837 0/8375Urteil 8373 (neuer Master) wiederhergestellt:
Schritt 10:
Der BGSAVE-Vorgang ist erforderlich, damit der Masterknoten 8373 abgeschlossen werden kann Vollständige Synchronisierung:
5230:C 09 Sep 18:59:01.491 * RDB: 7112 MB Speicher, der von Copy-on-Write verwendet wird4255:M 09 Sep 18:59:01.877 * Hintergrundspeicherung erfolgreich beendet
Schritt 11:
Slave-Knoten 8371 beginnt, Daten vom Master-Knoten 8373 zu empfangen: 46590:S 09 Sep 18:59:02.263 * MASTER <-> SLAVE-Synchronisierung: Empfang von 2657606930 Bytes vom Master
Schritt 12:
Master-Knoten 8373 stellt fest, dass der Slave-Knoten 8371 den Ausgabepuffer eingeschränkt hat:
4255:M 09 Sep 19:00:19.015 # Verbindung mit Slave xx.x.xxx.200: 8371 verloren.
Schritt 13:
Slave-Knoten 8371 konnte die Daten vom Master-Knoten 8373 nicht synchronisieren, die Verbindung wurde unterbrochen und die erste vollständige Synchronisierung schlug fehl:
46590:S 09. September 19:00 :19.018 # E/A-Fehler beim Versuch, mit MASTER zu synchronisieren: Verbindung verloren
46590:S 09. September 19:00:20.102 * Verbindung zu MASTER xx.x.xxx.199:8373
46590:S 09. September 19 :00 :20.102 * MASTER <-> SLAVE-Synchronisierung gestartet
Schritt 14:
Synchronisierung ab Knoten 8371 neu starten, die Verbindung ist fehlgeschlagen und die Anzahl der Verbindungen des Masterknotens 8373 ist voll Up:
46590:S 09. Sep. 19:00:21.103 * Verbindung zu MASTER xx.x.xxx.199:8373
46590:S 09. Sep. 19:00:21.103 * MASTER < ;-> SLAVE-Synchronisierung gestartet
46590:S 09. September 19:00:21.104 * Nicht blockierende Verbindung für SYNC hat das Ereignis ausgelöst.
46590:S 09. September 19:00:21.104 # Fehler bei der Antwort auf PING vom Master : '-ERR maximale Anzahl von Clients erreicht'
Schritt 15:
Slave-Knoten 8371 verbindet sich erneut mit Master-Knoten 8373 und startet zum zweiten Mal die vollständige Synchronisierung:
8371 log:
46590:S 09 Sep 19:00:49.175 * Verbindung zu MASTER xx.x.xxx.199:8373
46590:S 09 Sep 19:00:49.175 * MASTER <-> ; SLAVE-Synchronisierung gestartet
46590:S 09. September 19:00:49.175 * Nicht blockierende Verbindung für SYNC hat das Ereignis ausgelöst.
46590:S 09. September 19:00:49.176 * Master hat auf PING geantwortet, die Replikation kann fortgesetzt werden. ..
46590: S 09. September 19:00:49.179 * Teilweise Neusynchronisierung nicht möglich (kein zwischengespeicherter Master)
46590:S 09. September 19:00:49.501 * Vollständige Neusynchronisierung vom Master: d7751c4ebf1e63d3baebea1ed409e0e7243a4423:44 078076345 4
8373 log:
4255 :M 09 Sep 19:00:49.176 * Slave xx.x.xxx.200:8371 bittet um Synchronisierung
4255:M 09 Sep 19:00:49.176 * Vollständige Neusynchronisierung vom Slave angefordert x 18413
18413:C 09. September 19:01:52.466 * DB auf Festplatte gespeichert
18413:C 09. September 19:01:52.620 * RDB: 2124 MB Speicher, der von Copy-on-Write verwendet wird
4255 :M 09. September 19:01: 53.186 * Hintergrundspeicherung mit Erfolg beendet
Daten von Knoten 8371 erfolgreich synchronisiert und mit dem Laden des Speichers begonnen: 46590:S 09.09.19: 01:53.190 * MASTER <-> SLAVE-Synchronisierung: 2637183250 Bytes vom Master empfangen
46590:S 09.09. 19:04:51.485 * MASTER <-> SLAVE-Synchronisierung: Alt löschen Daten
46590:S 09 Sep 19:05:58.695 * MASTER <-> SLAVE sync: DB in Speicher laden
Cluster kehrt zum Normalzustand zurück: 42645 ; Es dauerte 7 Minuten:
46590:S 09. September 19:08:19.303 * MASTER <-> Mit Erfolg abgeschlossen
8371 Grund für Kontaktverlust Analyse:
, was der Grund dafür war, dass der Knoten den Kontakt verloren hat:
2016/9/9 18:57:43 Ausführung des KEYS-Befehls starten 2016/9/9 18:57:50 8371 wurde als getrennt eingestuft (Redis-Protokoll)
2016/9 /9 18:57:51 KEYS-Befehl abgeschlossen
Zusammenfassend gibt es folgende Probleme:
1 Cluster-Node-Timeout-Einstellung, langsame Abfrage von KEYS führte dazu, dass der Cluster-Beurteilungsknoten 8371 den Kontakt verlor
3. Aufgrund der Einschränkung beim Konfigurieren des Client-Output-Buffer-Limits ist die erste vollständige Synchronisierung fehlgeschlagen
Aufgrund eines Problems mit dem Verbindungspool von Der PHP-Client war hektisch mit dem Server verbunden, was zu einem Effekt führte, der einem SYN-Angriff ähnelte.
5 Nachdem die erste vollständige Synchronisierung fehlgeschlagen war, dauerte es 30 Sekunden, bis der Slave-Knoten die Verbindung herstellte Stellen Sie erneut eine Verbindung zum Masterknoten her (die maximale Anzahl von Verbindungen wird um 1 W überschritten)
Ergreifen Sie Maßnahmen:
# The syntax of every client-output-buffer-limit directive is the following: # # client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds> # # A client is immediately disconnected once the hard limit is reached, or if # the soft limit is reached and remains reached for the specified number of # seconds (continuously). # So for instance if the hard limit is 32 megabytes and the soft limit is # 16 megabytes / 10 seconds, the client will get disconnected immediately # if the size of the output buffers reach 32 megabytes, but will also get # disconnected if the client reaches 16 megabytes and continuously overcomes # the limit for 10 seconds. # # By default normal clients are not limited because they don't receive data # without asking (in a push way), but just after a request, so only # asynchronous clients may create a scenario where data is requested faster # than it can read. # # Instead there is a default limit for pubsub and slave clients, since # subscribers and slaves receive data in a push fashion. # # Both the hard or the soft limit can be disabled by setting them to zero. client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60
1. Reduzieren Sie die einzelne Instanz auf weniger als 4G, sonst dauert der Master-Slave-Schalter lange
2 Passen Sie den Parameter „client-output-buffer-limit“ an und verhindern Sie, dass die Synchronisierung fehlschlägt die Mitte
3. Cluster-Node-Timeout anpassen, das nicht weniger als 15 Sekunden betragen darf
4. Verbieten Sie alles, was länger als Cluster-Node-Timeout dauert , weil es zu einem Master-Slave-Wechsel führen wird
5. Beheben Sie die verrückte Verbindungsmethode des Clients, die dem SYN-Angriff ähnelt
Vollständige Aufzeichnung der Redis-Cluster-Konstruktion
Das obige ist der detaillierte Inhalt vonAnalyse zum Ausfall des Redis-Clusters. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
Was sind die vier Big-Data-Analysetools?
statistische Analyse
Häufig verwendete Datenbanksoftware
Was sind In-Memory-Datenbanken?
Welches hat eine schnellere Lesegeschwindigkeit, Mongodb oder Redis?
So verwenden Sie Redis als Cache-Server
Wie Redis die Datenkonsistenz löst
Wie stellen MySQL und Redis die Konsistenz beim doppelten Schreiben sicher?
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
