Logische Sicherung und Wiederherstellung in MySQL (mysqldump, MySQL Shell)

Logische Sicherung und Wiederherstellung mit mysqldump oder MySQL Shell (util.dumpInstance / dumpSchemas / dumpTables + util.loadDump): eine Tabelle, ein Schema oder die ganze Instanz; nur Struktur oder nur Daten; Migration auf einen anderen Server; eine einzelne Tabelle aus einem vollständigen Dump extrahieren; zeitgesteuerte Sicherung mit systemd/cron, ohne Passwort über login-path, verifiziert, mit Aufbewahrungsdauer. Jeder Weg endet mit einem Vergleich der Zeilenzahlen. Diesen Guide nutzt du für Migrationen, die Wiederherstellung einzelner Objekte und den Wechsel zwischen Versionen; für die tägliche Sicherung großer Datenbanken, schnelle Restores und die Rückkehr zu einem bestimmten Zeitpunkt (PITR) nutzt du den Guide zu Percona XtraBackup.

Topologie: 1 Server (bei Migration und Instanz-Wiederherstellung + Zielserver)

Szenarien

• Tabelle(n) exportieren / importieren — Eine oder mehrere Tabellen sichern, in ein anderes Schema bzw. auf einen anderen Server kopieren oder wiederherstellen. Die Quelle bleibt in Betrieb; auf InnoDB-Tabellen werden keine Locks gesetzt.
• Ein Schema (Datenbank) sichern / wiederherstellen — Eine komplette Datenbank (Schema) sichern oder in ein anderes Schema bzw. auf einen anderen Server laden. Die Quelle bleibt in Betrieb; gleichnamige Tabellen im Ziel werden gelöscht und neu angelegt.
• Ganze Instanz (Benutzer + alle Schemas) — Die Sicherung wird auf diesem Server erstellt, die Wiederherstellung erfolgt auf einem leeren Server: Benutzer, Berechtigungen und alle Schemas. Zum Neuaufbau eines Servers oder zum Wechsel von Version/Plattform.
• Nur Struktur (DDL) — Definitionen von Tabellen, Views, Triggern, Prozeduren und Events; keine Daten. Zum Schemavergleich, zum Aufbau einer leeren Umgebung oder um die Struktur unter Versionskontrolle zu stellen.
• Nur Daten — Nur die Zeilen werden übertragen, während die Struktur im Ziel bereits vorhanden ist (z. B. Testdaten auffrischen). Trigger im Ziel können während des Ladens auslösen; der Guide prüft das.
• Migration auf einen anderen Server — Du arbeitest auf dem Zielserver und verbindest dich über das Netz mit login-path zur Quelle. Beim Cutover stoppt die Anwendung das Schreiben; die Ausfallzeit entspricht der Dauer von Dump + Laden. Für den Wechsel von Server, Betriebssystem oder Version.
• Einzelne Tabelle aus einem vollständigen Dump extrahieren — Du hast einen vollständigen Dump und brauchst nur eine Tabelle (gelöschte Zeilen, per DROP gelöschte Tabelle). Sie wird ohne Eingriff in das ursprüngliche Schema in ein separates Schema extrahiert, oder die gelöschte Tabelle wird zurückgespielt.
• Zeitgesteuerte Sicherung (systemd timer / cron) — Automatische logische Sicherung jeden Tag zu einer festen Uhrzeit: eigener Backup-Benutzer, login-path, Skript, systemd timer oder cron, Aufbewahrungsdauer und Fehlerbenachrichtigung. Die Quelle bleibt in Betrieb.

Vor dem Start

