Zusammenfassung der Tests für logische MySQL-Sicherungen und -Wiederherstellungen

Zusammenfassung der Tests für logische MySQL-Sicherungen und -Wiederherstellungen

1. Was für eine Art von Backup ist ein logisches Datenbank-Backup?

Wie wir alle wissen, präsentiert uns die Datenbank, wenn sie uns Daten zur Verwendung zurückgibt, diese nacheinander in einem bestimmten logischen Zuordnungsformat, das wir ursprünglich entworfen und erwartet haben, und weist bestimmte Geschäftslogikattribute auf. Auf der physischen Speicherebene speichert die Datenbanksoftware die Daten jedoch nach einer bestimmten Verarbeitung in einem bestimmten, von der Datenbanksoftware entworfenen Format.

Logische Datenbanksicherung bedeutet, dass die Sicherungssoftware zusammengehörige Textdateien nacheinander entsprechend dem vordefinierten logischen Zuordnungsformat für die Daten in der Datenbank generiert, und zwar auf Grundlage der von uns ursprünglich entworfenen logischen Beziehung und unter Berücksichtigung der logischen Strukturobjekte der Datenbank als Einheiten, um so den Zweck der Sicherung zu erreichen.

2. Häufig verwendete logische Sicherung

Die logische Sicherung kann als die einfachste und am häufigsten verwendete Sicherungsmethode für kleine und mittelgroße Systeme bezeichnet werden. Es gibt zwei Haupttypen logischer Sicherungen, die wir häufig in MySQL verwenden. Eine besteht darin, INSERT-Anweisungen zu generieren, die die Daten in der aktuellen Datenbank vollständig reproduzieren können. Die andere besteht darin, logische Sicherungssoftware zu verwenden, um unsere Datenbanktabellendaten mit bestimmten Trennzeichen zu trennen und sie in einer Textdatei aufzuzeichnen.

① Generieren Sie eine Sicherung der INSERT-Anweisung

Die beiden Arten logischer Sicherungen haben ihre eigenen Vor- und Nachteile, und die Anwendungsszenarien, auf die sie abzielen, unterscheiden sich geringfügig. Schauen wir uns zunächst die logische Sicherung an, die INSERT-Anweisungen generiert.

In MySQL-Datenbanken verwenden wir normalerweise mysqldump im Toolprogramm, das mit der MySQL-Datenbanksoftware geliefert wird, um die logische Sicherungsdatei der sogenannten INSERT-Anweisung zu realisieren. Die grundlegende Verwendung ist wie folgt:

Dumping-Definition und Daten MySQL-Datenbank oder Tabelle
Verwendung: mysqldump [OPTIONEN] Datenbank [Tabellen]
ODER mysqldump [OPTIONEN] --databases [OPTIONEN] DB1 [DB2 DB3...]
ODER mysqldump [OPTIONEN] --all-databases [OPTIONEN]

Da mysqldump relativ einfach zu verwenden ist, können Sie die meisten benötigten Informationen durch Ausführen von „mysqldump --help“ abrufen. Hier möchte ich nur einige Konzepte und Prinzipien der MySQL-Datenbank zusammenfassen und mit Ihnen einige Tipps besprechen sowie erklären, worauf wir achten müssen, wenn wir mysqldump zur Durchführung logischer Datenbanksicherungen verwenden.

Wir alle wissen, dass die meisten Softwareprogramme oder Websites, die Datenbanken verwenden, darauf hoffen, dass ihre Datenbanken die höchstmögliche Verfügbarkeit bieten können, anstatt von Zeit zu Zeit heruntergefahren zu werden und die Bereitstellung von Diensten einzustellen. Denn wenn die Datenbank keine Dienste mehr bereitstellen kann, kann das System durch den Datenzugriff einige dynamische Funktionen nicht mehr bereitstellen.

Daher ist es für die meisten Systeme möglicherweise nicht akzeptabel, das System für jede Sicherung herunterzufahren. Das Implementierungsprinzip des mysqldump-Programms besteht jedoch darin, Daten aus jeder Tabelle über die von uns bereitgestellten Parameterinformationen plus die Systemtabelleninformationen in der Datenbank abzurufen, dann INSERT-Anweisungen zu generieren und sie in die Sicherungsdatei zu schreiben. Dies stellt ein Problem dar: Während des normalen Systembetriebs können kontinuierlich Anforderungen zur Ausführung von Datenänderungen auftreten, was zu Inkonsistenzen in den von mysqldump gesicherten Daten führen kann.

