--------------------------------- --- -
------Physisches Backup-Tool Innobackupex------
------------------ --- -----------
Offizielles Handbuch: https://www.percona.com/doc/ percona- xtrabackup/LATEST/index.html
wird hauptsächlich für Hot-Backups von Daten verwendet, die in Engines wie InnoDB und MyISAM gespeichert sind. Beim Backup werden die zu sichernden Daten in den Speicher geladen und dann darauf geschrieben die Sicherungsdatendatei auf der Festplatte. Die während der Sicherung geänderten Daten werden auf die gleiche Weise wie bei der Redo-Log-Wiederherstellung an die Sicherungsdatei angehängt.
========================================== == ============================================== == ==
innobackupex vollständiger Vorbereitungsprozess:
1. Aktivieren Sie xtrabackup_logfile. Wird verwendet, um diese neuen Datenänderungen in xtrabackup_logfile in Echtzeit während des gesamten Hot-Backup-Prozesses aufzuzeichnen, wenn neue DML-Vorgänge unter der InnoDB-Speicher-Engine Datenänderungen hervorrufen. Das Aufzeichnungsformat ist das gleiche wie Redo-Log
2, in page Einheiten. Kopieren Sie die in InnoDB gespeicherten Datendateien: ibdataX- und .ibd-Dateien im gemeinsam genutzten Tabellenbereich. Da die Seite möglicherweise während des Kopierens geschrieben wird, sind die Kopf- und Endprüfsummenwerte der Seite unterschiedlich. Daher müssen Sie beim späteren Generieren von Sicherungsdateien ein Protokoll anwenden, bevor Sie sie zum Reparieren einiger unvollständiger Seiten verwenden können.
3. Tabellen mit Lesesperre leeren. Fügen Sie der MyISAM-Tabelle eine Lesesperre hinzu, um die in der Nicht-Transaktions-Engine MyISAM gespeicherten Daten zu kopieren.
4. Kopieren Sie die Dateien .frm, .MYD und .MYI.
5. Holen Sie sich die aktuelle Position von Binlog zum Zeitpunkt des Abschlusses der Sicherung: xtrabackup_binlog_info (InnoDB-Datendateien werden möglicherweise aktualisiert).
6. Tabellen entsperren;
7. Nachdem die Sicherung abgeschlossen ist, notieren Sie die zum Starten der Sicherung erforderlichen Mindestparameter
( 2) Notieren Sie die LSN in xtrabackup_logfile.
(3) Notieren Sie den Sicherungstyp (vollständig gesichert: vollständig, inkrementell: inkrementell; das Protokoll der angewendeten Sicherungen wird in „vollständig vorbereitet“ geändert) und andere Informationen in xtrabackup_checkpoints.
(4) Zeichnen Sie einige andere Sicherungsinformationen auf: xtrabackup_info
Das Folgende ist eine Zusammenfassung der Datenbanktabellendaten, Tabellenbereichsdateien (ibdata) und Redo-Protokoll (ib_logfile) in das Datenverzeichnis außer dem Kopieren. Außerdem alle generierten Dateien:
(1) backup-my.cnf
(2) xtrabackup_binlog_info: Bei Verwendung von MyISAM für die Datensicherung, genauer als xtrabackup_binlog_pos_innodb
(3) xtrabackup_binlog_pos_innodb: Die neu generierte Datei nach dem Anwenden des Protokolls zeichnet nur die Binlog-Position von innodb auf und berechnet nicht das von generierte Binlog MyISAM
(4) xtrabackup_checkpoints
(5) xtrabackup_info
(6) xtrabackup_logfile (Kerndatei)
(7) xtrabackup_slave_info (wichtige Dateien aus der Bibliothek sichern): Sie müssen beim Sichern die Option --slave-info hinzufügen und „ändern „Master“ wird in dieser Datei unter „Informationen“ aufgezeichnet. Nach Verwendung der Sicherungsdatei zur Wiederherstellung der Slave-Datenbank werden diese Informationen als Referenz für die Synchronisierung auf die Master-Datenbank verwendet.
========================================== == ============================================== == ==
innobackupex inkrementeller Sicherungsprozess
Wenn innobackupex im Vergleich zum vollständigen Sicherungsprozess InnoDB-Tabellendaten inkrementell sichert, vergleicht die inkrementelle Sicherung die Seite, wenn sie kopiert wird. Die LSN der Seite zwischen der Datei und den aktuellen Daten sowie die LSN der Seite, die sich auf die geänderten Daten bezieht, werden erhöht. Innobackupex muss also nur Seiten mit geänderten LSNs sichern.
Beim Sichern von MyISAM wird weiterhin ein vollständiger Sicherungsvorgang durchgeführt.
========================================== == ============================================== == ==
Beispiel für eine Sicherungsanweisung
Erforderliche Berechtigungen für Sicherungskonto: RELOAD, LOCK TABLES, REPLICATION CLIENT
(1) Vollständig vorbereitet:
Schritt 1:
innobackupex --defaults-file=/usr/local/mysql/my.cnf --user=username --password='user_passwd' --host=[HOST] -- port=【PORT】 --no-timestamp /tmp/innobackup_all
Schritt 2:
innobackupex --apply-log --defaults-file=/tmp/innobackup_all/backup-my .cnf --user=username --password='user_passwd' --host=[HOST]--port=[PORT] --/tmp/innobackup_all
(2) Teilsicherungen: Sicherungsformular Zum Beispiel : mydatabase.mytable
Schritt 1:
Verwenden Sie --include mit regulärem Ausdruck
innobackupex --include='^mydatabase[.]mytable' /path/to /backup --no-timestamp
Verwenden Sie --tables-file mit einer Textdatei, die den vollständigen Tabellennamen aufzeichnet (ein Tabellenname pro Zeile)
echo "mydatabase.mytable " > /tmp/tables.txt
innobackupex --tables-file=/tmp/tables.txt /path/to/backup --no-timestamp
Verwenden Sie --databases, um Bibliotheken und Tabellen anzugeben (z. B. Sicherungstabelle: mydatabase.mytable und Bibliothek: mysql)
innobackupex --databases="mydatabase.mytable mysql" /path/to/backup --no -timestamp --user=backup --password=backup
Schritt 2:
Teilsicherung vorbereiten: innobackupex --apply-log --export /path/to/ backup/
(--databases unspezifizierte Datenbanktabellen werden während der Vorbereitungsphase mit der Meldung „Existiert“ gefragt, Sie können diese Meldung ignorieren)
(3) Inkrementelle Sicherung (vorausgesetzt, sie ist vollständig vorbereitet, Pfad: $FULLBACKUP)
Schritt 1:
Erstes inkrementelles Backup (basierend auf vollständigem Backup): innobackupex --incremental $INCREMENTALBACKUP_1 --incremental-basedir=$FULLBACKUP --user=USER --password=PASSWORD
Zweite inkrementelle Sicherung (basierend auf der ersten inkrementellen Sicherung): innobackupex --incremental $INCREMENTALBACKUP_2 --incremental-basedir=NCREMENTALBACKUP_1 --user=USER --password=PASSWORD
(...)
N. Mal
Schritt 2: Vorbereiten
innobackupex -- apply-log --redo-only $FULLBACKUP --use-memory=1G --user=USER --password=PASSWORD
innobackupex --apply-log --redo-only $FULLBACKUP--incremental- dir=$INCREMENTALBACKUP_1 --use- Speicher=1G --user=DVADER --password=D4RKS1D3
innobackupex --apply-log --redo-only $FULLBACKUP --incremental-dir=$ INCREMENTALBACKUP_2 --use-memory=1G --user=DVADER --password=D4RKS1D3
(...)
innobackupex --apply-log--redo -only $FULLBACKUP --incremental-dir=$ INCREMENTALBACKUP_N --use-memory=1G --user=DVADER --password=D4RKS1D3
innobackupex --apply-log $FULLBACKUP --use- Memory=1G --user=$USERNAME -- passwort=$PASSWORD
--use-memory: Geben Sie den Speicher an, den Prepare verwenden kann. Verwenden Sie ihn in Verbindung mit --apply-log, um die Vorbereitung zu beschleunigen >In der Vorbereitungsphase muss --redo-only während des ersten vollständigen Backup- und inkrementellen Backup-Integrationsprozesses hinzugefügt werden. Nachdem alle inkrementellen Sicherungen integriert wurden, müssen abschließend die vollständigen Sicherungsdateien, die in die inkrementellen Sicherungen integriert wurden, erneut vorbereitet werden.
========================================== == ============================================== == ==
Einige andere allgemeine Parameter:
Zusammen verwenden: --stream=xbstream --compress --compress-threads=8 --parallel=4 > xbstream-Option Die ibd-Dateien der Tabelle werden einzeln komprimiert und gestreamt, daher muss der Parameter innodb-file-per-table aktiviert werden)
--parallel: Backup-Parallelitätsnummer (bezogen auf das Kopieren). die ibd-Datei, anders als compress-threads. Ist die Anzahl der Threads, die die Komprimierung durchführen)
--stream: tar, xbstream. Wird oft zusammen mit verwendet: innobackupex [...] --stream=tar /backupdir/ |. gzip - > backupfile.tar.gz
--tmpdir: das temporäre Verzeichnis vor dem Streaming zum Remote-Computer 🎜>
--encryption: Backup-Verschlüsselung. In tatsächlichen Situationen wird am häufigsten
(1) openssl verwendet, das der oben genannten tar+gz-Methode Verschlüsselungsoptionen hinzufügt: innobackupex [...] --stream=tar /backupdir/ |. |. openssl aes -256-cbc -k "abc" > backupfile.tar.gz.aes-256-cbc
(2) des3, innobackupex [...] --stream=tar /backupdir/ |. gzip - |. openssl des3 -salt -k "abc" > backupfile.tar.gz.des3
================= === ============================================ === ======================
Innobackupex-Wiederherstellungsprozess
1. innobackupex – apply-log, der Zweck besteht darin, das Redo-Protokoll von xtrabackup_log abzurufen, einige unvollständige Seiten zu aktualisieren, die Kopf- und Endprüfsummenwerte zu erstellen und die LSN auf die neueste LSN-Nummer im Backup-Prozess zu aktualisieren unterteilt in den Sicherungsvorgang)
2. Kopieren Sie die Sicherungsdaten in das Datenbankdatenverzeichnis
3.
========================================== == ============================================== == ==
Beispiel für eine Wiederherstellungsanweisung:
1. Schließen Sie die Instanz vor der Wiederherstellung
2. Sichern Sie das ursprüngliche Datenverzeichnis (auch das Redo-Log und das Undo-Log). müssen gesichert werden, wenn sie getrennt sind)
3 .sock --defaults-file=/usr /local/mysql/my.cnf /tmp/innobackup_all (oder kopieren Sie direkt die vorbereitete Sicherungsdatei)
4. Ändern Sie die Verzeichnisberechtigungen und starten Sie MySQL
====== ====================================== ========== ====================================== =
Von Quanbei Mit dem Percona XtraBackup können Sie einzelne Tabellen aus jeder InnoDB-Datenbank exportieren und sie mit XtraDB oder MySQL 5.6 in Percona Server importieren (Die Quelle muss nicht XtraDB oder MySQL 5.6 sein, Dies funktioniert jedoch nur bei einzelnen .ibd-Dateien und kann keine Tabelle exportieren, die nicht in einer eigenen .ibd-Datei enthalten ist.
ist erforderlich. In der Vorbereitungsphase wird eine einzelne Tabelle exportiert die Option --export:
Sobald ein vollständiges Backup erstellt wurde, bereiten Sie es mit der Option --export vor:
$ innobackupex --apply-log --export /path/to/backup
Dadurch wird für jede InnoDB mit eigenem Tablespace eine Datei mit der Erweiterung .exp erstellt.
Für den Tabellenbereich jeder Innodb-Tabelle wird eine Datei mit der Endung .exp erstellt.
Die Ausgabedatei hat das Format:
/data/backups/mysql/test/export_test .exp
/data/backups/mysql/test/export_test.ibd
/data/backups/mysql/test/export_test.cfg
Beim Importieren von Tabellen von anderen Servern benötigen Sie um zuerst eine Tabelle zu erstellen (da es keine Tabellenstrukturinformationen in der unabhängigen Tabellendatei gibt):
mysqlfrm --diagnostic /data/2017-03-22_16-13-00/yayun/t1.frm (unter Verwendung der mysql-utilities-Tool mysqlfrm liest die Tabellenstruktur aus der Sicherungsdatei)
mysql> CREATE TABLE mytable (...) ENGINE=InnoDB; (Gehe zum Erstellen einer Tabelle basierend auf der zuvor gelesenen Tabellenstruktur)
Tabellenbereichsdateien löschen:
mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
Kopieren Sie die exportierten .ibd- und .exp-Dateien in das Datenverzeichnis:
Kopieren Sie anschließend die Dateien mytable.ibd und mytable.exp (oder mytable.cfg beim Import in MySQL 5.6) in die Datenbank-Homepage
und importieren Sie dann den Tablespace:
mysql> mydatabase.mytable IMPORT TABLESPACE;
-------------------------------------- --- ---
------Logisches Backup-Tool mydumper------
---------------- --- ----------
Einige englische Dokumente sind Auszüge aus der README-Datei auf GitHub: https://github. com/maxbube/ mydumper
In der MySQL-Datenbankversion 5.5/5.6 bietet das Multithread-Backup-Tool mydumper im Vergleich zur Verwendung des offiziell bereitgestellten mysqldump für Single-Thread-Backups einzigartige Vorteile. (Für Versionen nach MySQL 5.7.11 hat der Beamte endlich das Problem der konsistenten Sicherung des Parallellogik-Sicherungstools mysqlpump behoben. Informationen zu mysqlpump finden Sie in der Einführung von Daniel Jiang Chengyao: http://www.tuicool.com/articles/ E77bYz7)
Nachteile: Es ist schwierig, durch gleichzeitiges Streaming ein Backup zu einem Remote-Backup-Center durchzuführen, und häufiger erfolgt es direkt auf der lokalen Festplatte.
== Wie funktioniert ein konsistenter Snapshot? ==
Dies geschieht alles gemäß den besten MySQL-Praktiken und -Traditionen:
* Als Vorsichtsmaßnahme brechen langsam laufende Abfragen auf dem Server entweder ab Dump oder getötet werden
* Globale Schreibsperre wird erworben („FLUSH TABLES WITH READ LOCK“)
* Verschiedene Metadaten werden gelesen („SHOW SLAVE STATUS“, „SHOW MASTER STATUS“)
* Andere Threads Verbinden und Snapshots erstellen („START TRANSACTION WITH CONSISTENT SNAPSHOT“)
** In Versionen vor 4.1.8 wird eine Dummy-InnoDB-Tabelle erstellt und daraus gelesen.
* Sobald alle Arbeitsthreads die Snapshot-Erstellung ankündigen, wird der Master ausgeführt „UNLOCK TABLES“ und beginnt, Jobs in die Warteschlange zu stellen.
Konsistenzimplementierungsmechanismus von Mydumper:
* Wenn eine langsame Abfrage auftritt, stoppt entweder die Ausführung des Dumps oder mydumper bricht die langsame Abfrage ab. (Der Parameter --long-query-guard wird verwendet, um die Zeit für eine langsame Abfrage zu vereinbaren. Der Standardwert ist 60 Sekunden. Wenn --kill-long-queries zu diesem Parameter hinzugefügt wird, wird die langsame Abfrage aktiv beendet. Wenn es nicht hinzugefügt wird, bricht mydumper die langsame Abfrage automatisch ab, wenn die langsame Abfrage nicht mehr ausgeführt wird)
* Verwenden Sie „FLUSH TABLES WITH READ LOCK“, um eine globale Lesesperre anzuwenden, die DML-Anweisungen verhindert
* Metadaten anzeigen: „SLAVE-STATUS ANZEIGEN“, „MASTER-STATUS ANZEIGEN“
* „TRANSAKTION MIT konsistentem Snapshot STARTEN“: Wenn die Starttransaktion die Transaktion öffnet, wird sofort ein Snapshot des konsistenten Lesevorgangs der aktuellen Transaktion erstellt. Ohne die Option „with“ wird die Transaktion erst dann tatsächlich gestartet, wenn die erste Anweisung in der Transaktion ausgeführt wird, und ein konsistenter Lese-Snapshot erstellt wird
* Ab Version 4.1.8 erstellt mydumper eine virtuelle Tabelle vom Typ InnoDB . Daten daraus lesen
* Sobald alle Threads melden, dass der Konsistenz-Snapshot erstellt wurde, führen Sie „UNLOCK TABLES“ aus und starten Sie die Warteschlangenaufgabe.
Beispiel für eine Sicherungsanweisung:
mydumper --user=username --password=user_passwd --socket=/... --regex '^( ?!(mysql))' --output=/backupdir --compress --verbose=3 --logfile=/backupdir/mydumper_backup.log
Erklärung allgemeiner Parameter:
-- Datenbank Geben Sie die Bibliotheken an, die gesichert werden müssen
--tables-list Geben Sie die Tabellen an, die gesichert werden müssen, getrennt durch (bei Konflikten mit der Regex-Option hat Regex Vorrang)
- -regex '^(?!(mysql |test))': Datenbankfilteroptionen
--output=/backupdir: Ausgabepfad der Sicherungsdatei
--compress: Komprimierte Ausgabe Datei (.gz-Suffix)
--verbose=3: Informationen zur Protokollebene ausgeben, um die Beobachtung des Sicherungsstatus zu erleichtern (0 = still, 1 = Fehler, 2 = Warnungen, 3 = Informationen, Standard 2)
--logfile=/ backupdir/mydumper_backup.log: Geben Sie den Speicherort der von Mydumper ausgeführten Protokolldatei an
--threads Geben Sie die Anzahl der während der Sicherung verwendeten Threads an, der Standardwert ist 4
--statement-size: Begrenzen Sie die maximale Länge von SQL-Anweisungen (mydumper führt SQL während der Sicherung zusammen)
--rows: Teilen Sie die Tabelle nach der Anzahl der Zeilen. Verbessern Sie die Parallelitätsleistung, wenn myloader
--chunk-filesize: Tabellendaten entsprechend der Größe der Ausgabedatei aufteilen. Verbessern Sie die Parallelitätsleistung von myloader
--no-locks: Sperren Sie die Tabelle nicht (die Daten sind möglicherweise inkonsistent)
--binlogs: Sichern Sie Binlog. Wenn die Sicherung fehlschlägt, können Sie das Sicherungs-Binlog überprüfen und die Fehlerursache in der Nähe des Sicherungspunkts finden
Verzeichnis der Ausgabesicherungsdatei:
* Bibliotheksstruktur: Datenbankname-Schema- create.sql.gz
* Tabellenstruktur: dbname.tblname1-schema.sql.gz
* Tabellendaten: dbname.tblname1.sql.gz
(Jede Bibliothek und Tabelle verfügt über eine eigene unabhängige Sicherungsdatei. Wenn nur eine einzelne Tabelle wiederhergestellt werden muss, stellen Sie die einzelne Tabelle über wieder her vollständige Daten der mydumper-Tabelle + Binlog-Wiederherstellungsinkrement)
* Metadaten: Bei Einbeziehung der Sicherung ist die aktuelle Position von Binlog
---------------- -------------------------------------------------- --
Dump gestartet am: 04.07.2017 09:45:57
MASTERSTATUS ANZEIGEN:
Protokoll: mysql-bin.000048
Pos: 107
GTID: (null)
Fertiger Dump am: 04.07.2017 09:45:57
----------------------------------- ----- ---------------------------------------
* mydumper_backup.log: Zeichnet den Ausführungsstatus des Sicherungsprogramms auf
Erläuterung der relevanten Parameter des Wiederherstellungsbefehls myloader
--Verzeichnis-Speicherort der Sicherungsdatei
--Abfragen pro Transaktion Die Anzahl der für jede Transaktion ausgeführten SQL-Anweisungen, der Standardwert ist 1000
--overwrite-tables Löschen Sie zuerst vorhandene Tabellen und stellen Sie sie dann wieder her (beim Sichern von Dateien ist es erforderlich, die Tabellenstruktur zu sichern)
--database Gibt die Datenbank an, die wiederhergestellt werden muss
--enable-binlog wird zum Wiederherstellen von Daten verwendet. Vorgangsdatensatz binlog
--threads gibt die Anzahl der während der Wiederherstellung verwendeten Threads an, der Standardwert ist 4
- -enable-binlog: Stellen Sie das gesicherte Binlog wieder her
Hinweis: Myloader kann sich nur in der Bibliothek befinden. Bei der Wiederherstellung einer einzelnen Tabelle kann die entsprechende Datei mit SQL-Anweisungen in der Sicherungsdatei direkt aufgerufen werden
Darüber hinaus sichert innobackupex die Daten vor diesem Zeitpunkt, zu dem die Sicherung abgeschlossen ist, während mydumper (einschließlich mysqldump, mysqlpump usw.) der Zeitpunkt der gesicherten Daten der Zeitpunkt ist, zu dem die Sicherung beginnt.
Lassen Sie mich die Hauptidee der Wiederherstellung erwähnen: Unabhängig davon, ob es sich um eine physische Sicherung oder eine logische Sicherung handelt, besteht die zuverlässigste Wiederherstellungsvoraussetzung darin, dass die Datenbank das Schreiben von Daten vorübergehend verhindern muss. Stellen Sie dann zuerst die vollständige Sicherung wieder her, wenden Sie eine inkrementelle Sicherung auf den nächstgelegenen Fehlerpunkt an, wenden Sie dann das Binlog-Protokoll an und überspringen Sie den Fehlerpunkt.
Bedenken Sie immer, dass das Stoppen des Schreibvorgangs auf dem Online-Server für einige Fehloperationsanweisungen für eine einzelne Tabelle und die Verwendung der vollständigen + inkrementellen Wiederherstellungsmethode etwas mühsam ist und der Gewinn den Verlust überwiegt. Wenn keine Standby-Datenbank mit Replikationsverzögerungsstrategie vorhanden ist, ist es eine schnelle und gute Lösung, die von mydumper gesicherten Dateien zum Wiederherstellen einer einzelnen Tabelle zu verwenden oder einen Schritt zurückzutreten und Flashback zu verwenden.
Tipps:
Nachdem Sie Innobackupex oder mydumper zum Wiederherstellen der meisten Daten verwendet haben, füllen Sie mit mysqlbing die Datenteile aus, die vom oben genannten Sicherungsprogramm nicht abgedeckt werden können.
Mysqlbinlog-Parametererklärung:
–start-position=N (beim Lesen enthalten)
Beginnen Sie mit dem Lesen ab dem Ereignis, wenn die erste Position im Binärprotokoll dem N-Parameter entspricht.
–stop-position=N (beim Lesen nicht enthalten)
Beenden Sie das Lesen des Ereignisses, wenn die erste Position im Binärprotokoll gleich oder größer als der N-Parameter ist.
Wenn Sie mysqlbinlog zum Anwenden von Binlog-Protokollen verwenden und mehrere Dateien gleichzeitig lesen müssen, ist die Startposition der Startpunkt der ersten Binlog-Datei und die Stoppposition der Endpunkt der letzten Datei.
Beispiel: mysql-bin.000048 (pos856), mysql-bin.000051 (pos1042)
/usr/local/mysql/bin/mysqlbinlog mysql-bin.000048 mysql-bin. 000049 mysql-bin.000050 mysql-bin.000051 --start-position=856 --stop-position=1042 > /tmp/backup1/backup_new.sql
Tipps:
Sicherungsüberwachung immer vorhanden;
Die Sicherungsobjekte der beiden oben genannten Sicherungstools sind hauptsächlich im Datenverzeichnis enthalten. Es ist zu beachten, dass das Binlog auch einige Daten enthält Binlog ist ebenfalls erforderlich. Erstellen Sie Backups.
Eine kurze Erwähnung der Backup-Strategie Die von uns entwickelte Backup-Strategie richtet sich nach der Art des Unternehmens.
Für Unternehmen mit Datenwachstum wird eine vollständige + inkrementelle Strategie angewendet, während für den Datenaktualisierungstyp eine vollständige Sicherung angewendet wird.
Logische Sicherungen werden häufig für Vorgänge wie MySQL-Versions-Upgrades oder die Wiederherstellung einzelner Tabellen verwendet.
Zusammenfassend lässt sich sagen, dass Online-Datenbanken im Allgemeinen die physische Sicherung als Hauptmethode, die logische Sicherung als Ergänzung und die Binlog-Sicherung verwenden.
Referenzdokument:
Beschreibung der innobackupex Backup-Generierungsdatei:
http://fordba.com/xtrabackup-produce-file-intruduction.html
Rezepte für innobackupex:
https://www.percona.com/doc/percona-xtrabackup/LATEST/how-tos.html#recipes-ibk
So generieren Sie aus innobackupex Wiederherstellen einzelner Tabellen im Voll-Backup:
https://www.percona.com/doc/percona-xtrabackup/2.2/innobackupex/restoring_individual_tables_ibk.html
https:// www.percona.com/blog/2012/01/25/how-to-recover-a-single-innodb-table-from-a-full-backup/
https://www .percona.com/blog/2017/03/15/restore-single-innodb-table-full-backup-accidentally-dropping/
Tatsächlicher Wiederherstellungsfall für eine einzelne Tabelle:
http://www.cnblogs.com/gomysql/p/6600616.html
Teilsicherungen erstellen und wiederherstellen:
https://www.percona.com /doc/percona-xtrabackup/2.2/innobackupex/partial_backups_innobackupex.html
Mysqldump kombiniert mit Binlog-Wiederherstellungsfall:
http://blog.chinaunix.net/uid-25135004-id- 1761635 .html
http://www.cnblogs.com/hanyifeng/p/5756462.html
Verwenden Sie die vollständige mysqldump-Datei für die Wiederherstellung einer einzelnen Datenbank (zu testen)
https://stackoverflow.com/questions/1013852/can-i-restore-a-single-table-from-a-full-mysql-mysqldump-file
