DBAtlas · Atlas de operaciones de bases de datos

Exportación consistente para migración

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) es la herramienta estándar de exportación lógica para migraciones. Para la consistencia de lectura, pase FLASHBACK_SCN=<scn> (o FLASHBACK_TIME) para que todas las tablas se exporten de forma consistente en un único SCN; esto es crítico en un sistema en vivo. PARALLEL lo acelera y %U genera varios archivos.

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

Para migraciones se prefiere el formato pg_dump -Fc (custom) o -Fd (directory); ambos permiten una carga selectiva/en paralelo con pg_restore. Como pg_dump se ejecuta dentro de una única transacción, su salida es automáticamente un snapshot consistente. Los objetos de todo el clúster, como roles y tablespaces, se vuelcan por separado con pg_dumpall --globals-only.

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

En InnoDB, --single-transaction proporciona un único snapshot consistente y no bloquea las tablas. --source-data=2 (antes --master-data=2) escribe como comentario al principio de la salida la posición del binlog/GTID necesaria para iniciar la replicación/CDC; esto es esencial para un cutover sin indisponibilidad. Para grandes volúmenes, mydumper funciona en paralelo.

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

Al migrar a un SQL Server de la misma versión o más reciente, BACKUP ... RESTORE es la vía más fiable (la integridad se verifica con CHECKSUM). Para una migración independiente de versión/plataforma o un traslado a Azure SQL, se prefiere exportar esquema+datos a un único archivo .bacpac con SqlPackage /Action:Export. bcp se usa para tablas individuales.

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 es la exportación binaria (BSON) estándar para migraciones. En un replica set, la opción --oplog captura del oplog los cambios escritos mientras se ejecuta el dump, lo que proporciona un punto en el tiempo consistente (junto con mongorestore --oplogReplay); esta opción solo es válida para un dump completo. Para la migración de un clúster grande a nivel de clúster, mongosync/herramientas en vivo son más adecuadas.

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

En Redis, la exportación consistente es el snapshot RDB. BGSAVE genera en segundo plano, mediante fork, un dump.rdb consistente sin bloquear el proceso principal (SAVE bloquea y no debe usarse). La ruta del archivo se obtiene con CONFIG GET dir y dbfilename; migre copiando este dump.rdb al directorio de datos del servidor de destino.

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 }

En Elasticsearch, el método de exportación consistente para migraciones es el snapshot. Primero se registra un repositorio (fs, S3, GCS, etc.) y luego se toma el snapshot; los snapshots son incrementales y capturan un estado consistente del momento en que se toman. Para datos pequeños/un solo índice también se puede usar elasticdump, pero el estándar es el snapshot.

Abrir en DBAtlas →