Einen Schreibzugriff kann man nicht lastverteilen.
Identische Datenbankknoten sehen nach vervielfachter Schreibkapazität aus. Verteilen Sie Ihre Schreibzugriffe darauf, und das Cluster produziert Deadlocks. Das Design, das funktioniert.
In diesem Artikel 2 Abschnitte
- Der intuitive Cluster-Aufbau: identische Knoten, ein Load Balancer, alles per Round-Robin. Es sieht nach vervielfachter Kapazität aus.
- Unter völlig normaler Last liefert er Deadlock-Fehler an Redakteure mitten im Veröffentlichen, ohne einen Locking-Bug irgendwo im Code. Zwei Redakteure, zwei Knoten, eine heiße Zeile, und die Konfliktprüfung des Clusters wirft einen von beiden zurück.
- Die kontraintuitive Lösung: Jeder Schreibzugriff geht an einen gewählten Knoten, und nur die Lesezugriffe fächern sich auf.
- Die Pointe, die «aber ist verteilen nicht schneller?» beantwortet: Das Schreibvolumen ist selten die Grenze. Lesekapazität ist das, was skaliert, und die Fehler verschwinden.
Sie haben ein Datenbank-Cluster gekauft. Niemand kauft mehrere Exemplare einer Sache, um eines zu benutzen, also schreibt sich die Load-Balancer-Konfiguration praktisch von selbst: alles per Round-Robin über jeden Knoten. Die Überzeugung darunter ist einfach: Eine einzelne Abfrage wird nicht schneller, aber viele werden es, aufgeteilt auf die Maschinen. Es klingt offensichtlich richtig. Es ist auch die häufigste Art, auf die wir diese Klasse von Cluster falsch eingesetzt sehen.
Der Bug, der nicht im Code steckt
Unter gewöhnlicher Last drücken Redakteure gelegentlich auf Speichern und bekommen über das CMS einen rohen Datenbankfehler zurückgereicht: deadlock found. Er tritt sporadisch auf und ist schwer zu reproduzieren, und noch so viel Lesen des Anwendungscodes wird ihn nicht finden, denn der Bug steckt nicht im Code.
Die Workload, die zur Waffe wird, ist eine gewöhnliche. Ein CMS schreibt bei fast jeder Aktion eine Handvoll global benannter Konfigurationszeilen neu. Ein SEO-Plugin baut bei jedem Speichern seine Sitemap neu. Login-Zeitstempel und Aufrufzähler fassen alle dieselben heißen Zeilen an. Round-Robin streut diese konkurrierenden Schreibzugriffe über jeden Knoten. Jeder Knoten nimmt seinen eigenen Schreibzugriff lokal an, und dann fängt der Zertifizierungsschritt des Clusters die Kollision beim Commit ab und wirft sie einem Client zurück, der nichts falsch gemacht hat. Zwei Redakteure, zwei Knoten, dieselbe Zeile: Fehler 1213.
Ein Deadlock unter normaler Last, auf einem Cluster, ohne irgendein Locking-Muster in der Anwendung, ist ein Routing-Symptom. Die Workload ist nicht falsch. Die Topologie ist es.
Ein Writer für die Sicherheit, die Lesezugriffe auffächern
Verschwendet es die anderen Knoten, alle Schreibzugriffe auf einen zu leiten? Nein. Lesezugriffe verteilen sich gleichmäßig über das Cluster, und jeder Schreibzugriff geht an den einen gewählten Writer. Der Round-Robin-Instinkt hat bei den Lesezugriffen recht und bei den Schreibzugriffen unrecht. Single-Writer-Routing behält die Hälfte, die stimmt, und löscht die Fehler, die die andere Hälfte erzeugt. Wenn Ihr erster Instinkt auf einem ausgelasteten Cluster ist, hochzuskalieren, lautet die Schwesterlektion, dass der richtige Zug oft das Gegenteil ist (kleiner dimensionieren, nicht größer).
1213
1
“Ein Cluster ist multi-primary-fähig und single-writer-sicher. Das sind verschiedene Sätze.”
Wenn Sie ein Cluster mit verteilten Lesezugriffen betreiben, finden Sie heraus, wo Ihre Schreibzugriffe tatsächlich landen. Wenn die Antwort «wohin der Balancer sie gerade schickt» lautet, sind Sie einen ausgelasteten Nachmittag davon entfernt, aus Ihrem eigenen Erfolg Deadlocks zu produzieren. Die Prüfung kostet einen Blick in die Konfiguration. Die Lösung ist eine Routing-Regel, kein Rewrite.
Klare Antworten
Warum bekomme ich auf meinem Galera- oder PXC-Cluster unter normaler Last Deadlock-Fehler (1213)?+
Wenn in Ihrem Code kein Locking-Bug steckt, prüfen Sie das Schreib-Routing. Über Knoten gestreute Schreibzugriffe kollidieren bei der Zertifizierung auf heißen Zeilen, und das Cluster meldet die Kollision einem unschuldigen Client als Deadlock. Leiten Sie jeden Schreibzugriff an einen Knoten, und die ganze Fehlerklasse verschwindet.
Verschwendet es nicht mein Cluster, alle Schreibzugriffe an einen Knoten zu schicken?+
Schreibzugriffe sind fast nie der Engpass. Lesezugriffe sind das Volumen. Mit Single-Writer-Routing verteilen sich die Lesezugriffe weiterhin über jeden Knoten, und der Schreibdurchsatz ändert sich nicht, weil im Effekt immer ein Knoten die gesamte Schreibarbeit gemacht hat.
Kann ein Galera-Cluster Multi-Master-Schreibzugriffe?+
Es ist fähig, Schreibzugriffe auf jedem Knoten anzunehmen, und es ist sicher, wenn es nicht konkurrierende Schreibzugriffe auf heiße Zeilen von mehreren Knoten gleichzeitig zertifizieren muss. Multi-primary-fähig, single-writer-sicher. Nutzen Sie die Fähigkeit für Failover, nicht für Lastverteilung.
Wie skaliere ich dann Datenbank-Schreibzugriffe?+
Beweisen Sie zuerst, dass Sie es müssen: Messen Sie das Schreibvolumen gegen die Reserve des einzelnen Writers, die neben den Lesezugriffen meist ein Rundungsfehler ist. Echte Schreibskalierung ist Sharding- oder Workload-Redesign-Terrain, keine Load-Balancer-Einstellung.
Was leitet Lese- und Schreibzugriffe unterschiedlich?+
Eine Proxy-Schicht, die das Datenbankprotokoll spricht, kann sie trennen: Lesezugriffe fächern sich auf, Schreibzugriffe werden an den gewählten Writer gebunden, und ein Failover wählt automatisch einen neuen Writer. Wir betreiben dieses Muster in Produktion: ProxySQL vor Percona XtraDB Cluster.
Sehen Sie Deadlocks, die Sie in Ihrem Code nicht finden?
Schicken Sie uns nur den Fehler und wie Ihr Cluster verteilt ist. Wenn es die Topologie ist, zeigen wir es Ihnen und beheben es im Routing, nicht in Ihrer Anwendung.
Mit einem Ingenieur sprechenSie haben das Ende erreicht.
Setzen Sie das Gelesene um
Was betreiben Sie?
Erzählen Sie uns von Workload, Traffic und Anforderungen an die Wiederherstellung. Beginnen Sie mit dem Server-Konfigurator oder besprechen Sie die Details mit einem Ingenieur.
Geschrieben von den Ingenieuren, die die beschriebene Infrastruktur bauen und betreiben.Mit einem Ingenieur sprechen