DBAtlas · データベース運用アトラス

継続的レプリケーション/CDC を構成(ゼロダウンタイムの切り替え)

Oracle

# CDC-based replication with Oracle GoldenGate (outline)
# 1) Enable supplemental logging on the source:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
# 2) Extract (capture changes from redo) and Replicat (apply to the target) processes:
#   GGSCI> ADD EXTRACT ext1, INTEGRATED TRANLOG, BEGIN NOW
#   GGSCI> ADD REPLICAT rep1, INTEGRATED
# Alternative: initial load with Data Pump + incremental capture with GoldenGate

Oracle でゼロダウンタイム/異種間 CDC の標準ツールは Oracle GoldenGate。Extract プロセスが REDO ログから変更を取得し、Replicat がターゲットに適用する。サプリメンタルロギングを有効にする必要がある。典型的な移行では、初期ロードを Data Pump で取得し、以降は GoldenGate が変更をターゲットにストリーミングすることで、ほぼゼロのダウンタイムで切り替えられる。

PostgreSQL

-- Source (publisher): create a publication (wal_level must be logical)
CREATE PUBLICATION migration_pub FOR ALL TABLES;

-- Target (subscriber): create a subscription (initial copy + continuous stream)
CREATE SUBSCRIPTION migration_sub
  CONNECTION 'host=source dbname=shop user=repl password=***'
  PUBLICATION migration_pub;

PostgreSQL は組み込みの論理レプリケーションで CDC を提供する。ソースで CREATE PUBLICATION、ターゲットで CREATE SUBSCRIPTION を実行する。サブスクリプションの開始時に既存データをコピーし(初期コピー)、その後 WAL から変更を継続的にストリーミングする。wal_level=logical が必要。大規模/複雑なシナリオでは pglogical または Debezium が推奨される。

MySQL

-- Source: binlog must be enabled and in ROW format (log_bin, binlog_format=ROW)
-- Grant a replication user: GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

-- Define the source on the target (start from the binlog position of the initial load):
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='source', SOURCE_USER='repl', SOURCE_PASSWORD='***',
  SOURCE_LOG_FILE='binlog.000001', SOURCE_LOG_POS=1547;
START REPLICA;

MySQL でのゼロダウンタイムの切り替えは binlog ベースのレプリケーションで行う。初期ロードを mysqldump --source-data で取得し、binlog の位置/GTID を記録する。ターゲットでは CHANGE REPLICATION SOURCE TO(8.0.23+ の構文。旧 CHANGE MASTER TO)でその位置からレプリケーションを開始する。START REPLICA で変更を継続的に適用する。GTID ベースの構成のほうが安全。

SQL Server

-- Option A: Transactional Replication (publisher->distributor->subscriber) — SSMS wizard

-- Option B: Change Data Capture (track changes as tables)
EXEC sys.sp_cdc_enable_db;              -- enable CDC at database level
EXEC sys.sp_cdc_enable_table
  @source_schema = N'dbo', @source_name = N'customer',
  @role_name = NULL;                    -- enable CDC at table level
-- Changes are read from the cdc.dbo_customer_CT table and moved to the target.

SQL Server の継続的レプリケーションには主に 2 つの方法がある。ターゲットへの直接のストリームが必要なら Transactional Replication(パブリッシャー/サブスクライバー)を構成する。独自の ETL で変更を移す場合は Change Data Capture(sp_cdc_enable_db + sp_cdc_enable_table)を有効にし、_CT テーブルから読み取る。異種のターゲットには CDC を AWS DMS/Debezium と組み合わせる。

MongoDB

// Watch changes live with Change Streams (requires a replica set/sharded cluster)
const cs = db.customer.watch([], { fullDocument: "updateLookup" });
while (cs.hasNext()) { printjson(cs.next()); }  // apply to the target

// Official tool for managed cluster-to-cluster replication/migration: mongosync
// mongosync --cluster0 "mongodb://source" --cluster1 "mongodb://target"

MongoDB では CDC に Change Streams を使用する。db.collection.watch() は oplog から insert/update/delete のイベントをリアルタイムでストリーミングし、ターゲットに適用する(レプリカセットが必要)。クラスタ間の完全な継続的移行/レプリケーションには、MongoDB 公式の Cluster-to-Cluster Sync ツールである mongosync(Atlas 専用ではなく、セルフマネージドのクラスタでも動作する)が初期ロード + 継続的同期を管理する。

Redis

# Make the target instance a replica of the source (live synchronization)
# On the target Redis:
REPLICAOF source_host 6379
# Monitor sync status:
INFO replication   # master_link_status must be up

# Once the cutover is complete, make the target standalone:
REPLICAOF NO ONE

Redis でのゼロダウンタイムの切り替えはネイティブのレプリケーションで行う。ターゲットサーバーで REPLICAOF <source host port>(旧 SLAVEOF)を実行すると、ターゲットはまず完全な RDB を受信し、その後コマンドストリームで継続的に同期を保つ。INFO replication で master_link_status:up を確認し、切り替えが完了したら REPLICAOF NO ONE でターゲットをスタンドアロンにする。

Elasticsearch

# Incremental reindex from the old cluster to the new one within the same version family
POST _reindex?wait_for_completion=false
{ "source": { "remote": { "host": "http://old:9200" }, "index": "customer",
    "query": { "range": { "updated_at": { "gt": "<last-cursor>" } } } },
  "dest": { "index": "customer" } }

# Licensed feature: Cross-Cluster Replication (CCR) — continuous following
# On the target (follower) cluster: PUT /customer/_ccr/follow { "remote_cluster": "old", "leader_index": "customer" }

Elasticsearch の本来の継続的レプリケーション機能は Cross-Cluster Replication (CCR)。ターゲットクラスタがソースのリーダーインデックスをフォローし、変更を継続的に取得する(商用/Platinum ライセンスが必要)。ライセンスがない場合は、定期的なリモート reindex(時刻/シーケンスフィールドに基づく増分)でほぼ継続的な同期を実現する。

DBAtlas で開く →