Vollständige Wiederherstellung eines MySQL- oder MariaDB Galera-Clusters aus einer Sicherung

Das Durchführen regelmäßiger Sicherungen Ihres Datenbankclusters ist für Hochverfügbarkeit und Notfallwiederherstellung unerlässlich. Wenn Sie aus irgendeinem Grund Ihren gesamten Cluster verloren haben und eine vollständige Wiederherstellung aus einem Backup durchführen müssten, benötigen Sie ein zuverlässiges und aktuelles Backup, um damit zu beginnen.

Best Practices für Backups

Einige Empfehlungen für ein gutes geplantes Sicherungsregime:

• Sie sollten in der Lage sein, sich nach einem katastrophalen Ausfall von mindestens zwei vorherigen vollständigen Sicherungen vollständig zu erholen. Nur für den Fall, dass die letzte vollständige Sicherung beschädigt, verloren oder beschädigt ist,
• Ihr Backup sollte mindestens ein vollständiges Backup innerhalb eines gewählten Zyklus enthalten, normalerweise wöchentlich,
• Speichern Sie Backups außerhalb des aktuellen Datenspeicherorts, vorzugsweise außerhalb des Standorts,
• Verwenden Sie für zusätzliche Sicherheit eine Mischung aus mysqldump und Xtrabackup und verlassen Sie sich nicht auf eine Methode
• Testen Sie Ihre Sicherungen regelmäßig, z. alle zwei Monate.

Eine wöchentliche vollständige Sicherung in Kombination mit einer täglichen inkrementellen Sicherung ist normalerweise ausreichend. Es ist immer ein guter Plan, eine Reihe von Backups über einen bestimmten Zeitraum aufzubewahren, vielleicht bewahren Sie jedes wöchentliche Backup einen Monat lang auf. Auf diese Weise können Sie im Notfall oder aus irgendeinem Grund eine Beschädigung der lokalen Sicherungsdatei auf eine ältere Datenbank zurücksetzen.

mysqldump oder Xtrabackup

mysqldump ist wahrscheinlich die beliebteste Art, MySQL zu sichern. Es führt eine logische Sicherung der Daten durch, liest aus jeder Tabelle mithilfe von SQL-Anweisungen und exportiert dann die Daten in Textdateien. Wiederherstellung eines mysqldump ist so einfach wie das Erstellen der Dump-Datei. Die Hauptnachteile sind, dass es für große Datenbanken sehr langsam ist, nicht „heiß“ ist und den InnoDB-Pufferpool leert.

Xtrabackup führt Hot-Backups durch, sperrt die Datenbank während des Backups nicht und ist im Allgemeinen schneller. Hot Backups sind wichtig für Hochverfügbarkeit, da sie ausgeführt werden, ohne die Anwendung zu blockieren. Dies ist auch beim Einsatz mit Galera ein wichtiger Faktor, da Galera auf synchrone Replikation setzt. Das Wiederherstellen eines xtrabackup kann jedoch auf manuelle Weise etwas schwierig sein.

ClusterControl unterstützt die Planung von sowohl mysqldump als auch Xtrabackup (vollständig und inkrementell) sowie die Backup-Wiederherstellung direkt über die Benutzeroberfläche.

Vollständige Wiederherstellung aus Backup

In diesem Beitrag zeigen wir Ihnen, wie Sie Xtrabackup (vollständig + inkrementell) auf einem leeren Cluster wiederherstellen, der auf MariaDB Galera Cluster ausgeführt wird. Diese Schritte sollten auch auf Percona XtraDB Cluster oder Galera Cluster for MySQL von Codership funktionieren.

In unserem ursprünglichen Cluster war täglich ein vollständiges xtrabackup geplant, wobei stündlich inkrementelle Backups erstellt wurden. Die Backups werden wie im folgenden Screenshot gezeigt auf ClusterControl gespeichert:

Nehmen wir nun an, wir haben unseren ursprünglichen Cluster verloren und müssen eine vollständige Wiederherstellung auf einem neuen Cluster durchführen. Die Schritte umfassen:

0. Richten Sie einen neuen ClusterControl-Server ein.
1. Richten Sie einen neuen MariaDB-Cluster ein.
2. Exportieren Sie die Sicherungsdatensätze und -dateien auf den neuen ClusterControl-Server.
3. Starten Sie den Wiederherstellungsprozess.
4. Starten Sie die verbleibenden Knoten.

Das folgende Diagramm veranschaulicht unsere Architektur für diese Übung:

Schritt 1 – Neuen MariaDB-Cluster einrichten

Installieren Sie ClusterControl und stellen Sie einen neuen MariaDB-Cluster bereit. Gehen Sie zu ClusterControl -> Deploy -> Deploy Database Cluster -> MySQL Galera und geben Sie die erforderlichen Informationen im Deployment-Dialog an:

Klicken Sie auf die Schaltfläche Bereitstellen und starten Sie die Bereitstellung. Da wir nur einen Cluster auf dem alten Server haben, sollte die Cluster-ID in dieser neuen Instanz identisch sein (Cluster-ID:1).

Exportieren Sie auf dem alten ClusterControl-Server die Tabelle backup_records in Dump-Dateien:

$ mysqldump -uroot -p --single-transaction --no-create-info cmon backup_records > backup_records.sql

Führen Sie dann eine Remote-Kopie der Sicherungsdateien vom alten Server auf den neuen ClusterControl-Server durch:

