Der Kern von ClusterControl ist die Automatisierung, ebenso wie die Sicherstellung, dass Ihre Daten sicher gesichert und zur Wiederherstellung bereit sind, wenn etwas schief geht. Eine effektive Sicherungsstrategie und ein Disaster-Recovery-Plan sind der Schlüssel zum Erfolg jeder Anwendung oder Umgebung.
In unserer neuesten Version, ClusterControl 1.5, haben wir eine Reihe von Verbesserungen für die Sicherung von MySQL- und MariaDB-basierten Systemen eingeführt.
Eine der wichtigsten Verbesserungen ist die Möglichkeit, Backups von ClusterControl zum Cloud-Anbieter Ihrer Wahl zu erstellen. Cloud-Anbieter wie Google Cloud Services und Amazon S3 bieten jeweils praktisch unbegrenzten Speicherplatz und reduzieren so den lokalen Platzbedarf. Auf diese Weise können Sie Ihre Sicherungsdateien länger aufbewahren, so lange Sie möchten, und sich keine Sorgen um den lokalen Speicherplatz machen müssen.
Lassen Sie uns all die aufregenden neuen Sicherungsfunktionen für ClusterControl 1.5 erkunden...
Neugestaltung des Sicherungs-/Wiederherstellungsassistenten
Zunächst werden Sie feststellen, dass die Sicherungs- und Wiederherstellungsassistenten überarbeitet wurden, um die Benutzererfahrung zu verbessern. Es wird nun als Seitenmenü auf der rechten Seite des Bildschirms geladen:
Die Backup-Liste erhält auch eine kleine Optimierung, bei der Backup-Details angezeigt werden, wenn Sie auf das jeweilige Backup klicken:
Sie können den Sicherungsspeicherort anzeigen und welche Datenbanken sich in der Sicherung befinden. Es gibt auch Optionen, um das Backup wiederherzustellen oder es in die Cloud hochzuladen.
PITR-kompatibles Backup
ClusterControl führt die standardmäßige mysqldump-Sicherung mit separaten Schema- und Datendumps durch. Dies erleichtert die Wiederherstellung von Teilsicherungen. Es bricht jedoch die Konsistenz des Backups (Schema und Daten werden in zwei separaten Sitzungen ausgegeben), daher kann es nicht verwendet werden, um eine Slave- oder Point-in-Time-Wiederherstellung bereitzustellen.
Ein mysqldump PITR-kompatibles Backup enthält eine einzelne Dump-Datei mit GTID-Informationen, Binlog-Datei und Position. Daher ist nur für den Datenbankknoten, der das Binärprotokoll erstellt, die Option „PITR-kompatibel“ verfügbar, wie im folgenden Screenshot hervorgehoben:
Wenn die Option „PITR-kompatibel“ aktiviert ist, sind die Datenbank- und Tabellenfelder ausgegraut, da ClusterControl immer die Sicherung aller Datenbanken, Ereignisse, Trigger und Routinen des Ziel-MySQL-Servers durchführt.
Die folgenden Zeilen erscheinen in den ersten ~50 Zeilen der fertigen Dump-Datei:
$ head -50 mysqldump_2017-11-07_072250_complete.sql
...
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='20dc5247-4a98-ee18-73af-5c79373388ee:1-1681';
--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=2457790;
...Die Informationen können verwendet werden, um Slaves aus einer Sicherung zu erstellen oder eine Point-in-Time-Wiederherstellung zusammen mit Binärprotokollen durchzuführen, wobei Sie die Wiederherstellung aus den in der Dump-Datei gemeldeten MASTER_LOG_FILE und MASTER_LOG_POS mit dem Dienstprogramm "mysqlbinlog" starten können. Beachten Sie, dass Binärlogs nicht von ClusterControl gesichert werden.
Slaves aus Backup erstellen Eine weitere Funktion ist die Möglichkeit, einen Slave direkt aus einem PITR-kompatiblen Backup zu erstellen, anstatt dies von einem ausgewählten Master aus zu tun. Dies ist ein großer Vorteil, da es den Master-Server entlastet. Diese Option kann mit MySQL Replication oder Galera Cluster verwendet werden. Ein vorhandenes Backup kann verwendet werden, um einen vorhandenen Replikations-Slave neu zu erstellen oder während der Staging-Phase einen neuen Replikations-Slave hinzuzufügen, wie im folgenden Screenshot gezeigt:
Sobald die Bereitstellung abgeschlossen ist, verbindet sich der Slave mit dem ausgewählten Master und beginnt mit dem Aufholen. Zuvor führte ClusterControl mit Percona Xtrabackup ein Streaming-Backup direkt vom ausgewählten Master durch. Dies könnte die Leistung des Masters beeinträchtigen, wenn ein großes Dataset skaliert wird, obwohl der Vorgang auf dem Master nicht blockiert wird. Mit der neuen Option werden, wenn das Backup auf ClusterControl gespeichert wird, nur diese Hosts (ClusterControl + der Slave) damit beschäftigt, die Daten auf dem Slave bereitzustellen.
Sichern in der Cloud
Backups können jetzt automatisch in die Cloud hochgeladen werden. Dazu muss ein ClusterControl-Modul namens clustercontrol-cloud installiert werden (Cloud-Integrationsmodul) und clustercontrol-clud (Cloud-Download/Upload-CLI), die in v1.5 und höher verfügbar sind. Die Upgrade-Anweisungen sind in diesen Paketen enthalten und sie werden ohne zusätzliche Konfiguration geliefert. Derzeit sind die unterstützten Cloud-Plattformen Amazon Web Services und Google Cloud Platform. Cloud-Anmeldeinformationen werden unter ClusterControl -> Einstellungen -> Integrationen -> Cloud-Anbieter konfiguriert.
Beim Erstellen oder Planen eines Backups sollten die folgenden zusätzlichen Optionen angezeigt werden, wenn „Backup in die Cloud hochladen“ aktiviert ist:
Die Funktion ermöglicht einen einmaligen Upload oder das Planen von Sicherungen, die nach Abschluss hochgeladen werden (Amazon S3 oder Google Cloud Storage). Sie können die Sicherungen dann nach Bedarf herunterladen und wiederherstellen.
Benutzerdefinierte Komprimierung für mysqldump
Diese Funktion wurde tatsächlich erstmals mit ClusterControl v1.4.2 nach dessen Veröffentlichung eingeführt. Wir haben eine Backup-Komprimierungsstufe basierend auf gzip hinzugefügt. Zuvor verwendete ClusterControl die standardmäßige Sicherungskomprimierung (Stufe 6), wenn sich das Sicherungsziel auf dem Controller-Knoten befand. Die niedrigste Komprimierung (Stufe 1 – schnellste, geringere Komprimierung) wurde verwendet, wenn sich das Sicherungsziel auf dem Datenbankhost selbst befand, um sicherzustellen, dass die Datenbank während des Komprimierungsvorgangs nur minimal beeinträchtigt wird.
In dieser Version haben wir den Komprimierungsaspekt verfeinert und Sie können jetzt die Komprimierungsstufe unabhängig vom Sicherungsziel anpassen. Wenn Sie Ihre ClusterControl-Instanz aktualisieren, werden alle geplanten Backups automatisch auf Level 6 konvertiert, es sei denn, Sie bearbeiten sie explizit in v1.5.
Die Backup-Komprimierung ist unerlässlich, wenn Ihr Dataset groß ist, kombiniert mit einer langen Backup-Aufbewahrungsrichtlinie, während der Speicherplatz begrenzt ist. Mysqldump, das textbasiert ist, kann von der Komprimierung mit Einsparungen von bis zu 60 % des Speicherplatzes der ursprünglichen Dateigröße profitieren. In manchen Fällen ist die höchste Komprimierungsrate die beste Option, obwohl sie bei der Wiederherstellung mit einer längeren Dekomprimierung verbunden ist.
Bonusfunktion:Automatische Sicherungsüberprüfung
Wie alte Systemadministratoren sagen:Ein Backup ist kein Backup, wenn es nicht wiederherstellbar ist. Die Backup-Überprüfung wird normalerweise von vielen vernachlässigt. Einige Systemadministratoren haben dafür eigene Routinen entwickelt, die normalerweise eher manuell als automatisiert sind. Die Automatisierung ist schwierig, hauptsächlich aufgrund der Komplexität des gesamten Vorgangs – angefangen bei der Bereitstellung des Hosts, der Installation und Vorbereitung von MySQL, der Übertragung von Sicherungsdateien, der Dekomprimierung, dem Wiederherstellungsvorgang, den Überprüfungsverfahren und der abschließenden Bereinigung des Systems nach dem Vorgang. All diese Probleme führen dazu, dass Menschen einen so wichtigen Aspekt eines zuverlässigen Backups vernachlässigen. Im Allgemeinen sollte mindestens einmal im Monat oder bei wesentlichen Änderungen der Datengröße oder Datenbankstruktur ein Backup-Wiederherstellungstest durchgeführt werden. Finden Sie einen Zeitplan, der für Sie funktioniert, und formalisieren Sie ihn mit einem geplanten Ereignis.
ClusterControl kann die Backup-Überprüfung automatisieren, indem die Wiederherstellung auf einem neuen Host durchgeführt wird, ohne die oben genannten Überprüfungsverfahren zu beeinträchtigen. Dies kann mit einer gewissen Verzögerung oder direkt nach Abschluss der Sicherung erfolgen. Es meldet den Backup-Status basierend auf dem Exit-Code des Wiederherstellungsvorgangs, führt ein automatisches Herunterfahren durch, wenn das Backup verifiziert ist, oder lässt den wiederhergestellten Host einfach laufen, damit Sie zusätzliche manuelle Überprüfungen der Daten durchführen.
Beim Erstellen oder Planen einer Sicherung haben Sie zusätzliche Optionen, wenn "Sicherung überprüfen" aktiviert ist:
Wenn „Datenbanksoftware installieren“ aktiviert ist, entfernt ClusterControl alle vorhandenen MySQL-Installationen auf dem Zielhost und installiert die Datenbanksoftware mit derselben Version wie der vorhandene MySQL-Server neu. Andernfalls können Sie diese Option überspringen, wenn Sie eine bestimmte Einrichtung für den wiederhergestellten Host haben. Die restlichen Optionen sind selbsterklärend.
Bonusfunktion:PostgreSQL nicht vergessen
Zusätzlich zu all diesen großartigen Funktionen für MySQL und MariaDB bietet ClusterControl 1.5 PostgreSQL jetzt auch eine zusätzliche Backup-Methode (pg_basebackup), die für Online-Binär-Backups verwendet werden kann. Mit pg_basebackup erstellte Sicherungen können später für die Point-in-Time-Wiederherstellung und als Ausgangspunkt für Standby-Server für Protokollversand oder Streaming-Replikation verwendet werden.
Das war es jetzt. Probieren Sie ClusterControl v1.5 aus, spielen Sie mit den neuen Funktionen herum und teilen Sie uns Ihre Meinung mit.
