Datenbank-Container zwischen Hosts migrieren: Dump vs. Volume-Kopie

1. Warum die Migrationsmethode ueber Erfolg oder Ausfall entscheidet

Einen Datenbank-Container zwischen Hosts migrieren zu muessen ist einer der Momente, in denen sich die Wahl der richtigen Methode direkt in Ausfallzeit und Datenverlustrisiko niederschlaegt. Anders als bei zustandslosen Anwendungscontainern, die man einfach neu deployt, traegt ein Datenbank-Container Zustand in sich, der bei jedem Schritt der Migration konsistent bleiben muss. Ein falscher Griff, etwa das Kopieren eines Volumes waehrend die Datenbank noch schreibt, kann zu einer korrupten Kopie fuehren, die erst beim naechsten Neustart am neuen Host auffaellt.

Die Wahl der Methode haengt massgeblich von drei Faktoren ab: der Datenmenge, der tolerierbaren Downtime und der Netzwerkverbindung zwischen Quell- und Ziel-Host. Wer einen Datenbank-Container zwischen Hosts migrieren will und dabei nur wenige Gigabyte bewegt, kommt oft mit einem simplen Dump aus. Bei mehreren hundert Gigabyte oder einer Anforderung an Zero-Downtime wird die Methode entscheidend komplexer. Die folgenden Abschnitte stellen die drei gaengigen Ansaetze gegenueber und zeigen, wann welcher die richtige Wahl ist.

2. Logischer Dump: mysqldump und pg_dump im Detail

Der logische Dump ist die einfachste und portabelste Methode, um einen Datenbank-Container zwischen Hosts migrieren zu koennen. mysqldump erzeugt eine SQL-Datei mit allen CREATE- und INSERT-Statements, die auf dem Ziel-Host einfach neu eingespielt wird. Der entscheidende Parameter fuer InnoDB-Tabellen ist --single-transaction, der den Dump innerhalb einer einzigen Transaktion mit konsistentem Snapshot ausfuehrt, ohne Tabellen fuer die Dauer des Exports zu sperren. Ohne diesen Parameter kann ein Dump waehrend paralleler Schreibvorgaenge inkonsistente Zwischenstaende einfangen.

Der grosse Vorteil des logischen Dumps liegt in seiner Versions- und Architekturunabhaengigkeit: Eine SQL-Datei laesst sich problemlos von einer aelteren MySQL-Version in eine neuere einspielen, sogar quer ueber unterschiedliche CPU-Architekturen wie von x86 zu ARM. Der Nachteil ist die Geschwindigkeit bei grossen Datenmengen, weil jede Zeile einzeln als INSERT ausgefuehrt wird. Bei mehreren hundert Gigabyte kann ein Dump-basierter Datenbank-Container zwischen Hosts migrieren Vorgang mehrere Stunden dauern, waehrend eine rohe Volume-Kopie in Bruchteilen dieser Zeit fertig ist.

#!/usr/bin/env bash
# migrate-via-dump.sh — consistent logical dump migration
set -euo pipefail

SOURCE_CONTAINER="mysql-prod"
TARGET_HOST="db2.internal.mironsoft.de"
DUMP_FILE="/tmp/migration-$(date +%Y%m%d).sql.gz"

# Consistent snapshot dump, no table locking for InnoDB
docker exec "$SOURCE_CONTAINER" \
  mysqldump --single-transaction --routines --triggers \
  -u root -p"${MYSQL_ROOT_PASSWORD}" --all-databases | gzip > "$DUMP_FILE"

echo "[INFO] Dump size: $(du -h "$DUMP_FILE" | cut -f1)"

# Transfer over SSH to target host
scp "$DUMP_FILE" "deploy@${TARGET_HOST}:/tmp/"

# Restore on target
ssh "deploy@${TARGET_HOST}" \
  "gunzip -c /tmp/$(basename "$DUMP_FILE") | docker exec -i mysql-new mysql -u root -p\${MYSQL_ROOT_PASSWORD}"

