Zusammenfassung verschiedener Methoden zur MySQL-Datenwiederherstellung

Inhaltsverzeichnis

1. Einleitung
2. Direkte Wiederherstellung

2.1 Vollständige Wiederherstellung des mysqldump-Backups
2.2 xtrabackup Backup vollständige Wiederherstellung
2.3 Wiederherstellung basierend auf einem Zeitpunkt

3. Eine Tabelle wiederherstellen

3.1 Wiederherstellen einer Tabelle aus einem mysqldump-Backup
3.2 Wiederherstellen einer Tabelle aus einem xtrabackup-Backup

4. Überspringen Sie fehlerhafte SQL-Operationen

4.1 Wiederherstellen Überspringen mit Backup-Datei
4.2 Überspringen mit der Delay-Bibliothek

5. Rückblende.

5.1 binlog2sql
5.2 Mein Flash

1. Einleitung

Voraussetzung für die Datenwiederherstellung ist, ein gutes Backup zu erstellen und Binlog im Zeilenformat zu aktivieren. Wenn keine Sicherungsdatei vorhanden ist, wird die Bibliothekstabelle nach dem Löschen tatsächlich gelöscht. Wenn in lsof noch Datensätze vorhanden sind, können einige Dateien wiederhergestellt werden. Wenn die Datenbank diese Tabellendatei jedoch nicht öffnet, können Sie nur weglaufen. Wenn Binlog nicht aktiviert ist, gehen nach der Wiederherstellung alle Daten vom Sicherungszeitpunkt verloren. Wenn das Binärprotokollformat nicht zeilenweise vorliegt, besteht nach einer fehlerhaften Operation an den Daten keine Möglichkeit, einen Flashback-Vorgang durchzuführen. Sie können nur den Sicherungs- und Wiederherstellungsprozess durchlaufen.

2. Direkte Wiederherstellung

Bei der direkten Wiederherstellung wird die Sicherungsdatei verwendet, um eine vollständige Wiederherstellung durchzuführen. Dies ist das gängigste Szenario.

2.1 Vollständige Wiederherstellung des mysqldump-Backups

Das Wiederherstellen von Daten mit der mysqldump-Datei ist sehr einfach. Einfach entpacken und ausführen:

gzip -d backup.sql.gz | mysql -u<Benutzer> -h<Host> -P<Port> -p

2.2 xtrabackup Backup vollständige Wiederherstellung

Wiederherstellungsprozess:

# Schritt 1: Dekomprimieren (wenn keine Komprimierung vorhanden ist, können Sie diesen Schritt überspringen)
innobackupex --decompress <Sicherungsdateiverzeichnis>

# Schritt 2: Protokoll anwenden innobackupex --apply-log <Sicherungsdateiverzeichnis>

 # Schritt 3: Kopieren Sie die Sicherungsdatei in das Datenverzeichnis innobackupex --datadir=<MySQL-Datenverzeichnis> --copy-back <Sicherungsdateiverzeichnis>

2.3 Wiederherstellung basierend auf einem Zeitpunkt

Die zeitpunktbezogene Wiederherstellung basiert auf Binärprotokollen. Sie müssen alle Protokolle vom Sicherungspunkt bis zum Wiederherstellungspunkt im Binärprotokoll suchen und sie dann anwenden. Lass es uns testen.

Erstellen Sie eine neue Testtabelle:

chengqm-3306>>show create table mytest.mytest \G;
*************************** 1. Reihe ***************************
       Tabelle: mytest
Tabelle erstellen: CREATE TABLE `mytest` (
  `id` int(11) NICHT NULL AUTO_INCREMENT,
  `ctime` Datum/Uhrzeit STANDARD NULL,
  PRIMÄRSCHLÜSSEL (`id`)
) ENGINE=InnoDB STANDARD-CHARSET=utf8

Fügen Sie pro Sekunde ein Datenelement ein:

[mysql@mysql-test ~]$ while true; mache mysql -S /tmp/mysql.sock -e 'insert in

Sicherung:

[mysql@mysql-test ~]$ mysqldump --opt --single-transaction --master-data=2 --defa

Ermitteln Sie den Speicherort des Protokolls zum Zeitpunkt der Sicherung:

[mysql@mysql-test ~]$ head -n 25 backup.sql | grep 'ÄNDERN SIE MASTER IN MASTER_LOG_FILE'
-- ÄNDERN SIE MASTER IN MASTER_LOG_FILE='mysql-bin.000032', MASTER_LOG_POS=39654;

Angenommen, wir möchten den Zeitpunkt vom 09.08.2019, 11:01:54 Uhr wiederherstellen, durchsuchen wir das Binärprotokoll nach Protokollen von 39654 bis 09.08.2019, 11:01:54 Uhr.

[mysql@mysql-test ~]$ mysqlbinlog --start-position=39654 --stop-datetime='2019-08-09 11:01:54' /data/mysql_log/mysql_test/mysql-bin.000032 > backup_inc.sql
[mysql@mysql-test-83 ~]$ tail -n 20 backup_inc.sql
......
### INSERT INTO `mytest`.`mytest`
### SATZ
### @1=161 /* INT meta=0 nullable=0 is_null=0 */
### @2='2019-08-09 11:01:53' /* DATETIME(0) meta=0 nullable=1 is_null=0 */
......

Aktueller Bestand an Dateneinträgen:

-- Die Anzahl der Daten vor 2019-08-09 11:01:54chengqm-3306>>select count(*) from mytest.mytest where ctime < '2019-08-09 11:01:54';
+----------+
| Anzahl(*) |
+----------+
| 161 |
+----------+
1 Zeile im Satz (0,00 Sek.)

Alle Datenelemente

chengqm-3306>>Wählen Sie count(*) aus mytest.mytest aus.
+----------+
| Anzahl(*) |
+----------+
| 180 |
+----------+
1 Zeile im Satz (0,00 Sek.)

Führen Sie dann die Wiederherstellung durch:

# Vollständige Wiederherstellung [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup.sql

 # Inkrementelles Protokoll anwenden [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup_inc.sql

Überprüfen Sie die Daten:

chengqm-3306>>Wählen Sie count(*) aus mytest.mytest aus.
+----------+
| Anzahl(*) |
+----------+
| 161 |
+----------+
1 Zeile im Satz (0,00 Sek.)

chengqm-3306>>Wählen Sie * aus mytest.mytest, sortiert nach ID-Beschreibungslimit 5;
+-----+---------------------+
| Ich würde | cZeit |
+-----+---------------------+
| 161 | 09.08.2019 11:01:53 |
| 160 | 09.08.2019 11:01:52 |
| 159 | 09.08.2019 11:01:51 |
| 158 | 09.08.2019 11:01:50 |
| 157 | 09.08.2019 11:01:49 |
+-----+---------------------+
5 Zeilen im Satz (0,00 Sek.)

Es wurde auf den Zeitpunkt 09.08.2019 11:01:54 wiederhergestellt.

3. Eine Tabelle wiederherstellen

3.1 Wiederherstellen einer Tabelle aus einem mysqldump-Backup

Angenommen, die wiederherzustellende Tabelle ist mytest.mytest:

# Alle Daten aus einer Datenbank extrahieren sed -n '/^-- Aktuelle Datenbank: `mytest`/,/^-- Aktuelle Datenbank:/p' backup.sql > backup_mytest.sql

# Extrahieren Sie die Anweisung zur Tabellenerstellung aus der Sicherungsdatei der Bibliothek sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `mytest`/!d;q' backup_mytest.sql > mytest_table_create.sql

# Extrahieren Sie die Anweisung zum Einfügen von Daten aus der Sicherungsdatei der Bibliothek grep -i 'INSERT INTO `mytest`' backup_mytest.sql > mytest_table_insert.sql

# Stellen Sie die Tabellenstruktur in der Mytest-Bibliothek wieder her mysql -u<Benutzer> -p mytest < mytest_table_create.sql

# Tabellendaten in mytest.mytest wiederherstellen tablemysql -u<Benutzer> -p mytest < mytest_table_insert.sql

3.2 Wiederherstellen einer Tabelle aus einem xtrabackup-Backup

Angenommen, das Verzeichnis ./backup_xtra_full enthält die Sicherungsdateien mit den nach der Dekomprimierung angewendeten Protokollen.