• MySQL … läuft; der Betriebssystembenutzer root kann sich mit dem Befehl mysql ohne Passwort verbinden (auth_socket oder ~/.mylogin.cnf). Wurde mit dem DBAtlas-Guide MySQL-Einzelserver-Installation installiert, sind die Pfade identisch.
• Die Größe der Schemas ist bekannt, und im Sicherungsverzeichnis … ist genügend freier Platz (eine komprimierte logische Sicherung umfasst meist 10–30 % der Datenmenge; Indexe gehen nur als Definition in den Dump ein).
• Alle Tabellen sind InnoDB. --single-transaction (und der konsistente Dump von MySQL Shell) ist nur für InnoDB-Tabellen lockfrei und konsistent; gibt es eine MyISAM-Tabelle, führen Schreibzugriffe darauf während des Dumps zu Inkonsistenzen.
• Der Server, auf dem MySQL Shell installiert wird, erreicht das MySQL-Repository (repo.mysql.com), oder ein interner Mirror ist eingerichtet.
• Auf dem Zielserver … ist dieselbe oder eine neuere MySQL-Version installiert (mit dem DBAtlas-Installationsguide), sie läuft und enthält keine Benutzerschemas. Das Laden in eine ältere Version, etwa von 8.4 nach 8.0 für einen Rollback, wird nicht unterstützt.
• Der Zielserver erreicht Port … der Quelle.
• Der Server kann E-Mails versenden: Der lokale MTA (postfix) leitet an das SMTP-Relay der Organisation weiter.
• Für eine große Wiederherstellung oder Migration ist ein Wartungsfenster geplant; wird das Ziel überschrieben, wurde das Ziel vorher gesichert.
• Dieser Server ist eine gesunde Replica: IO- und SQL-Thread stehen auf Yes, die Verzögerung ist gering. Die Binlog-Position im Dump (--source-data=2) bezieht sich auf das eigene Binlog dieser Replica; soll sie für PITR genutzt werden, muss log_replica_updates aktiviert sein (Standard in 8.x).
• Dieser Server ist Mitglied eines InnoDB Clusters und derzeit SECONDARY / ONLINE.

Phasen der Anleitung

• Vorbereitung — Sicherungsverzeichnis anlegen · Tabellen-Engines und lange Transaktionen prüfen · MySQL Shell installieren
• Wiederherstellung (Import) — Zielschema anlegen · Tabellenstruktur im Ziel anlegen · Trigger im Ziel prüfen · Laden (mysql) · Laden (mysql, über dasselbe Schema) · Laden (util.loadDump) …
• Instanzsicherung — Benutzer und Berechtigungen exportieren · Alle Schemas sichern (mysqldump) · Instanz sichern (util.dumpInstance) · Sicherung auf den Wiederherstellungsserver kopieren · Sicherung laden (mysql) · Benutzer laden …
• Migrationskonto auf dem Quellserver — Migrationsbenutzer anlegen · Port in der Firewall für das Ziel öffnen · Anwendung stoppen (Cutover)
• Übertragung auf dem Zielserver — Quellverbindung als login-path speichern · Benutzer migrieren · Schemas übertragen (mysqldump | mysql) · Benutzer im Ziel laden · Dump der Quelle erstellen (util.dumpInstance / dumpSchemas) · Ins Ziel laden (util.loadDump) …
• Einzelne Tabelle aus einem Dump extrahieren — Prüfen, ob die Tabelle im Dump enthalten ist · Tabelle aus dem Dump extrahieren · Zielschema anlegen · Tabelle laden · Tabelle in das ursprüngliche Schema zurückspielen · Zeilenzahl vergleichen …
• Backup-Benutzer und login-path — Betriebssystembenutzer für die Sicherung anlegen · MySQL-Backup-Konto anlegen · login-path speichern (mysql_config_editor)
• Sicherungsskript — Benachrichtigungswerkzeug installieren · Sicherungsskript schreiben · Skript ausführbar machen · Erste Sicherung von Hand erstellen
• Zeitsteuerung (systemd timer) — systemd-Service schreiben · systemd timer schreiben · Timer aktivieren und Service von Hand auslösen · Prüfen, ob der zeitgesteuerte Job gelaufen ist (am nächsten Tag)
• Zeitsteuerung (cron) — cron-Dienst vorbereiten · cron-Job schreiben · Rechte der cron-Datei setzen und in einer cron-Umgebung testen · Prüfen, ob der zeitgesteuerte Job gelaufen ist (am nächsten Tag)
• Verifikation und Monitoring — Letzte Sicherung in ein Testschema zurückspielen · Alter der letzten Sicherung überwachen
• Nächster Schritt: physische Sicherung — Grenzen der logischen Sicherung abdecken