Mysql
 sql >> Datenbank >  >> RDS >> Mysql

Erfolgreiche Sicherungs- und Wiederherstellungsstrategien für MySQL/MariaDB

Ein wesentlicher Bestandteil der Vermeidung von Datenverlusten in jeder Situation sind geeignete Sicherungs- und Wiederherstellungsrichtlinien. Es ist auch wichtig, die Datenwiederherstellung zu jedem Zeitpunkt des Lebenszyklus des Anwendungs-Workflows sicherzustellen. Sowohl MySQL als auch MariaDB bieten Lösungen für diese Fälle. In diesem Artikel werden die bestehenden Optionen und Verfahren sowie andere potenzielle Backup-Optionen für MySQL und MariaDB untersucht.

Sicherungsstrategien

Da Daten der wichtigste Teil jeder Anwendung sind, ist der Schutz ihrer Integrität von entscheidender Bedeutung, um im Kampf ums Überleben zu überleben. Jede Unterbrechung des Datenzugriffs oder der Datenintegrität für einen beliebigen Zeitraum kann der Anwendung und dem Unternehmen/Dienst, den sie bereitstellt, ernsthaft schaden.

Um einen erfolgreichen Anwendungsworkflow und Geschäftskontinuität zu gewährleisten, müssen Sie geeignete Sicherungs- und Wiederherstellungsrichtlinien mit täglichen, wöchentlichen, monatlichen und jährlichen Sicherungen implementieren. Solche Sicherungen werden zu kritischen Zeiten ausgeführt, wie z. B.:

  • vor einem täglichen Batchfenster;
  • vor massiver Datenaufnahme;
  • vor einem Anwendungs-Upgrade;
  • wöchentliche, monatliche und jährliche Sicherungen zur Erfüllung behördlicher Auflagen;
  • oder andere täglich/wöchentlich geplante Wartungsarbeiten.

Backup-Tools

MySQL und MariaDB bieten mehrere Möglichkeiten zum Einrichten und Ausführen von Sicherungs- und Wiederherstellungsplänen. Zu diesen Methoden gehören physische Backups mit dem MySQL Enterprise mysqlbackup-Tool , mariabackup-Tool von MariaDB , oder XtraBackup-Tool von Percona . Außerdem logische Sicherungen, die mit dem mysqldump-Tool von Mysql erstellt wurden kann sich als nützlich erweisen. Eine weitere Option ist die Point-in-Time-Wiederherstellung mit den Datenbank-Bin-Logs (den Transaktionsprotokollen) in Kombination mit den zuvor erwähnten Tools.

Sie können geeignete Methoden in Ihre Sicherungsstrategie integrieren, um die Wiederherstellbarkeit der Datenbank im Falle eines Ausfalls oder einer Katastrophe zu maximieren.

Hinweis:In der MariaDB-Version 10.4.6, symlink von mysqldump heißt mariadb-dump . In den späteren Versionen, einschließlich 10.5.2, änderten sich die Namen erneut – mysqldump wurde symlink .

Um die Verfahren zu veranschaulichen, werde ich das mariabackup-Tool verwenden um physische Backups zu erstellen. Die grundlegende Funktionalität des Tools ist die gleiche wie bei den oben genannten Tools, obwohl es einige geringfügige Unterschiede gibt, die für jedes Tool einzigartig sind.

Physische Datenbanksicherungen

Physische Sicherungen sind Sicherungen auf Dateiebene, die Ihnen schnelle Dateikopiermethoden bieten. Solche Sicherungen sind in Notfallwiederherstellungsszenarien, beim Klonen von Datenbanken und/oder beim Erstellen von Slave-Datenbanken vorzuziehen.

Wenn Sie physische Sicherungen erstellen, können Sie wählen, ob Sie vollständige oder inkrementelle Sicherungen erstellen möchten. Vollständige Sicherungen umfassen eine vollständige Sicherung des Datenbankservers. Inkrementelle Sicherungen speichern nur Änderungen der letzten vollständigen oder inkrementellen Sicherung.