Mit anderen Worten: Die Sicherungsdaten entsprechen möglicherweise nicht den Daten zum selben Zeitpunkt und können möglicherweise nicht einmal die Integritätsbeschränkungen erfüllen. Für manche Systeme stellt ein solcher Sicherungssatz möglicherweise kein großes Problem dar, für manche Systeme mit strengen Anforderungen an die Datenkonsistenz und -integrität ist er jedoch ein großes Problem, da es sich um einen völlig ungültigen Sicherungssatz handelt.

Was sollten wir in einem solchen Szenario tun? Wir wissen, dass die Konsistenz der Daten in der Datenbank nur in zwei Situationen gewährleistet werden kann.

  • Nehmen Sie zunächst alle Daten gleichzeitig heraus.
  • Zweitens liegen die Daten in der Datenbank im Ruhezustand.

In der ersten Situation muss sich jeder fragen: Ist das möglich?

Egal was passiert, solange es mehr als zwei Tabellen gibt, egal wie wir das Programm schreiben, ist es unmöglich, die Daten gleichzeitig wie letzte Nacht abzurufen. Ja, wir können mit herkömmlichen Methoden die Zeitpunkte des Datenabrufs nicht völlig konsistent machen, aber vergessen Sie nicht, dass die Datenbank in derselben Transaktion sicherstellen kann, dass die gelesenen Daten zum selben Zeitpunkt erfolgen.

Daher können wir bei Speicher-Engines, die Transaktionen unterstützen, wie Innodb oder BDB, den gesamten Sicherungsvorgang innerhalb derselben Transaktion steuern, um Konsistenz und Integrität der Sicherungsdaten zu erreichen. Das Programm mysqldump stellt uns auch entsprechende Parameteroptionen zur Unterstützung dieser Funktion zur Verfügung, d. h. durch die Option „--single-transaction“ können keine normalen Dienste der Datenbank beeinträchtigt werden.

Ich denke, im zweiten Fall ist das Erste, was jedem in den Sinn kommt, die Tabelle, die gesichert werden muss, zu sperren und nur das Lesen, aber kein Schreiben zuzulassen.

Ja, das ist alles, was wir tun können. Wir können nur einen Kompromissansatz verwenden, bei dem die Datenbank während des Sicherungsvorgangs nur Datenabfragedienste bereitstellt und den Schreibdienst sperrt, sodass die Daten vorübergehend in einem konsistenten Zustand sind, der nicht geändert wird. Nachdem mysqldump die Sicherung abgeschlossen hat, wird die Schreibsperre aufgehoben und der vollständige Dienst wird fortgesetzt.

Das mysqldump-Programm selbst bietet auch verwandte Optionen wie „--lock-tables“ und „--lock-all-tables“, die die Tabelle vor der Ausführung sperren und die Sperre nach der Ausführung automatisch aufheben.

Zu beachten ist hierbei, dass „--lock-tables“ nicht alle Tabellen, die auf einmal gesichert werden müssen, sperrt, sondern immer nur die Tabellen einer Datenbank auf einmal. Wenn die Tabellen, die gesichert werden müssen, in mehreren Datenbanken liegen, müssen Sie „--lock-all-tables“ verwenden, um die Konsistenz und Integrität der Daten sicherzustellen.

Beim Generieren einer logischen Sicherungsdatei einer INSERT-Anweisung über mysqldump steht uns eine sehr nützliche Option zur Verfügung: „--master-data[=value]“. Wenn „--master-data=1“ hinzugefügt wird, zeichnet mysqldump den Namen und die Position des aktuell von MySQL verwendeten Binlog-Protokolls in der Dump-Datei auf, und zwar in Form einer CHANGE_MASTER-Anweisung. Wenn nur „--master-data“ oder „--master-data=2“ verwendet wird, liegt die CHANGE_MASTER-Anweisung in Form eines Kommentars vor. Diese Option ist sehr nützlich, wenn Sie die Online-Einrichtung eines Slaves durchführen. Auch wenn der Slave nicht online eingerichtet wird, können Sie in manchen Fällen während des Wiederherstellungsvorgangs weitere Wiederherstellungsvorgänge über das Backup-Binlog durchführen.

