Tatsächlicher Datensatz zur Wiederherstellung der MySQL-Datenbank nach Zeitpunkt

Einführung: MySQL-Datenbankwiederherstellung nach Zeitpunkt

Für jedes Unternehmen sind Daten das wertvollste Gut.

Wie die Datenintegrität geschützt wird, wie Daten vor Beschädigungen geschützt werden, wie Daten im Fehlerfall aufbewahrt werden und wie Daten im Falle einer Fehlbedienung, eines Hackerangriffs, einer Datenmanipulation usw. auf der Grundlage unserer Backups wiederhergestellt werden können, sind wichtige Punkte, auf die jeder Techniker achten muss.

Alibaba Cloud engagiert sich für seine Kunden und bietet kontinuierlichen Datenschutz sowie kostengünstige Backup-Dienste für Kundendatenbanken. Es bietet starken Schutz und leistungsstarke Wiederherstellung für Daten in verschiedenen Umgebungen. In extremen Fällen von Datenverlust oder Datenbeschädigung verfügt die RDS-Verwaltungs- und Steuerungsplattform über eine Ein-Klick-Wiederherstellungsfunktion, die basierend auf dem vom Kunden festgelegten Zeitpunkt eine umfassende Datenwiederherstellung durchführen kann.

​​1. Technische Umsetzung der Point-in-Time-Wiederherstellung​

Wenn ein Kunde zu einem bestimmten Zeitpunkt aufgrund einer fehlerhaften Operation Daten verliert, wie stellt der RDS-Verwaltungsdienst diese wieder her?

Die Gesamtidee der Point-in-Time-Wiederherstellung ist wie folgt: Eine vollständige Datenwiederherstellung besteht aus physischer Sicherung + Binlog-Wiederherstellung + Binlog-Bereinigung.

Abbildung 1

Besorgen Sie sich zunächst den verfügbaren Sicherungssatz, wenden Sie den Sicherungssatz auf die Zielinstanz an, spielen Sie dann die Binlog-Datei erneut ab, die auf der Zielinstanz wiederhergestellt werden muss, und wenden Sie schließlich die SQL-Datei in Form einer Binlog-Beschneidung an, um eine Gesamtwiederherstellung zu erreichen.

2. Management- und Kontrollprozess für die zeitpunktbezogene Wiederherstellung

1. Erstellen Sie eine Instanz zur Wiederherstellung

Wenn wir die Quelldatenbankdaten als Ganzes wiederherstellen müssen, müssen wir zuerst eine Zielinstanz mit denselben Spezifikationen und derselben Netzwerkumgebung wie die Quellinstanz erstellen.

Warum das tun?

Da Backup und Wiederherstellung risikoreiche Vorgänge sind, sind bei einer direkten Wiederherstellung auf der Quellinstanz nicht nur die verlorenen Daten unwiederbringlich, wenn Probleme wie fehlendes Backup-Set oder fehlendes Binlog auftreten, sondern sogar die Originaldaten bleiben möglicherweise nicht intakt erhalten. Daher wird dringend empfohlen, für die Wiederherstellung eine neue Instanz zu verwenden!

2. Festlegen der Sicherungs- und Wiederherstellungszeitpunkte

Wenn ein Kunde eine Reihe von Datenbankvorgängen durchführt, z. B. versehentliches Löschen oder Ändern, ohne sich dessen bewusst zu sein, und wenn dadurch das Geschäft geschädigt wird oder ein Fehler auftritt, wie lässt sich dann zur Datenwiederherstellung der genaue Zeitpunkt des Vorgangs ermitteln?

Methode 1: Sie können die Protokollprüfungsfunktion verwenden, um den entsprechenden fehlerhaften Vorgangszeitpunkt zu finden.

Methode 2: Sie können das Binärprotokoll in Text analysieren und den entsprechenden Zeitpunkt des Fehlervorgangs abfragen.

3. Verfügbare Backup-Sets über den Backup-Verlauf abrufen

