MySQL 8.0 ist seit einiger Zeit verfügbar und Percona XtraDB Cluster 8.0 ist ebenfalls seit einiger Zeit verfügbar. Außerdem nähert sich MySQL 5.6 seinem Lebensende und Benutzer von PXC 5.6 werden ebenfalls bald auf eine neuere Version migrieren wollen. Lassen Sie uns einen Blick auf den Prozess werfen und einige Tipps dazu geben.
Denken Sie daran, es ist MySQL Underneath...
Für den Anfang müssen Sie bedenken, dass Galera nur ein Plugin ist, das mit MySQL funktioniert, also müssen Sie sicherstellen, dass Sie die Migrationsregeln und -prozesse für Ihre spezielle MySQL-Version einhalten, die in Ihrem verwendet wird PXC. Wenn wir PXC 5.7 ausführen und Sie auf PXC 8.0 aktualisieren möchten, müssen Sie zuerst alle Kästchen auf der MySQL-Upgrade-Checkliste aktivieren. Einiges davon haben wir in unserem Blog behandelt, in dem der Upgrade-Prozess zwischen MySQL 5.7 und MySQL 8.0 beschrieben wird. Dies bedeutet auch, dass nur von MySQL unterstützte Upgrade-Pfade möglich sind – Sie können beispielsweise PXC 5.6 nicht direkt auf PXC 8.0 aktualisieren, da ein direktes MySQL-Upgrade von 5.6 auf 8.0 nicht unterstützt wird.
Lesen Sie die Upgrade-Dokumentation
Wie üblich sollten Sie sich, wenn Sie ein Upgrade planen, mit der vom Anbieter erstellten Dokumentation vertraut machen. Percona hat eine Webseite, die der Erläuterung des Upgrade-Prozesses und der damit verbundenen Vorbehalte gewidmet ist. Wir gehen in diesem Blogbeitrag auf einige dieser Punkte ein.
Konfigurationsänderungen
Es gibt ein paar Änderungen in den Standardkonfigurationseinstellungen, die Probleme im Upgradeprozess auslösen können - pxc_strict_mode ist standardmäßig auf ENFORCING eingestellt. Dieser Modus blockiert jede Art von Konfiguration, die experimentell ist und die Stabilität des Clusters beeinträchtigen kann. Geprüft werden unter anderem verwendete Speicher-Engines, binäres Log-Format, Vorhandensein von Primärschlüsseln und einiges mehr. Beim Upgrade möchten Sie es möglicherweise auf PERMISSIVE setzen, um die Inkompatibilitäten im Fehlerprotokoll zu verfolgen, aber ansonsten den PXC laufen lassen, auch wenn einige Dinge nicht in bester Verfassung sind.
Eine weitere Einstellung, pxc_encrypt_cluster_traffic, ist ebenfalls standardmäßig aktiviert und erzwingt die Verschlüsselung der Galera-Kommunikation zwischen Knoten. Es ist nicht möglich, Knoten mit verschlüsselten und unverschlüsselten Knoten im selben Cluster zu mischen, daher müssen Sie es entweder auf allen Knoten einrichten oder sicherstellen, dass Sie pxc_encrypt_cluster_traffic auf den neuen PXC 8.0-Knoten deaktivieren.
Änderung im Standard-Authentifizierungs-Plugin
Wir haben dies in unserem Blog-Beitrag zur Migration zu MySQL 8.0 erwähnt, aber die Änderung ist so wichtig, dass wir sie hier auch wiederholen möchten - mit MySQL 8.0 ändert sich das Standard-Authentifizierungs-Plugin in caching_sha2_password - dies kann passieren machen einige der älteren Anwendungen inkompatibel mit MySQL 8.0. Natürlich können Sie diese Einstellung ändern, aber wenn Sie sie nicht berücksichtigen, kann es nach Abschluss des Upgrades nach hinten losgehen.
Upgrade-Prozesse
Beachten Sie für den Anfang bitte, dass es bei einigen möglich ist, dass sowohl PXC 5.7- als auch PXC 8.0-Knoten im selben Cluster ausgeführt werden, obwohl dies nicht empfohlen wird. Dies eröffnet die Möglichkeit, ein direktes Live-Upgrade durchzuführen. Der Prozess wäre ganz einfach – stoppen Sie den PXC 5.7-Knoten, aktualisieren Sie ihn auf PXC 8.0, indem Sie eine neue Version installieren und starten. Im Prozessdatenverzeichnis wird auf die neue Version aktualisiert und der neue PXC 8.0-Knoten sollte ordnungsgemäß starten und dem Cluster beitreten können. Dann fahren Sie mit den Knoten nacheinander fort und migrieren sie von PXC 5.7 auf PXC 8.0. Bitte beachten Sie, dass Sie SST vermeiden sollten, da ein Datenverzeichnis vom PXC 8.0-Knoten nicht auf 5.7 verwendet werden kann. Umgekehrt sollte es funktionieren. Um zu verhindern, dass SST auftritt, stellen Sie sicher, dass die gcache-Größe groß genug ist, um Schreibvorgänge aufzunehmen und IST zu ermöglichen. IST selbst wird gut funktionieren.
Wenn Sie mehr freie Knoten haben, können Sie das Upgrade immer mit zwei Clustern auf verschiedenen Hauptversionen durchführen, die parallel laufen und durch asynchrone Replikation verbunden sind. Wichtig ist, dass Sie mit einem solchen Ansatz den PXC 8.0 gründlicher testen können, da Sie ihn eine Weile in Betrieb haben (im Grunde so lange, wie Sie ihn benötigen) und Sie Ihre Anwendung auf diesem Cluster testen können – zu jedem beliebigen Zeitpunkt Zeit können Sie einen Teil der schreibgeschützten Arbeitslast auf PXC 8.0 verschieben und sehen, wie Abfragen verarbeitet werden, wenn Fehler oder Leistungsprobleme auftreten.
Wenn Sie ClusterControl verwenden, können Sie dies mit dem Job „Create Slave Cluster“ erreichen.
Sie werden gefragt, woher die Ausgangsdaten stammen sollen, master PXC-Knoten oder aus der Sicherung.
Sie müssen auch die Konnektivitätsdetails wie SSH-Benutzer und Schlüsselpfad übergeben .
Dann werden Sie aufgefordert, den Anbieter und die Version auszuwählen – Sie möchten wahrscheinlich Um vorerst PXC 5.7 zu verwenden, werden Sie die Knoten später aktualisieren und den Upgrade-Prozess selbst testen.
Schließlich müssen Sie die Knotenhostnamen oder IP-Adressen für ClusterControl übergeben Stellen Sie eine Verbindung her und beginnen Sie mit der Einrichtung der Knoten.
Als Ergebnis haben Sie einen zweiten Percona XtraDB-Cluster, der in Version 5.7 ausgeführt wird , die aus dem ursprünglichen Cluster repliziert werden. Dieser Cluster kann auf die neue Version aktualisiert werden und schließlich können Sie Ihren Datenverkehr darauf umstellen. Wir haben diesen Vorgang ausführlich in unserem vorherigen Blogbeitrag erklärt.
Wir hoffen, dass dieser kurze Blogbeitrag Ihnen hilft, sich besser auf das Upgrade Ihres Percona XtraDB-Clusters auf Version 8.0 vorzubereiten.
