MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Tipps für die Migration von MySQL Replication zu MySQL Galera Cluster 4.0

Wir haben zuvor über Neuigkeiten in MySQL Galera Cluster 4.0, Umgang mit großen Transaktionen mit Streaming-Replikation und MariaDB 10.4 gebloggt und einige Leitfäden zur Verwendung der neuen Streaming-Replikationsfunktion in einer Reihe von Teil 1 und Teil 2 vorgestellt.

Die Umstellung Ihrer Datenbanktechnologie von MySQL Replication auf MySQL Galera Cluster erfordert, dass Sie über die richtigen Fähigkeiten und ein Verständnis dafür verfügen, was Sie tun, um erfolgreich zu sein. In diesem Blog teilen wir einige Tipps für die Migration von einem MySQL-Replikations-Setup zu einem MySQL Galera Cluster 4.0-Setup.

Die Unterschiede zwischen MySQL-Replikation und Galera-Cluster

Wenn Sie mit Galera noch nicht vertraut sind, empfehlen wir Ihnen, unser Galera Cluster for MySQL Tutorial durchzugehen. Galera Cluster verwendet eine ganz andere Replikationsebene, die auf synchroner Replikation basiert, im Gegensatz zur MySQL-Replikation, die asynchrone Replikation verwendet (aber auch so konfiguriert werden könnte, dass eine halbsynchrone Replikation erreicht wird).

Galera Cluster unterstützt auch Multi-Master-Replikation. Es ist in der Lage, uneingeschränkte parallele Anwendungen (d. h. „parallele Replikation“), Multicast-Replikation und automatische Knotenbereitstellung durchzuführen.

Der Hauptfokus von Galera Cluster liegt auf der Datenkonsistenz, während es bei der MySQL-Replikation anfällig für Dateninkonsistenz ist (was mit Best Practices und richtiger Konfiguration vermieden werden kann, wie z. B. das Erzwingen von Nur-Lesen auf den zu vermeidenden Slaves unerwünschte Schreibvorgänge innerhalb der Slaves).

Obwohl von Galera empfangene Transaktionen entweder auf jeden Knoten oder gar nicht angewendet werden, zertifiziert jeder dieser Knoten den replizierten Write-Set in der Applier-Warteschlange (Transaktions-Commits), der auch Informationen zu allen enthält Sperren, die während der Transaktion von der Datenbank gehalten wurden. Diese Schreibsätze werden angewendet, sobald keine widersprüchlichen Sperren identifiziert wurden. Bis zu diesem Zeitpunkt gelten Transaktionen als festgeschrieben und werden weiterhin auf den Tablespace angewendet. Im Gegensatz zur asynchronen Replikation wird dieser Ansatz auch als virtuell synchrone Replikation bezeichnet, da das Schreiben und Festschreiben in einem logisch synchronen Modus erfolgt, das eigentliche Schreiben und Festschreiben in den Tablespace jedoch unabhängig erfolgt und auf jedem Knoten asynchron erfolgt.

Im Gegensatz zu MySQL Replication ist ein Galera-Cluster ein echter Multi-Master, Multi-Threaded Slave, ein reines Hot-Standby, ohne Notwendigkeit für Master-Failover oder Read-Write-Splitting. Die Migration zu Galera Cluster bedeutet jedoch keine automatische Antwort auf Ihre Probleme. Galera Cluster unterstützt nur InnoDB, daher kann es zu Designänderungen kommen, wenn Sie MyISAM- oder Memory-Speicher-Engines verwenden.

Nicht-InnoDB-Tabellen in InnoDB konvertieren

Galera Cluster erlaubt es Ihnen, MyISAM zu verwenden, aber dafür wurde Galera Cluster nicht entwickelt. Galera Cluster wurde entwickelt, um die Datenkonsistenz innerhalb aller Knoten innerhalb des Clusters strikt zu implementieren, und dies erfordert eine starke ACID-kompatible Datenbank-Engine. InnoDB ist eine Engine, die in diesem Bereich über diese starken Fähigkeiten verfügt, und es wird empfohlen, dass Sie InnoDB verwenden. insbesondere bei Transaktionen.

