Mysqldump ist das beliebteste logische Backup-Tool für MySQL. Es ist in der MySQL-Distribution enthalten und kann daher auf allen MySQL-Instanzen verwendet werden.
Logische Backups sind jedoch weder die schnellste noch die platzsparendste Art, MySQL-Datenbanken zu sichern, aber sie haben einen großen Vorteil gegenüber physischen Backups.
Physische Backups sind normalerweise Alles-oder-Nichts-Backups. Es ist zwar möglich, mit Xtrabackup ein teilweises Backup zu erstellen (wir haben dies in einem unserer vorherigen Blogbeiträge beschrieben), aber das Wiederherstellen eines solchen Backups ist schwierig und zeitaufwändig.
Wenn wir eine einzelne Tabelle wiederherstellen wollen, müssen wir grundsätzlich die gesamte Replikationskette stoppen und die Wiederherstellung auf allen Knoten gleichzeitig durchführen. Dies ist ein großes Problem – heutzutage können Sie es sich selten leisten, alle Datenbanken zu stoppen.
Ein weiteres Problem ist, dass die Tabellenebene die niedrigste Granularitätsebene ist, die Sie mit Xtrabackup erreichen können:Sie können eine einzelne Tabelle wiederherstellen, aber Sie können keinen Teil davon wiederherstellen. Die logische Sicherung kann jedoch durch Ausführen von SQL-Anweisungen wiederhergestellt werden, daher kann sie problemlos auf einem laufenden Cluster durchgeführt werden, und Sie können (wir würden es nicht einfach nennen, aber dennoch) auswählen, welche SQL-Anweisungen ausgeführt werden sollen, damit Sie können Führen Sie eine teilweise Wiederherstellung einer Tabelle durch.
Schauen wir uns an, wie dies in der realen Welt umgesetzt werden kann.
Eine einzelne MySQL-Tabelle mit mysqldump wiederherstellen
Bitte bedenken Sie zu Beginn, dass Teilsicherungen keine konsistente Sicht auf die Daten liefern. Wenn Sie Backups von separaten Tabellen erstellen, können Sie ein solches Backup nicht zu einem bekannten Zeitpunkt wiederherstellen (z. B. um den Replikations-Slave bereitzustellen), selbst wenn Sie alle Daten aus dem Backup wiederherstellen würden. Wenn wir das hinter uns haben, machen wir weiter.
Wir haben einen Herrn und einen Sklaven:
Datensatz enthält ein Schema und mehrere Tabellen:
mysql> SHOW SCHEMAS;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sbtest |
| sys |
+--------------------+
5 rows in set (0.01 sec)
mysql> SHOW TABLES FROM sbtest;
+------------------+
| Tables_in_sbtest |
+------------------+
| sbtest1 |
| sbtest10 |
| sbtest11 |
| sbtest12 |
| sbtest13 |
| sbtest14 |
| sbtest15 |
| sbtest16 |
| sbtest17 |
| sbtest18 |
| sbtest19 |
| sbtest2 |
| sbtest20 |
| sbtest21 |
| sbtest22 |
| sbtest23 |
| sbtest24 |
| sbtest25 |
| sbtest26 |
| sbtest27 |
| sbtest28 |
| sbtest29 |
| sbtest3 |
| sbtest30 |
| sbtest31 |
| sbtest32 |
| sbtest4 |
| sbtest5 |
| sbtest6 |
| sbtest7 |
| sbtest8 |
| sbtest9 |
+------------------+
32 rows in set (0.00 sec)Jetzt müssen wir ein Backup machen. Es gibt mehrere Möglichkeiten, wie wir dieses Problem angehen können. Wir können einfach eine konsistente Sicherung des gesamten Datensatzes erstellen, aber dies erzeugt eine große, einzelne Datei mit allen Daten. Um die einzelne Tabelle wiederherzustellen, müssten wir Daten für die Tabelle aus dieser Datei extrahieren. Es ist natürlich möglich, aber es ist ziemlich zeitaufwändig und es ist ziemlich viel manueller Vorgang, der per Skript ausgeführt werden kann, aber wenn Sie keine geeigneten Skripts haben, schreiben Sie Ad-hoc-Code, wenn Ihre Datenbank ausgefallen ist und Sie unter starkem Druck stehen nicht unbedingt die sicherste Idee.
Stattdessen können wir das Backup so vorbereiten, dass jede Tabelle in einer separaten Datei gespeichert wird:
[email protected]:~/backup# d=$(date +%Y%m%d) ; db='sbtest'; for tab in $(mysql -uroot -ppass -h127.0.0.1 -e "SHOW TABLES FROM ${db}" | grep -v Tables_in_${db}) ; do mysqldump --set-gtid-purged=OFF --routines --events --triggers ${db} ${tab} > ${d}_${db}.${tab}.sql ; doneBitte beachten Sie, dass wir --set-gtid-purged=OFF setzen. Wir brauchen es, wenn wir diese Daten später in die Datenbank laden würden. Andernfalls wird MySQL versuchen, @@GLOBAL.GTID_PURGED zu setzen, was höchstwahrscheinlich fehlschlagen wird. MySQL würde auch SET @@SESSION.SQL_LOG_BIN=0 setzen; was wir definitiv nicht wollen. Diese Einstellungen sind erforderlich, wenn wir eine konsistente Sicherung des gesamten Datensatzes erstellen und damit einen neuen Knoten bereitstellen möchten. In unserem Fall wissen wir, dass es sich nicht um ein konsistentes Backup handelt, und wir können daraus auf keinen Fall etwas wiederherstellen. Alles, was wir wollen, ist, einen Dump zu generieren, den wir auf den Master laden und ihn auf die Slaves replizieren können.
Dieser Befehl hat eine schöne Liste von SQL-Dateien generiert, die in den Produktionscluster hochgeladen werden können:
[email protected]:~/backup# ls -alh
total 605M
drwxr-xr-x 2 root root 4.0K Mar 18 14:10 .
drwx------ 9 root root 4.0K Mar 18 14:08 ..
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest10.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest11.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest12.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest13.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest14.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest15.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest16.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest17.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest18.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest19.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest1.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest20.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest21.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest22.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest23.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest24.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest25.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest26.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest27.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest28.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest29.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest2.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest30.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest31.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest32.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest3.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest4.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest5.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest6.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest7.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest8.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest9.sqlWenn Sie die Daten wiederherstellen möchten, brauchen Sie nur die SQL-Datei in den Master-Knoten zu laden:
[email protected]:~/backup# mysql -uroot -ppass sbtest < 20200318_sbtest.sbtest11.sqlDaten werden in die Datenbank geladen und auf alle Slaves repliziert.
Wie stellt man eine einzelne MySQL-Tabelle mit ClusterControl wieder her?
ClusterControl bietet derzeit keine einfache Möglichkeit, nur eine einzelne Tabelle wiederherzustellen, aber es ist immer noch möglich, dies mit nur wenigen manuellen Eingriffen zu tun. Es gibt zwei Optionen, die Sie verwenden können. Erstens, geeignet für eine kleine Anzahl von Tabellen, können Sie grundsätzlich einen Zeitplan erstellen, in dem Sie Teilsicherungen einer separaten Tabelle nacheinander durchführen:
Hier erstellen wir eine Sicherungskopie der Tabelle sbtest.sbtest1. Wir können ganz einfach ein weiteres Backup für die Tabelle sbtest2 planen:
Alternativ können wir eine Sicherung durchführen und Daten aus einem einzelnen Schema in ein separate Datei:
Jetzt können Sie die fehlenden Daten entweder per Hand in der Datei finden, wiederherstellen dieses Backup auf einen separaten Server oder lassen Sie es ClusterControl machen:
Sie halten den Server am Laufen und können die Daten extrahieren, die Sie benötigen wollte entweder mit mysqldump oder SELECT … INTO OUTFILE wiederherstellen. Solche extrahierten Daten können auf dem Produktionscluster angewendet werden.
