Designideen für MySQL-Backup und -Wiederherstellung

Hintergrund

Lassen Sie mich zunächst den Hintergrund erklären. Aufgrund bestimmter Einschränkungen verwendet die aktuelle Sicherungsstrategie unseres Unternehmens jeden zweiten Tag eine vollständige Sicherungslösung und die inkrementelle Sicherung verwendet die Binlog-Servermethode. Die schnelle Wiederherstellung ist also ein Problem, über das wir nachdenken müssen.

Wiederherstellungsbedarf

Nach meiner bisherigen Erfahrung sind die Szenarien, in denen Daten aus einem Backup wiederhergestellt werden müssen, in der Regel die folgenden:

1. Die Bibliothek wurde versehentlich gelöscht

2. Die Tabelle wurde versehentlich gelöscht, der Typ ist TRUNCATE oder DROP

3. Die Spalte wurde versehentlich gelöscht, der Typ ist ALTER ... DROP COLUMN

4. Daten wurden versehentlich gelöscht, der Typ ist DELETE, UPDATE oder REPLACE

5. Der Tabellenbereich ist beschädigt oder es tritt ein fehlerhafter Block auf

Je nach Szenario können wir es grob in zwei Kategorien unterteilen:

• Der erste Typ ist die irreversible Wiederherstellung, also das übliche DDL, wie die oben genannten Szenarien 1, 2, 3, 5 und andere.
• Der zweite Typ ist die reversible Wiederherstellung, die normalerweise mit Binlog zurückgesetzt werden kann (erfordert das Binlog-Format ROW und Binlog_Image FULL), was dem oben genannten Szenario 4 entspricht.
  

Die zweite Art von Wiederherstellungsanforderungen ist im Allgemeinen einfacher zu handhaben. Sie können Binlog-Rollback-Tools wie binlog2sql und MyFlash verwenden, die in der Branche bekannt sind. Wir werden hier nicht ins Detail gehen und uns auf die erste Art von Anforderungen konzentrieren.

Um das Ziel einer schnellen Wiederherstellung zu erreichen, besteht der von DBAs in der Branche häufig verfolgte Ansatz darin, eine verzögerte Slave-Datenbank bereitzustellen, um das Problem zu lösen. Derzeit haben alle Kern-DBs unseres Unternehmens verzögerte Slave-Datenbanken bereitgestellt. Wenn wir jedoch auch bei einem verzögerten Slave die Verzögerungszeit verpassen oder den falschen Speicherort angeben, wenn wir den verzögerten Slave später zur Wiederherstellung verwenden und dadurch der versehentlich gelöschte DDL auch auf den Slave angewendet wird, können wir den verzögerten Slave nicht als Rettungsleine verwenden.

Vollständige Wiederherstellung (Wiederherstellung auf verschiedenen Maschinen)

Derzeit können wir Daten nur durch ein Backup wiederherstellen. Zuerst müssen wir das vollständige Backup wiederherstellen, normalerweise das physische Backup, das von xtrabackup gesichert wurde. Vorausgesetzt, Ihr Backup befindet sich auf einem Remotecomputer, müssen Sie möglicherweise die folgenden Schritte ausführen, um eine vollständige Backup-Wiederherstellung durchzuführen:

1. scp oder rsync das Backup auf die Ziel-Instanz-Maschine
2. Wenn die Sicherungsdatei komprimiert ist, müssen Sie sie dekomprimieren.
3. Nach der Dekomprimierung müssen Sie ein Redo-Log anwenden
4. Ändern der Dateiberechtigungen
5. Vorausgesetzt, Sie haben die Dateien direkt in das Verzeichnis datadir der Zielinstanz kopiert, können Sie mysqld in diesem Schritt direkt starten. Wenn nicht, müssen Sie die Datendateien auch in das Verzeichnis datadir der Zielinstanz zurückverschieben oder zurückkopieren.
6. Instanzstart
   

Hinzufügen von Sicherung und Wiederherstellung

An diesem Punkt wurde die vollständige Sicherung wiederhergestellt und der nächste Schritt ist die inkrementelle Wiederherstellung. Gemäß unserem vorherigen Sicherungsplan müssen wir Binlog verwenden, um die Wiederherstellung inkrementeller Daten abzuschließen. Für die Binlog-Wiederherstellung benötigen wir normalerweise die folgenden Schritte

1. Bestimmen Sie den Binlog-Speicherort, der der vollständigen Sicherung entspricht. Dies ist der Ausgangspunkt, der wiederhergestellt werden muss
2. Analysieren Sie das Binärprotokoll der Masterdatenbank, um den Speicherort der versehentlich gelöschten Daten als Endpunkt unserer Wiederherstellung zu ermitteln
3. Verwenden Sie mysqlbinlog —start-position —stop-position+pipeline, um Binlog auf der Zielinstanz wiederherzustellen.

Es gibt viele Möglichkeiten, Binlog wiederherzustellen. Sie können das Binlog auf dem ursprünglichen Master oder das Binlog auf dem Binlogserver verwenden. Sie müssen lediglich den Endpunkt der Binlog-Wiederherstellung finden.

Backup- und Recovery-Optimierung