echo "[OK] Dump-based migration complete"

3. Rohe Volume-Kopie mit rsync und tar

Die zweite Methode, um einen Datenbank-Container zwischen Hosts migrieren zu koennen, ist die direkte Kopie der Datenverzeichnisse ueber rsync. Diese Methode ist deutlich schneller als ein logischer Dump, weil rohe Bytes uebertragen werden, statt SQL zu parsen und neu auszufuehren. Die Voraussetzung ist allerdings, dass Quell- und Ziel-Datenbank exakt dieselbe Major-Version und dieselbe Storage-Engine verwenden, weil das binaere Datenformat sonst nicht kompatibel ist.

Der kritische Schritt bei der Volume-Kopie ist, die Datenbank vor dem Kopieren zu stoppen, damit keine offenen Dateihandles oder unvollstaendig geschriebenen Seiten mitkopiert werden. Ein zweiter, optionaler rsync-Lauf vor dem eigentlichen Stopp reduziert die Downtime erheblich, weil beim ersten Durchlauf bereits der Grossteil der Daten uebertragen wird, waehrend die Datenbank noch laeuft, und nur die Differenz nach dem Stopp uebertragen werden muss. Dieses zweistufige Vorgehen macht den Datenbank-Container zwischen Hosts migrieren Prozess bei grossen Datenmengen deutlich praktikabler.

#!/usr/bin/env bash
# migrate-via-rsync.sh — two-pass rsync to minimize downtime
set -euo pipefail

TARGET_HOST="db2.internal.mironsoft.de"
VOLUME_PATH="/var/lib/docker/volumes/mysql-data/_data"

# Pass 1: sync while database is still running (bulk transfer)
echo "[INFO] First pass — database still running"
rsync -avz --delete "${VOLUME_PATH}/" "deploy@${TARGET_HOST}:${VOLUME_PATH}/"

# Pass 2: stop database, transfer remaining diff only
echo "[INFO] Stopping source database for final consistent sync"
docker stop mysql-prod

rsync -avz --delete "${VOLUME_PATH}/" "deploy@${TARGET_HOST}:${VOLUME_PATH}/"

# Start database on target host
ssh "deploy@${TARGET_HOST}" "docker start mysql-new"

echo "[OK] Volume copy migration complete, downtime limited to final diff sync"

4. Replikations-Cutover fuer minimale Downtime

Wo Downtime praktisch nicht toleriert wird, ist ein Replikations-Cutover die richtige Wahl, um einen Datenbank-Container zwischen Hosts migrieren zu koennen. Bei diesem Ansatz wird der neue Host zunaechst als Replika des alten Hosts eingerichtet, ueber die native Replikationsfunktion von MySQL oder PostgreSQL. Waehrend die Replika kontinuierlich Aenderungen vom Primary uebernimmt, laeuft die Anwendung unveraendert weiter gegen den alten Host, bis die Replika vollstaendig synchron ist.

Der eigentliche Umzug reduziert sich dann auf einen kurzen Cutover-Moment: Anwendung stoppen, letzte Aenderungen replizieren lassen, Replika zum neuen Primary befoerdern, Anwendung mit neuer Connection-String starten. Dieser Cutover dauert typischerweise nur wenige Sekunden statt Stunden, weil der Grossteil der Datenuebertragung bereits vor dem eigentlichen Wechsel abgeschlossen ist. Der Aufwand fuer die Einrichtung der Replikation ist hoeher als bei Dump oder rsync, lohnt sich aber, wenn ein Datenbank-Container zwischen Hosts migrieren Vorgang bei laufendem Geschaeftsbetrieb ohne spuerbare Unterbrechung erfolgen muss.

#!/usr/bin/env bash
# cutover.sh — final steps after replication has caught up
set -euo pipefail