In manchen Fällen möchten wir vielleicht nur einige spezielle Daten in andere Datenbanken exportieren, aber nicht zuerst eine temporäre Tabelle erstellen. Wir können hierfür auch die Funktion „--where='where-condition'“ des mysqldump-Programms verwenden, aber dies kann nur verwendet werden, wenn nur eine Tabelle gesichert wird.

Tatsächlich bietet mysqldump neben den oben genannten Verwendungstipps auch viele andere nützliche Optionen, die Sie in verschiedenen Szenarien verwenden können, z. B. die Verwendung von „--no-data“, um nur das Skript zur Erstellung der Datenbankstruktur zu dumpen, die Verwendung von „--no-create-info“, um den Befehl zum Erstellen der Tabellenstruktur in der Dump-Datei zu entfernen usw. Interessierte Leser können die Einführung in die Verwendung des Programms mysqldump im Detail lesen und es dann selbst testen.

② Erstellen Sie eine Datensicherungsdatei im Klartext in einem bestimmten Format

Zusätzlich zur Erstellung logischer Sicherungen durch die Generierung von INSERT-Befehlen können wir auch eine andere Methode verwenden, um die Daten in der Datenbank mit bestimmten Trennzeichen zu trennen und sie in einer Textdatei aufzuzeichnen, um den Effekt einer logischen Sicherung zu erzielen. Im Vergleich zu INSERT-Befehlsdateien benötigen solche Sicherungsdaten weniger Speicherplatz, haben ein übersichtlicheres Datenformat und sind einfacher zu bearbeiten. Der Nachteil besteht jedoch darin, dass die Sicherungsdaten mehrerer Tabellen nicht in derselben Sicherungsdatei vorhanden sein können und kein Befehl zum Wiederherstellen der Datenbankstruktur vorhanden ist. Der Sicherungssatz erfordert mehrere Dateien, was sich für uns nur insofern auswirkt, als dass die Wartungs- und Wiederherstellungskosten aufgrund der Zunahme der Dateien steigen. Dies kann jedoch grundsätzlich durch das Schreiben einiger einfacher Skripte erreicht werden.

Welche Methode können wir also im Allgemeinen verwenden, um eine solche Sicherungssatzdatei zu generieren? Tatsächlich hat MySQL die entsprechende Funktion bereits für uns implementiert.

In MySQL werden im Allgemeinen die folgenden beiden Methoden verwendet, um Sicherungsdateien im Klartext mit benutzerdefinierten Trennzeichen zu erhalten.

1. Implementiert durch Ausführen des Befehls SELECT ... TO OUTFILE FROM ...

MySQL bietet eine SELECT-Syntax, mit der Benutzer bestimmte Daten in einem angegebenen Format über SQL-Anweisungen in eine Textdatei ausgeben können. Es bietet auch praktische Tools und zugehörige Befehle, um die exportierte Datei einfach unverändert in die Datenbank zu importieren. Ist das nicht genau das, was wir zur Sicherung brauchen?

Dieser Befehl verfügt über mehrere Parameter, die wie folgt beachtet werden müssen:

  • „FIELDS ESCAPED BY ['name']“ implementiert die Zeichen-Escape-Funktion, um die Zeichen zu escapen, die in der SQL-Anweisung escaped werden müssen;
  • „FIELDS [OPTIONALLY] ENCLOSED BY 'name'“ kann den Inhalt des Felds „umschließen“. Wenn „OPTIONALLY“ nicht verwendet wird, werden alle Datentypen, einschließlich numerischer Daten, „umschlossen“. Nach der Verwendung von „OPTIONALLY“ werden numerische Daten nicht mit den angegebenen Zeichen „umschlossen“.
  • Mit „FIELDS TERMINATED BY“ kann das Trennzeichen zwischen jeweils zwei Feldern festgelegt werden.
  • „LINES TERMINATED BY“ teilt MySQL mit, welche Zeichen am Ende jedes Datensatzes in der Ausgabedatei hinzugefügt werden sollen.

Zum Beispiel:

