DBAtlas · Atlas für Datenbankbetrieb

Konsistentes logisches Backup mit GTID-Informationen per mysqldump erstellen

MySQLBackup & PITR

Befehl

mysqldump -h db1 -u backup -p \
  --single-transaction --source-data=2 --set-gtid-purged=ON \
  --routines --events --triggers --hex-blob \
  --all-databases | gzip > /backup/full_$(date +%F_%H%M).sql.gz

# Restore: GTID sets must not overlap on the target
zcat /backup/full_2026-10-08_0200.sql.gz | mysql -h db2 -u root -p

Was es tut

Sichert InnoDB-Tabellen innerhalb eines einzigen konsistenten Snapshots und schreibt Binlog-Datei / -Position (als Kommentar) und eine Anweisung SET @@GLOBAL.GTID_PURGED an den Anfang, sodass der Dump eine Replica initialisieren oder als Startpunkt für binlogbasiertes PITR dienen kann.

Wann einsetzen

Für Datenbanken bis zu einigen zehn GB, zum Verschieben von Schemas / Tabellen und für logische Migration zwischen Versionen.

Vorsicht

--single-transaction ist nur für InnoDB konsistent; MyISAM-Tabellen kommen inkonsistent heraus. DDL (ALTER / RENAME / TRUNCATE) auf einer Tabelle während des Dumps lässt den Dump fehlschlagen oder die Tabelle auslassen. --source-data / --set-gtid-purged nehmen am Anfang kurz einen globalen Read Lock (Privileg RELOAD nötig); läuft in diesem Moment eine lange Abfrage, stehen alle Schreibvorgänge still, solange die Sperre wartet. Ein Teil-Dump (--databases) schreibt trotzdem alle GTIDs; beim Übertragen einer Teilmenge auf einen anderen Server --set-gtid-purged=OFF verwenden. Der Dump ist single-threaded; für große Datenmengen MySQL Shell Dump oder XtraBackup bevorzugen.

In DBAtlas öffnen →

Verwandte Einträge