Wenn Sie ClusterControl verwenden, können Sie leicht Ihre Datenbankinstanz(en) für beliebige MyISAM-Tabellen bestimmen, die von Performance Advisors bereitgestellt werden. Sie finden dies unter Leistung → Registerkarte Berater. Zum Beispiel

Wenn Sie MyISAM- und MEMORY-Tabellen benötigen, können Sie sie trotzdem verwenden, aber make Sichern Sie Ihre Daten, die nicht repliziert werden müssen. Sie können Ihre gespeicherten Daten nur zum Lesen verwenden und gegebenenfalls „TRANSAKTION STARTEN NUR LESEN“ verwenden.

Hinzufügen von Primärschlüsseln zu Ihren InnoDB-Tabellen

Da Galera Cluster nur InnoDB unterstützt, ist es sehr wichtig, dass alle Ihre Tabellen einen geclusterten Index haben müssen (auch Primärschlüssel oder eindeutiger Schlüssel genannt). Um die beste Leistung aus Abfragen, Einfügungen und anderen Datenbankoperationen zu erzielen, ist es sehr wichtig, dass Sie jede Tabelle mit einem oder mehreren eindeutigen Schlüsseln definieren, da InnoDB den gruppierten Index verwendet, um die häufigsten Such- und DML-Operationen für jede Tabelle zu optimieren . Dies hilft, lang andauernde Abfragen innerhalb des Clusters zu vermeiden und kann möglicherweise Schreib-/Lesevorgänge im Cluster verlangsamen.

In ClusterControl gibt es Advisors, die Sie darauf hinweisen können. In Ihrem Master/Slave-Cluster für die MySQL-Replikation erhalten Sie beispielsweise einen Alarm aus der oder Ansicht aus der Liste der Berater. Der Beispiel-Screenshot unten zeigt, dass Sie keine Tabellen haben, die keinen Primärschlüssel haben:

Identifizieren Sie einen Master- (oder Active-Writer-)Knoten

Galera Cluster ist eine reine Multi-Master-Replikation. Dies bedeutet jedoch nicht, dass es Ihnen freisteht, den Knoten zu schreiben, auf den Sie abzielen möchten. Eine Sache, die Sie erkennen sollten, ist, dass Sie, wenn Sie auf einen anderen Knoten schreiben und eine widersprüchliche Transaktion erkannt wird, wie unten in ein Deadlock-Problem geraten:

2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:

TRANSACTION 728431, ACTIVE 0 sec starting index read

mysql tables in use 1, locked 1

MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)

2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:

TRANSACTION 728426, ACTIVE 3 sec updating or deleting

mysql tables in use 1, locked 1

, undo log entries 11409

MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating

update sbtest1_success set k=k+1 where id > 1000 and id < 100000

2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X

Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0

 0: len 8; hex 73757072656d756d; asc supremum;;

Das Problem mit mehreren schreibenden Knoten, ohne dass ein aktiver Writer-Knoten identifiziert wird, Sie werden mit diesen Problemen enden, die sehr häufige Probleme sind, die ich bei der Verwendung von Galera Cluster beim Schreiben auf mehreren Knoten gesehen habe die selbe Zeit. Um dies zu vermeiden, können Sie den Single-Master-Setup-Ansatz verwenden:

Aus der Dokumentation,

Um die Flusskontrolle zu lockern, können Sie die folgenden Einstellungen verwenden:

wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"

Das obige erfordert einen Serverneustart, da fc_master_slave nicht dynamisch ist.

Debugging-Modus zum Protokollieren von Konflikten oder Deadlocks aktivieren