Wichtig:Die Größe der Datenbank regelt den Zeitpunkt der Sicherung. Aus diesem Grund kann eine gute Strategie zum Sichern einer sehr großen Datenbank darin bestehen, vollständige und inkrementelle Sicherungen zu kombinieren. Auf diese Weise sparen Sie sowohl den Speicherplatz der Sicherungen als auch die gesamte Sicherungs- und Wiederherstellungszeit.

Ein weiterer Punkt, den Sie beachten sollten, ist, dass Sie beim Wiederherstellen der Daten aus einer physischen Sicherung den Prozess Ihrer MySQL/MariaDB-Datenbankinstanz anhalten müssen, bis die letzten Wiederherstellungsschritte abgeschlossen sind.

Die Durchführung einer einfachen physikalischen Vollsicherung können Sie wie folgt durchführen:

 mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220 \
   --user=backupuser --password=backuppasswd

Das –Zielverzeichnis Option teilt dem Backup-Tool mit, wo das Backup abgelegt werden soll.

In diesem Beispiel habe ich mein Backup im Verzeichnis DYYYYMMDD organisiert wo jedes vollständige Backup gespeichert wird (D steht für Daily). Auf diese Weise haben wir eine einfache Möglichkeit, die Datenbank aus der an einem bestimmten Datum erstellten Sicherung wiederherzustellen.

Das nächste Beispiel zeigt die Ausführung eines einfachen inkrementellen Backups:

mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220_inc1/ \
   --incremental-basedir=/data/backups/mariadb/D20210220/ \
   --user=backupuser --password=backuppasswd

Die nachfolgende inkrementelle Sicherung würde wie folgt aussehen:

mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220_inc2/ \
   --incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
   --user=backupuser --password=backuppasswd

Das –inkrementbasierteir weist das Backup-Tool an, das zuvor erstellte vollständige oder inkrementelle Backup als Ausgangspunkt für die Erstellung inkrementeller Delta-Dateien für das aktuelle Backup zu verwenden. Auf diese Weise baut es eine Kette aus einem vollständigen Backup mit nachfolgenden inkrementellen Backups auf. Zusammen bilden sie ein einziges Backup, das bei Bedarf wiederhergestellt werden kann.

Lassen Sie uns nun herausfinden, wie der Name der physischen Datenbankdatei lautet, in der alle Verzeichnisdaten gespeichert sind. Die Datenbank, die sich auf Domänencontrollern befindet, ist ein Active Directory. Dieses Verzeichnis wird verwendet, um Benutzer, Daten usw. zu verwalten. Der Kern eines Active Directory ist die Datenbankdatei NTDS.DIT, die aus Link, Sicherheitsbeschreibung und Datentabellen besteht. Alle Verzeichnisdaten werden in dieser physischen Datenbankdatei gespeichert.

Es ist notwendig, zwischen physischen und logischen Dateien zu unterscheiden. Tatsächliche Systemdaten befinden sich in physischen Dateien, während logische Dateien die Beschreibung von Datensätzen enthalten, die in physischen Dateien gespeichert sind.

Die Aufgabe, die MySQL-Datenbank aus physischen Dateien wiederherzustellen, kann manchmal schwierig sein. Der mysqldump Befehl könnte in diesem Fall hilfreich sein. Wir werden dieses Thema weiter behandeln.

Logische Datenbanksicherungen

Logische Backups werden mit mysqldump erstellt Werkzeug. Diese Sicherungsmethode ist flexibler als eine physische Sicherung. Es besteht aus allen DML- und/oder DDL-SQL-Anweisungen, die zum Erstellen einer konsistenten Sicherung erforderlich sind, und kombiniert alle festgeschriebenen Daten und Änderungen, die vor und während der Sicherung vorgenommen wurden. Wenn Sie mehr darüber erfahren möchten, wie Sie alle Datenbanken sichern und wiederherstellen, können Sie diesen Artikel lesen.