# 1. Confirm replica lag is zero before cutover
docker exec mysql-replica mysql -u root -p"${MYSQL_ROOT_PASSWORD}" \
  -e "SHOW REPLICA STATUS\G" | grep "Seconds_Behind_Source"

# 2. Stop application to prevent new writes on old primary
docker stop app-container

# 3. Wait for final events to replicate, then promote replica
docker exec mysql-replica mysql -u root -p"${MYSQL_ROOT_PASSWORD}" \
  -e "STOP REPLICA; RESET REPLICA ALL;"

# 4. Point application at new primary and restart
sed -i 's/DB_HOST=db-old/DB_HOST=db-new/' .env
docker start app-container

echo "[OK] Cutover complete, application now writes to new host"

5. Netzwerk zwischen Hosts: SSH-Tunnel und Bandbreite

Jede Methode, um einen Datenbank-Container zwischen Hosts migrieren zu koennen, haengt von einer verlaesslichen und sicheren Netzwerkverbindung zwischen den beiden Maschinen ab. Ein SSH-Tunnel ist der Standardweg, um Daten verschluesselt zwischen Hosts zu uebertragen, ohne Datenbankports direkt ins offene Internet zu exponieren. Fuer rsync und scp geschieht diese Verschluesselung automatisch, waehrend fuer eine direkte Replikationsverbindung zusaetzlich TLS zwischen den Datenbankinstanzen konfiguriert werden sollte.

Die verfuegbare Bandbreite zwischen den Hosts bestimmt massgeblich, welche Methode praktikabel ist. Bei einer langsamen Verbindung zwischen zwei Rechenzentren kann selbst ein komprimierter Dump mehrere Stunden zur Uebertragung brauchen, waehrend dieselbe Migration innerhalb desselben Rechenzentrums oder ueber eine dedizierte Standleitung in Minuten abgeschlossen ist. Wer einen Datenbank-Container zwischen Hosts migrieren Prozess plant, sollte die tatsaechliche Transferzeit vorab mit einem Testlauf kleinerer Datenmengen abschaetzen, statt sich auf theoretische Bandbreitenangaben zu verlassen.

6. Versionskompatibilitaet und Storage-Engine-Unterschiede

Ein haeufig unterschaetzter Aspekt beim Versuch, einen Datenbank-Container zwischen Hosts migrieren zu wollen, ist die Versionskompatibilitaet zwischen Quelle und Ziel. Bei einer rohen Volume-Kopie muss die Ziel-Datenbank exakt dieselbe oder eine kompatible Major-Version verwenden, weil sich das binaere Speicherformat von InnoDB zwischen Major-Releases aendern kann. Ein Volume, das von MySQL 8.0 kopiert und an MySQL 5.7 angehaengt wird, startet im besten Fall gar nicht, im schlimmsten Fall mit stillen Datenkorruptionen.

Ein logischer Dump umgeht dieses Problem vollstaendig, weil SQL-Statements versionsunabhaengig interpretiert werden. Wer also gleichzeitig einen Host- und einen Versionswechsel plant, etwa von MySQL 5.7 auf MySQL 8.0, sollte den Dump-Ansatz dem raw Volume-Copy vorziehen, selbst wenn die Migration dadurch laenger dauert. Ein Datenbank-Container zwischen Hosts migrieren Vorhaben mit gleichzeitigem Versionssprung ohne Dump ist eines der haeufigsten Muster fuer nicht mehr startende Datenbanken nach der Migration.

7. Downtime-Fenster planen und kommunizieren

Unabhaengig von der gewaehlten Methode braucht jeder Versuch, einen Datenbank-Container zwischen Hosts migrieren zu wollen, ein realistisch geplantes Downtime-Fenster. Die Planung sollte nicht nur die reine Transferzeit einkalkulieren, sondern auch Zeit fuer die Validierung nach dem Umzug, fuer einen moeglichen Rollback und fuer die DNS- oder Load-Balancer-Umstellung auf den neuen Host. Ein zu knapp bemessenes Fenster fuehrt haeufig dazu, dass Teams unter Zeitdruck Validierungsschritte ueberspringen.