root@localhost: Test 10:02:02> SELECT * INTO OUTFILE '/tmp/dump.text'
-> FELDER, DIE DURCH ',' BEENDET WERDEN, OPTIONAL DURCH '"' EINGESCHLOSSEN
-> ZEILEN, DIE DURCH '\n' BEENDET WERDEN
-> VON test_outfile-Limit 100;
Abfrage OK, 100 Zeilen betroffen (0,00 Sek.)
root@localhost: Test 10:02:11> beenden
Tschüss
root@sky:/tmp# cat dump.text
350021,21,"A","abcd"
350022,22,"B","abcd"
350023,23,"C","abcd"
350024,24,"D","abcd"
350025,25,"A","abcd"
... ...

2. Export über mysqldump

Wir alle wissen, dass mysqldump in Form von INSERT-Anweisungen zugehörige Sicherungsdateien mit den Daten in der Datenbank generieren kann. Tatsächlich kann mysqldump neben der Generierung von INSERT-Anweisungen auch die durch das obige „SELECT ... TO OUTFILE FROM ...“ implementierten Funktionen implementieren und gleichzeitig ein Erstellungsskript generieren, das der relevanten Datenbankstruktur entspricht.

Zum Beispiel:

root@sky:~# ls -l /tmp/mysqldump
gesamt 0
root@sky:~# mysqldump -uroot -T/tmp/mysqldump test test_outfile --fields enclosed-by=\" --fields-terminated-by=,
root@sky:~# ls -l /tmp/mysqldump
insgesamt 8
-rw-r--r-- 1 root root 1346 20.04.2021 22:18 test_outfile.sql
-rw-rw-rw- 1 mysql mysql 2521 20.04.2021 22:18 test_outfile.txt
root@sky:~# cat /tmp/mysqldump/test_outfile.txt
350021,21,"A","abcd"
350022,22,"B","abcd"
350023,23,"C","abcd"
350024,24,"D","abcd"
350025,25,"A","abcd"
... ...
root@sky:~# cat /tmp/mysqldump/test_outfile.sql
--MySQL-Dump 10.11
--
-- Host: localhost Datenbank: test
-- ------------------------------------------------------
--Serverversion 5.0.51a-log
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 NAMEN FESTLEGEN utf8 */;
/*!40103 SETZEN @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SETZE ZEITZONE='+00:00' */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Tabellenstruktur für Tabelle „test_outfile“
--
Tabelle löschen, wenn `test_outfile` vorhanden ist;
SET @saved_cs_client = @@character_set_client;
SET Zeichensatzclient = utf8;
CREATE TABLE `test_outfile` (
`id` int(11) NICHT NULL Standard '0',
`t_id` int(11) standardmäßig NULL,
`a` char(1) Standard NULL,
`mid` varchar(32) Standard NULL
)ENGINE=MyISAM STANDARD-CHARSET=utf8;
SET Zeichensatzclient = @saved_cs_client;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40101 SET CHARACTER_SET_CLIENT=@ALTER_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@ALTE_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
-- Dump abgeschlossen am 20.04.2021 14:18:23

Diese Ausgabestruktur eignet sich sehr gut für die Verwendung als Backup. Wenn mehrere Tabellen gleichzeitig gesichert werden müssen, werden natürlich für jede Tabelle zwei entsprechende Dateien generiert.

3. Logische Sicherungs- und Wiederherstellungsmethode

Nur Backups zu haben, reicht nicht aus. Wir müssen wissen, wie man diese Backups verwendet. Sehen wir uns nun an, wie man die oben erstellten logischen Backups wiederherstellt:

Da alle Sicherungsdaten in einem Format gespeichert werden, das sich auf den Entwurf unserer ursprünglichen Datenbankstruktur bezieht, ist die Wiederherstellung logischer Sicherungen relativ einfach. Natürlich unterscheiden sich die Wiederherstellungsmethoden für die beiden unterschiedlichen logischen Sicherungsformen leicht. Nachfolgend stellen wir kurz die Wiederherstellungsmethoden dieser beiden logischen Sicherungsdateien vor.

①Wiederherstellung von INSERT-Anweisungsdateien

Das Wiederherstellen einer Sicherungsdatei in Form einer INSERT-Anweisung ist am einfachsten. Wir müssen nur alle (oder einen Teil) der SQL-Befehle in der Sicherungsdatei ausführen. Erstens, wenn eine vollständige Wiederherstellung erforderlich ist, können wir die Sicherungsdatei direkt mit „mysql < backup.sql“ aufrufen, um alle darin enthaltenen Befehle auszuführen und die Daten vollständig in den Zustand zum Zeitpunkt der Sicherung wiederherzustellen. Wenn Sie über MySQL eine Verbindung zu MySQL hergestellt haben, können Sie die Wiederherstellung auch durchführen, indem Sie in MySQL „source/path/backup.sql“ oder „\./path/backup.sql“ ausführen.

