So sichern und wiederherstellen Sie ClusterControl

ClusterControl 1.7.1 hat eine neue Funktion eingeführt, mit der Sie Ihren ClusterControl-Server sichern und (zusammen mit Metadaten zu Ihren verwalteten Datenbanken) auf einem anderen Server wiederherstellen können. Es sichert die ClusterControl-Anwendung sowie alle ihre Konfigurationsdaten. Die Migration von ClusterControl auf einen neuen Server war früher ein Problem, aber jetzt nicht mehr.

Dieser Blogbeitrag führt Sie durch diese neue Funktion.

Wir werden ClusterControl von einem Server auf einen anderen migrieren und dabei alle Konfigurationen und Einstellungen beibehalten.

Außerdem zeigen wir Ihnen, wie Sie die Verwaltung eines Clusters von einer ClusterControl-Instanz auf eine andere übertragen.

Unsere Beispielarchitektur begann mit zwei Produktionsclustern (siehe Screenshot unten):

Cluster-ID 1:3 Galera-Knoten (PXC) + 1 HAProxy + 1 ProxySQL (5 Knoten)
Cluster-ID 2:1 MySQL-Master + 2 MySQL-Slaves + 1 ProxySQL (4 Knoten)

Einführung

ClusterControl CLI (s9s) ist ein Befehlszeilenschnittstellentool zur Interaktion, Steuerung und Verwaltung von Datenbankclustern mithilfe der ClusterControl-Plattform. Ab Version 1.4.1 installiert das Installationsskript dieses Paket automatisch auf dem ClusterControl-Knoten.

Es gibt im Wesentlichen 4 neue Optionen, die unter dem Befehl „s9s backup“ eingeführt wurden, die verwendet werden können, um unser Ziel zu erreichen:

Flag	Beschreibung
--save-controller	Speichert den Status des Controllers in einem Tarball.
--restore-controller	Stellt den gesamten Controller aus einem zuvor erstellten Tarball wieder her (erstellt mit Hilfe von --save-controller
--save-cluster-info	Speichert die Informationen, die der Controller über einen Cluster hat.
--restore-cluster-info	Stellt die Informationen, die der Controller über einen Cluster hat, aus einer zuvor erstellten Archivdatei wieder her.

Dieser Blogbeitrag behandelt beispielhafte Anwendungsfälle zur Nutzung dieser Optionen. Im Moment befinden sie sich im Release Candidate-Stadium und sind nur über das ClusterControl CLI-Tool verfügbar.

ClusterControl sichern

Dazu muss der ClusterControl-Server mindestens v1.7.1 und höher sein. Um den ClusterControl-Controller zu sichern, führen Sie einfach den folgenden Befehl auf dem ClusterControl-Knoten als Root-Benutzer (oder mit sudo) aus:

$ s9s backup \
--save-controller \
--backup-directory=$HOME/ccbackup \
--output-file=controller.tar.gz \
--log

Die --output-file muss ein Dateiname oder physischer Pfad sein (wenn Sie das Flag --backup-directory weglassen wollen), und die Datei darf vorher nicht existieren. ClusterControl ersetzt die Ausgabedatei nicht, wenn sie bereits vorhanden ist. Durch die Angabe von --log wird gewartet, bis der Job ausgeführt wird, und die Job-Protokolle werden im Terminal angezeigt. Auf dieselben Protokolle kann über die ClusterControl-Benutzeroberfläche unter Aktivität -> Jobs -> Controller speichern zugegriffen werden :

Der Job „Controller speichern“ führt im Wesentlichen die folgenden Vorgänge aus:

Rufen Sie die Controller-Konfiguration ab und exportieren Sie sie in JSON
CMON-Datenbank als MySQL-Dump-Datei exportieren
Für jeden Datenbankcluster:
1. Rufen Sie die Clusterkonfiguration ab und exportieren Sie sie in JSON

In der Ausgabe sehen Sie möglicherweise, dass der gefundene Job N + 1 ist Cluster, zum Beispiel „3 Cluster zum Speichern gefunden“, obwohl wir nur zwei Datenbank-Cluster haben. Dazu gehört die Cluster-ID 0, die in ClusterControl als global initialisierter Cluster eine besondere Bedeutung hat. Es gehört jedoch nicht zur CmonCluster-Komponente, die das Datenbank-Cluster unter ClusterControl-Verwaltung ist.

ClusterControl auf einem neuen ClusterControl-Server wiederherstellen

Angenommen, ClusterControl ist bereits auf dem neuen Server installiert, möchten wir die zu verwaltenden Datenbank-Cluster auf den neuen Server migrieren. Das folgende Diagramm veranschaulicht unsere Migrationsübung:

Übertragen Sie zunächst das Backup vom alten Server auf den neuen Server:

$ scp $HOME/ccbackup/controller.tar.gz 192.168.0.190:~

Bevor wir die Wiederherstellung durchführen, müssen wir passwortloses SSH zu allen Knoten vom neuen ClusterControl-Server einrichten:

$ ssh-copy-id 192.168.0.11 #proxysql cluster 1
$ ssh-copy-id 192.168.0.12 #proxysql cluster 1
$ ssh-copy-id 192.168.0.21 #pxc cluster 1
$ ssh-copy-id 192.168.0.22 #pxc cluster 1
$ ssh-copy-id 192.168.0.23 #pxc cluster 1
$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2

Führen Sie dann auf dem neuen Server die Wiederherstellung durch:

$ s9s backup \
--restore-controller \
--input-file=$HOME/controller.tar.gz \
--debug \
--log

Dann müssen wir den Cluster in der Benutzeroberfläche synchronisieren, indem wir zu Globale Einstellungen -> Clusterregistrierungen -> Cluster synchronisieren gehen . Wenn Sie dann zum Haupt-Dashboard von ClusterControl zurückkehren, sehen Sie Folgendes:

Keine Panik. Die neue ClusterControl-Benutzeroberfläche kann die Überwachungs- und Verwaltungsdaten aufgrund eines falschen RPC-API-Tokens nicht abrufen. Wir müssen es nur entsprechend aktualisieren. Rufen Sie zuerst den rpc_key-Wert für die jeweiligen Cluster ab:

$ cat /etc/cmon.d/cmon_*.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=8fgkzdW8gAm2pL4L
cluster_id=2
rpc_key=tAnvKME53N1n8vCC

Klicken Sie in der Benutzeroberfläche auf den Link „hier“ am Ende der Zeile „Change the RPC API token here“. Es öffnet sich folgender Dialog:

Fügen Sie den entsprechenden rpc_key-Wert in das Textfeld ein und klicken Sie auf Speichern. Wiederholen Sie dies für den nächsten Cluster. Warten Sie einen Moment und die Clusterliste sollte automatisch aktualisiert werden.

Der letzte Schritt besteht darin, die MySQL cmon-Benutzerrechte für die neuen Änderungen der ClusterControl-IP-Adresse, 192.168.0.190, zu korrigieren. Melden Sie sich bei einem der PXC-Knoten an und führen Sie Folgendes aus:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** Ersetzen Sie durch das gleiche cmon-MySQL-Passwort wie im mysql_password-Wert in /etc/cmon.cnf. Wiederholen Sie denselben Schritt auf dem zweiten Cluster, MySQL-Replikation, aber führen Sie ihn nur einmal auf dem Master-Knoten aus.

Sobald die Berechtigung eingerichtet ist, sollten Sie sehen, dass die Clusterliste grün ist, ähnlich wie die alte:

Es ist erwähnenswert, dass ClusterControl standardmäßig die automatische Wiederherstellung des Clusters deaktiviert (wie Sie das rote Symbol neben dem Wort „Cluster“ sehen können), um eine Race-Bedingung mit einer anderen ClusterControl-Instanz zu vermeiden. Es wird empfohlen, diese Funktion zu aktivieren (indem Sie auf das grüne Symbol klicken), sobald der alte Server außer Betrieb genommen wurde.

Unsere Migration ist nun abgeschlossen. Alle Konfigurationen und Einstellungen des alten Servers bleiben erhalten und werden auf den neuen Server übertragen.

Migrieren der Verwaltung eines Clusters auf einen anderen ClusterControl-Server

Cluster-Informationen sichern

Hier geht es darum, Cluster-Metadaten und -Informationen zu sichern, damit wir sie auf einen anderen ClusterControl-Server übertragen können, was auch als Teilsicherung bezeichnet wird. Andernfalls müssen wir sie mit „Vorhandene Server/Cluster importieren“ erneut in das neue ClusterControl importieren, was bedeutet, dass Sie die Überwachungsdaten des alten Servers verlieren würden. Wenn Sie Load Balancer oder asynchrone Slave-Instanzen haben, müssten diese importiert werden, sobald der Cluster importiert wird, Knoten für Knoten. Es ist also ein bisschen umständlich, wenn Sie ein vollständiges Produktionssetup haben.

Die Migrationsübung für den Cluster "Manager" wird im folgenden Diagramm veranschaulicht:

Grundsätzlich möchten wir unsere MySQL-Replikation (Cluster-ID:2) migrieren, um von einer anderen ClusterControl-Instanz verwaltet zu werden. Wir werden dafür die Optionen --save-cluster-info und --restore-cluster-info verwenden. Die Option --save-cluster-info exportiert die entsprechenden Cluster-Informationen, um sie woanders zu speichern. Exportieren wir unseren MySQL-Replikationscluster (Cluster-ID:2). Gehen Sie auf dem aktuellen ClusterControl-Server wie folgt vor:

$ s9s backup \
--save-cluster-info \
--cluster-id=2 \
--backup-directory=$HOME/ccbackup \
--output-file=cc-replication-2.tar.gz \
--log

Sie werden eine Reihe neuer Zeilen im Terminal sehen, die anzeigen, dass der Backup-Job ausgeführt wird (auf die Ausgabe kann auch über ClusterControl -> Activity -> Jobs zugegriffen werden ):

Wenn Sie sich die Jobprotokolle genau ansehen, werden Sie feststellen, dass der Job versucht hat, alle zugehörigen Informationen und Metadaten für Cluster-ID 2 zu exportieren. Die Ausgabe wird als komprimierte Datei gespeichert und befindet sich unter dem Pfad, den wir unter Verwendung von --backup angegeben haben -Verzeichnis-Flag. Wenn dieses Flag ignoriert wird, speichert ClusterControl die Ausgabe im Standard-Backup-Verzeichnis, das das Home-Verzeichnis des SSH-Benutzers ist, unter $HOME/backups.

Cluster-Informationen wiederherstellen

Die hier erläuterten Schritte ähneln den Wiederherstellungsschritten für die ClusterControl-Vollsicherung. Übertragen Sie das Backup vom aktuellen Server auf den anderen ClusterControl-Server:

$ scp $HOME/ccbackup/cc-replication-2.tar.gz 192.168.0.190:~

Bevor wir die Wiederherstellung durchführen, müssen wir passwortloses SSH zu allen Knoten vom neuen ClusterControl-Server einrichten:

$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2
$ ssh-copy-id 192.168.0.19 #prometheus cluster 2

Führen Sie dann auf dem neuen Server die Wiederherstellung der Clusterinformationen für unsere MySQL-Replikation durch:

$ s9s backup \
--restore-cluster-info \
--input-file=$HOME/cc-replication-2.tar.gz \
--log

Sie können den Fortschritt unter Aktivität -> Jobs -> Cluster wiederherstellen überprüfen :

Wenn Sie sich die Auftragsmeldungen genau ansehen, können Sie sehen, dass ClusterControl die Cluster-ID auf dieser neuen Instanz automatisch auf 1 neu zuweist (auf der alten Instanz war es Cluster-ID 2).

Synchronisieren Sie dann den Cluster in der Benutzeroberfläche, indem Sie zu Globale Einstellungen -> Clusterregistrierungen -> Cluster synchronisieren gehen . Wenn Sie zum Haupt-Dashboard von ClusterControl zurückkehren, sehen Sie Folgendes:

Der Fehler bedeutet, dass die neue ClusterControl-Benutzeroberfläche die Überwachungs- und Verwaltungsdaten aufgrund eines falschen RPC-API-Tokens nicht abrufen kann. Wir müssen es nur entsprechend aktualisieren. Rufen Sie zunächst den rpc_key-Wert für unsere Cluster-ID 1 ab:

$ cat /etc/cmon.d/cmon_1.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=tAnvKME53N1n8vCC

Klicken Sie in der Benutzeroberfläche auf den Link „hier“ am Ende der Zeile „Change the RPC API token here“. Es öffnet sich folgender Dialog:

Fügen Sie den entsprechenden rpc_key-Wert in das Textfeld ein und klicken Sie auf Speichern. Warten Sie einen Moment und die Clusterliste sollte automatisch aktualisiert werden.

Der letzte Schritt besteht darin, die MySQL cmon-Benutzerrechte für die neuen Änderungen der ClusterControl-IP-Adresse, 192.168.0.190, zu korrigieren. Melden Sie sich beim Master-Knoten (192.168.0.31) an und führen Sie die folgende Anweisung aus:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** Ersetzen Sie durch das gleiche cmon-MySQL-Passwort wie im mysql_password-Wert in /etc/cmon.cnf.

Sie können auch die alten Benutzerrechte widerrufen (der Benutzer wird durch das Widerrufen nicht gelöscht) oder den alten Benutzer einfach löschen:

$ mysql -uroot -p -e 'DROP USER [email protected]"192.168.0.19"'

Sobald die Berechtigung eingerichtet ist, sollten Sie sehen, dass alles grün ist:

An diesem Punkt sieht unsere Architektur in etwa so aus:

Unsere Migrationsübung ist jetzt abgeschlossen.

Abschließende Gedanken

Es ist jetzt möglich, vollständige und teilweise Sicherungen Ihrer ClusterControl-Instanzen und der von ihnen verwalteten Cluster durchzuführen, sodass Sie sie mit geringem Aufwand frei zwischen Hosts verschieben können. Vorschläge und Feedback sind willkommen.