3.2.1 MyISAM-Tabelle Angenommen, die Tabelle mytest.t_myisam wird aus der Sicherungsdatei wiederhergestellt. Suchen Sie die drei Dateien t_myisam.frm, t_myisam.MYD und t_myisam.MYI aus der Sicherungsdatei, kopieren Sie sie in das entsprechende Datenverzeichnis und autorisieren Sie

Geben Sie MySQL ein. Checkliste Zustand:

chengqm-3306>>Tabellen anzeigen;
+------------------+
| Tabellen_in_mytest |
+------------------+
| meintest |
| t_myisam |
+------------------+
2 Zeilen im Satz (0,00 Sek.)

chengqm-3306>>Tabelle t_myisam prüfen;
+-----------------+----------+----------+----------+
| Tabelle | Op | Nachrichtentyp | Nachrichtentext |
+-----------------+----------+----------+----------+
| mytest.t_myisam | prüfen | Status | OK |
+-----------------+----------+----------+----------+
1 Zeile im Satz (0,00 Sek.)

3.2.2 Innodb-Tabelle Angenommen, die Tabelle mytest.t_innodb wird aus der Sicherungsdatei wiederhergestellt. Voraussetzung für die Wiederherstellung ist, dass innodb_file_per_table = on gesetzt ist:

Starten Sie eine neue Instanz;
Erstellen Sie auf der Instanz eine Tabelle, die genau mit der ursprünglichen Tabelle identisch ist.
Führen Sie „alter table t_innodb discard tablespace;“ aus, um den Tablespace zu löschen. Dieser Vorgang löscht t_innodb.ibd.
Suchen Sie die Datei t_innodb.ibd in der Sicherungsdatei, kopieren Sie sie in das entsprechende Datenverzeichnis und autorisieren Sie sie.
Führen Sie „alter table t_innodb IMPORT tablespace“ aus, um den Tablespace zu laden.
Führen Sie „flush table t_innodb;check table t_innodb;“ aus, um die Tabelle zu überprüfen.
Verwenden Sie mysqldump, um die Daten zu exportieren und sie dann in die wiederherzustellende Datenbank zu importieren.

Beachten:

Das Wiederherstellen auf einer neuen Instanz und anschließende Auslagern dient der Risikovermeidung. Wenn es sich um einen Test handelt, können Sie die Schritte 2 bis 6 direkt auf der Originaldatenbank ausführen.
Nur gültig in Versionen vor 8.0.

4. Überspringen Sie fehlerhafte SQL-Operationen

Das Überspringen von falschem SQL wird im Allgemeinen verwendet, um Vorgänge auszuführen, die nicht zurückgesetzt werden können, z. B. „Drop table\database“.

4.1 Wiederherstellen Überspringen mit Backup-Datei

4.1.1 GTID deaktivieren

Die Schritte zum Wiederherstellen mithilfe einer Sicherungsdatei ähneln denen für die zeitpunktbezogene Wiederherstellung, mit dem Unterschied, dass zusätzlich ein Binärprotokoll-Suchvorgang durchgeführt wird. Ich habe beispielsweise zwei Tabellen a und b erstellt, jede Minute ein Datenelement eingefügt, dann ein vollständiges Backup erstellt und anschließend Tabelle b gelöscht. Jetzt möchte ich dieses SQL überspringen.

Der Datenbankstatus nach dem Löschen der Tabelle b:

chgnqm-3306>>Tabellen anzeigen;
+------------------+
| Tabellen_in_mytest |
+------------------+
| ein |
+------------------+
1 Zeile im Satz (0,00 Sek.)

Ermitteln Sie den Speicherort des Protokolls zum Zeitpunkt der Sicherung

[mysql@mysql-test ~]$ head -n 25 backup.sql | grep 'CHANGE MASTER TO MASTER_LOG_FILE'
-- ÄNDERN SIE MASTER IN MASTER_LOG_FILE='mysql-bin.000034', MASTER_LOG_POS=38414;

Suchen Sie die POS-Position, an der die Drop-Table-Anweisung ausgeführt wurde

[mysql@mysql-test mysql_test]$ mysqlbinlog -vv /data/mysql_log/mysql_test/mysql-bin.000034 | grep -i -B 3 'Tabelle ‚b‘ löschen';
# bei 120629
#190818 19:48:30 Server-ID 83 end_log_pos 120747 CRC32 0x6dd6ab2a Abfrage Thread_ID=29488 exec_time=0 error_code=0
ZEITSTEMPEL FESTLEGEN=1566128910/*!*/;
DROP TABLE `b` /* vom Server generiert */