②Wiederherstellung einer reinen Datentextsicherung

Wenn es sich um die zweite Form der logischen Sicherung handelt, ist die Wiederherstellung etwas mühsamer und Sie müssen jede Tabelle einzeln mit den entsprechenden Befehlen wiederherstellen. Natürlich ist es auch bequemer, Skripte zu verwenden, um eine automatische Wiederherstellung mehrerer Tabellen zu erreichen. Es gibt auch zwei Wiederherstellungsmethoden. Eine besteht darin, den MySQL-Befehl „LOAD DATA INFILE“ zu verwenden, und die andere besteht darin, zur Wiederherstellung das von MySQL bereitgestellte Tool mysqlimport zu verwenden.

Was kann ein logisches Backup leisten? Was ist nicht möglich?

Nachdem wir verstanden haben, wie logische Backups zur Wiederherstellung verwendet werden, müssen wir wissen, was wir mit diesen logischen Backups tun können.

  1. Durch logisches Backup können wir die relevanten Daten in der Datenbank durch Ausführen relevanter SQL- oder Befehle vollständig in den Zustand zum Zeitpunkt des Backups wiederherstellen, ohne irrelevante Daten zu beeinträchtigen;
  2. Durch die logische Sicherung der gesamten Datenbank können wir in der neuen MySQL-Umgebung eine Datenbank vollständig neu aufbauen, die mit der zum Zeitpunkt der Sicherung identisch ist und nicht durch die Art der Plattform eingeschränkt ist, auf der sich MySQL befindet.
  3. Durch logisches Backup unter bestimmten Bedingungen können wir bestimmte Daten problemlos in andere MySQL- oder andere Datenbankumgebungen migrieren (oder synchronisieren).
  4. Durch logisches Backup können wir nur einen Teil der Daten im Backup-Set wiederherstellen, ohne alle Daten wiederherzustellen.

Nachdem wir wissen, was ein logisches Backup kann, müssen wir uns auch darüber im Klaren sein, was es nicht kann, damit wir klar erkennen können, ob ein solches Backup unsere Erwartungen erfüllen kann und ob es wirklich das ist, was wir wollen.

Bei der logischen Sicherung können Daten nicht zu einem anderen Zeitpunkt als dem Sicherungszeitpunkt wiederhergestellt werden.

4. Logischer Backup- und Recovery-Test

Manchmal hören Sie, dass bei jemandem ein Problem mit der Datenbank vorliegt. Wenn Sie sich dann darauf vorbereiten, die zuvor erstellte Datenbank wiederherzustellen, stellen Sie fest, dass Ihr Sicherungssatz nicht verfügbar ist oder nicht den Wiederherstellungseffekt erzielen kann, den Sie beim Erstellen der Sicherung erwartet hatten. Ich fürchte, dass jeder in einer solchen Situation extrem deprimiert wird. Der wichtigste und kritischste Einsatzzweck einer Datenbanksicherung besteht dann, wenn in unserer Datenbank abnormale Bedingungen vorliegen und Daten wiederhergestellt werden müssen.

Als Betreuer sollten wir niemals solche geringfügigen Fehler machen. Wie können wir solche Probleme vermeiden?

Es gibt nur eine Möglichkeit: Durch regelmäßige Durchführung simulierter Wiederherstellungstests können wir überprüfen, ob unser Sicherungssatz wirklich gültig ist und ob er gemäß unseren Sicherungserwartungen wiederhergestellt werden kann.

An dieser Stelle fragen sich manche vielleicht, wie wir den Wiederherstellungstest durchführen sollen. Wir können die Daten in der Online-Umgebung nicht wirklich wiederherstellen, oder?

Ja, Daten in der Online-Umgebung können nicht wiederhergestellt werden, aber warum können wir dies nicht in der Testumgebung oder anderswo tun?

Der Zweck von Wiederherstellungstests besteht lediglich darin, zu überprüfen, ob unser Backup gültig ist und unseren Erwartungen entspricht.

