DBAtlas · Atlas de operações de banco de dados

Exportação consistente para migração

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

O Data Pump (expdp) é a ferramenta padrão de exportação lógica para migração. Para consistência de leitura, passe FLASHBACK_SCN=<scn> (ou FLASHBACK_TIME) para que todas as tabelas sejam exportadas de forma consistente em um único SCN; isso é crítico em um sistema em produção. PARALLEL acelera o processo, e %U gera vários arquivos.

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 migração, prefere-se o formato pg_dump -Fc (custom) ou -Fd (directory); ambos permitem carga seletiva/paralela com pg_restore. Como o pg_dump roda dentro de uma única transação, sua saída é automaticamente um snapshot consistente. Objetos de todo o cluster, como roles e tablespaces, são exportados separadamente com 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

No InnoDB, --single-transaction fornece um único snapshot consistente e não bloqueia tabelas. --source-data=2 (antes --master-data=2) grava como comentário no início da saída a posição do binlog/GTID necessária para iniciar a replicação/CDC; isso é essencial para um cutover sem downtime. Para grandes volumes, o mydumper roda em 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

Ao migrar para o mesmo SQL Server ou um mais novo, BACKUP ... RESTORE é o caminho mais confiável (a integridade é verificada com CHECKSUM). Para migração independente de versão/plataforma ou para o Azure SQL, prefere-se exportar schema+dados em um único arquivo .bacpac com SqlPackage /Action:Export. O bcp é usado para tabelas individuais.

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.

O mongodump é a exportação binária (BSON) padrão para migração. Em um replica set, a opção --oplog captura do oplog as alterações gravadas enquanto o dump está em execução, fornecendo um ponto no tempo consistente (em conjunto com mongorestore --oplogReplay); essa opção só vale para um dump completo. Para migração em nível de cluster de um cluster grande, mongosync/ferramentas live são mais adequados.

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

No Redis, a exportação consistente é o snapshot RDB. BGSAVE gera um dump.rdb consistente em segundo plano via fork, sem bloquear o processo principal (SAVE bloqueia e não deve ser usado). O caminho do arquivo é obtido com CONFIG GET dir e dbfilename; migre copiando esse dump.rdb para o diretório de dados do 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 }

No Elasticsearch, o método de exportação consistente para migração é o snapshot. Primeiro registra-se um repository (fs, S3, GCS etc.) e depois tira-se o snapshot; os snapshots são incrementais e capturam um estado consistente do momento em que são tirados. O elasticdump também pode ser usado para dados pequenos/um único índice, mas o snapshot é o padrão.

Abrir no DBAtlas →