Aus den Ergebnissen können wir ersehen, dass die Startposition der Drop-Anweisung 120629 und die Endposition 120747 ist.

Extrahieren Sie andere Datensätze aus Binglog, die diese Anweisung überspringen

# Die Startposition der ersten Zeile ist die POS-Position der Sicherungsdatei und die Stoppposition ist die Startposition der Drop-Anweisung mysqlbinlog -vv --start-position=38414 --stop-position=120629 /data/mysql_log/mysql_test/mysql-bin.000034 > backup_inc_1.sql

# Die Startposition der zweiten Zeile ist die Endposition der Drop-Anweisung mysqlbinlog -vv --start-position=120747 /data/mysql_log/mysql_test/mysql-bin.00003

Wiederherstellen einer Sicherungsdatei

[mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup.sql

Status nach vollständiger Genesung:

chgnqm-3306>>Tabellen anzeigen;
+------------------+
| Tabellen_in_mytest |
+------------------+
| ein |
| b |
+------------------+
2 Zeilen im Satz (0,00 Sek.)

chgnqm-3306>>Wählen Sie count(*) aus a aus;
+----------+
| Anzahl(*) |
+----------+
| 71 |
+----------+
1 Zeile im Satz (0,00 Sek.)

Inkrementelle Daten wiederherstellen

[mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup_inc_1.sql
[mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup_inc_2.sql

Nach der Wiederherstellung können Sie sehen, dass die Drop-Anweisung übersprungen wurde:

chgnqm-3306>>Tabellen anzeigen;
+------------------+
| Tabellen_in_mytest |
+------------------+
| ein |
| b |
+------------------+
2 Zeilen im Satz (0,00 Sek.)

chgnqm-3306>>Wählen Sie count(*) aus a aus;
+----------+
| Anzahl(*) |
+----------+
| 274 |
+----------+
1 Zeile im Satz (0,00 Sek.)

4.1.2 GTID aktivieren
Mit GTID können Sie das fehlerhafte SQL direkt überspringen:

Ermitteln Sie den Speicherort des Protokolls zum Zeitpunkt der Sicherung.
Finden Sie den GTID-Wert heraus, der die Drop-Table-Anweisung ausgeführt hat.
Beim Exportieren des Backups wird der Protokollspeicherort in das neueste Binglog-Protokoll verschoben.
Sicherungsdateien wiederherstellen;
Überspringen Sie diese GTID;

SET SESSION GTID_NEXT='entsprechender GTID-Wert';
BEGINNEN; VERPFLICHTEN;
SETZEN SIE DIE SESSION GTID_NEXT = AUTOMATISCH;

Wenden Sie das in Schritt 3 erhaltene inkrementelle Binärprotokoll an.

4.2 Überspringen mit der Delay-Bibliothek

4.2.1 GTID deaktivieren

Der Schlüsselvorgang bei der verzögerten Bibliothekswiederherstellung besteht darin, den Slave zu starten, bis. Ich habe in der Testumgebung zwei MySQL-Knoten eingerichtet. Knoten 2 hatte eine Verzögerung von 600 Sekunden. Es wurden zwei Tabellen, a und b, erstellt. Jede Sekunde wurde ein Datenelement eingefügt, um das Einfügen von Geschäftsdaten zu simulieren.

localhost:3306 -> localhost:3307 (Verzögerung 600)

Aktueller Knoten 2-Status:

chengqm-3307>>Slave-Status anzeigen \G;
...
                  Master_Port: 3306
                Verbindungswiederholung: 60
              Master_Log_File:mysql-bin.000039
          Read_Master_Log_Pos: 15524
               Relay-Log-Datei:mysql-relay-bin.000002
                Relay_Log_Pos: 22845
        Relay_Master_Log_File: mysql-bin.000038
             Slave_IO_Running: Ja
            Slave_SQL_Running: Ja
...
        Sekunden_Hinter_Master: 600
...

Aktuelle Tabelle mit Knoten zwei:

chengqm-3307>>Tabellen anzeigen;
+------------------+
| Tabellen_in_mytest |
+------------------+
| ein |
| b |
+------------------+

Tabelle b am Knoten 1 löschen:

chengqm-3306>>Tabelle b löschen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

chengqm-3306>>Tabellen anzeigen;
+------------------+
| Tabellen_in_mytest |
+------------------+
| ein |
+------------------+
1 Zeile im Satz (0,00 Sek.)

Der nächste Schritt besteht darin, die SQL-Anweisung zu überspringen.

Verzögerung der Bibliotheksbeendigung bei der Synchronisierung

Sklave stoppen;

Suchen Sie die POS-Position der Anweisung, bevor die Drop-Table-Anweisung ausgeführt wird

[mysql@mysql-test ~]$ mysqlbinlog -vv /data/mysql_log/mysql_test/mysql-bin.000039 | grep -i -B 10 'Tabelle ‚b‘ löschen';
...
# bei 35134
#190819 11:40:25 Server-ID 83 End-Log-Pos 35199 CRC32 0x02771167 Anonymous_GTID last_committed=132 Sequenznummer=133 rbr_only=nein
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# bei 35199
#190819 11:40:25 Server-ID 83 end_log_pos 35317 CRC32 0x50a018aa Abfrage Thread_ID=37155 Exec_Time=0 Error_Code=0
verwende „mytest“/*!*/;
ZEITSTEMPEL EINSTELLEN=1566186025/*!*/;
DROP TABLE `b` /* vom Server generiert */

Aus den Ergebnissen können wir ersehen, dass die Startposition der Anweisung vor der Drop-Anweisung 35134 ist, also synchronisieren wir auf 35134 (treffen Sie nicht die falsche Wahl).

Verzögerung der Datenbanksynchronisierung mit SQL, um sie zu überspringen Zurück

Ändere Master in Master_Delay=0;
Slave starten, bis master_log_file='mysql-bin.000039',master_log_pos=35134;

Überprüfen Sie den Status, um festzustellen, ob die Synchronisierung mit dem entsprechenden Knoten erfolgt ist:

chengqm-3307>>Slave-Status anzeigen \G;
...
                  Master_Port: 3306
                Verbindungswiederholung: 60
              Master_Log_File:mysql-bin.000039
          Read_Master_Log_Pos: 65792
...
             Slave_IO_Running: Ja
            Slave_SQL_Running: Nein
          Exec_Master_Log_Pos: 35134
...
               Bis_Log_Datei: mysql-bin.000039
                Bis_Log_Pos: 35134

Starten Sie die Synchronisierung, nachdem Sie eine SQL-Anweisung übersprungen haben

Setzen Sie den globalen sql_slave_skip_counter = 1.
Slave starten;

Überprüfen Sie den Synchronisierungsstatus und die Anweisung zum Löschen der Tabelle B wurde übersprungen:

chengqm-3307>>Slave-Status anzeigen \G;
...
             Slave_IO_Running: Ja
            Slave_SQL_Running: Ja
...
1 Zeile im Satz (0,00 Sek.)

chengqm-3307>>Tabellen anzeigen;
+------------------+
| Tabellen_in_mytest |
+------------------+
| ein |
| b |
+------------------+
2 Zeilen im Satz (0,00 Sek.)

4.2.2 GTID aktivieren
Die Schritte zum Überspringen mit GTID sind viel einfacher. Sie müssen nur eine Transaktion mit derselben GTID wie das zu überspringende SQL ausführen.

Synchronisierung beenden;
Finden Sie die GTID heraus, die die Drop-Table-Anweisung ausgeführt hat.
Führen Sie die Transaktion dieser GTID aus;

SET SESSION GTID_NEXT='entsprechender GTID-Wert';
BEGINNEN; VERPFLICHTEN;
SETZEN SIE DIE SESSION GTID_NEXT = AUTOMATISCH;

Synchronisierung fortsetzen;

5. Rückblende.

Der Flashback-Vorgang ist die umgekehrte Operation. Wenn beispielsweise „delete from a where id=1“ ausgeführt wird, führt der Flashback den entsprechenden Einfügevorgang „insert into a (id,...) values(1,...)“ aus. Er wird verwendet, um fehlerhafte Datenoperationen zu korrigieren. Er ist nur für DML-Anweisungen gültig und erfordert, dass das Binlog-Format auf ROW eingestellt ist. In diesem Kapitel werden zwei relativ nützliche Open-Source-Tools vorgestellt.

5.1 binlog2sql

binlog2sql ist ein von Dianping.com entwickeltes Open-Source-Tool zum Parsen von Binlogs. Es kann zum Generieren von Flashback-Anweisungen verwendet werden. Die Projektadresse lautet binlog2sql.

5.1.1 Installation

wget https://github.com/danfengcao/binlog2sql/archive/master.zip -O binlog2sql.zip
entpacken Sie binlog2sql.zip
cd binlog2sql-master/

# Abhängigkeiten installieren pip install -r requirements.txt

5.1.2 Rollback-SQL generieren

python binlog2sql/binlog2sql.py --flashback \
-h<Host> -P<Port> -u<Benutzer> -p'<Passwort>' -d<Datenbankname> -t<Tabellenname>\
--start-file='<binlog_datei>' \
--start-datetime='<Startzeit>' \
--stop-datetime='<Stoppzeit>' > ./flashback.sql

python binlog2sql/binlog2sql.py --flashback \
-h<Host> -P<Port> -u<Benutzer> -p'<Passwort>' -d<Datenbankname> -t<Tabellenname> \
--start-file='<binlog_datei>' \
--start-position=<Startposition> \
--stop-position=<Stoppposition> > ./flashback.sql

5.2 Mein Flash

MyFlash ist ein Tool zum Zurücksetzen von DML-Operationen, das von der technischen Abteilung von Meituan Dianping entwickelt und gepflegt wird. Der Projektlink lautet MyFlash.

Limit:

Das Binlog-Format muss Zeile und binlog_row_image=full sein;
Unterstützt nur 5.6 und 5.7;
Nur DML (Hinzufügen, Löschen, Ändern) kann zurückgesetzt werden.

5.2.1 Installation

# Abhängigkeiten (Centos)
yum installiere gcc* pkg-config glib2 libgnomeui-devel -y

# Laden Sie die Datei herunter wget https://github.com/Meituan-Dianping/MyFlash/archive/master.zip -O MyFlash.zip
entpacken Sie MyFlash.zip
CD MyFlash-Master

# Kompilieren und installieren Sie gcc -w `pkg-config --cflags --libs glib-2.0` source/binlogParseGlib.c -o binary/flashback
mv binär /usr/local/MyFlash
ln -s /usr/local/MyFlash/flashback /usr/bin/flashback

5.2.2 Verwenden Sie die generierte Rollback-Anweisung:

Flashback --databaseNames=<Datenbankname> --binlogFileNames=<Binärlogdatei> --start-position=<s

Nach der Ausführung wird eine Datei binlog_output_base.flashback generiert, die vor der Verwendung von mysqlbinlog analysiert werden muss:

mysqlbinlog -vv binlog_output_base.flashback | mysql -u<Benutzer> -p

Oben finden Sie detaillierte Informationen zu den verschiedenen Methoden zur MySQL-Datenwiederherstellung. Weitere Informationen zur MySQL-Datenwiederherstellung finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!

Das könnte Sie auch interessieren:

So stellen Sie Daten mit Binlog in MySQL 5.7 wieder her
MySQL stellt Daten über Binlog wieder her
MySQL verwendet frm-Dateien und ibd-Dateien, um Tabellendaten wiederherzustellen
MySQL verwendet Binlog-Protokolle zur Implementierung der Datenwiederherstellung
Implementierung von MySQL mit dem Befehl mysqlbinlog zum Wiederherstellen versehentlich gelöschter Daten
Zwei Methoden zum Wiederherstellen von MySQL-Daten
Implementierungscode für die Sicherung und Wiederherstellung von MySQL-Datenbanken
MySQL verwendet mysqldump + binlog, um die Prinzipanalyse der gelöschten Datenbank vollständig wiederherzustellen
Analyse der Implementierungsmethoden für MySQL-Datensicherung und -Wiederherstellung
MySQL Binlog-Datenwiederherstellung: Detaillierte Erklärung zum versehentlichen Löschen einer Datenbank

<<: Detaillierte Erklärung des Ungültigkeitsprozesses des VUE-Tokens

>>: Der derzeit bessere Weg, eine Auswahlliste mit allen Optionen zu erstellen, wenn diese ausgewählt/fokussiert sind