Bei der logischen Sicherung kann es sich um eine einzelne Datei oder mehrere Dateien handeln (die mit einem bestimmten Skript erstellt wurden). Außerdem können Sie die Struktur und/oder Daten wiederherstellen, ohne Ihre MySQL/MariaDB-Instanz (Prozess) herunterzufahren. Dementsprechend werden logische Backups auf Datenbank- und/oder Tabellenebene durchgeführt, während physische Backups auf Dateisystemebene (Verzeichnisse und Dateien) erfolgen.

Beachten Sie auch, dass logische Backups ausschließlich vollständige Backup-Images der vorgesehenen Datenbanken und/oder Tabellen sind.

Eine logische Sicherung der gesamten MySQL/MariaDB-Instanz wird unten erstellt:

mysqldump --all-databases --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/full-backup-$(date +'%Y%m%d_%H%M%S').sql

Beachten Sie, dass physische Backups und logische Backups im Dateisystem speziell für Backup-Verwaltungszwecke unterschieden werden.

Im Gegensatz zum vorherigen Beispiel wird ein logisches Backup einer einzelnen Datenbank (Schema) auf folgende Weise erstellt:

mysqldump empdb --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-full-backup-$(date +'%Y%m%d_%H%M%S').sql

Um schließlich ein logisches Backup einer einzelnen Tabelle in einer Datenbank zu erstellen, fügen Sie den Namen der Tabelle nach der Datenbank hinzu:

mysqldump empdb departments --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-departments-full-backup-$(date +'%Y%m%d_%H%M%S').sql

Wenn Sie die DROP DATABASE- oder DROP TABLE-Anweisungen bearbeiten und zum Wiederherstellungsszenario hinzufügen müssen, kann das Arbeiten mit großen Sicherungsdateien einschränkende Auswirkungen auf Texteditoren haben, bis zu dem Punkt, an dem sie ersticken.

Erwägen Sie in solchen Fällen das Hinzufügen anderer Optionen, wie z. B. –add-drop-database und/oder –add-drop-table diese DROP-Anweisungen in die Sicherung aufzunehmen. In anderen Szenarien möchten Sie diese Anweisungen möglicherweise ausschließen und durch –skip-add-drop-table ersetzen Option zum Befehl.

Sie können die Nur-Daten- oder Nur-DDL-Sicherungen jedoch auch mit –no-create-info erstellen oder –no-data Optionen. Separate Daten- und Struktursicherungen können in einigen Wiederherstellungsszenarien eine gute Wahl sein, insbesondere wenn Sie die DDL-Struktur nur benötigen, um eine leere geklonte Datenbank und/oder ihre Tabellen zu erstellen.

Datenbank mit Festplatten-Snapshots sichern

Wenn die Daten wachsen, kann es notwendig werden, sie auf mehreren Platten und/oder Dateisystemen zu organisieren. Neben den Leistungsgründen müssen Sie sicherstellen, dass effiziente Sicherungs- und Wiederherstellungsstrategien die Festplatten- und Dateisystem-Snapshot-Funktionen beinhalten, da I/O auf mehrere Festplatten/Dateisysteme verteilt wird.

Beginnen Sie mit dem Entwerfen und Erstellen der Dateisystemlayouts, in denen sich jede Datenbank, jede Tabellengruppe und jeder Index befindet. Organisieren Sie dann Ihre Tabellen und konfigurieren Sie das Datenbanksystem. Sie sollten sich entweder alle in einem einzigen Verzeichnis befinden:

innodb_home_dir = /<path where your InnoDB tables will reside>

Oder Sie können das DATA_DIRECTORY verwenden und INDEX_DIRECTORY Optionen im CREATE table-Anweisung, um sie separat an verschiedene Speicherorte im Dateisystem zu verteilen.