Das Debuggen oder Verfolgen von Problemen mit Ihrem Galera-Cluster ist sehr wichtig. Sperren in Galera sind im Vergleich zu MySQL-Replikation anders implementiert. Es verwendet optimistisches Sperren beim Umgang mit Transaktionen im gesamten Cluster. Im Gegensatz zur MySQL-Replikation hat sie nur pessimistische Sperren, die nicht wissen, ob in einem Co-Master in einem Multi-Master-Setup eine solche gleiche oder widersprüchliche Transaktion ausgeführt wird. Galera verwendet weiterhin pessimistisches Sperren, jedoch auf dem lokalen Knoten, da es von InnoDB verwaltet wird, der unterstützten Speicher-Engine. Galera verwendet optimistische Sperren, wenn es zu anderen Knoten geht. Das bedeutet, dass keine Überprüfungen mit anderen Knoten des Clusters durchgeführt werden, wenn lokale Sperren erreicht werden (pessimistisches Sperren). Galera geht davon aus, dass, sobald die Transaktion die Commit-Phase innerhalb der Speicher-Engine durchlaufen hat und die anderen Knoten informiert sind, alles in Ordnung ist und keine Konflikte entstehen.

In der Praxis ist es am besten, wsrep_logs_conflicts zu aktivieren. Dadurch werden die Details von widersprüchlichen MDL- sowie InnoDB-Sperren im Cluster protokolliert. Die Aktivierung dieser Variablen kann dynamisch festgelegt werden, aber Vorsicht, sobald dies aktiviert ist. Es füllt Ihre Fehlerprotokolldatei ausführlich und kann Ihre Festplatte füllen, sobald Ihre Fehlerprotokolldatei zu groß ist.

Seien Sie vorsichtig mit Ihren DDL-Abfragen

Im Gegensatz zu MySQL Replication kann sich das Ausführen einer ALTER-Anweisung nur auf eingehende Verbindungen auswirken, die den Zugriff oder Verweis auf die Tabelle erfordern, auf die Ihre ALTER-Anweisung abzielt. Es kann auch Sklaven betreffen, wenn der Tisch groß ist, und Sklavenverzögerungen verursachen. Schreibvorgänge an Ihren Master werden jedoch nicht blockiert, solange Ihre Abfragen nicht mit dem aktuellen ALTER in Konflikt stehen. Dies ist jedoch nicht der Fall, wenn Sie Ihre DDL-Anweisungen wie ALTER mit Galera Cluster ausführen. ALTER-Anweisungen können Probleme verursachen, z. B. dass der Galera-Cluster aufgrund einer clusterweiten Sperre hängen bleibt, oder dass die Flusssteuerung beginnt, die Replikation zu entspannen, während sich einige Knoten von großen Schreibvorgängen erholen.

In einigen Situationen kann es zu Ausfallzeiten Ihres Galera-Clusters kommen, wenn diese Tabelle zu groß und eine primäre und wichtige Tabelle für Ihre Anwendung ist. Es kann jedoch ohne Ausfallzeit erreicht werden. Wie Rick James in seinem Blog betonte, können Sie den folgenden Empfehlungen folgen:

RSU vs. TOI

  • Rollendes Schema-Upgrade =Manuelles Ausführen eines Knotens (offline) nach dem anderen
  • Total Order Isolation =Galera synchronisiert so, dass dies gleichzeitig (in der Replikationsreihenfolge) auf allen Knoten erfolgt. RSU und TOI

Achtung:Da es keine Möglichkeit gibt, die Clients mit der DDL zu synchronisieren, müssen Sie sicherstellen, dass die Clients entweder mit dem alten oder dem neuen Schema zufrieden sind. Andernfalls müssen Sie wahrscheinlich den gesamten Cluster herunterfahren und gleichzeitig sowohl das Schema als auch den Client-Code umstellen.

