So planen Sie Datenbanksicherungen mit ClusterControl

Die Datenbanksicherung ist ein kritischer Teil der Datenbankverwaltung und muss sorgfältig geplant werden. Es reicht nicht aus, ein Backup zu planen, Backup-Daten müssen auch auf Konsistenz und Integrität überprüft werden. Es gibt andere Überlegungen wie Verschlüsselung und Offsite-Archivierung. Ein guter Sicherungsmanager hätte Funktionen, die all diese unterschiedlichen Überlegungen berücksichtigen.

In diesem Blogbeitrag werden wir untersuchen, wie Sie Ihre Datenbanksicherungen mit ClusterControl planen können.

Datenbanksicherungen mit ClusterControl

ClusterControl unterstützt je nach Clustertyp eine Reihe von Backup-Methoden, wie in der folgenden Tabelle zusammengefasst:

Beim Planen der Sicherung mit ClusterControl kann jede der Sicherungsmethoden mit einer Reihe von Optionen konfiguriert werden, wie die Sicherung ausgeführt werden soll. Unterschiedliche Datenbank-Workloads und Sicherungsstrategien würden die Unterstützung verschiedener Funktionen erfordern, zum Beispiel:

• Festplatten-IOPS-Drosselung
• Netzwerkdrosselung
• Sicherungssperren
• Verschlüsselung
• Komprimierung
• Aufbewahrungsfrist
• Verifizierung

ClusterControl stellt automatisch eine Reihe von Backup-Optionen ein, die den Best Practices des jeweiligen Datenbankanbieters folgen. Wenn für den Zieldatenbankknoten beispielsweise das Binärprotokoll aktiviert ist, wird ein zusätzliches Flag --master-data angehängt um die binären Protokollkoordinaten (Dateiname und Position) des gedumpten Servers einzuschließen. Wenn es sich um einen Galera-Knoten handelt und die Sicherungsmethode xtrabackup ist, hängt ClusterControl ein zusätzliches Flag an, --galera-info die den Zustand des lokalen Knotens zum Zeitpunkt der Sicherung enthält.

Planen einer Sicherung

Bevor wir ein Backup planen, müssen wir planen, wie der Backup-Vorgang ablaufen soll. Die Beantwortung der folgenden Beispielfragen wäre hilfreich, bevor Sie einen Backup-Zeitplan erstellen:

• Welche Sicherungsmethode möchten Sie verwenden? Einige Backup-Methoden sind nicht blockierend, aber sehr ressourcenintensiv. Verstehen Sie die Kompromisse, damit Sie nicht überrascht sind, wie sich der Prozess in der Produktion verhält.
• Wie oft möchten Sie Ihre Datenbanken sichern? Das Ausführen einer vollständigen Sicherung kann schmerzhaft sein, wenn das Sicherungsintervall zu kurz ist. Wahrscheinlich benötigen Sie eine Mischung aus vollständigen und inkrementellen Sicherungen.
• Wie schnell möchten Sie Ihre Daten wiederherstellen? Die physische Sicherung ist in Bezug auf die vollständige Wiederherstellungszeit normalerweise viel schneller als die logische Sicherung. Andererseits ist eine logische Sicherung bei einer teilweisen Wiederherstellung normalerweise schneller.
• Wie groß ist Ihre Datengröße? In manchen Fällen ist die logische Sicherung für große Datenbanken keine gute Wahl, und die binäre Sicherung ist die einzige Möglichkeit.
• Wie viel freier Speicherplatz steht Ihnen zum Speichern Ihrer Sicherung zur Verfügung? Backups neigen dazu, viel Platz zu verbrauchen. Entscheiden Sie, ob eine Komprimierung erforderlich ist und welche Komprimierungsstufe Sie sich leisten können. Eine bessere Komprimierung erfordert eine höhere CPU-Auslastung.
• Was ist, wenn der Sicherungsserver während der Sicherungszeit ausfällt? Soll das Backup auf einen anderen verfügbaren Host umgeschaltet werden? Das Überspringen eines Backups aufgrund eines Wartungsfensters ist normalerweise keine gute Idee.
• Wie kann die Integrität des erstellten Backups sichergestellt werden? Denken Sie daran, dass ein Backup kein Backup ist, wenn es nicht wiederherstellbar ist.
• Vertrauen Sie dem Sicherungsspeicher? Verschlüsselung kann eine gute Idee sein, um Ihre Daten zu schützen.

Im Allgemeinen können wir durch die Beantwortung dieser Fragen eine geeignete Sicherungsstrategie entwickeln. Die Liste der Fragen könnte je nach Ihrer Sicherungs- und Wiederherstellungsrichtlinie länger sein.

Wir haben dieses Kapitel ausführlich in unserem Whitepaper The DevOps Guide to Database Backups for MySQL and MariaDB behandelt.

