移行用の一貫性のあるエクスポート

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)は、レプリケーション/CDC の開始に必要な binlog の位置/GTID 情報を出力の先頭にコメントとして書き込む。これはゼロダウンタイムの切り替えに不可欠。大容量データでは 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 への移行には、SqlPackage /Action:Export でスキーマ + データを単一の .bacpac ファイルにエクスポートする方法が推奨される。個別のテーブルには 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 は fork によりメインプロセスをブロックせずに、バックグラウンドで一貫性のある dump.rdb を生成する(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 での移行用の一貫性のあるエクスポート方法はスナップショット。まずリポジトリ(fs、S3、GCS など)を登録し、次にスナップショットを取得する。スナップショットは増分で、取得時点の一貫性のある状態を捕捉する。小さなデータ/単一のインデックスには elasticdump も使用できるが、標準はスナップショット。

DBAtlas で開く →