Im Allgemeinen planen Kunden je nach Wichtigkeit ihres Geschäfts ihre eigenen Datenbanksicherungszyklen in der Cloud, und die RDS-Verwaltung sucht basierend auf dem vom Benutzer ausgewählten Wiederherstellungszeitpunkt automatisch nach verfügbaren physischen Sicherungssätzen.

Es ist ersichtlich, dass die Datensicherung für die Hochverfügbarkeit und Notfallwiederherstellung von Datenbanken von größter Bedeutung ist!

4. Holen Sie sich den Binlog-Punkt, der dem Backup-Set entspricht

Die Sicherung privater Clouds erfolgt grundsätzlich auf Basis des Tools xtrabackup. Xtrabackup verfügt über die Funktionen Hot Backup und Fast Recovery. Gleichzeitig schreibt es die Dateien und Punkte des am Ende der Sicherung angewendeten Binlogs in die entsprechenden Dateien. Die RDS-Steuerung schreibt die Binärprotokolldatei , Binärprotokollpositionen und andere Informationen in die Datenbank. Wenn eine Sicherung und Wiederherstellung erforderlich ist, wird der Punkt direkt zur Wiederherstellung abgerufen.

Wie in der folgenden Abbildung dargestellt:

Abbildung 2

5. Wiederherstellen des Backup-Sets auf der Zielinstanz

Die Schritte 1 bis 4 dienen der Vorbereitung. Jetzt beginnen wir mit der Datenwiederherstellung. Der erste Schritt bei der Datenwiederherstellung besteht darin, den verfügbaren vollständigen physischen Sicherungssatz auf die Zielinstanz herunterzuladen und ihn mit dem Tool „xtrabackup“ wiederherzustellen.

//​​Beenden Sie zuerst den MySQL-Prozess auf der Zielinstanz​

​systemctl stop mysql​

//​​Dann führen Sie die Daten zusammen. Vorausgesetzt, das Backup ist im Verzeichnis /root/backup/ entpackt, können Sie den wiederherzustellenden Instanzport angeben. Sie müssen den Parameter --defaults-file hinzufügen, um ihn anzugeben. Der Standardwert ist 3306.​

innobackupex --apply-log /root/backup/

​//​​Löschen Sie die ursprüngliche Verzeichnisdatei​

rm -rf /data/mysql

//Den Datensatz wiederherstellen. Das Verzeichnis, in das die Daten wiederhergestellt werden, wird durch das datadir in der Konfigurationsdatei my.cnf bestimmt. Dieses Feld muss auf Richtigkeit überprüft werden.

innobackupex --copy-back /root/backup/

​//​​Verzeichnisautorisierung​

​chown ​​-​​R mysql:mysql ​​/​​Daten​​/​​mysql

6. Überprüfen Sie, ob die Wiederherstellung erfolgreich war

Der Verwaltungsdienst muss überprüfen, ob die Wiederherstellung erfolgreich war, bevor er entscheidet, ob er fortfahren möchte. Die Überprüfungsschritte sind ebenfalls sehr einfach und grob. Überprüfen Sie einfach, ob im Sicherungswiederherstellungsprotokoll ein FEHLER vorliegt und ob die letzte Zeile ordnungsgemäß abgeschlossen wurde!

Die folgende Abbildung zeigt eine erfolgreiche Sicherung und Wiederherstellung.

Abbildung 3

7. Holen Sie sich das Binlog-Protokoll zur Wiederherstellung

Dieser Schritt ist für den Erfolg der Wiederherstellung und die Integrität der Daten von entscheidender Bedeutung.

Wie erhält der RDS-Verwaltungsdienst das richtige Binärprotokoll für die Wiederherstellung? Schauen wir uns das Bild unten an.

Abbildung 4

Beispielsweise gibt es in unserem aktuellen Backup insgesamt 8 Binlog-Backups (000-008). Holen Sie sich zuerst das erste Binlog über den Dateinamen und die Position des im physischen Backup aufgezeichneten Binlogs, z. B. binlog004 in der obigen Abbildung. Suchen Sie dann das entsprechende letzte Binlog über den Zeitstempel des vom Kunden festgelegten Zeitpunkts, der wiederhergestellt werden soll, z. B. binlog007 in der obigen Abbildung. Laden Sie schließlich die vier Binlog-Backups binlog004, binlog005, binlog006 und binlog007 zur Wiederherstellung auf die Zielinstanz herunter.

