Konsistenter Export für die Migration

Oracle

# Consistent logical export with Data Pump (at a single SCN)
expdp system/password schemas=shop directory=DIR_DMP \
  dumpfile=shop_%U.dmp logfile=shop_exp.log \
  flashback_scn=<scn> parallel=4

# Current SCN for point-in-time consistency:
# SELECT current_scn FROM v$database;
# Alternative: FLASHBACK_TIME=SYSTIMESTAMP

Data Pump (expdp) ist das Standardtool für den logischen Export bei Migrationen. Für Lesekonsistenz übergib FLASHBACK_SCN=<scn> (oder FLASHBACK_TIME), damit alle Tabellen konsistent zu einer einzigen SCN exportiert werden; auf einem Live-System ist das entscheidend. PARALLEL beschleunigt, %U erzeugt mehrere Dateien.

PostgreSQL

# Single compressed file in custom format (restorable in parallel)
pg_dump -Fc -Z6 -f shop.dump shop

# Directory format (parallel dump + parallel restore):
pg_dump -Fd -j4 -f shop_dir shop

# For the whole cluster + roles/tablespaces:
# pg_dumpall --globals-only > roles.sql

Für die Migration wird das Format pg_dump -Fc (custom) oder -Fd (directory) bevorzugt; beide erlauben selektives/paralleles Laden mit pg_restore. Da pg_dump in einer einzigen Transaktion läuft, ist seine Ausgabe automatisch ein konsistenter Snapshot. Clusterweite Objekte wie Rollen und Tablespaces werden separat mit pg_dumpall --globals-only gesichert.

MySQL

# Consistent, lock-free export for InnoDB
mysqldump --single-transaction --quick --routines --triggers --events \
  --source-data=2 shop > shop.sql

# Note: older versions use --master-data=2 instead of --source-data.
# Parallel, fast alternative: mydumper -B shop -o ./backup --threads 4

Bei InnoDB liefert --single-transaction einen einzigen konsistenten Snapshot und sperrt keine Tabellen. --source-data=2 (früher --master-data=2) schreibt die zum Start von Replikation/CDC nötige Binlog-Position/GTID als Kommentar an den Anfang der Ausgabe; für eine Umschaltung ohne Ausfallzeit ist das unerlässlich. Bei großen Datenmengen arbeitet mydumper parallel.

SQL Server

-- Full backup for physical migration (to the same/compatible version):
BACKUP DATABASE shop TO DISK = 'C:\backup\shop.bak' WITH COMPRESSION, CHECKSUM;

-- Portable/version-independent logical export (BACPAC = schema+data):
-- sqlpackage /Action:Export /SourceConnectionString:"..." /TargetFile:shop.bacpac

-- For a single table: bcp shop.dbo.customer out customer.dat -n -S server -T

Bei der Migration auf denselben oder einen neueren SQL Server ist BACKUP ... RESTORE der zuverlässigste Weg (Integrität per CHECKSUM geprüft). Für versions-/plattformunabhängige Migration oder den Umzug nach Azure SQL wird der Export von Schema+Daten in eine einzige .bacpac-Datei mit SqlPackage /Action:Export bevorzugt. bcp wird für einzelne Tabellen genutzt.

MongoDB

# Consistent binary (BSON) export; point-in-time consistency with the oplog
mongodump --uri="mongodb://source:27017" \
  --oplog --out=./backup --numParallelCollections=4

# --oplog captures changes made during the dump (requires a replica set);
# it works only with a FULL dump and cannot be combined with --db / --collection.
# On restore, mongorestore --oplogReplay brings it to a single point in time.
# If you need a single database: take it with --db=shop (without the oplog) or use --nsInclude='shop.*' on restore.

mongodump ist der Standard-Binärexport (BSON) für Migrationen. Auf einem Replica Set erfasst die Option --oplog die während des Dumps geschriebenen Änderungen aus dem Oplog und liefert so einen konsistenten Zeitpunkt (zusammen mit mongorestore --oplogReplay); die Option gilt nur für einen vollständigen Dump. Für die Migration großer Cluster auf Clusterebene eignen sich mongosync/Live-Tools besser.

Redis

# Create an RDB snapshot in the background (non-blocking)
redis-cli BGSAVE
# Check for completion:
redis-cli INFO persistence | grep rdb_bgsave_in_progress

# Move the resulting file (path: CONFIG GET dir + dbfilename)
# e.g. /var/lib/redis/dump.rdb  ->  copy to the target server

In Redis ist der konsistente Export der RDB-Snapshot. BGSAVE erzeugt per Fork im Hintergrund eine konsistente dump.rdb, ohne den Hauptprozess zu blockieren (SAVE blockiert und sollte nicht verwendet werden). Den Dateipfad liefern CONFIG GET dir und dbfilename; migriert wird, indem diese dump.rdb in das Datenverzeichnis des Zielservers kopiert wird.

Elasticsearch

# 1) Register a snapshot repository (shared file system / S3)
PUT _snapshot/migration_repo
{ "type": "fs", "settings": { "location": "/mnt/es_backup" } }

# 2) Take a consistent snapshot
PUT _snapshot/migration_repo/migration_1?wait_for_completion=true
{ "indices": "customer,orders", "include_global_state": false }

In Elasticsearch ist der Snapshot die konsistente Exportmethode für Migrationen. Zuerst wird ein Repository (fs, S3, GCS usw.) registriert, dann der Snapshot erstellt; Snapshots sind inkrementell und erfassen einen konsistenten Zustand zum Erstellungszeitpunkt. Für kleine Datenmengen/einen einzelnen Index lässt sich auch elasticdump nutzen, Standard ist aber der Snapshot.

In DBAtlas öffnen →