Stellen Sie für InnoDB sicher, dass Sie file_per_table =ON verwenden (standardmäßig EIN in den neuesten Versionen). Wählen Sie den Pfad für die InnoDB-Tabellen sorgfältig aus, wenn Sie sie erstellen. Es ist unmöglich, den Pfad zu ändern, ohne die Tabelle zu löschen und neu zu erstellen.

Es ist hilfreich, über geeignete Dateisysteme mit integrierten Snapshot-Funktionen zu verfügen, z. XFS und ZFS unter Linux. Beachten Sie, dass das Erstellen der Snapshot-Sicherungen dem Erstellen physischer Sicherungen ähnelt, aber Besonderheiten aufweist. Es erfordert das Stoppen des Schreibvorgangs (FLUSH with READ LOCK oder ähnliches – siehe BACKUP-STUFE Befehl in der MariaDB-Online-Dokumentation), bevor Sie den Snapshot erstellen und LOCKS freigeben unmittelbar nach Fertigstellung des Snapshots. Es ist notwendig, die Datenkonsistenz zu gewährleisten.

Sie sollten die Snapshot-Sicherungen in Notfallwiederherstellungsszenarien berücksichtigen und verwenden. Sie eignen sich aber auch zum Klonen von Datenbankinstanzen.

Wiederherstellungsstrategien

Wiederherstellung von physischen Sicherungen

Zuvor haben wir die physischen Backup-Schritte beschrieben. Auf diese Weise können Sie entweder eine Kette von vollständigen Sicherungen oder eine Kette von vollständigen und inkrementellen Sicherungen aufbauen. Die letztere Option bedeutet, dass eine vollständige Sicherung, gefolgt von einer anschließenden inkrementellen Sicherung, Nullpunkt ist, wenn ein Fehler auftritt.

Beispielsweise führt ein DBA sonntags vollständige Sicherungen und an anderen Tagen inkrementelle Sicherungen durch. Nach einer inkrementellen Sicherung am Mittwoch tritt ein Fehler auf. Daher müssen sie die Datenbank wiederherstellen. Unter solchen Umständen muss unser DBA die am Sonntag erstellte vollständige Sicherung und die am Montag, Dienstag und Mittwoch erstellten inkrementellen Sicherungen verwenden. Wenn es tägliche vollständige Backups gäbe, würde es ausreichen, das Backup vom Mittwoch wiederherzustellen.

Um nach einem Ausfall das „nächstgelegene“ Backup wiederherzustellen, egal ob es sich um ein vollständiges oder ein inkrementelles Backup handelt, müssen Sie sicherstellen, dass ALLE Backup-Dateien zeitpunktkonsistent sind mit dem Zeitpunkt des nächsten Sicherungsendes. Andernfalls lehnt die InnoDB-Engine die Daten ab, indem sie sie für beschädigt hält.

Ein weiterer wichtiger Punkt ist, wenn Sie Sicherungen vorbereiten, kopieren Sie die betroffenen vollständigen Sicherungen an einen anderen Ort bevor Sie die Schritte anwenden, um die Point-in-Time-Konsistenz sicherzustellen. Auf diese Weise bewahren Sie den ursprünglichen Sicherungszustand, was später nützlich sein kann. Ich empfehle dringend, bei diesem Ansatz zu bleiben.

Um eine vollständige Sicherung vorzubereiten, wählen Sie diejenige aus, die dem Fehler am nächsten liegt, kopieren Sie sie an den bevorzugten Speicherort und führen Sie den folgenden Befehl aus:

mariabackup --prepare \
   --target-dir=data/backups/mariadb/COPY_D20210220

Um die nächste inkrementelle Sicherung wiederherzustellen, erstellen Sie eine Kopie der nächsten vollständigen Sicherung und fügen Sie alle relevanten inkrementellen Sicherungen hinzu in einer Folgebestellung . Das wiederhergestellte Datenbank-Image sollte wie folgt aussehen:

Wir erreichen dies, indem wir prepare ausführen Befehl für jede inkrementelle Sicherung wie unten gezeigt:

mariabackup --prepare \
   --target-dir=/data/backups/mariadb/COPY_D20210220 \
   --incremental-dir=/data/backups/mariadb/D20210220_INC#

Nach dem Erstellen der Sicherungskopie müssen wir die Datenbankinstanz herunterfahren (Prozess). Außerdem müssen wir die leeren Datenbankverzeichnis bevor Sie den Wiederherstellungsvorgang abschließen. Sie können beide Befehle mit –copy-back ausführen Möglichkeit

mariabackup --copy-back \
   --target-dir=data/backups/mariadb/COPY_D20210220

oder mit –move-back Möglichkeit:

mariabackup --move-back \
   --target-dir=data/backups/mariadb/COPY_D20210220

Der letzte Befehl verschiebt das kopierte Verzeichnis in das Datenbankverzeichnis. Das Kopieren der ursprünglichen Sicherung an einen anderen Ort ist eine kluge Wahl. Andernfalls geht das Backup verloren, da es nicht für andere Situationen und Szenarien verwendet werden kann.

Der letzte Schritt vor dem Start der Datenbankinstanz besteht darin, die Eigentümerschaft der Dateien an den Benutzer und die Gruppe des Prozesseigentümers anzupassen. Normalerweise ist es MySQL.

Wiederherstellung von logischen Sicherungen

Sehr oft übersehen wir einen wichtigen Punkt bei der Wiederherstellung von Datenbanken und/oder Tabellen mit logischen Backups. Dieser Punkt setzt das max_allowed_packet Größe der Sitzung (es kann klüger sein, sie global einzustellen) auf den Maximalwert 1073741824. Es muss sichergestellt werden, dass große Puffer und INSERT-Anweisungen in ein einzelnes Paket zwischen Client und Server passen. Dies sollte die Wiederherstellungszeit verkürzen.

Ein weiterer wichtiger Aspekt beim Erstellen eines Backups ist das Einschließen oder Ausschließen der DROP-Anweisungen, wie zuvor erwähnt. Wir benötigen es, um sicherzustellen, dass der Backup-Wiederherstellungsprozess so reibungslos wie möglich abläuft. Verwenden Sie in diesem Sinne den folgenden Code, um die Sicherungswiederherstellung auszuführen:

mysql -u backupuser -p backuppasswd  < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sql

Wenn Sie keine Datenbank in der Sicherung enthalten haben, wie bei einzelnen Datenbanksicherungen, oder Sie die Wiederherstellung auf eine andere Datenbank umleiten müssen, verwenden Sie einen anderen Code:

mysql -u backupuser -p backuppasswd  newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sql

Wiederherstellung mit Festplatten-Snapshots

Zur Wiederherstellung vom Festplatten-Snapshot immer beginnen Sie damit, sicherzustellen dass das Datenbanksystem vorher heruntergefahren wird der Wiederherstellungsprozess wird ausgeführt . Jeder Versuch, eine Live-Datenbank mithilfe des Festplatten-Snapshots wiederherzustellen, führt zu Dateninkonsistenzen und, was noch wahrscheinlicher ist, zu Datenbeschädigungen.

Point-in-Time-Wiederherstellung

Point-in-Time-Recovery (PITR) ist, wie der Name schon sagt, eine Methode, um Datenbanken und Tabellen so nah wie möglich am Zeitpunkt vor dem Ausfall wiederherzustellen. Oder, wenn der tägliche Batch-Prozess fehlgeschlagen ist und erneut ausgeführt werden muss, haben Sie auch die einzige Option – führen Sie eine PITR-Backup-Wiederherstellung durch.

Es ist wichtig, das Datenbank-Bin-Log zu aktivieren und das Bin-Log-Format entweder auf anweisungsbasierte, zeilenbasierte oder gemischte Protokollierung einzustellen, je nach Art der Arbeitslast, die Ihre Datenbank ausführt. Außerdem müssen Sie möglicherweise die Komprimierung mit log_bin_compress =ON (Standard OFF) aktivieren um Speicherplatz zu sparen.