An diesem Punkt denken Sie vielleicht, dass die Verwendung der Binlog-Wiederherstellung etwas mühsam ist. Dies ist tatsächlich der Fall. Es gibt keine Möglichkeit, mit dem Befehl mysqlbinlog anzugeben, welche GTID wiederhergestellt werden soll. Sie können nur das Binärprotokoll analysieren, um die POS-Position zu finden, die der wiederherzustellenden GTID entspricht, was bei automatischer Implementierung schwieriger ist. Wenn Sie außerdem den Befehl mysqlbinlog zur Wiederherstellung verwenden, handelt es sich um eine Single-Thread-Wiederherstellung. Wenn die Menge des wiederherzustellenden Binlogs relativ groß ist, kann man sich die Zeit für diese inkrementelle Wiederherstellung vorstellen.

Gibt es also eine Möglichkeit, Binlog-Anwendungen zu beschleunigen? Hier denken wir an die parallele Replikation von MySQL 5.7. Wenn wir die parallele Replikation von SQL-Threads verwenden können, wird dieses Problem dann gelöst?

Binlog-Wiederherstellung auf dem Master

Wir kehren zum Punkt der vollständigen Wiederherstellung zurück, machen die neue Instanz zu einem Slave des ursprünglichen Masters und stellen sie dann an der angegebenen GTID-Position wieder her? Ja, dies ist eine sehr einfache, leichte und fehleranfällige Methode, und sie kann auch das Prinzip der parallelen Replikation nutzen, um Binlog-Anwendungen zu beschleunigen. Eine Voraussetzung für diese Methode ist jedoch, dass das älteste Binärprotokoll des ursprünglichen Masters den Startwiederherstellungspunkt enthält, den wir benötigen. Das ist leicht zu begreifen, daher wird dies unsere bevorzugte Wiederherstellungsmethode sein.

Binlog-Wiederherstellung auf Binlogserver

Vorausgesetzt, dass das ursprüngliche Binärprotokoll auf dem Master gelöscht wurde, müssen wir es aus dem Binärprotokoll wiederherstellen. Manche Leute denken vielleicht daran, das Binlog auf dem Binlogserver auf den ursprünglichen Master zu kopieren und dann den Binlog-Index zu ändern, um den Zweck der Registrierung zu erreichen. Tatsächlich ist dies nicht ratsam. Aus bestimmten Gründen siehe „Manuelle Registrierung von Binlog-Dateien verursacht Master-Slave-Anomalien.“

Welchen Ansatz können wir verfolgen? Dabei wird binlogserver verwendet, um sich als Master auszugeben, und dann die Slave-Bibliothek geändert. Die Idee besteht darin, den Slave zu täuschen, den io_thread des Slaves das fehlende Binlog abrufen zu lassen und sql_thread das Binlog-Ereignis parallel anzuwenden (wir werden diese Methode im nächsten Abschnitt ausführlich demonstrieren).

Optimierter Wiederherstellungsprozess

Nach der Optimierung lautet unser Backup-Wiederherstellungsprozess: Zuerst die Wiederherstellung über das Binlog auf dem Master durchführen. Wenn festgestellt wird, dass das Binlog auf dem Master gelöscht wurde, dann die Wiederherstellung über das Binlog auf dem Binlogserver durchführen. Ich denke, das ist ein wissenschaftlicherer und vernünftigerer Wiederherstellungsprozess.

Vergleich der Aktualität verschiedener Wiederherstellungsmethoden

Geschäftserholung

An diesem Punkt haben wir die vollständige und inkrementelle Datenwiederherstellung abgeschlossen. Zu diesem Zeitpunkt müssen wir die Daten mit R&D bestätigen. Nach der Bestätigung stellen wir die entsprechende Tabelle auf dem ursprünglichen Master wieder her. Die am häufigsten verwendeten Methoden sind:

1. mysqldump export + import Zielinstanz
2. Tablespace-Transport
   

Zusammenfassen

In diesem Abschnitt wird hauptsächlich der Entwurfsprozess von Sicherung und Wiederherstellung vorgestellt. Wenn wir keine Möglichkeit haben, die vollständige Wiederherstellung zu optimieren, können wir die Wiederherstellungszeit verkürzen, indem wir die Methode und den Prozess der inkrementellen Sicherung optimieren. Eine Sache muss erklärt werden: Ich habe die in diesem Abschnitt vorgestellten Punkte noch nicht vollständig getestet und kann nicht garantieren, dass jeder Punkt korrekt ist. Eine weitere Überprüfung ist erforderlich. Nach erfolgreicher Überprüfung werde ich Sie benachrichtigen und es mit der vorhandenen Plattform für Datenbankbetrieb und -wartung kombinieren, um eine automatische Wiederherstellung zu erreichen.

Zum Schluss noch ein paar Hinweise:

1. Daten sind immaterielles Eigentum. Sichern und überprüfen Sie diese daher unbedingt.
2. Wenn die Bedingungen es erlauben, versuchen Sie, verzögerte Slaves einzusetzen
3. Erstellen Sie einen Wiederherstellungsplan, um bei der Wiederherstellung nicht in Eile zu geraten.
4. Wählen Sie je nach Szenario geeignete Wiederherstellungsmethoden und versuchen Sie, die Wiederherstellungszeit zu verkürzen

Oben finden Sie ausführliche Informationen zu Designideen für MySQL-Sicherungen und -Wiederherstellungen. Weitere Informationen zu MySQL-Sicherungen und -Wiederherstellungen finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!