Eine kurze Analyse der MySQL-Sicherung und -Wiederherstellung

1. Einleitung

Daten sind unbezahlbar. Als Datenbanksystem ist die Sicherung von MySQL sehr wichtig und notwendig. Es gibt tausende Gründe für Backups, wie z. B. Fehlerverhütung, Sicherheitsanforderungen, Rollback, Auditing, Lösch- und Änderungsanforderungen usw. Die Wichtigkeit von Backups liegt auf der Hand. Neben der Sicherung selbst ist auch die Verwendung der Sicherung zur Wiederherstellung von Diensten ein wichtiges Thema. Eine Sicherung, die nicht zur Wiederherstellung verwendet werden kann, ist wertlos. Dieser Artikel gibt hauptsächlich eine kurze Einführung in die beiden Aspekte der Sicherung und Wiederherstellung.

Dieser Artikel ist eine Lesenotiz für die Backup-bezogenen Kapitel von „High Performance MySQL“.

2. Einfache Definition von Backup und Wiederherstellung

Wie in der Einleitung erwähnt, ist die Datensicherung jedem bekannt und es fällt den Leuten leicht, darauf zu achten. Es ist üblich, reguläre Skripte je nach Bedarf zu schreiben oder andere Methoden zu verwenden. Allerdings verlief die Erholung weniger dramatisch. Beispielsweise sind möglicherweise automatische Sicherungen auf wöchentlicher/täglicher Basis geplant. Aber wie oft werden Wiederherstellungstests von Backups durchgeführt? Ist die Sicherung abgeschlossen? Kann es zur Wiederherstellung verwendet werden? Ist der Wiederherstellungsprozess im Falle eines Fehlers einfach durchzuführen?

Das Backup ist nur eine Datenquelle. So verwenden Sie die Datenquelle, um das System vollständig wiederherzustellen. Es ist auch sehr wichtig. Backup und Wiederherstellung sind beides Dinge, die Sie im MySQL-Betrieb und bei der MySQL-Wartung beherrschen müssen.

Der Zweck der Sicherung ist die Wiederherstellung. Wenn es nicht wiederhergestellt werden kann, wird es nicht als Backup bezeichnet (ein RAID-Array ist beispielsweise kein Backup. Wenn Sie die Datenbank löschen, kann das RAID-Array nicht wiederhergestellt werden).

Der Unterschied zwischen [Wiederherstellen] und [Wiederherstellen]:

• Wiederherstellen: bezieht sich einfach auf das Extrahieren und Laden des Inhalts aus der Sicherungsdatei.
• Wiederherstellung: Eine Reihe von Maßnahmen, einschließlich der Wiederherstellung von Sicherungsdateien, um den Normalbetrieb des Dienstes wiederherzustellen, z. B. ein Neustart von MySQL, das Ändern der Konfiguration und andere Vorgänge.
  

Mit anderen Worten besteht die Wiederherstellung darin, alle Vorgänge wiederherzustellen, die vor dem Auftreten der Ausnahme ausgeführt wurden (z. B. Ändern von Parametern, Neustarten von Diensten usw.). Machen Sie mehr, als nur ein Backup wiederherzustellen.

3. Mehrere Faktoren, die im Wiederherstellungsplan berücksichtigt werden müssen

Bei der Erstellung eines Wiederherstellungsplans müssen einige Faktoren berücksichtigt werden, damit eine bessere Planung entsprechend den unterschiedlichen Anforderungen durchgeführt werden kann. Es kann bei der Formulierung geeigneter Wiederherstellungsstrategien basierend auf den beiden Anforderungen RPO (Recovery Point Objective) und RTO (Recovery Time Objective) hilfreich sein.

• RPO (Recovery Point Objective): Wie viel Datenverlust kann toleriert werden? (Müssen Sie alle Daten wiederherstellen oder können Sie den Datenverlust seit der letzten Sicherung tolerieren?)
• RTO (Recovery Time Objective): Wie lange müssen Sie auf die Wiederherstellung der Daten warten? (Inwieweit können Benutzer es akzeptieren)
  

Vielleicht sollten Sie auch überlegen: Was muss wiederhergestellt werden? (Gesamter Server, einzelne Datenbank, einzelne Tabelle oder Transaktion)

Zweitens muss der Wiederherstellungsplan regelmäßig getestet werden. Daten sollten extrahiert werden, um zu prüfen, ob die Sicherung tatsächlich wirksam ist. Außerdem sollte eine vollständige Sicherungswiederherstellung durchgeführt werden, um sich mit dem gesamten Wiederherstellungsprozess vertraut zu machen und sicherzustellen, dass die Wiederherstellung ordnungsgemäß abgeschlossen werden kann, wenn tatsächlich ein Problem auftritt.

