Das Aktualisieren Ihrer Datenbank für Galera-basierte Cluster wie Percona XtraDB Cluster (PXC) oder MariaDB Galera Cluster kann eine Herausforderung darstellen, insbesondere für eine produktionsbasierte Umgebung. Sie können es sich nicht leisten, den Zustand Ihrer Hochverfügbarkeit zu verlieren und aufs Spiel zu setzen.
Ein Upgrade-Verfahren muss gut dokumentiert sein, und idealerweise sollten Dokumentation, strenge Tests und Benchmarking vor Upgrades durchgeführt werden. Am wichtigsten ist, dass Sicherheit und Verbesserungen auch basierend auf dem Änderungsprotokoll des Upgrades der Datenbankversion identifiziert werden müssen.
Bei allen Bedenken trägt die Automatisierung dazu bei, einen effizienteren Upgrade-Prozess zu erreichen, menschliche Fehler zu vermeiden und die RTO zu verbessern.
Verwalten des PXC/MariaDB Galera-Cluster-Upgrade-Prozesses
Das Upgrade Ihres PXC/MariaDB Galera-Clusters erfordert eine ordnungsgemäße Dokumentation und einen ordnungsgemäßen Prozessablauf, der auflistet, was zu tun ist und was zu tun ist, falls die Dinge schief gehen. Das bedeutet, dass ein Business Continuity Plan erstellt werden sollte, der auch Ihren Disaster Recovery Plan abdeckt. Sie können es sich nicht leisten, Ihr Geschäft im Falle von Problemen zu verlieren.
Die übliche Vorgehensweise ist, zuerst mit der Testumgebung zu beginnen. Die Testumgebung sollte genau die gleichen Einstellungen und Konfigurationen wie Ihre Produktionsumgebung haben. Sie können nicht direkt mit dem Upgrade der Produktionsumgebung fortfahren, da Sie nicht sicher sind, welche Auswirkungen und Auswirkungen es haben wird, wenn die Dinge nicht dem Plan entsprechen.
Die Arbeit mit einer Produktionsumgebung ist sehr sensibel, daher gibt es in den meisten Fällen immer ein Ausfallzeit- und Wartungsfenster, um drastische Auswirkungen zu vermeiden.
Es gibt zwei Arten von Upgrades für PCX oder MariaDB Galera Cluster, die Sie beachten müssen. Dies sind das Major-Release-Upgrade und das Minor-Release-Upgrade oder oft als In-Place-Upgrade bezeichnet. Bei einem direkten Upgrade können Sie Ihre Datenbankversion auf die neueste Nebenversion aktualisieren, indem Sie dieselben Binärdaten Ihrer Datenbank verwenden. Es werden keine physischen Änderungen an den Daten selbst vorgenommen, sondern nur an der Datenbankbinärdatei oder den zugrunde liegenden Softwarepaketen.
Upgrade von PCX oder MariaDB Galera Cluster auf eine Hauptversion
Das Upgrade auf eine Hauptversion kann eine Herausforderung darstellen, insbesondere für eine Produktionsumgebung. Es handelt sich um eine komplexe Art der Datenbankkonfiguration und spezielle integrierte Funktionen von PXC oder MariaDB Galera Cluster. Räumlich-zeitliche, zeitgestempelte Daten, Maschinendaten oder beliebige Daten mit mehreren Facetten sind sehr konservativ und empfindlich gegenüber Upgrades. Sie können für diesen Prozess kein direktes Upgrade anwenden, da viele größere Änderungen vorgenommen worden wären. Es sei denn, Sie haben sehr kleine Daten oder Daten, die aus Idempotenten bestehen, oder Daten, die leicht generiert werden können, können dies sicher tun, solange Sie wissen, dass die Auswirkungen Ihre Daten nicht beeinträchtigen.
Wenn Ihr Datenvolumen groß ist, ist es am besten, den Upgrade-Prozess zu automatisieren. Es ist jedoch möglicherweise keine ideale Lösung, die gesamte Sequenz im Upgrade-Prozess zu automatisieren, da sich während der Haupt-Upgrade-Phase unerwartete Probleme einschleichen können. Es ist am besten, sich wiederholende Schritte und Prozesse mit bekannten Ergebnissen in einem größeren Upgrade zu automatisieren. Zu jedem Zeitpunkt ist eine Ressource erforderlich, um zu bewerten, ob der Automatisierungsprozess sicher ist, um Unterbrechungen des Upgrade-Prozesses zu vermeiden. Automatisierte Tests nach dem Upgrade sind ebenso wichtig und sollten Teil des Post-Upgrade-Prozesses sein.
Upgrade von PCX oder MariaDB Galera Cluster auf eine Nebenversion
Ein Minor-Release-Upgrade, das als In-Placed-Upgrade bezeichnet wird, ist normalerweise ein sichererer Ansatz zur Durchführung eines Upgrade-Prozesses. Dies liegt daran, dass die häufigsten Änderungen für diese Version Sicherheits- und Exploit-Patches oder -Verbesserungen, Fehler (normalerweise schwerwiegende) oder Kompatibilitätsprobleme sind, die Patches erfordern, insbesondere wenn Änderungen an der aktuellen Hardware oder am Betriebssystem vorgenommen wurden, die dazu führen können, dass auch die Datenbank dies nicht tut einwandfrei funktionieren. Obwohl die Auswirkungen normalerweise mit minimalen Auswirkungen behoben werden können, ist es dennoch ein Muss, dass Sie sich das Änderungsprotokoll ansehen und lesen müssen, das auf das spezifische Upgrade der Nebenversion übertragen wurde.
Die Bereitstellung des Jobs zur Durchführung des Upgrade-Prozesses ist ein ideales Beispiel für die Automatisierung. Der übliche Ablauf ist sehr repetitiv und fügt Ihrem bestehenden PXC- oder MariaDB-Galera-Cluster meistens keinen Schaden zu. Am wichtigsten ist, dass nach dem Upgrade automatisierte Tests durchgeführt werden, um festzustellen, dass Einrichtung, Konfiguration, Effizienz und Funktionalität nicht beschädigt sind.
Vermeide die Fiaskos! Sei bereit, lass es automatisieren!
Ein Kunde von uns hat sich an uns gewandt und um Unterstützung gebeten, weil nach dem geringfügigen Datenbank-Upgrade eine Funktion, die er in der Datenbank verwendet, nicht richtig funktioniert. Sie fragten nach Schritten und Prozessen, wie ein Downgrade durchgeführt werden kann und wie sicher es sein wird. Ihre Kunden beschwerten sich, dass ihre Anwendung überhaupt nicht funktioniert, und verallgemeinerten, dass sie nicht nützlich sei.
Selbst bei einem so kleinen Fehler kann ein verärgerter Kunde Ihrem Produkt eine schlechte Bemerkung machen. Die Lehre aus diesem Szenario ist, dass ein Fehler beim Testen nach einem Upgrade zu der Annahme führt, dass alle Funktionen in einer Datenbank wie erwartet funktionieren.
Angenommen, Sie haben Pläne, den Upgrade-Prozess zu automatisieren, dann beachten Sie, dass die Art des Automatisierungsprozesses von der Art der durchzuführenden Upgrades abhängt. Wie bereits erwähnt, hat ein Haupt-Upgrade im Vergleich zu einem Neben-Upgrade unterschiedliche Ansätze. Daher gilt Ihr Automaten-Setup möglicherweise nicht für beide Datenbank-Software-Upgrades.
Automatisierung nach dem Upgrade-Prozess
An diesem Punkt wird erwartet, dass Sie Ihren Upgrade-Prozess idealerweise durch Automatisierung durchführen lassen. Nachdem Ihre Datenbank nun bereit ist, Client-Verbindungen zu empfangen, muss eine strenge Testphase folgen.
mysql_upgrade ausführen
Es ist sehr wichtig und wird dringend empfohlen, mysql_upgrade auszuführen, sobald der Upgrade-Prozess abgeschlossen ist. mysql_upgrade sucht nach Inkompatibilitäten mit dem aktualisierten MySQL-Server, indem es die folgenden Dinge tut:
-
Es aktualisiert die Systemtabellen im mysql-Schema, sodass Sie neue Privilegien oder Fähigkeiten nutzen können wurden hinzugefügt.
-
Es aktualisiert das Leistungsschema und das Systemschema.
-
Untersucht Benutzerschemas.
Das mysql_upgrade stellt fest, ob eine Tabelle Probleme hat, wie z. B. Inkompatibilitäten aufgrund von Änderungen in der neuesten Version nach dem Upgrade, und versucht, dies durch Reparieren der Tabelle zu beheben. Andernfalls, wenn er fehlschlägt, muss Ihr Automatisierungstest fehlschlagen und darf nicht mit etwas anderem fortfahren. Es muss zuerst untersucht und eine manuelle Reparatur durchgeführt werden.
Fehlerprotokolle prüfen
Sobald das mysql_upgrade abgeschlossen ist, müssen Sie die aufgetretenen Fehler überprüfen und verifizieren. Sie können dies in ein Skript einfügen und in den Fehlerprotokollen nach „Fehler“- oder „Warnung“-Labels suchen. Es ist sehr wichtig festzustellen, ob es solche gibt. Ihr automatisierter Test muss in der Lage sein, Fehlerfallen abzufangen, entweder kann er auf eine Benutzereingabe warten, um fortzufahren, wenn der Fehler nur sehr gering oder erwartet ist, andernfalls den Upgrade-Prozess stoppen.
Führen Sie einen Einheitentest durch
Eine TDD-Datenbankumgebung (Test Driven Development) ist ein Softwareentwicklungsansatz, bei dem eine Reihe von Testfällen validiert und festgestellt werden muss, ob die Validierung wahr (bestanden) oder falsch (nicht bestanden) ist. Etwas wie das, was wir im Screenshot unten haben:
Bild mit freundlicher Genehmigung von guru99.com
Dies ist eine Art von Unit-Tests, die dabei hilft, unerwünschte Bugs oder logische Fehler in Ihrer Anwendung und in Ihrer Datenbank zu vermeiden. Denken Sie daran, dass ungültige Daten in der Datenbank allen Geschäftsanalysen und Transaktionen schaden würden, insbesondere wenn es sich um komplexe Finanzberechnungen oder mathematische Gleichungen handelt.
Wenn Sie fragen, ist es wirklich notwendig, nach dem Upgrade einen Komponententest durchzuführen? Natürlich ist es das! Sie müssen dies nicht unbedingt in der Produktionsumgebung ausführen. Während der Testphasen, d. h. wenn Sie zuerst Ihre QAs, Entwicklungs-/Staging-Umgebung aktualisieren, muss es in diesem Bereich angewendet werden. Die Daten müssen eine exakte Kopie sein, die mindestens oder nahezu identisch mit ihrer Produktionsumgebung ist. Ihr Ziel ist es hier, unerwünschte Ergebnisse und definitiv falsche logische Ergebnisse zu vermeiden. Sie müssen natürlich gut auf Ihre Daten aufpassen und feststellen, ob die Ergebnisse den Validierungstest bestehen.
Wenn Sie beabsichtigen, mit Ihrer Produktion zu laufen, dann tun Sie es. Seien Sie jedoch nicht so starr wie Ihre Testphase in der QA-, Entwicklungs- oder Staging-Umgebung. Dies liegt daran, dass Sie Ihre Zeit basierend auf dem verfügbaren Wartungsfenster planen und Verzögerungen und längere RTOs vermeiden müssen.
Meiner Erfahrung nach wählen Kunden während der Upgrade-Phase einen schnelleren Ansatz, der wichtig ist, um festzustellen, ob eine solche Funktion das richtige Ergebnis liefert. Darüber hinaus können Sie ein Skript haben, um den Test einer Reihe von logischen Geschäftsfunktionen oder gespeicherten Prozeduren zu automatisieren, da es hilft, die Abfragen zwischenzuspeichern und Ihre Datenbank warm zu machen.
Wenn Sie sich auf den Komponententest für Ihre Datenbank vorbereiten, vermeiden Sie es, das Rad neu zu erfinden. Schauen Sie sich stattdessen die verfügbaren Tools an, die Sie auswählen können, wenn sie für Ihre Anforderungen und Bedürfnisse geeignet sind. Sehen Sie sich Selenium an oder besuchen Sie diesen Blog.
Identität von Abfragen überprüfen
Das gebräuchlichste Tool, das Sie verwenden können, ist Perconas pt-upgrade. Es überprüft, ob die Abfrageergebnisse auf verschiedenen Servern identisch sind. Es führt Abfragen basierend auf den angegebenen Protokollen und der bereitgestellten Verbindung (oder als DSN bezeichnet) aus, vergleicht dann die Ergebnisse und meldet alle signifikanten Unterschiede. Es bietet darüber hinaus Optionen zum Sammeln oder Analysieren der Abfragen, beispielsweise über tcpdump.
Die Verwendung des pt-Upgrades ist einfach. Beispielsweise können Sie mit dem folgenden Befehl ausführen:
## Comparing via slow log for the given hosts
pt-upgrade h=host1 h=host2 slow.log
## or use fingerprints, useful for debugging purposes
pt-upgrade --fingerprints --run-time=1h mysqld-slow.log h=127.0.0.1,P=5091 h=127.0.0.1,P=5517
## or with tcpdump,
tcpdump -i eth0 port 3306 -s 65535 -x -n -q -tttt \
| pt-query-digest --type tcpdump --no-report --print \
| pt-upgrade h=host1 h=host2Es hat sich bewährt, dass nach der Durchführung eines Upgrades, insbesondere eines Major-Release-Upgrades, pt-upgrade verwendet wird, um fortzufahren und eine Abfrageanalyse durchzuführen, bei der Unterschiede basierend auf den Ergebnissen identifiziert werden. Es empfiehlt sich, dies während der Testphase zu tun, während Sie es in Ihrer QAs- oder Staging- und Entwicklungsumgebung tun, damit Sie entscheiden können, ob es sicherer ist, fortzufahren. Sie können dies zu Ihrem Automatisierungstool hinzufügen und es als Playbook ausführen, sobald es bereit ist, seine Aufgabe zu erfüllen.
Wie lässt sich der Testprozess automatisieren?
In unseren vorherigen Blogs haben wir verschiedene Möglichkeiten zur Automatisierung Ihrer Datenbanken vorgestellt. Die gängigsten Werkzeuge, die im Trend liegen, sind diese IaC-Bereitstellungssoftware-Tools (Infrastructure as Code). Sie können Puppet, Chef, SaltStack oder Ansible verwenden, um die Arbeit zu erledigen.
Meine Präferenz war schon immer Ansible, um meine automatisierten Tests durchzuführen, es erlaubt mir, Playbooks nach seiner Jobrolle zu erstellen. Natürlich kann ich nicht einen ganzen Automaten erstellen, der alle Dinge erledigt, weil die Situation und die Umgebung variieren. Basierend auf den zuvor angegebenen Upgrade-Typen (Haupt- und Neben-Upgrade) sollten Sie den Prozess unterscheiden. Selbst wenn es sich nur um ein Inplace-Upgrade handelt, müssen Sie dennoch sicherstellen, dass Ihre Playbooks die richtige Aufgabe erfüllen.
ClusterControl ist Ihr Datenbankautomatisierungsfreund!
ClusterControl ist eine gute Option, um grundlegende und automatisierte Tests durchzuführen. ClusterControl ist kein Framework zum Testen; Es ist kein Tool zum Bereitstellen von Komponententests. Es handelt sich jedoch um ein Datenbankverwaltungs- und Überwachungstool, das viele automatisierte Bereitstellungen basierend auf den angeforderten Auslösern des Benutzers oder Administrators der Software enthält.
ClusterControl bietet Nebenversions-Upgrades an, was den DBAs bei der Durchführung von Upgrades Komfort bietet. Es macht auch mysql_upgrade im laufenden Betrieb. Sie müssen es also nicht manuell ausführen. ClusterControl erkennt auch neue zu aktualisierende Versionen und empfiehlt Ihnen die nächsten Schritte. Falls ein Fehler auftritt, wird das Upgrade nicht fortgesetzt.
Hier ist ein Beispiel für den kleinen Upgrade-Job:
Wenn Sie genau hinschauen, läuft das mysql_upgrade erfolgreich. Es wird zwar kein automatisches Upgrade des Masters empfohlen und durchgeführt, aber es ist nicht der richtige Ansatz, um fortzufahren. In diesem Fall müssen Sie den neuen Slave heraufstufen und dann den Master als Slave degradieren, um das Upgrade durchzuführen.
Fazit
Das Tolle an ClusterControl ist, dass Sie die Überprüfung von Fehlerprotokollen integrieren, einen Komponententest durchführen und die Identität von Abfragen überprüfen können, indem Sie Advisors erstellen. Es ist nicht schwierig, dies zu tun. Weitere Informationen finden Sie in unserem vorherigen Blog Using ClusterControl Advisor to Create Checks for SELinux and Meltdown/Spectre:Part One. Dies veranschaulicht, wie Sie die Vorteile nutzen und entweder den nächsten auszuführenden Job auslösen können, sobald das Upgrade ausgeführt wurde. ClusterControl verfügt über integrierte Warnungen oder Alarme, die sich in Ihre bevorzugten Warnsysteme von Drittanbietern integrieren lassen, um Sie über den aktuellen Status Ihrer automatisierten Tests zu informieren.