Planen einer Sicherung
 

Mit ClusterControl ist die Planung ziemlich einfach. Gehen Sie direkt zu Backup -> Backup erstellen -> Backup planen und Ihnen wird das folgende Dialogfeld angezeigt:

Je nach Clustertyp können die Optionen unterschiedlich sein, wie in den folgenden Screenshots für PostgreSQL und MongoDB gezeigt:

Die meisten Optionen sind selbsterklärend und werden im Benutzerhandbuch ausführlich behandelt. Sobald der Zeitplan erstellt ist, können Sie die Konfigurationssicherungen bearbeiten, die Sicherung aktivieren/deaktivieren oder den Zeitplan auf der Registerkarte „Geplante Sicherungen“ löschen:

Beachten Sie beim Planen von Backups mit ClusterControl, dass alle Zeiten in der UTC-Zeitzone des ClusterControl-Servers geplant werden müssen. Der Grund dafür ist, die Verwirrung der Backup-Ausführungszeit zu beseitigen. Bei der Arbeit mit einem Cluster könnten die Datenbankserver in verschiedenen Zeitzonen und verschiedenen geografischen Gebieten verteilt sein. Die Verwendung einer Referenzzeitzone zur Verwaltung aller stellt sicher, dass die Sicherungen immer zur richtigen Zeit ausgeführt werden.

Sie können den Fortschritt eines Backups überwachen, indem Sie zu Aktivität -> Jobs schauen, sobald die Zeit gekommen ist. Wenn der Sicherungsjob fehlgeschlagen ist, sehen Sie den Fehler sofort:

Auf das obige Protokoll kann auch unter der Registerkarte „Backup“ in jedem Backup-Eintrag zugegriffen werden:

Prüfungen und Verifizierung nach der Sicherung

Sobald der Backup-Auftrag abgeschlossen ist, bedeutet dies nicht, dass Ihre Verantwortung zu Ende ist. Es gibt ein paar Dinge, denen nachgegangen werden muss. Der wichtigste ist der Zustand des erstellten Backups. ClusterControl bietet E-Mail-Benachrichtigungen und benachrichtigt Sie über den Status. Dieser Benachrichtigungsdienst ist natürlich basierend auf dem Schweregrad unter Einstellungen -> Allgemeine Einstellungen -> E-Mail-Benachrichtigungseinstellungen -> Backup:

Liefern bedeutet, dass ClusterControl sofort eine E-Mail-Benachrichtigung sendet, nachdem ein Alarm für diese Komponente ausgelöst wurde. Sie können es auch als Ignorieren oder Digest konfigurieren, wobei ClusterControl eine tägliche Zusammenfassung der ausgelösten Alarme sendet.

Wenn das Backup erfolgreich erstellt wurde, wird dringend empfohlen, zu überprüfen, ob das Backup wiederherstellbar ist. Sie können die Backup-Verifizierungsfunktion verwenden, indem Sie auf die Schaltfläche „Wiederherstellen“ der ausgewählten Backup-ID klicken, und Ihnen werden zwei Wiederherstellungsoptionen angezeigt:

"Auf eigenständigem Host wiederherstellen und überprüfen" erfordert einen separaten Host, der nicht bereits Teil der Datenbankeinrichtung ist. ClusterControl stellt zunächst eine MySQL-Instanz auf dem Zielhost bereit, startet den Dienst, kopiert das Backup aus dem Backup-Repository und startet die Wiederherstellung. Sobald dies erledigt ist, haben Sie die Möglichkeit, den Server nach der Wiederherstellung entweder herunterzufahren oder ihn laufen zu lassen, damit Sie weitere Untersuchungen auf dem Server durchführen können.

Die Haushaltsführung ist ebenfalls wichtig, um nur die nützlichen Backups in Ihrem Speicher zu behalten. Konfigurieren Sie daher die Backup-Aufbewahrung nach Bedarf. Standardmäßig löscht ClusterControl Backups, die älter als 30 Tage sind. Sie können auch jeden Sicherungszeitplan mit unterschiedlichen Aufbewahrungsfristen anpassen.

Wenn der Backup-Speicher sich einer Speicherplatzgrenze nähert oder Sie Ihr Backup außerhalb archivieren möchten, können Sie die Datei manuell löschen, indem Sie auf das Papierkorbsymbol klicken, oder sie in die Cloud hochladen, wie unten hervorgehoben:

Zum Zeitpunkt der Erstellung dieses Artikels werden AWS S3 und GCP Cloud Storage unterstützt. Die Cloud-Anmeldeinformationen müssen unter Seitenmenü -> Integrationen -> Cloud-Anbieter vorkonfiguriert werden.

Das ist es, Leute. Viel Spaß beim Clustern!