Eine "schnelle" DDL kann auch über TOI erfolgen. Dies ist eine vorläufige Liste von solchen:

  • DATENBANK/TABELLE ERSTELLEN/LÖSCHEN/UMBENENNEN
  • ALTER um STANDARD zu ändern
  • ALTER, um die Definition von ENUM oder SET zu ändern (siehe Vorbehalte im Handbuch)
  • Bestimmte PARTITION ALTERs, die schnell sind.
  • DROP INDEX (außer PRIMARY KEY)
  • INDEX HINZUFÜGEN?
  • Andere ALTERs auf 'kleinen' Tabellen.
  • Da 5.6 und insbesondere 5.7 viele ALTER ALGORITHM=INPLACE-Fälle haben, überprüfen Sie, welche ALTERs auf welche Weise ausgeführt werden sollten.

Andernfalls verwenden Sie RSU. Gehen Sie für jeden Knoten separat wie folgt vor:

SET GLOBAL wsrep_OSU_method='RSU';

Damit wird der Knoten auch aus dem Cluster entfernt.

ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';

Setzt wieder ein, was zu einer Neusynchronisierung führt (hoffentlich ein schneller IST, kein langsamer SST)

Bewahren Sie die Konsistenz Ihres Clusters

Galera Cluster unterstützt keine Replikationsfilter wie binlog_do_db oder binlog_ignore_db, da Galera nicht auf binäre Protokollierung angewiesen ist. Es stützt sich auf die Ringpufferdatei, auch GCache genannt, die Schreibsätze speichert, die entlang des Clusters repliziert werden. Sie können kein inkonsistentes Verhalten oder inkonsistenten Status solcher Datenbankknoten anwenden.

Galera hingegen setzt strikt auf Datenkonsistenz innerhalb des Clusters. Es ist immer noch möglich, dass es zu Inkonsistenzen kommt, wenn Zeilen oder Datensätze nicht gefunden werden können. Wenn Sie beispielsweise Ihre Variable wsrep_OSU_method entweder RSU oder TOI für Ihre DDL-ALTER-Anweisungen festlegen, kann dies zu inkonsistentem Verhalten führen. Überprüfen Sie diesen externen Blog von Percona, in dem über Inkonsistenzen mit Galera bei TOI vs. RSU diskutiert wird.

Wsrep_on=OFF zu setzen und anschließend DML- oder DDL-Abfragen auszuführen, kann für Ihren Cluster gefährlich sein. Sie müssen auch Ihre gespeicherten Prozeduren, Trigger, Funktionen, Ereignisse oder Ansichten überprüfen, wenn die Ergebnisse nicht vom Zustand oder der Umgebung eines Knotens abhängen. Wenn ein oder mehrere bestimmte Knoten inkonsistent sind, kann dies möglicherweise dazu führen, dass der gesamte Cluster ausfällt. Sobald Galera ein inkonsistentes Verhalten erkennt, versucht Galera, den Cluster zu verlassen und diesen Knoten zu beenden. Daher ist es möglich, dass alle Knoten inkonsistent sind und Sie in einem Dilemma zurücklassen.

Wenn auch ein Galera-Cluster-Knoten einen Absturz erleidet, insbesondere in einer Zeit mit hohem Datenverkehr, ist es besser, den Knoten nicht sofort zu starten. Führen Sie stattdessen so bald wie möglich oder sobald der Datenverkehr nachlässt, einen vollständigen SST durch oder bringen Sie eine neue Instanz. Es kann möglich sein, dass der Knoten ein inkonsistentes Verhalten aufweist, das möglicherweise Daten beschädigt hat.

Große Transaktionen trennen und entscheiden, ob die Streaming-Replikation verwendet werden soll 