Wenn für die Wiederherstellung das falsche Binlog abgerufen wird, z. B. wenn binlog003/binlog005 fälschlicherweise als erstes Binlog festgelegt wird, werden die auf binlog003/binlog005 ausgeführten DML-Anweisungen auf der neuen Instanz erneut ausgeführt und die wiederhergestellten Daten werden größer oder fehlen. Wenn beispielsweise binlog0006 oder binlog0008 fälschlicherweise als letztes Binlog festgelegt wird, fehlen die wiederhergestellten Daten und der erwartete Effekt kann nicht erzielt werden.

8. Relaylog wiederholen

Kopieren Sie das heruntergeladene Binärprotokoll in das Protokollverzeichnis der neuen Instanz, benennen Sie die Binärprotokolle mit Ausnahme des letzten Binärprotokolls (das Binärprotokoll, das den Wiederherstellungszeitpunkt abdeckt) in „Relaylog“ um und spielen Sie diese Relaylogs dann mit der neuen Instanz erneut ab.

​//​​Binlog umbenennen, der Name der Relaylog-Datei kann durch Ausführen von Show-Variablen wie „%relay%“ in der MySQL-Instanz angezeigt werden.​

​umbenennen mysql​​-​​bin MySQL2​​-​​relay​​-​​bin mysql​​-​​bin​​*​

​//​​Relay-Informationen in Indexdatei initialisieren​

​ls .​​/​​MySQL2​​-​​relay​​-​​bin.​​0000​​*​​​​>​​MySQL2​​-​​relay​​-​​bin.index​

​//​​Diese Dateien in die Datendatei kopieren​

​cp MySQL2-relay-bin.*/data/mysql/​

​//​​Dateiautorisierung​

​chown ​​-​​R mysql:mysql ​​/​​Daten​​/​​mysql​

​//​​Starten Sie die MySQL-Instanz​

​systemctl starte mysql​

//Ändern Sie den Master in eine nicht vorhandene Instanz, simulieren Sie diese Instanz als Standby-Datenbank, geben Sie eine leere Master-Datenbank an, erstellen Sie einen SQL-Thread und stellen Sie ihn dann entsprechend der Binlogdatei und Binlogpos des Sicherungsdatensatzes ein. Und starten Sie den SQL_Thread des Slaves​

​ÄNDERN SIE MASTER IN MASTER_HOST​​=​​'1.1.1.1'​​,RELAY_LOG_FILE​​=​​'MySQL2-relay-bin.000011'​​,RELAY_LOG_POS​​=​​160338​​;​

​START SLAVE SQL_THREAD;​

​Slave-Status anzeigen\G

9. Überprüfen Sie, ob die Relaylog-Wiedergabe erfolgreich ist

Überprüfen Sie dies, indem Sie „show slave status\G“ ausführen. Die Wiederherstellung nach diesem Schritt dauert in der Regel lange, je nach Anzahl und Größe der Datenbank-Binärprotokolle.

Überprüfung 1: Überprüfen Sie, ob der Wert des Felds relay_log_file der größte in der Datei MySQL2-relay-bin.index verwaltete Wert ist. Wenn ja, beweist dies, dass alle Bilogs erfolgreich wiedergegeben wurden.

Überprüfung 2: Überprüfen Sie, ob das Feld Slave_SQL_Running JA ist.

Wie in der folgenden Abbildung dargestellt:

Abbildung 5

10. Verwenden Sie die Funktion mysqlbinlog, um das Binlog zum Wiederherstellungszeitpunkt zu kürzen und eine SQL-Datei zu generieren

Zu diesem Zeitpunkt wurden mit den Schritten 1 bis 9 die meisten Daten wiederhergestellt. Außerdem gibt es ein Binärprotokoll, das unseren Wiederherstellungszeitpunkt abdeckt und nicht wiederhergestellt werden konnte.

Also, wie machen wir es?

