In einem der vorherigen Blogs haben wir neue Funktionen behandelt, die in MariaDB 10.4 herauskommen. Wir haben dort erwähnt, dass in dieser Version eine neue Galera-Cluster-Version enthalten sein wird. In diesem Blogbeitrag gehen wir auf die Funktionen von Galera Cluster 26.4.0 (oder Galera 4) ein, werfen einen kurzen Blick darauf und untersuchen, wie sie sich auf Ihre Einrichtung bei der Arbeit mit MariaDB Galera Cluster auswirken.
Streaming-Replikation
Galera Cluster ist keineswegs ein Drop-in-Ersatz für eigenständiges MySQL. Die Art und Weise, wie die Writeset-Zertifizierung funktioniert, führte zu mehreren Einschränkungen und Grenzfällen, die die Migrationsfähigkeit in Galera Cluster ernsthaft einschränken können. Die drei häufigsten Einschränkungen sind...
- Probleme mit langen Transaktionen
- Probleme mit großen Transaktionen
- Probleme mit Hotspots in Tabellen
Es ist großartig zu sehen, dass Galera 4 die Streaming-Replikation einführt, die dazu beitragen kann, diese Einschränkungen zu verringern. Sehen wir uns den aktuellen Status etwas genauer an.
Lange laufende Transaktionen
In diesem Fall sprechen wir von Zeitangaben, die bei Galera definitiv problematisch sind. Das Wichtigste, was Sie verstehen müssen, ist, dass Galera Transaktionen als Writesets repliziert. Diese Schreibsätze werden auf den Mitgliedern des Clusters zertifiziert, wodurch sichergestellt wird, dass alle Knoten einen bestimmten Schreibsatz anwenden können. Das Problem ist, Sperren werden auf dem lokalen Knoten erstellt, sie werden nicht über den Cluster repliziert. Wenn Ihre Transaktion also mehrere Minuten dauert, bis sie abgeschlossen ist, und wenn Sie auf mehr als einen Galera-Knoten schreiben, wird es mit der Zeit immer wahrscheinlicher, dass dies aktiviert ist Einer der verbleibenden Knoten Einige Transaktionen ändern einige der Zeilen, die in Ihrer lang andauernden Transaktion aktualisiert wurden. Dies führt dazu, dass die Zertifizierung fehlschlägt und lang andauernde Transaktionen müssen rückgängig gemacht werden. Kurz gesagt, wenn Sie Schreibvorgänge an mehr als einen Knoten im Cluster senden, je länger die Transaktion ist, desto wahrscheinlicher ist es, dass die Zertifizierung aufgrund eines Konflikts fehlschlägt.
Hotspots
Damit meinen wir Zeilen, die häufig aktualisiert werden. Normalerweise handelt es sich um eine Art Zähler, der immer wieder aktualisiert wird. Der Schuldige des Problems ist derselbe wie bei langen Transaktionen - Zeilen werden nur lokal gesperrt. Auch hier gilt:Wenn Sie Schreibvorgänge an mehr als einen Knoten senden, ist es wahrscheinlich, dass derselbe Zähler gleichzeitig auf mehr als einem Knoten geändert wird, was zu Konflikten führt und die Zertifizierung fehlschlagen lässt.
Für diese beiden Probleme gibt es eine Lösung:Sie können Ihre Schreibvorgänge an nur einen Knoten senden, anstatt sie über den gesamten Cluster zu verteilen. Sie können dafür Proxys verwenden - ClusterControl setzt HAProxy und ProxySQL ein, beide können so konfiguriert werden, dass Schreibvorgänge nur an einen Knoten gesendet werden. Wenn Sie Schreibvorgänge nicht nur an einen Knoten senden können, müssen Sie akzeptieren, dass Sie von Zeit zu Zeit Zertifizierungskonflikte und Rollbacks sehen werden. Im Allgemeinen muss die Anwendung Rollbacks von der Datenbank verarbeiten können - daran führt kein Weg vorbei, aber es ist noch wichtiger, wenn die Anwendung mit Galera Cluster arbeitet.
Dennoch reicht das Senden des Datenverkehrs an einen Knoten nicht aus, um das dritte Problem zu lösen.
Große Transaktionen
Es ist wichtig zu beachten, dass das Writeset nur dann zur Zertifizierung gesendet wird, wenn die Transaktion abgeschlossen ist. Dann wird das Writeset an alle Knoten gesendet und der Zertifizierungsprozess findet statt. Dies führt zu Einschränkungen hinsichtlich der Größe der einzelnen Transaktion, da Galera sie beim Vorbereiten des Writesets im In-Memory-Puffer speichert. Zu große Transaktionen verringern die Clusterleistung. Daher wurden zwei Variablen eingeführt:wsrep_max_ws_rows, die die Anzahl der Zeilen pro Transaktion begrenzt (obwohl sie auf 0 gesetzt werden kann - unbegrenzt) und, was noch wichtiger ist:wsrep_max_ws_size, die auf 2 GB eingestellt werden kann. Die größte Transaktion, die Sie mit Galera Cluster ausführen können, ist also bis zu 2 GB groß. Außerdem müssen Sie bedenken, dass die Zertifizierung und Anwendung der großen Transaktion ebenfalls Zeit in Anspruch nimmt, was zu „Verzögerungen“ führt – Lesen nach Schreiben, das einen anderen Knoten trifft als den, an dem Sie die Transaktion ursprünglich ausgeführt haben, wird höchstwahrscheinlich zu falschen Daten führen, da dies der Fall ist Transaktion wird noch angewendet.
Galera 4 wird mit Streaming-Replikation geliefert, mit der all diese Probleme gemildert werden können. Der Hauptunterschied besteht darin, dass das Writeset jetzt in Teile aufgeteilt werden kann – es muss nicht mehr gewartet werden, bis die gesamte Transaktion abgeschlossen ist, bevor die Daten repliziert werden. Sie fragen sich vielleicht, wie die Zertifizierung in einem solchen Fall aussieht? Kurz gesagt, die Zertifizierung erfolgt im laufenden Betrieb – jedes Fragment wird zertifiziert und alle beteiligten Zeilen werden auf allen Knoten im Cluster gesperrt. Dies ist eine gravierende Änderung in der Funktionsweise von Galera - bisher wurden Sperren lokal erstellt, mit Streaming-Replikation werden Sperren auf allen Knoten erstellt. Dies hilft in den oben besprochenen Fällen – das Sperren von Zeilen beim Eintreffen von Transaktionsfragmenten trägt dazu bei, die Wahrscheinlichkeit zu verringern, dass die Transaktion zurückgesetzt werden muss. Lokal ausgeführte widersprüchliche Transaktionen können die benötigten Sperren nicht erhalten und müssen warten, bis die replizierende Transaktion abgeschlossen ist und die Zeilensperren freigibt.
Im Fall von Hotspots ist es mit Streaming-Replikation möglich, die Sperren auf allen Knoten zu erhalten, wenn die Zeile aktualisiert wird. Andere Abfragen, die dieselbe Zeile aktualisieren möchten, müssen warten, bis die Sperre aufgehoben wird, bevor sie ihre Änderungen ausführen.
Große Transaktionen profitieren von der Streaming-Replikation, da sie nicht mehr warten müssen, bis die gesamte Transaktion abgeschlossen ist, und sie werden auch nicht durch die Transaktionsgröße begrenzt – große Transaktionen werden in Fragmente aufgeteilt. Es hilft auch, das Netzwerk besser zu nutzen – anstatt 2 GB Daten auf einmal zu senden, können dieselben 2 GB Daten in Fragmente aufgeteilt und über einen längeren Zeitraum gesendet werden.
Es gibt zwei Konfigurationsoptionen für die Streaming-Replikation:wsrep_trx_fragment_size, die angibt, wie groß ein Fragment sein soll (standardmäßig ist es auf 0 gesetzt, was bedeutet, dass die Streaming-Replikation deaktiviert ist) und wsrep_trx_fragment_unit, die angibt, was das Fragment wirklich ist. Standardmäßig sind es Bytes, aber es können auch „Anweisungen“ oder „Zeilen“ sein. Diese Variablen können (und sollten) auf Sitzungsebene festgelegt werden, sodass der Benutzer entscheiden kann, welche bestimmte Abfrage mithilfe der Streaming-Replikation repliziert werden soll. Wenn Sie die Einheit auf „Anweisungen“ und die Größe auf 1 setzen, können Sie beispielsweise die Streaming-Replikation nur für eine einzelne Abfrage verwenden, die beispielsweise einen Hotspot aktualisiert.
Natürlich gibt es Nachteile beim Ausführen der Streaming-Replikation, hauptsächlich aufgrund der Tatsache, dass jetzt Sperren auf allen Knoten im Cluster vorgenommen werden. Wenn Sie schon lange gesehen haben, wie große Transaktionen zurückgesetzt werden, müssen solche Transaktionen jetzt auf allen Knoten zurückgesetzt werden. Offensichtlich besteht die beste Vorgehensweise darin, die Größe einer Transaktion so weit wie möglich zu reduzieren, um Rollbacks zu vermeiden, die Stunden dauern. Ein weiterer Nachteil besteht darin, dass aus Gründen der Wiederherstellung nach einem Absturz aus jedem Fragment erstellte Writesets auf allen Knoten in der Tabelle wsrep_schema.SR gespeichert werden, was sozusagen einen doppelten Schreibpuffer implementiert und die Belastung des Clusters erhöht. Daher sollten Sie sorgfältig entscheiden, welche Transaktion mit der Streaming-Replikation repliziert werden soll, und Sie sollten sich, solange dies möglich ist, an die Best Practices halten, kleine, kurze Transaktionen zu haben oder die große Transaktion in kleinere Stapel aufzuteilen.
Backup-Sperren
Schließlich können MariaDB-Benutzer von Backup-Sperren für SST profitieren. Die Idee hinter SST, das mit (für MariaDB) mariabackup ausgeführt wird, ist, dass der gesamte Datensatz im laufenden Betrieb übertragen werden muss, wobei Redo-Protokolle im Hintergrund gesammelt werden. Dann muss eine globale Sperre erworben werden, die sicherstellt, dass kein Schreibvorgang stattfindet, die endgültige Position des Redo-Protokolls muss erfasst und gespeichert werden. In der Vergangenheit wurde der Sperrteil für MariaDB mit FLUSH TABLES WITH READ LOCK ausgeführt, was seine Aufgabe erfüllte, aber unter hoher Last ziemlich schwer zu erlangen war. Es ist auch ziemlich schwer - nicht nur Transaktionen müssen auf die Freigabe der Sperre warten, sondern auch die Daten müssen auf die Festplatte geschrieben werden. Mit MariaDB 10.4 ist es jetzt möglich, eine weniger aufdringliche BACKUP-SPERRE zu verwenden, bei der keine Daten geleert werden müssen, sondern nur Commits für die Dauer der Sperre blockiert werden. Dies sollte weniger aufdringliche SST-Operationen bedeuten, was definitiv großartig zu hören ist. Jeder, der seinen Galera-Cluster im Notfallmodus auf einem Knoten betreiben musste und die Daumen drückte, dass SST den Cluster-Betrieb nicht beeinträchtigt, sollte mehr als erfreut sein, von dieser Verbesserung zu hören.
Kausale Lesevorgänge aus der Anwendung
Galera 4 hat drei neue Funktionen eingeführt, die dazu beitragen sollen, Unterstützung für kausale Lesevorgänge in den Anwendungen hinzuzufügen - WSREP_LAST_WRITTEN_GTID(), das die GTID des letzten vom Client durchgeführten Schreibvorgangs zurückgibt, WSREP_LAST_SEEN_GTID(), das die GTID der letzten beobachteten Schreibtransaktion zurückgibt durch den Client und WSREP_SYNC_WAIT_UPTO_GTID(), wodurch der Client blockiert wird, bis die an die Funktion übergebene GTID auf dem Knoten festgeschrieben ist. Sicher, Sie können bereits jetzt kausale Lesevorgänge in Galera erzwingen, aber durch die Nutzung dieser Funktionen wird es möglich sein, sicheres Lesen nach dem Schreiben in den Teilen der Anwendung zu implementieren, in denen es benötigt wird, ohne Änderungen an der Galera-Konfiguration vornehmen zu müssen.
Upgrade auf MariaDB Galera 10.4
Wenn Sie Galera 4 ausprobieren möchten, ist es im neuesten Release Candidate für MariaDB 10.4 verfügbar. Gemäß der MariaDB-Dokumentation gibt es derzeit keine Möglichkeit, ein Live-Upgrade von 10.3 Galera auf 10.4 durchzuführen. Sie müssen den gesamten 10.3-Cluster stoppen, auf 10.4 aktualisieren und dann erneut starten. Dies ist ein ernsthafter Blocker und wir hoffen, dass diese Einschränkung in einer der nächsten Versionen entfernt wird. Es ist von größter Bedeutung, die Option für ein Live-Upgrade zu haben, und dafür müssen sowohl MariaDB 10.3 als auch MariaDB 10.4 im selben Galera-Cluster koexistieren. Eine andere Möglichkeit, die ebenfalls geeignet sein kann, ist die Einrichtung einer asynchronen Replikation zwischen altem und neuem Galera-Cluster.
Wir hoffen sehr, dass Ihnen dieser kurze Überblick über die Funktionen von MariaDB 10.4 Galera Cluster gefallen hat. Wir freuen uns darauf, die Streaming-Replikation in echten Live-Produktionsumgebungen zu sehen. Wir hoffen auch, dass diese Änderungen dazu beitragen werden, die Akzeptanz von Galera noch weiter zu steigern. Schließlich löst die Streaming-Replikation viele Probleme, die Menschen daran hindern können, zu Galera zu migrieren.
