마이그레이션용 일관된 export

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)는 마이그레이션을 위한 표준 논리 export 도구다. 읽기 일관성을 위해 FLASHBACK_SCN=<scn>(또는 FLASHBACK_TIME)을 지정하면 모든 테이블이 단일 SCN 기준으로 일관되게 export된다. 운영 중인 시스템에서는 이것이 매우 중요하다. 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) export다. replica set에서 --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에서 일관된 export는 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에서 마이그레이션을 위한 일관된 export 방법은 스냅샷이다. 먼저 리포지토리(fs, S3, GCS 등)를 등록한 뒤 스냅샷을 생성한다. 스냅샷은 증분 방식이며 생성 시점의 일관된 상태를 캡처한다. 소량 데이터/단일 인덱스에는 elasticdump도 사용할 수 있지만 표준은 스냅샷이다.

DBAtlas에서 열기 →