Bevor wir einen Wiederherstellungstest durchführen, müssen wir uns daher zunächst darüber im Klaren sein, für welches Szenario unser Backup gedacht ist.

Wenn wir beispielsweise eine logische Sicherung der gesamten Datenbank durchführen, kann der Zweck darin bestehen, die gesamten Datenbankdaten zum Zeitpunkt der Sicherung wiederherstellen zu können, wenn die Datenbank logische oder physische Anomalien aufweist. Dann muss unser Wiederherstellungstest nur die gesamte logische Sicherung der gesamten Datenbank wiederherstellen, um festzustellen, ob wir eine vollständige Datenbank erfolgreich wiederherstellen können.

Ob die wiederhergestellten Daten mit dem Sicherungszeitpunkt übereinstimmen, können wir nur selbst beurteilen und manuell vergleichen.

Darüber hinaus können wir auch hoffen, dass bei einem Problem mit einem Datenbankobjekt, beispielsweise einer Tabelle, die Tabellendaten so schnell wie möglich auf den Sicherungszeitpunkt wiederhergestellt werden können. Anschließend können wir einen Beispielwiederherstellungstest an einer einzelnen angegebenen Tabelle durchführen.

Nehmen wir an, dass der Datenbankhost abstürzt und die Hardware beschädigt wird, wodurch alle Datenbankdaten verloren gehen, und führen Sie ein Testbeispiel für eine vollständige Datenbankwiederherstellung durch:

Wenn in unserer Datenbank ein Hardwarefehler auftritt und alle Daten verloren gehen, müssen wir so schnell wie möglich einen neuen Host finden, um den beschädigten Host zu ersetzen und den entsprechenden Dienst wiederherzustellen. Bevor wir den Dienst wiederherstellen, müssen wir zunächst die beschädigte Datenbank neu erstellen. Angenommen, wir haben bereits einen neuen Host, die MySQL-Software wurde installiert, die relevanten Einstellungen wurden vorgenommen und wir warten nur noch auf die Wiederherstellung der Datenbank.

Wir müssen die aktuellste vollständige logische Datenbanksicherungsdatei vom Zeitpunkt des Absturzes abrufen, sie auf den vorbereiteten neuen Host kopieren und das installierte MySQL starten.

Da wir über zwei logische Sicherungsformate verfügen, ist die Wiederherstellungsmethode für jedes Format unterschiedlich. Deshalb geben wir hier Beispiele für die Wiederherstellung logischer Sicherungen in beiden Formaten.

①Wenn es sich um eine logische Sicherung der INSERT-Anweisung handelt

a. Bereiten Sie die Sicherungsdatei vor und kopieren Sie sie in ein bestimmtes Verzeichnis, beispielsweise „/tmp“;

b. Führen Sie die entsprechenden Befehle im Sicherungssatz aus, indem Sie die folgenden Befehle ausführen:

mysql -uBenutzername -p < Backup.sql

Oder melden Sie sich zuerst über MySQL bei der Datenbank an und führen Sie dann den folgenden Befehl aus:

root@localhost: (keine) 09:59:40> Quelle /tmp/backup.sql

c. Prüfen Sie anschließend die entsprechenden Datenbankobjekte in der Datenbank auf Vollständigkeit;

d. Überprüfen Sie die Daten in mehreren Tabellen stichprobenartig zur manuellen Überprüfung und benachrichtigen Sie die Anwendung, damit sie mit der internen Testüberprüfung beginnen kann. Wenn alle Überprüfungen erfolgreich sind, können die Dienste für die Außenwelt bereitgestellt werden.

Natürlich werden alle oben genannten Schritte unter der Voraussetzung ausgeführt, dass jeder Schritt normal ist. Wenn in einem bestimmten Schritt ein Problem gefunden wird. Wenn in Schritt b eine Ausnahme auftritt und der Vorgang nicht fortgesetzt werden kann, müssen wir zunächst überprüfen, ob mit unserem Wiederherstellungsbefehl, der auf dem aufgetretenen Fehler basiert, etwas nicht stimmt. Stimmt etwas nicht mit unserer Umwelt? usw.