4. Sicherung

4.1. Was beinhaltet das Backup?

Die einfachste Strategie besteht darin, nur die Daten und Tabellendefinitionen zu sichern. Für die Wiederherstellung einer Datenbank ist allerdings mehr Inhalt erforderlich. Und je umfassender die Sicherung ist, desto einfacher ist die Wiederherstellung. (Hauptsächlich abhängig von der Nachfrage)

Beispielsweise können Sie je nach tatsächlichen Bedingungen die Sicherung folgender Inhalte in Betracht ziehen:

1. Binlog- und InnoDB-Transaktionsprotokoll.

2. Konfigurationsdateien der Master/Slave-Bibliothek.

3. Konfiguration des Datenbank-Betriebssystems (Cron, Skripte, Kernel-Parameter)

Das heißt, der Backup-Inhalt kann beliebig erweitert werden. Wenn ein hoher Bedarf an Datenbankwiederherstellung oder sogar Rekonstruktion (z. B. eine schnellere Wiederherstellung) besteht, ist es auch erforderlich, mehr Inhalte zu sichern. Wenn Sie die Möglichkeit benötigen, die Datenbank von Grund auf wiederherzustellen, ist ein höherer Arbeitsaufwand erforderlich.

4.2 Physische Sicherung und logische Sicherung

Eine kleine Auswahl zwischen physischem Backup und logischem Backup:

• Für große Datenbanken sind physische Backups ein Muss. Wenn die logische Sicherung zu langsam ist, können Sie als Hilfsmittel auch die Verwendung einer Snapshot-basierten Sicherung in Betracht ziehen.
• Für kleine Datenbanken sind logische Backups fast ausreichend.
  

Die physische Sicherung ist einfach und effizient, und auch logische Sicherungen sollten so oft wie möglich durchgeführt werden. [Je nach Bedarf und Ressourcenzuweisung sind beide erforderlich]

Zweitens: Sie können nicht davon ausgehen, dass ein Backup verwendbar ist, wenn Sie es nicht getestet haben. Verwenden Sie beispielsweise mysqlcheck -A, um die Datenbank zu testen.

4.3 Binlog-Sicherung

Binlog ist auch ein wichtiger Teil der Sicherung, weil es für eine zeitpunktbezogene Wiederherstellung benötigt wird. Darüber hinaus ist Binlog im Allgemeinen sehr klein und häufige Backups sind einfacher zu implementieren. Wenn Sie über eine Sicherungskopie der Daten zu einem bestimmten Zeitpunkt sowie aller Binärprotokolle seitdem verfügen, können Sie alle Änderungen rückgängig machen.

4.3.1. Einige Strategien zum Sichern von Binlog

Protokolle leeren
--log_slave_updata

Es ist zu beachten, dass expire_log_days durch den Änderungszeitpunkt der Protokolldatei und nicht durch den Inhalt bestimmt wird. (Wenn nur eine Binlog-Datei vorhanden ist, wird sie möglicherweise nicht bereinigt.) Verwenden Sie daher unbedingt FLUSH LOGS, um Binlog regelmäßig zu aktualisieren.

4.3.2. Altes Binlog bereinigen

Am besten verwenden Sie expire_log_days zur automatischen Bereinigung und behalten eine bestimmte Anzahl von Tagen bei. Verwenden Sie bei Bedarf cron zum Aufräumen. Verwenden Sie dann nicht den mit find+rm konfigurierten Cron zum Bereinigen der Protokolle.

0 3 * * * /usr/bin/mysql /var/log/mysql -mtime +N -name "mysql-bin.[0-9]"* | xargs rm

Verwenden Sie stattdessen den folgenden Cron:

0 3 * * * /usr/bin/mysql -e "MASTERPROTOKOLLE VOR DEM AKTUELLEN DATUM LÖSCHEN - INTERVALL N TAG"

4.3.3. Einige Hinweise zur Binlog-Sicherung

• Die Erhöhung der Aufbewahrungszeit ist lediglich eine Konfiguration und bedeutet nicht, dass das Binlog selbst nicht gesichert werden muss. Das Binärprotokoll muss weiterhin regelmäßig gesichert werden, damit es in Verbindung mit der aktuellsten Sicherung verwendet werden kann.
• Es ist zu beachten, dass die Slave-Bibliothek auch Binlog verwendet. Daher muss zwischen der Binlog-Verwaltung von Slave-Bibliotheken und Backups unterschieden werden.
  

