Export cohérent pour 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) est l'outil d'export logique standard pour la migration. Pour la cohérence en lecture, passez FLASHBACK_SCN=<scn> (ou FLASHBACK_TIME) afin que toutes les tables soient exportées de façon cohérente à un même SCN ; c'est essentiel sur un système en production. PARALLEL accélère l'export et %U produit plusieurs fichiers.

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

Le format pg_dump -Fc (custom) ou -Fd (directory) est préférable pour la migration ; tous deux permettent un chargement sélectif/parallèle avec pg_restore. pg_dump s'exécutant dans une seule transaction, sa sortie est automatiquement un snapshot cohérent. Les objets de niveau cluster comme les rôles et tablespaces sont exportés séparément avec 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

Sur InnoDB, --single-transaction fournit un snapshot cohérent unique et ne verrouille pas les tables. --source-data=2 (anciennement --master-data=2) écrit en commentaire en tête de sortie la position binlog/le GTID nécessaire pour démarrer la réplication/le CDC ; c'est indispensable pour une bascule sans interruption. Pour de gros volumes, mydumper fonctionne en parallèle.

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

Pour migrer vers une version de SQL Server identique ou plus récente, BACKUP ... RESTORE est la voie la plus fiable (intégrité vérifiée avec CHECKSUM). Pour une migration indépendante de la version/plateforme ou vers Azure SQL, l'export du schéma et des données dans un seul fichier .bacpac avec SqlPackage /Action:Export est préférable. bcp sert pour les tables individuelles.

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 est l'export binaire (BSON) standard pour la migration. Sur un replica set, l'option --oplog capture depuis l'oplog les modifications écrites pendant le dump, ce qui donne un instant cohérent (à combiner avec mongorestore --oplogReplay) ; cette option n'est valable que pour un dump complet. Pour la migration d'un grand cluster au niveau cluster, mongosync/les outils en direct sont plus adaptés.

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

Dans Redis, l'export cohérent est le snapshot RDB. BGSAVE produit en arrière-plan, via fork, un dump.rdb cohérent sans bloquer le processus principal (SAVE bloque et ne doit pas être utilisé). Le chemin du fichier s'obtient avec CONFIG GET dir et dbfilename ; migrez en copiant ce dump.rdb dans le répertoire de données du serveur cible.

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 }

Dans Elasticsearch, la méthode d'export cohérent pour la migration est le snapshot. On enregistre d'abord un repository (fs, S3, GCS, etc.), puis on prend le snapshot ; les snapshots sont incrémentaux et capturent un état cohérent au moment de leur création. elasticdump peut aussi servir pour de petits volumes/un seul index, mais le snapshot est la norme.