In den letzten fünf Beiträgen der Blogserie haben wir die Bereitstellung von Clustering/Replikation (MySQL/Galera, MySQL-Replikation, MongoDB und PostgreSQL), die Verwaltung und Überwachung Ihrer vorhandenen Datenbanken und Cluster, die Leistungsüberwachung und den Zustand sowie die Erstellung Ihrer Einrichtung behandelt hochverfügbar über HAProxy und MaxScale und im letzten Beitrag, wie Sie sich durch Planen von Backups auf Katastrophen vorbereiten können.
Seit ClusterControl 1.2.11 haben wir wesentliche Verbesserungen am Datenbankkonfigurationsmanager vorgenommen. Die neue Version erlaubt es, Parameter auf mehreren Datenbankhosts gleichzeitig zu ändern und, wenn möglich, deren Werte zur Laufzeit zu ändern.
Wir haben das neue MySQL-Konfigurationsmanagement in einem Tipps &Tricks-Blogbeitrag vorgestellt, aber dieser Blogbeitrag wird tiefer gehen und das Konfigurationsmanagement innerhalb von ClusterControl für MySQL, PostgreSQL und MongoDB behandeln.
ClusterControl-Konfigurationsverwaltung
Die Konfigurationsverwaltungsoberfläche finden Sie unter Verwalten> Konfigurationen. Von hier aus können Sie die Konfigurationen Ihrer Datenbankknoten und anderer Tools, die ClusterControl verwaltet, anzeigen oder ändern. ClusterControl importiert die neueste Konfiguration von allen Knoten und überschreibt zuvor erstellte Kopien. Derzeit werden keine historischen Daten gespeichert.
Wenn Sie die Konfigurationsdateien lieber direkt auf den Knoten manuell bearbeiten möchten, können Sie die geänderte Konfiguration erneut importieren, indem Sie auf die Schaltfläche Importieren klicken.
Und nicht zuletzt:Sie können Konfigurationsvorlagen erstellen oder bearbeiten. Diese Vorlagen werden immer dann verwendet, wenn Sie neue Knoten in Ihrem Cluster bereitstellen. Natürlich werden alle an den Vorlagen vorgenommenen Änderungen nicht rückwirkend auf die bereits bereitgestellten Knoten angewendet, die mit diesen Vorlagen erstellt wurden.
MySQL-Konfigurationsverwaltung
Wie bereits erwähnt, wurde das MySQL-Konfigurationsmanagement in ClusterControl 1.2.11 komplett überarbeitet. Die Benutzeroberfläche ist jetzt intuitiver. Beim Ändern der Parameter prüft ClusterControl, ob der Parameter tatsächlich existiert. Dadurch wird sichergestellt, dass Ihre Konfiguration den Start von MySQL nicht aufgrund nicht vorhandener Parameter verweigert.
Unter Verwalten -> Konfigurationen finden Sie eine Übersicht aller im ausgewählten Cluster verwendeten Konfigurationsdateien, einschließlich Lastausgleichsknoten.
Wir verwenden eine Baumstruktur, um Hosts und ihre jeweiligen Konfigurationsdateien einfach anzuzeigen. Am Ende der Baumstruktur finden Sie die für diesen Cluster verfügbaren Konfigurationsvorlagen.
Ändern von Parametern
Angenommen, wir müssen einen einfachen Parameter wie die maximale Anzahl erlaubter Verbindungen (max_connections) ändern, dann können wir diesen Parameter einfach zur Laufzeit ändern.
Wählen Sie zuerst die Hosts aus, auf die diese Änderung angewendet werden soll.
Wählen Sie dann den Abschnitt aus, den Sie ändern möchten. In den meisten Fällen werden Sie den MYSQLD-Abschnitt ändern wollen. Wenn Sie den Standardzeichensatz für MySQL ändern möchten, müssen Sie dies sowohl in MYSQLD- als auch in Client-Abschnitten ändern.
Bei Bedarf können Sie auch einen neuen Abschnitt erstellen, indem Sie einfach den neuen Abschnittsnamen eingeben. Dadurch wird ein neuer Abschnitt in my.cnf erstellt.
Sobald wir einen Parameter ändern und seinen neuen Wert durch Drücken von „Fortfahren“ festlegen, prüft ClusterControl, ob der Parameter für diese Version von MySQL existiert. Damit soll verhindert werden, dass nicht vorhandene Parameter die Initialisierung von MySQL beim nächsten Neustart blockieren.
Wenn wir für die Änderung von max_connections auf „Proceed“ drücken, erhalten wir eine Bestätigung, dass sie auf die Konfiguration angewendet und zur Laufzeit mit SET GLOBAL festgelegt wurde. Ein Neustart ist nicht erforderlich, da max_connections ein Parameter ist, den wir zur Laufzeit ändern können.
Nehmen wir nun an, wir wollen die Größe des Pufferpools ändern, dies würde einen Neustart von MySQL erfordern, bevor es wirksam wird:
Und wie erwartet wurde der Wert in der Konfigurationsdatei geändert, aber ein Neustart ist erforderlich. Sie können dies tun, indem Sie sich manuell beim Host anmelden und den MySQL-Prozess neu starten. Eine andere Möglichkeit, dies von ClusterControl aus zu tun, ist die Verwendung des Nodes-Dashboards.
Knoten in einem Galera-Cluster neu starten
Sie können einen Neustart pro Knoten durchführen, indem Sie „Knoten neu starten“ auswählen und auf die Schaltfläche „Fortfahren“ klicken.
Wenn Sie auf einem Galera-Knoten „Initial Start“ auswählen, leert ClusterControl das MySQL-Datenverzeichnis und erzwingt auf diese Weise eine vollständige Kopie. Bei einer Konfigurationsänderung ist dies natürlich unnötig. Stellen Sie sicher, dass Sie das Kontrollkästchen „Initial“ im Bestätigungsdialogfeld deaktiviert lassen. Dadurch wird MySQL auf dem Host gestoppt und gestartet, aber je nach Arbeitslast und Größe des Pufferpools kann dies eine Weile dauern, da MySQL damit beginnt, die schmutzigen Seiten aus dem InnoDB-Pufferpool auf die Festplatte zu löschen. Dies sind die Seiten, die im Speicher, aber nicht auf der Festplatte geändert wurden.
Knoten in MySQL-Master-Slave-Topologien neu starten
Bei MySQL-Master-Slave-Topologien können Sie nicht einfach Knoten für Knoten neu starten. Sofern die Ausfallzeit des Masters nicht akzeptabel ist, müssen Sie die Konfigurationsänderungen zuerst auf die Slaves anwenden und dann einen Slave zum neuen Master machen.
Sie können die Slaves einzeln durchgehen und einen „Restart Node“ auf ihnen ausführen.
Nachdem Sie die Änderungen auf alle Slaves angewendet haben, befördern Sie einen Slave zum neuen Master:
Nachdem der Slave zum neuen Master geworden ist, können Sie den alten Master-Knoten herunterfahren und neu starten, um die Änderung zu übernehmen.
Importieren von Konfigurationen
Nachdem wir die Änderung nun direkt auf die Datenbank sowie die Konfigurationsdatei angewendet haben, dauert es bis zum nächsten Konfigurationsimport, bis die Änderung in der in ClusterControl gespeicherten Konfiguration widergespiegelt wird. Wenn Sie weniger geduldig sind, können Sie einen sofortigen Konfigurationsimport planen, indem Sie auf die Schaltfläche „Importieren“ klicken.
PostgreSQL-Konfigurationsverwaltung
Bei PostgreSQL funktioniert das Konfigurationsmanagement etwas anders als das MySQL-Konfigurationsmanagement. Im Allgemeinen haben Sie hier die gleiche Funktionalität:Konfiguration ändern, Konfigurationen für alle Knoten importieren und Vorlagen definieren/ändern.
Der Unterschied besteht hier darin, dass Sie sofort die gesamte Konfigurationsdatei ändern und diese Konfiguration in den Datenbankknoten zurückschreiben können.
Wenn die vorgenommenen Änderungen einen Neustart erfordern, wird eine Schaltfläche „Neustart“ angezeigt, mit der Sie den Knoten neu starten können, um die Änderungen zu übernehmen.
MongoDB-Konfigurationsverwaltung
Das MongoDB-Konfigurationsmanagement funktioniert ähnlich wie das MySQL-Konfigurationsmanagement:Sie können die Konfiguration ändern, Konfigurationen für alle Knoten importieren, Parameter ändern und Vorlagen ändern.
Das Ändern der Konfiguration ist ziemlich einfach, indem Sie das Dialogfeld "Parameter ändern" verwenden (wie im Abschnitt "Parameter ändern" beschrieben::
Nach der Änderung können Sie die von ClusterControl vorgeschlagene Aktion nach der Änderung im Dialog "Konfigurationsänderungsprotokoll" sehen:
Anschließend können Sie die jeweiligen MongoDB-Knoten neu starten, einen Knoten nach dem anderen, um die Änderungen zu laden.
Abschließende Gedanken
In diesem Blogbeitrag haben wir erfahren, wie Sie Ihre Konfigurationen in ClusterControl verwalten, ändern und mit Vorlagen versehen. Durch das Ändern der Vorlagen können Sie viel Zeit sparen, wenn Sie nur einen Knoten in Ihrer Topologie bereitgestellt haben. Da die Vorlage für neue Knoten verwendet wird, ersparen Sie sich das nachträgliche Ändern aller Konfigurationen. Für MySQL- und MongoDB-basierte Knoten ist das Ändern der Konfiguration auf allen Knoten jedoch aufgrund der neuen Konfigurationsverwaltungsschnittstelle trivial geworden.
Zur Erinnerung:Wir haben kürzlich in derselben Serie die Bereitstellung von Clustering/Replikation (MySQL/Galera, MySQL-Replikation, MongoDB und PostgreSQL), die Verwaltung und Überwachung Ihrer vorhandenen Datenbanken und Cluster, die Leistungsüberwachung und den Zustand sowie die Optimierung Ihrer Einrichtung behandelt verfügbar über HAProxy und MaxScale und im letzten Beitrag, wie Sie sich auf Katastrophen vorbereiten können, indem Sie Backups planen.