$ scp -r /root/backups 192.168.55.150:/root/
$ scp ~/backup_records.sql 192.168.55.150:~

Als Nächstes ändern Sie die Speicherauszugsdateien, damit sie die neue IP-Adresse des ClusterControl-Servers widerspiegeln. Vergessen Sie nicht, den Punkt in der IP-Adresse zu maskieren:

$ sed -i "s/192\.168\.55\.170/192\.168\.55\.150/g" backup_records.sql

Importieren Sie auf dem neuen ClusterControl-Server die Dump-Dateien:

$ mysql -uroot -p cmon < backup_records.sql

Überprüfen Sie, ob die Sicherungsliste im neuen ClusterControl-Server korrekt ist:

Wie Sie sehen können, wurden alle Vorkommen der vorherigen IP-Adresse (192.168.55.170) durch die neue IP-Adresse (192.168.55.150) ersetzt. Jetzt können wir die Wiederherstellung auf dem neuen Server durchführen.

Schritt 3 – Führen Sie die Wiederherstellung durch

Die Wiederherstellung über die ClusterControl-Benutzeroberfläche ist ein einfacher Point-and-Click-Schritt. Wählen Sie aus, welches Backup wiederhergestellt werden soll, und klicken Sie auf die Schaltfläche „Wiederherstellen“. Wir werden das neueste verfügbare inkrementelle Backup wiederherstellen (Backup:9). Klicken Sie auf die Schaltfläche „Wiederherstellen“ direkt unter dem Backup-Namen und Ihnen wird der folgende Vorab-Wiederherstellungsdialog angezeigt:

Sieht so aus, als ob die Backup-Größe ziemlich klein ist (165,6 kB). Es spielt keine Rolle, da ClusterControl alle inkrementellen Backups vorbereitet, die unter Backup-Set 6 gruppiert sind, das das vollständige Xtrabackup enthält. Sie haben auch mehrere Optionen nach der Wiederherstellung:

• Backup wiederherstellen auf – Wählen Sie den Knoten, auf dem das Backup wiederhergestellt werden soll.
• Tmp Dir - Verzeichnis wird auf dem lokalen ClusterControl-Server als temporärer Speicher während der Backup-Vorbereitung verwendet. Es muss so groß sein wie das geschätzte MySQL-Datenverzeichnis.
• Bootstrap-Cluster vom wiederhergestellten Knoten – Da dies ein neuer Cluster ist, schalten wir dies ein, damit ClusterControl den Cluster automatisch bootet, nachdem die Wiederherstellung erfolgreich war.
• Erstellen Sie eine Kopie des Datenverzeichnisses, bevor Sie das Backup wiederherstellen – Wenn die wiederhergestellten Daten beschädigt sind oder nicht Ihren Erwartungen entsprechen, haben Sie ein Backup des vorherigen MySQL-Datenverzeichnisses. Da dies ein neuer Cluster ist, werden wir diesen ignorieren.

Die Percona Xtrabackup-Wiederherstellung führt dazu, dass der Cluster gestoppt wird. ClusterControl wird:

1. Alle Knoten im Cluster stoppen.
2. Stellen Sie die Sicherung auf dem ausgewählten Knoten wieder her.
3. Bootstrapping des ausgewählten Knotens.

Um den Fortschritt der Wiederherstellung anzuzeigen, gehen Sie zu Aktivität -> Jobs -> Sicherung wiederherstellen und klicken Sie auf die Schaltfläche „Vollständige Jobdetails“. Sie sollten so etwas sehen:

Eine wichtige Sache, die Sie tun müssen, ist, die Ausgabe des MySQL-Fehlerprotokolls auf dem Zielknoten (192.168.55.151) während des Wiederherstellungsprozesses zu überwachen. Nach Abschluss der Wiederherstellung und während des Bootstrapping-Prozesses sollten die folgenden Zeilen beginnen zu erscheinen:

Version: '10.1.22-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:52 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:53 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:54 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:55 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)

Keine Panik. Dies ist ein erwartetes Verhalten, da dieser Sicherungssatz die cmon-Anmeldeinformationen des neuen ClusterControl-cmon-Passworts nicht speichert. Es hat stattdessen den alten cmon-Benutzer wiederhergestellt/ersetzt. Was Sie tun müssen, ist, den Benutzer cmon wieder an den Server zurückzugeben, indem Sie die folgende Anweisung auf diesem DB-Knoten ausführen:

GRANT ALL PRIVILEGES ON *.* to [email protected]'192.168.55.150' IDENTIFIED BY 'mynewCMONpassw0rd' WITH GRANT OPTION;
FLUSH PRIVILEGES;

ClusterControl wäre dann in der Lage, sich mit dem Bootstrap-Knoten zu verbinden und den Knoten- und Backup-Status zu bestimmen. Wenn alles in Ordnung ist, sollten Sie so etwas sehen:

An diesem Punkt wird der Zielknoten gebootstrapped und ausgeführt. Wir können die verbleibenden Knoten unter Knoten starten -> Knoten auswählen -> Knoten starten und das Kontrollkästchen „Perform an Initial Start“ aktivieren:

Die Wiederherstellung ist nun abgeschlossen und Sie können davon ausgehen, dass Leistung -> DB-Wachstum die aktualisierte Größe unseres neu wiederhergestellten Datensatzes meldet:

Viel Spaß beim Wiederherstellen!