Bei geschaeftskritischen Systemen empfiehlt sich ein Trockenlauf der gesamten Migration auf einer Kopie der Produktionsdaten, bevor das eigentliche Downtime-Fenster beginnt. Dieser Trockenlauf deckt Ueberraschungen wie fehlende Berechtigungen, falsch konfigurierte Netzwerkregeln oder unerwartet lange Laufzeiten auf, bevor sie im echten Produktionsfenster fuer boese Ueberraschungen sorgen. Ein gut vorbereiteter Datenbank-Container zwischen Hosts migrieren Ablauf unterscheidet sich von einem improvisierten vor allem durch diesen vorherigen Testlauf.

8. Integritaet nach der Migration validieren

Nach jedem Versuch, einen Datenbank-Container zwischen Hosts migrieren zu koennen, muss die Integritaet der Daten am neuen Host verifiziert werden, bevor der alte Host abgeschaltet wird. Ein einfacher erster Schritt ist der Vergleich von Zeilenzahlen und Tabellengroessen zwischen altem und neuem Host fuer alle kritischen Tabellen. Weichen diese Zahlen ab, deutet das auf einen unvollstaendigen Transfer oder einen Fehler waehrend des Dumps hin.

Fuer eine tiefergehende Pruefung eignet sich ein Checksummen-Vergleich einzelner Tabellen, etwa mit pt-table-checksum aus dem Percona Toolkit, das inhaltliche Unterschiede zwischen zwei MySQL-Instanzen zuverlaessig aufdeckt. Erst nach einer erfolgreichen Validierung sollte der alte Host aus dem produktiven Betrieb genommen werden, idealerweise mit einer Uebergangsfrist, in der er als Fallback erreichbar bleibt, falls nach der Migration doch noch unerwartete Probleme auftauchen.

9. Migrationsmethoden im direkten Vergleich

Die drei vorgestellten Ansaetze unterscheiden sich deutlich in Geschwindigkeit, Downtime und Komplexitaet der Einrichtung. Die folgende Tabelle fasst zusammen, wann welche Methode die richtige Wahl ist, um einen Datenbank-Container zwischen Hosts migrieren zu koennen.

Fuer die meisten kleineren bis mittleren produktiven Umgebungen ist der logische Dump mit --single-transaction der pragmatischste Weg, einen Datenbank-Container zwischen Hosts migrieren zu koennen, weil er unkompliziert, versionsunabhaengig und gut testbar ist. Erst bei sehr grossen Datenmengen oder harten Zero-Downtime-Anforderungen lohnt sich der zusaetzliche Aufwand fuer Volume-Kopie oder Replikation.

10. Zusammenfassung

Wer einen Datenbank-Container zwischen Hosts migrieren muss, sollte die Methode nach Datenmenge, Downtime-Toleranz und Versionskompatibilitaet waehlen. Ein logischer Dump mit mysqldump --single-transaction ist unkompliziert und versionsunabhaengig, aber langsamer bei grossen Datenmengen. Eine rohe Volume-Kopie per rsync ist schnell, erfordert aber identische Datenbankversionen. Ein Replikations-Cutover reduziert die Downtime auf Sekunden, verlangt dafuer mehr Vorbereitungsaufwand.

Unabhaengig von der gewaehlten Methode gehoert ein realistisch geplantes Downtime-Fenster, ein vorheriger Trockenlauf und eine Integritaetspruefung nach der Migration zum Pflichtprogramm. Ein Datenbank-Container zwischen Hosts migrieren Vorgang ohne diese Absicherungen ist ein unnoetig hohes Risiko fuer produktive Systeme.

11. FAQ: Datenbank-Container zwischen Hosts migrieren