Mysqldump ist ein Client-Dienstprogramm, das verwendet wird, um logische Sicherungen der MySQL-Datenbank durchzuführen. Dieses beliebte Migrationstool ist für verschiedene Anwendungsfälle von MySQL nützlich, wie zum Beispiel:
- Sicherung und Wiederherstellung von Datenbanken.
- Migration von Daten von einem Server auf einen anderen.
- Migration von Daten zwischen verschiedenen verwalteten MySQL-Dienstanbietern.
- Migration von Daten zwischen verschiedenen Versionen von MySQL.
Mysqldump funktioniert, indem es die Quelldatenbankobjekte liest und eine Reihe von SQL-Anweisungen generiert, die in einer Dump-Datei gespeichert werden. Durch die Wiedergabe dieser Anweisungen auf dem Zieldatenbankserver werden die ursprünglichen Daten rekonstruiert. Da bei diesem Modell die gesamte Datenbank gelesen und dann im Wesentlichen neu erstellt wird, sind sowohl das Sichern als auch das Wiederherstellen zeitaufwändige Vorgänge für eine große Datenbank. Der Prozess kann sogar umständlich werden, wenn beim Sichern oder Wiederherstellen Fehler auftreten, da dies dazu führen kann, dass Sie die Probleme beheben und die Vorgänge erneut ausführen. Aus diesem Grund ist es wichtig, gut zu planen, bevor Sie mit der Dump- und Wiederherstellungsaktivität beginnen.
In dieser zweiteiligen Blogserie diskutieren wir einige der allgemeinen Aspekte, die Sie im Voraus behandeln sollten, um eine erfolgreiche Dump- und Wiederherstellungsaktivität sicherzustellen. Im ersten Teil konzentrieren wir uns auf die Voraussetzungen, die Sie beim Importieren der MySQL-Tabellendaten beachten müssen, und im zweiten Teil sprechen wir darüber, wie der Import für gespeicherte Programmobjekte und Ansichten gehandhabt wird.
1. Platzbedarf
Zunächst einmal ist es wichtig sicherzustellen, dass Ihr Zieldatenbankvolume über ausreichend Speicherplatz verfügt, um die importierten Daten zu speichern. Insbesondere müssen Sie vorsichtig sein, wenn Binärprotokolle in Ihrer MySQL-Zieldatenbank aktiviert sind, da Binärprotokolle, die beim Importieren der Daten generiert werden, fast die gleiche Größe wie die Daten selbst einnehmen können. Binäre Protokolle werden benötigt, wenn Sie Ihre Daten auf einem Server wiederherstellen und diese replizieren möchten. In solchen Fällen ist es eine gute Idee, die Zielgröße größer als die doppelte Größe der Quelldatenbank zu planen.
Es ist auch wichtig sicherzustellen, dass auf dem Volume, auf dem Sie die mysqldump-Ausgabedatei generieren, ausreichend Speicherplatz verfügbar ist. Ohne diese Vorsichtsmaßnahmen kann es vorkommen, dass Ihr Speicherauszug oder Ihre Wiederherstellung nach längerer Ausführung aufgrund von unzureichendem Speicherplatz fehlschlägt, was einen Verlust Ihrer produktiven Zeit und Mühe bedeutet.
2. Sql_mode
sql_mode-Einstellungen für den MySQL-Server bestimmen die SQL-Anweisungssyntax und Datenvalidierungsprüfungen, die der Server für die Operationen durchführt. Es ist wichtig, den sql_mode sicherzustellen der Quell- und Ziel-MySQL-Server miteinander kompatibel sind, oder es kann zu Fehlern beim Wiederherstellen des erstellten Dumps kommen. Lassen Sie uns dies anhand eines Beispiels demonstrieren.
Angenommen, Sie haben eine Tabelle in Ihrer Quelle, die eine Datumsspalte mit Einträgen als Nulldaten enthält:
mysql> show create table sched; --------------------------------------------------------+ | Table | Create Table | --------------------------------------------------------+ | sched | CREATE TABLE `sched` ( `id` int(11) DEFAULT NULL, `ts` date DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +-------+--------------------------------------------------------------------------------------------------------------------- mysql> select * from sched; +------+------------+ | id | ts | +------+------------+ | 1 | 2020-01-12 | | 2 | 0000-00-00 | +------+------------+
Nehmen Sie den strengen sql_mode an (und NO_ZERO_DATE ) ist auf der Quelle deaktiviert, aber auf dem Ziel aktiviert – das Wiederherstellen solcher Zeilen führt zu einem Fehler wie:
ERROR 1292 (22007) at line 40: Incorrect date value: '0000-00-00' for column 'ts’' at row 2
Sie werden solche Probleme normalerweise sehen, wenn Sie einen kompakten Dump erstellen, indem Sie die Option compact als Teil Ihres mysqldump aktivieren.
Wenn compact deaktiviert ist (was standardmäßig der Fall ist), tritt dieses Problem nicht auf, da mysqldump die folgende bedingte Anweisung als Teil des Dumps generiert:
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
Das bedeutet, dass während der Wiederherstellung sql_mode auf 'NO_AUTO_VALUE_ON_ZERO' gesetzt ist bevor die Tabellendaten wiederhergestellt werden, damit die Wiederherstellung problemlos durchläuft.
3. Unique_checks und Foreign_key_checks
Standardmäßig (wenn Sie die Option –compact nicht verwenden) legt mysqldump auch Folgendes fest:
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
Wie hier erklärt, können Sie den Wiederherstellungsvorgang beschleunigen, indem Sie die Eindeutigkeitsprüfungen während der Sitzung vorübergehend deaktivieren. Bei großen Tabellen spart dies viel Festplatten-I/O, da InnoDB seinen Änderungspuffer verwenden kann, um sekundäre Indexdatensätze in einem Stapel zu schreiben.
Wenn Sie FOREIGN KEY haben Beschränkungen in Ihren Tabellen können Sie den Tabellenwiederherstellungsvorgang beschleunigen, indem Sie die Fremdschlüsselprüfungen für die Dauer der Wiederherstellungssitzung deaktivieren:Bei großen Tabellen kann dies eine Menge Festplatten-E/A einsparen.
FOREIGN_KEY_CHECKS deaktivieren hilft auch dabei, Fehler aufgrund von Foregin-Key-Constraint-Checks während des Wiederherstellungsvorgangs zu vermeiden. Immer wenn eine Tabelle mit Foregin-Key-Constraint erstellt wird, erwartet MySQL, dass die Elterntabelle, auf die der Foregin-Key verweist, bereits existiert. Dies ist ein Problem, da das Dienstprogramm mysqldump die Tabellen in alphabetischer Reihenfolge ausgibt. Nehmen wir ein Beispiel, um dies zu demonstrieren.
In der Quelldatenbank haben wir zwei Tabellen:
CREATE TABLE `solution_table` ( `num1` int(11) NOT NULL, `num2` int(11) DEFAULT NULL, PRIMARY KEY (`num1`)); CREATE TABLE `ref_table` ( `key` int(11) DEFAULT NULL, `ref_num` int(11) DEFAULT NULL, KEY `ref_num` (`ref_num`), CONSTRAINT `ref_num_ibfk_1` FOREIGN KEY (`ref_num`) REFERENCES `solution_table` (`num1`) )
Die Tabelle ref_table hat eine Fremdschlüsseleinschränkung, die auf die solution_table verweist . Basierend auf der alphabetischen Reihenfolge gibt mysqldump zuerst den Inhalt von ref_table aus . Wenn dies zum Zeitpunkt der Wiederherstellung wiedergegeben wird, schlägt es mit folgendem Fehler fehl:
ERROR 1215 (HY000) at line 50: Cannot add foreign key constraint -
Was passiert, während die Anweisung zum Erstellen einer Tabelle für ‘ref_table’ ausgeführt wird .
Zusammenfassend sollten Sie sich der Probleme bewusst sein, auf die Sie stoßen können, wenn Sie --compact angeben Option beim Ausführen von mysqldump.
4. Erforderliche Berechtigungen zum Ausführen von mysqldump
Die Mindestberechtigung, die mysqldump zum Sichern einer Datenbank benötigt, ist SELECT in dieser Datenbank.
Wenn Ihre Datenbank jedoch Ansichten hat, benötigen Sie auch SHOW VIEW-Berechtigungen, da mysqldump Ansichten immer zusammen mit den Tabellen der Datenbank ausgibt. Angenommen, Sie haben SHOW VIEW nicht Berechtigungen, dann schlägt mysqldump fehl mit:
mysqldump: Couldn't execute 'show create table `ivew`': SHOW VIEW command denied to user ‘dumpuser’@'172.31.18.79' for table 'iview' (1142)
Ein weiterer interessanter Punkt ist, ob Ihr Dumpuser SELECT hat Berechtigungen nur für eine bestimmte Tabelle der Datenbank, wird mysqldump Daten nur für diese bestimmte Tabelle ausgeben und automatisch alle anderen Tabellen oder Ansichten ignorieren.
Stellen Sie daher bitte sicher, dass der Benutzer, der mysqldump ausführt, im Voraus alle erforderlichen Berechtigungen hat, um spätere Überraschungen oder Fehler zu vermeiden.
|
5. Max_allowed_packet
Das größte von mysql verarbeitete Kommunikationspaket wird durch die Einstellung max_allowed_packet bestimmt . Im Kontext des Imports ist ein Kommunikationspaket eine einzelne SQL-Anweisung, die während der Wiederherstellung an den MySQL-Server gesendet wird, ODER eine einzelne Zeile, die während des Dumps an den Client gesendet wird.
Der Standardwert von max_allowed_packet für mysqldump beträgt 24 MB. Wenn mysqldump ein Paket empfängt, das größer als dieses ist, dann könnten Sie auf den Fehler stoßen:
mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `huge1` at row: 2.
Stellen Sie also sicher, dass mysqldump denselben oder einen größeren Wert von max_allowed_packet verwendet die auf der MySQL-Quellinstanz konfiguriert ist.
Die Option kann mit dem Flag --max-allowed-packet=value beim Aufrufen von mysqldump.
Stellen Sie beim Wiederherstellen des Dumps sicher, dass max_allowed_packet Größe Ihres Zielservers groß genug ist, um die Pakete aus der Dump-Datei zu empfangen.
Andernfalls erhalten Sie beim Wiederherstellen des Dumps eine Fehlermeldung:
ERROR 2006 (HY000) at line 70: MySQL server has gone away
Dieser Fehler kann ein wenig irreführend sein, da Sie vielleicht denken, dass der MySQL-Server heruntergefahren oder abgestürzt ist. Aber es bedeutet nur, dass der Server ein Paket empfangen hat, das größer ist als seine konfigurierte Größe von max_allowed_packet . Auch hier besteht die bewährte Vorgehensweise darin, sicherzustellen, dass das max_allowed_packet Wert für Ihren Zielserver ist derselbe wie der Wert auf dem Quellserver. Dies ist auch eine wichtige Einstellung, die im Voraus überprüft und entsprechend eingestellt werden kann, anstatt sich den Fehlern zu einem späteren Zeitpunkt zu stellen.
In diesem ersten Teil der mysqldump-Reihe haben wir die Voraussetzungen für einen erfolgreichen Dump- und Wiederherstellungsvorgang für große MySQL-Datenbanken besprochen, um Ihnen dabei zu helfen, mehrere Versuche und unproduktiven Zeitaufwand zu vermeiden.
Im nächsten Teil besprechen wir Best Practices zum Importieren der gespeicherten Programme und Ansichten aus Ihrer MySQL-Datenbank.
