Analyse zum Ausfall des Redis-Clusters

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:

8373 log::

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:

60295:M 09 Sep 18:58:18.181 * Löschen FAIL-Status für Knoten 792020fe66c00ae56e27cd7a048ba6bb2b67adb6: ist wieder erreichbar und nach einiger Zeit bedient niemand mehr seine Slots.

Schritt 10:

Der BGSAVE-Vorgang ist erforderlich, damit der Masterknoten 8373 abgeschlossen werden kann Vollständige Synchronisierung:

5230:C 09 Sep 18:59:01.474 * DB auf Festplatte gespeichert

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 e09be6022d700e04aeaa85a5f42fdcb2 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.014 # Client-ID =14259015 addr=xx.x.xxx.200:21772 fd=844 name= age=148 im Leerlauf =148 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl= 16349 oll=4103 omem=95944066 events=rw cmd=psync soll so schnell wie möglich geschlossen werden, um die Ausgabe zu beheben Puffergrenzen.

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 e09be6022d700e04aeaa85a5f42fdcb2 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

Schritt 16:

Daten von Knoten 8371 erfolgreich synchronisiert und mit dem Laden des Speichers begonnen: 46590:S 09.09.19: 01:53.190 * MASTER e09be6022d700e04aeaa85a5f42fdcb2 SLAVE-Synchronisierung: 2637183250 Bytes vom Master empfangen
46590:S 09.09. 19:04:51.485 * MASTER e09be6022d700e04aeaa85a5f42fdcb2 SLAVE-Synchronisierung: Alt löschen Daten
46590:S 09 Sep 19:05:58.695 * MASTER e09be6022d700e04aeaa85a5f42fdcb2 SLAVE sync: DB in Speicher laden

Schritt 17:

Cluster kehrt zum Normalzustand zurück: 42645 ; Es dauerte 7 Minuten:
46590:S 09. September 19:08:19.303 * MASTER e09be6022d700e04aeaa85a5f42fdcb2 Mit Erfolg abgeschlossen

8371 Grund für Kontaktverlust Analyse:

Da sich mehrere Maschinen im selben Rack befinden, ist eine Netzwerkunterbrechung unwahrscheinlich, daher habe ich die langsame Abfrage überprüft Loggen Sie sich über den Befehl SLOWLOG GET ein und stellen Sie fest, dass ein Befehl KEYS ausgeführt wurde, der 8,3 Sekunden dauerte. Nach Überprüfung der Clusterknoten-Timeout-Einstellung wurde festgestellt, dass er 5 Sekunden betrug (Cluster-Node-Timeout 5000)

, was der Grund dafür war, dass der Knoten den Kontakt verloren hat:

Der Client hat einen Befehl ausgeführt, der 8,3 Sekunden gedauert 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

2 Aufgrund des Kontaktverlusts von 8371 wurde 8373 zum Master hochgestuft und die Master-Slave-Synchronisierung gestartet

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)

Über den Parameter „client-output-buffer-limit“:

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&#39;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

Verwandte Empfehlungen:

Vollständige Aufzeichnung der Redis-Cluster-Konstruktion

Detaillierte Erläuterung des Wissens über die Redis-Cluster-Spezifikation

Redis-Cluster-Praxis

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!