Wie in der folgenden Abbildung dargestellt:

Abbildung 6

Je nach Zeitpunkt des Kunden (z. B. Daten, die bis 15:00 Uhr wiederhergestellt werden müssen) muss das RDS-Management das Binärprotokoll, das unseren Wiederherstellungszeitpunkt abdeckt, entsprechend der Wiederherstellungszeit kürzen, d. h. nur die Daten von 12:00 bis 15:00 Uhr werden angewendet. Die Daten von 15:00 bis 18:00 Uhr gehören zur Fehlerbetriebszeit und sollten nicht verwendet werden.

//​​Verwenden Sie die Bereinigungsfunktion des mysqlbinlog-Tools, um das Binlog zu bereinigen

mysqlbinlog ​​--​​start​​-​​position​​=​​4​​​​--​​stop​​-​​datetime​​=​​'2021-04-23 15:00:00'​​​​-​​R ​​-​​h127.​​0.0​​.​​1​​​​-​​uroot ​​-​​pxxxx ​​-​​P3306 mysql​​-​​bin.​​007​​​​>​​​​/​​tmp​​/​​mysql​​-​​bin.​​007.​​sql

11. Die Zielinstanz führt die wiederherzustellenden Daten über die SQL-Datei aus

Führen Sie die SQL-Datei auf der Zielinstanz aus.

//​​Ermächtigung​

​chown mysql:mysql ​​/​​tmp​​/​​mysql​​-​​bin.​​007.​​sql​

​//​​Daten wiederherstellen​
mysql -uroot -pxxxx -h127.0.0.1-P3306 -f --max_allowed_packet=1073741824 </root/mysql-bin.007.sql

12. Daten überprüfen

An diesem Punkt ist die gesamte Sicherung und Wiederherstellung abgeschlossen. Jetzt muss der Kunde die Daten überprüfen und die Daten der Zielinstanz auf der Quellinstanz wiederherstellen.

Wir sind das Alibaba Cloud Intelligent Global Technical Service-SRE-Team. Wir haben uns zum Ziel gesetzt, ein technologiebasiertes, serviceorientiertes Engineering-Team zu werden, das eine hohe Verfügbarkeit von Geschäftssystemen gewährleistet. Wir bieten professionelle und systematische SRE-Dienste, um unseren Kunden zu helfen, die Cloud besser zu nutzen, stabilere und zuverlässigere Geschäftssysteme auf Basis der Cloud aufzubauen und die Geschäftsstabilität zu verbessern. Wir hoffen, weitere Technologien teilen zu können, die Unternehmenskunden dabei helfen, in die Cloud zu wechseln, die Cloud sinnvoll zu nutzen und die Cloud-Geschäftsabläufe der Kunden stabiler und zuverlässiger zu machen. Sie können mit DingTalk den untenstehenden QR-Code scannen, um dem DingTalk-Kreis der Alibaba Cloud SRE Technology Academy beizutreten und mit mehr Leuten in der Cloud über Cloud-Plattformen zu kommunizieren.

Originallink: https://developer.aliyun.com/article/784887?

Copyright-Erklärung: Der Inhalt dieses Artikels wurde von registrierten Benutzern von Alibaba Cloud mit echtem Namen beigesteuert. Das Copyright liegt beim ursprünglichen Autor. Die Alibaba Cloud Developer Community besitzt das Copyright nicht und trägt keine entsprechende rechtliche Verantwortung. Spezifische Regeln finden Sie im „Alibaba Cloud Developer Community User Service Agreement“ und in den „Alibaba Cloud Developer Community Intellectual Property Protection Guidelines“. Wenn Sie in dieser Community auf Inhalte stoßen, die des Plagiats verdächtigt werden, füllen Sie bitte das Beschwerdeformular aus, um dies zu melden. Nach der Überprüfung wird diese Community die mutmaßlich rechtsverletzenden Inhalte umgehend löschen.

Dies ist das Ende dieses Artikels über die praktische Wiederherstellung von MySQL-Datenbanken nach Zeitpunkt. Weitere relevante Inhalte zur Wiederherstellung von MySQL-Datenbanken finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!