Lassen Sie uns direkt darauf eingehen. Eine der größten Neuerungen speziell bei Galera Cluster 4.0 ist die Streaming-Replikation. Frühere Versionen von Galera Cluster 4.0 begrenzten Transaktionen <2GiB, was typischerweise durch die Variablen wsrep_max_ws_rows und wsrep_max_ws_size gesteuert wird. Seit Galera Cluster 4.0 können Sie> 2 GiB an Transaktionen senden, aber Sie müssen bestimmen, wie groß die Fragmente während der Replikation verarbeitet werden müssen. Es muss pro Sitzung festgelegt werden und die einzigen Variablen, die Sie beachten müssen, sind wsrep_trx_fragment_unit und wsrep_trx_fragment_size. Das Deaktivieren der Streaming-Replikation ist einfach, da die Einstellung von wsrep_trx_fragment_size =0 dies tut. Beachten Sie, dass die Replikation einer großen Transaktion auch einen Overhead auf den Slave-Knoten (Knoten, die gegen den aktuellen Active-Writer/Master-Knoten replizieren) mit sich bringt, da Protokolle in die wsrep_streaming_log-Tabelle in der MySQL-Datenbank geschrieben werden.

Eine weitere Sache, die hinzugefügt werden muss, da Sie es mit großen Transaktionen zu tun haben, ist es beträchtlich, dass Ihre Transaktion einige Zeit dauern kann, bis sie abgeschlossen ist, so dass das Setzen der Variable innodb_lock_wait_timeout auf einen hohen Wert berücksichtigt werden muss. Stellen Sie dies je nach der von Ihnen geschätzten Zeit über die Sitzung ein, aber größer als die Zeit, die Sie für das Ende schätzen, andernfalls erhöhen Sie eine Zeitüberschreitung.

Wir empfehlen Ihnen, diesen vorherigen Blog über Streaming-Replikation in Aktion zu lesen.

GRANTs-Anweisungen replizieren

Wenn Sie GRANTs und verwandte Operationen verwenden, wirken Sie auf die MyISAM/Aria-Tabellen in der Datenbank `mysql`. Die GRANT-Anweisungen werden repliziert, die zugrunde liegenden Tabellen jedoch nicht. Das bedeutet also, INSERT INTO mysql.user ... wird nicht repliziert, weil die Tabelle MyISAM ist.

Das Obige trifft jedoch möglicherweise nicht mehr zu, seit Percona XtraDB Cluster(PXC) 8.0 (derzeit experimentell) als MySQL-Schematabellen in InnoDB konvertiert wurden, während in MariaDB 10.4 einige der Tabellen noch vorhanden sind im Aria-Format, aber andere sind in CSV oder InnoDB. Sie sollten feststellen, welche Version und welchen Anbieter von Galera Sie haben, aber am besten vermeiden Sie die Verwendung von DML-Anweisungen, die auf das mysql-Schema verweisen. Andernfalls erhalten Sie möglicherweise unerwartete Ergebnisse, es sei denn, Sie sind sich sicher, dass es sich um PXC 8.0 handelt.

XA-Transaktionen, LOCK/UNLOCK TABLES, GET_LOCK/RELEASE_LOCK werden nicht unterstützt

Galera Cluster unterstützt keine XA-Transaktionen, da XA-Transaktionen Rollbacks und Festschreibungen anders handhaben. Es ist gefährlich, LOCK/UNLOCK- oder GET_LOCK/RELEASE_LOCK-Anweisungen mit Galera anzuwenden oder zu verwenden. Möglicherweise kommt es zu einem Absturz oder Sperren, die nicht getötet werden können und gesperrt bleiben. Zum Beispiel

---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec

mysql tables in use 2, locked 2

3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5

MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)

insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5

Diese Transaktion wurde bereits freigeschaltet und sogar abgebrochen, aber ohne Erfolg. Wir schlagen vor, dass Sie Ihren Anwendungsclient neu gestalten und diese Funktionen entfernen müssen, wenn Sie zu Galera Cluster migrieren.

Netzwerkstabilität ist ein MUSS!!!