4.4. Inkrementelles Backup und differentielles Backup

Inkrementelles Backup: Ein Backup aller Inhalte, die seit irgendeinem Backup-Typ geändert wurden.

Differenzielles Backup: bezieht sich speziell auf die Sicherung aller seit dem letzten vollständigen Backup geänderten Inhalte.

Das heißt, differenzielle Backups basieren auf vollständigen Backups. Inkrementelle Backups basieren auf einem beliebigen Backup (z. B. einem angegebenen differenziellen Backup).

Optionen für differenzielle Sicherungen:

• Sichern Sie keine Tabellen, die sich nicht geändert haben.
• Keine Sicherung unveränderter Zeilen
  

Allerdings kann die Durchführung differenzieller Sicherungen die Wiederherstellungsgeschwindigkeit erhöhen. Eine vollständige Sicherung ist jedoch weiterhin erforderlich. (Vollständige Sicherungen können seltener durchgeführt werden, müssen aber durchgeführt werden).

4.5. Backup aus der Datenbank

Manchmal ist das Sichern in einem Slave eine Option, die den Master nicht beeinträchtigt und eine zusätzliche Belastung des Masters vermeidet. Zweitens sollten beim Planen einer Sicherung von einem Slave weitere Informationen gespeichert werden, wie etwa der Standort (Offset) des Slaves relativ zum Master.

Erstens ist die Slave-Datenbank nicht identisch mit der Sicherung, und es kommt sehr häufig vor, dass die Daten der Slave-Datenbank und der Master-Datenbank nicht übereinstimmen. Zweitens kann das Sichern aus der Slave-Datenbank zwar die Belastung beim Sichern der Master-Datenbank verringern, es ist jedoch nicht gut genug. Aus Stabilitätsgründen wird empfohlen, eine Hauptdatenbanksicherung und eine vollständige Sicherung durchzuführen.

4.6 Sonstige Hinweise

4.6.1. Online-Backup und Offline-Backup

Die Offline-Sicherung ist die einfachste und sicherste. Es hat auch die beste Konsistenz. Das Problem besteht darin, dass die meisten Datenbanken keine Ausfallzeiten für die Datensicherung tolerieren können. Daher wird weiterhin die Online-Sicherung bzw. die Nonstop-Sicherung verwendet.

Sie können die Durchführung einer Online-Sicherung außerhalb der Geschäftszeiten in Erwägung ziehen. Auch bei steigender Belastung hat dies keine großen Auswirkungen.

4.6.2 Datenkonsistenz

Datenkonsistenz: Anforderungen an die Datenkonsistenz zwischen mehreren Tabellen. (Wenn beispielsweise zwei logisch verwandte Vorgänge in zwei Transaktionen aufgeteilt werden und die Sicherung zwischen den beiden Transaktionen durchgeführt wird, führt dies zu inkonsistenten Daten.)

InnoDB kann beim Dumpen einer Reihe zusammengehöriger Tabellen eine Transaktion starten, wodurch die Datenkonsistenz weitgehend sichergestellt werden kann.

Beachten Sie jedoch, dass es auch dann zu Dateninkonsistenzen kommt, wenn die Transaktionseinstellungen nicht sinnvoll sind, z. B. wenn die Änderung einer Reihe verknüpfter Tabellen auf zwei Transaktionen aufgeteilt wird. (Zusammenhängende Operationen an einer Reihe von Tabellen müssen innerhalb einer Transaktion sichergestellt werden)

4.6.3. Führen Sie regelmäßig Backup- und Recovery-Tests durch, um die für den gesamten Recovery-Prozess erforderlichen Ressourcen zu bestätigen.

Ein wiederherstellbares Backup ist wertvoll, nicht einfach nur ein Backup zu haben.

Zusammenfassung

In diesem Artikel werden einige grundlegende Kenntnisse und Konzepte zur Datensicherung erläutert, darunter einige grundlegende Konzepte, die Bedeutung der Wiederherstellung und einfache Strategien für die Datensicherung und Wiederherstellung. Außerdem werden die Auswahl des Sicherungsinhalts, die differenzielle/inkrementelle Sicherung, die Binlog-Sicherung usw. erwähnt. Sie müssen sich weiterbilden, um die spezifischen Betriebsmethoden und Praktiken der Sicherung und Wiederherstellung zu verstehen.

Oben finden Sie eine kurze Analyse der Details zur MySQL-Sicherung und -Wiederherstellung. Weitere Informationen zur MySQL-Sicherung und -Wiederherstellung finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!