Da das Bin-Log ein Transaktionsprotokoll ist und in einer Sequenz erstellt wird, ist es wichtig, eine Sicherungskopie aller Protokolldateien zu erstellen. Der PITR-Prozess ist unmöglich ohne logfiles. Außerdem sollten die Bin-Log-Wartung und der Lebenszyklus dem Lebenszyklus aller vollständigen und inkrementellen Backups folgen. Stellen Sie daher sicher, dass nur die Protokolle gelöscht werden, die älter sind als die älteste Sicherung in der Sicherungsrichtlinie.

Sie können Binärprotokolle auf zwei Arten löschen. Erstens wird der nächste Bin-Log-Name zum ältesten Backup deklariert, wie im folgenden Löschbefehl gezeigt:

PURGE BINARY LOGS TO 'mariadb-bin.000063';

Zweitens, indem das Datum des ältesten Backups im Purge-Befehl angegeben wird:

PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';

Um die Wiederherstellung vorzubereiten, müssen wir alle erforderlichen Aussagen abrufen, um sie bis zum erforderlichen Zeitpunkt wiederzugeben. Sammeln Sie alle verfügbaren Bin-Logs ab dem Zeitpunkt, an dem die Sicherung gestartet wurde, bis zu dem Zeitpunkt, zu dem Sie die Wiederherstellung durchführen.

Untersuchen Sie zunächst die Protokollliste vom Ende der Sicherung bis zur PITR-Zeit:

mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql

Untersuchen Sie dann die temporären Dateien, um die genauen Protokollpositionen zu finden, die Sie anwenden und verwenden möchten. Diese sind –start-position und –stop-position die die genauen Positionen im Befehl setzen und mysqlbinlog erneut ausführen Befehl:

mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql

An diesem Punkt hat der Wiederherstellungsprozess begonnen. Es verwendet entweder physische oder logische Sicherungen, vollständig oder inkrementell.

Schließen Sie die Wiederherstellung ab, indem Sie final_temporary_PITR_file.sql anwenden mit dem MySQL-Client wie unten gezeigt:

mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sql

Wir haben die PITR-Wiederherstellung abgeschlossen, indem wir die Sicherung und die wiedergegebenen Transaktionen aus dem Protokoll bis zum nächstgelegenen Punkt zum Zeitpunkt des Auftretens des Fehlers wiederhergestellt haben.

Werkbank

Für Datenbankdesign und -entwicklung, Test und Wartung in MySQL und MariaDB können wir eine Windows-Anwendung Workbench verwenden. Es funktioniert auch unter Linux. Mit dieser Anwendung können Benutzer Datenbanken gestalten, Metadaten einsehen und ändern, Daten und Metadaten übertragen und vieles mehr. Es ist erwähnenswert, dass es möglich ist, dbForge Studio für MySQL anstelle von Workbench zu verwenden.

Schlussfolgerung

Insgesamt haben wir die Sicherungs- und Wiederherstellungstechniken für Datenbanken mit Tools und Methoden, die in MySQL und MariaDB verfügbar sind, kurz besprochen und veranschaulicht.

Um das Datenbanksystem erfolgreich nach einem Ausfall wiederherzustellen, müssen wir sowohl physische als auch logische Sicherungen implementieren oben genannten Methoden in die Richtlinien und Pläne, vom gesamten System bis hin zu einzelnen Tabellen.

Um ein PITR erfolgreich durchzuführen, müssen wir das Bin-Log aktiviert haben und eine ordnungsgemäße Protokollverwaltung benötigen vorhanden.

Allerdings wäre es der falsche Ansatz, nur eine Backup-Methode zu verwenden und keine Bin-Logs zu verwenden. Dies kann zu Datenverlust führen und die Geschäftskontinuität Ihrer Anwendung beeinträchtigen. Kombinieren Sie daher verschiedene Methoden und schließen Sie die Protokolldateien immer in die Sicherungs- und Wiederherstellungsrichtlinien ein!