Galera-Cluster kann sogar mit Inter-WAN-Topologie oder Inter-Geo-Topologie ohne Probleme arbeiten (lesen Sie diesen Blog über die Implementierung von Inter-Geo-Topologie mit Galera). Wenn Ihre Netzwerkverbindung zwischen den einzelnen Knoten jedoch nicht stabil ist oder zeitweise für eine unerwartete Zeit ausfällt, kann dies für den Cluster problematisch sein. Am besten haben Sie einen Cluster, der in einem privaten und lokalen Netzwerk läuft, in dem jeder dieser Knoten verbunden ist. Planen Sie beim Entwerfen eines Knotens als Notfallwiederherstellung die Erstellung eines Clusters, wenn sich diese in einer anderen Region oder Region befinden. Sie können mit dem Lesen unseres vorherigen Blogs, Using MySQL Galera Cluster Replication to Create a Geo-Distributed Cluster:Part One, beginnen, da dies Ihnen am besten helfen könnte, Ihre Galera-Cluster-Topologie zu bestimmen.

Eine weitere Sache, die Sie bezüglich der Investition in Ihre Netzwerkhardware hinzufügen sollten:Es wäre problematisch, wenn Ihre Netzwerkübertragungsrate Ihnen eine niedrigere Geschwindigkeit beim Wiederaufbau einer Instanz während IST oder noch schlimmer bei SST bietet, insbesondere wenn Ihr Datensatz riesig ist . Die Netzwerkübertragung kann viele Stunden dauern und die Stabilität Ihres Clusters beeinträchtigen, insbesondere wenn Sie einen 3-Knoten-Cluster haben, während 2 Knoten nicht verfügbar sind, wenn diese 2 ein Spender und ein Joiner sind. Beachten Sie, dass während der SST-Phase die DONOR/JOINER-Knoten nicht verwendet werden können, bis sie endlich mit dem primären Cluster synchronisiert werden können.

In früheren Versionen von Galera wurde bei der Auswahl des Spenderknotens der State Snapshot Transfer (SST)-Spender zufällig ausgewählt. In Glera 4 wurde es viel weiter verbessert und hat die Möglichkeit, den richtigen Spender innerhalb des Clusters auszuwählen, da es einen Spender bevorzugt, der einen inkrementellen Zustandstransfer (IST) bereitstellen kann, oder einen Spender im selben Segment auswählt. Alternativ können Sie die Variable wsrep_sst_donor auf den richtigen Spender setzen, den Sie immer auswählen möchten.

Sichern Sie Ihre Daten und führen Sie strenge Tests während der Migration und vor der Produktion durch

Sobald Sie fit sind und sich entschieden haben, Ihre Daten auf Galera Cluster 4.0 zu migrieren, stellen Sie sicher, dass Sie immer Ihr Backup vorbereitet haben. Wenn Sie ClusterControl ausprobiert haben, sollte es einfacher sein, Backups zu erstellen.

Stellen Sie sicher, dass Sie auf die richtige Version von InnoDB migrieren und vergessen Sie nicht, immer mysql_upgrade anzuwenden und auszuführen, bevor Sie den Test durchführen. Stellen Sie sicher, dass alle Ihre Tests das gewünschte Ergebnis bestehen, das Ihnen die MySQL-Replikation bieten kann. Höchstwahrscheinlich gibt es keinen Unterschied zwischen der InnoDB-Speicher-Engine, die Sie in einem MySQL-Replikationscluster verwenden, und dem MySQL-Galera-Cluster, solange die Empfehlungen und Tipps vorher angewendet und vorbereitet wurden.

Fazit

Die Migration auf Galera Cluster 4.0 ist möglicherweise nicht Ihre gewünschte Datenbanktechnologielösung. Es hält Sie jedoch nicht davon ab, Galera Cluster 4.0 zu verwenden, solange seine spezifischen Anforderungen vorbereitet, eingerichtet und bereitgestellt werden können. Galera Cluster 4.0 ist jetzt zu einer sehr leistungsstarken, praktikablen Wahl und Option geworden, insbesondere auf einer hochverfügbaren Plattform und Lösung. Wir empfehlen Ihnen auch, diese externen Blogs über Galera-Vorbehalte oder die Einschränkungen des Galera-Clusters oder dieses Handbuch von MariaDB zu lesen.