Wenn wir bestätigen, dass das Problem an der Sicherungsdatei liegt, ist unsere Sicherung ungültig und der Test ist fehlgeschlagen. Wenn unser Wiederherstellungsprozess normal verläuft, wir jedoch bei der Überprüfung feststellen, dass Datenbankobjekte fehlen, die Daten in einigen Objekten falsch sind oder überhaupt keine Daten vorhanden sind. Dies bedeutet auch, dass unser Backup-Level nicht den Erwartungen entsprechen kann und das Backup fehlschlägt.

Wenn wir während des Wiederherstellungsprozesses der eigentlichen Arbeit auf eine ähnliche Situation stoßen und ein früherer Sicherungssatz vorhanden ist, müssen wir natürlich einen Schritt zurückgehen und den früheren Sicherungssatz verwenden, um denselben Wiederherstellungsvorgang durchzuführen. Obwohl die Daten im früheren Sicherungssatz möglicherweise etwas verzerrt sind, können sie zumindest teilweise wiederhergestellt werden, ohne dass alle Daten verloren gehen.

② Wenn wir eine reine Textdatei sichern, die durch ein spezielles Trennzeichen getrennt ist

a. Der erste Schritt ist derselbe wie bei „Sicherungsdatei einfügen“, d. h. es wird die Sicherungsdatei vorbereitet, die dem Absturzzeitpunkt am nächsten liegt.

b. Importieren Sie Daten in die Datenbank mit bestimmten Tools oder Befehlen:

Da das Skript zum Erstellen der Datenbankstruktur und die Sicherungsdatei mit den Klartextdaten separat gespeichert sind, müssen wir zuerst das Skript zum Erstellen der Datenbankstruktur ausführen und dann die Daten importieren. Die Vorgehensweise zum Erstellen des Strukturskripts ist exakt die gleiche wie bei Schritt b im Wiederherstellungstest des ersten Backups oben.

Nachdem wir nun die Datenbankstruktur haben, können wir die Sicherungsdaten wie folgt importieren:

mysqlimport --user=name --password=pwd test --fields-enclosed-by=\" --fields-terminated-by=, /tmp/test_outfile.txt

oder

LADEN SIE DIE DATEN IN DER DATEI '/tmp/test_outfile.txt' IN DIE TABELLE test_outfile. FELDER MIT '"' ABGESCHLOSSEN UND EINGESCHLOSSEN IN ',';

Die nachfolgenden Schritte sind exakt dieselben wie beim Wiederherstellen der Sicherungsdatei für INSERT-Anweisungen und werden daher hier nicht wiederholt.

Oben finden Sie eine detaillierte Zusammenfassung des logischen Backup- und Wiederherstellungstests von MySQL. Weitere Informationen zum logischen Backup- und Wiederherstellungstest von MySQL finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!

Das könnte Sie auch interessieren:
  • Tutorial zum Exportieren von MySQL-Daten mit der Anweisung SELECT... INTO OUTFILE
  • Logisches MySQL-Backup in die Ausgabedatei

<<:  Eine Zusammenfassung einiger Orte, an denen ich Zeit mit TypeScript verbracht habe

>>:  Liste der HTML-Tags und Hinweise zur Verwendung

Artikel empfehlen

Beispiel für einen WeChat-Applet-Rechner

Beispiel für einen WeChat-Applet-Rechner. Zu Ihre...

Implementierung des Markdown-Renderings in einer Vue-Einzelseitenanwendung

Beim Rendern von Markdown habe ich zuvor den Vors...

Haben Sie die MySQL-Verbindungsabfrage wirklich gelernt?

1. Übersicht über Inner Join-Abfragen Der Inner J...

Beschreibung der chinesischen Sortierregeln für MySQL

Bei der Verwendung von MySQL sortieren und fragen...

Ein kurzer Vortrag über die Geschichte von React Router

Wenn Sie React Router verstehen möchten, sollten ...

Detaillierte Erklärung zum einfachen Wechseln von CSS-Themen

Ich habe meiner persönlichen Website vor Kurzem e...

Detaillierte Erklärung des JavaScript ES6-Moduls

Inhaltsverzeichnis 0. Was ist ein Modul 1.Modul l...

Fallstudie zur Implementierung eines jQuery Ajax-Chatbots

Chatbots können viel manuelle Arbeit sparen und i...

Eine kurze Analyse der MySQL-Sicherung und -Wiederherstellung

Inhaltsverzeichnis 1. Einleitung 2. Einfache Defi...