Ich habe 5 dedizierte Server (identische Maschinen: 32 Kerne, 96 GB RAM, SSD-Laufwerke im RAID und Gigabit-Ethernet-Verbindung), die mit Percona XtraDB Cluster konfiguriert sind.
Es gibt ein wiederkehrendes Problem, das zu einer erheblichen Verlangsamung des Clusters führt, die normalerweise etwa 30 bis 60 Sekunden dauert. Manchmal bleibt er jedoch bis zu 5 bis 10 Minuten hängen.
Das System wird für ein vielbeschäftigtes Netzwerk von Websites verwendet und ich verwende auf jedem Webserver einen MySQL-Proxy, um den Datenverkehr zur Datenbank auszugleichen.
Das Problem tritt nicht auf, wenn nur ein Knoten aktiviert ist. Mit jedem hinzugefügten Knoten nimmt die Intensität des Problems zu (Zeitraum, in dem die Abfragen verlangsamt/gesperrt sind), bis es bei 4 aktiven Knoten unerträglich wird (der Cluster kann sich an diesem Punkt nicht mehr automatisch wiederherstellen).
Hier sind die detaillierten Symptome:
- Alle 5 bis 15 Minuten bleiben alle Schreibabfragen (INSERTs/UPDATEs) in der Warteschlange jedes Knotens hängen. Einige der Abfragen werden nach 45-50 Sekunden abgefertigt, während andere komplett blockiert sind.
- Meistens ist der Cluster nach 30 bis 60 Sekunden irgendwie in der Lage, aufzuholen und die Abfragen innerhalb von 1-2 Sekunden schnell zu versenden.
- Manchmal ist der Cluster nicht in der Lage, diese feststeckenden Abfragen automatisch zu verarbeiten, und ich muss die am stärksten frequentierten Websites manuell deaktivieren, damit die Belastung verringert wird und der Cluster nach etwa 30 Sekunden praktisch keiner Belastung wieder in der Lage ist, alle Abfragen zu verarbeiten.
Die Fehlerprotokolle sind normalerweise sauber und enthalten keine Fehlermeldungen vor oder nach der Verlangsamung. Selten erhalte ich so etwas (vielleicht 1 von 10 Malen):
130906 9:53:27 [Hinweis] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp://0.0.0.0:4567') Aktivieren der Anforderung einer Nachrichtenweiterleitung, nicht aktive Peers: tcp://IPOFONEOFTHENODES
130906 9:53:27 [Hinweis] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp://0.0.0.0:4567') Deaktivieren der Anforderung eines Nachrichten-Relays
Normalerweise habe ich unter normaler Last eine wsrep_cert_deps_distance von etwa 400. Sobald die Verlangsamung beginnt, erhöht sich die wsrep_cert_deps_distance langsam bis in den Bereich von 2k-3k (wenn sie die 3k-Marke erreicht, muss ich die Anwendung manuell deaktivieren, sonst kann sich der Cluster nicht selbst wiederherstellen).
Beim Monitoring mit mytop und atop stelle ich keine hohe Belastung des Servers oder des MySQL-Prozesses fest. Die CPU-Auslastung ist sowohl im Normalbetrieb als auch während der Verlangsamungen immer relativ niedrig (etwa 25 % des Maximums). Die I/O-Auslastung ist in Ordnung, viel RAM frei, vmcom unter dem Limit.
Ich verwende myq_status, um den Cluster auf jedem Knoten in Echtzeit zu überwachen, und Folgendes passiert:
- Die Variable wsrep_flow_control_paused steht immer auf 0,0, auch wenn es zu Verlangsamungen kommt.
- Es treten keine wsrep_local_bf_aborts oder wsrep_local_cert_failures auf.
- Auf jedem Knoten beträgt die ausgehende Replikation normalerweise 0 und steigt auf 200–300, wenn die Verlangsamung auftritt.
- Die eingehende Replikation ist auf jedem Knoten immer 0 (selten 1, aber das passiert auch bei normaler Belastung). Das verwirrt mich, da es im Cluster anscheinend keinen langsamen Knoten gibt.
- 10-15 Sekunden nach Beginn der Verlangsamung werden die gesendeten und empfangenen Operationen und Bytes auf jedem Knoten auf 0 gesetzt. Sie bleiben ein oder zwei Sekunden lang auf 0, dann erfolgt in der nächsten Sekunde eine erhöhte Anzahl von Operationen und Bytes, verbunden mit einer hohen Anzahl von „oooe“-Operationen (Out-of-Order-Execution). Dies wiederholt sich alle paar Sekunden, bis der Server wieder normal läuft.
Hier sind die Details der Tests, die ich durchgeführt habe, um das Problem zu beheben (ohne Erfolg …):
- Ich habe zuerst das Netzwerk überprüft: Die Server befinden sich im selben Rack mit einem dedizierten Gigabit-Netzwerk und alles scheint einwandfrei zu funktionieren, ohne Paketverlust oder andere offensichtliche Netzwerkprobleme.
- Ich habe die Bandbreitennutzung überprüft: Jeder Knoten nutzt durchschnittlich 30 bis 100 MBit/s (Megabit) Bandbreite. Ich überprüfe in Echtzeit mit „iftop“ und während das Problem auftritt, ist die Bandbreitennutzung normalerweise geringer als der Durchschnitt (15 bis 30 MBit/s). Während der Synchronisierung eines Knotens steigt die Bandbreite auf 800–900 MBit/s (wie es sein sollte), daher glaube ich nicht, dass das Netzwerk gesättigt ist.
- Ich habe eine Kombination aller Knoten ausprobiert, um sicherzustellen, dass ein bestimmter Knoten alle anderen beeinflusst: Das Problem ist immer vorhanden, egal welchen Knoten ich deaktiviere oder verwende. Das Problem hängt immer mit der Anzahl der gleichzeitig aktiven Knoten zusammen.
Hat jemand schon einmal ein ähnliches Problem gehabt? Vielen Dank im Voraus!