Согласованная выгрузка для миграции

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) — стандартный инструмент логической выгрузки для миграции. Для согласованности чтения передайте FLASHBACK_SCN=<scn> (или FLASHBACK_TIME), чтобы все таблицы выгружались согласованно на один SCN; на живой системе это критично. PARALLEL ускоряет выгрузку, а %U создаёт несколько файлов.

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

Для миграции предпочтителен формат pg_dump -Fc (custom) или -Fd (directory); оба позволяют выборочную/параллельную загрузку через pg_restore. Так как pg_dump работает в одной транзакции, его вывод автоматически является согласованным снимком. Объекты уровня кластера, такие как роли и табличные пространства, выгружаются отдельно через 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

В InnoDB --single-transaction даёт единый согласованный снимок и не блокирует таблицы. --source-data=2 (ранее --master-data=2) записывает комментарием в начале вывода позицию binlog/GTID, нужную для запуска репликации/CDC; это необходимо для переключения без простоя. Для больших данных mydumper работает параллельно.

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

При миграции на тот же или более новый SQL Server самый надёжный путь — BACKUP ... RESTORE (целостность проверяется через CHECKSUM). Для миграции, независимой от версии/платформы, или переноса в Azure SQL предпочтительна выгрузка схемы+данных в один файл .bacpac через SqlPackage /Action:Export. Для отдельных таблиц используется bcp.

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 — стандартная бинарная (BSON) выгрузка для миграции. В наборе реплик опция --oplog захватывает из oplog изменения, записанные во время дампа, обеспечивая согласованную точку во времени (в паре с mongorestore --oplogReplay); опция действует только для полного дампа. Для миграции большого кластера на уровне кластера лучше подходят mongosync/онлайн-инструменты.

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

В Redis согласованная выгрузка — это снимок RDB. BGSAVE создаёт согласованный dump.rdb в фоне через fork, не блокируя основной процесс (SAVE блокирует, использовать не следует). Путь к файлу определяется через CONFIG GET dir и dbfilename; для миграции скопируйте этот dump.rdb в каталог данных целевого сервера.

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 }

В Elasticsearch согласованный способ выгрузки для миграции — снимок (snapshot). Сначала регистрируется репозиторий (fs, S3, GCS и т. д.), затем делается снимок; снимки инкрементальны и фиксируют согласованное состояние на момент создания. Для небольших данных/одного индекса можно использовать и elasticdump, но стандарт — snapshot.