Skip to content
Published on

AWS DMS 実践 — 移行と継続的レプリケーション(CDC)

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに — 無停止移行という難題

データベース移行は、ほぼすべてのインフラエンジニアが一度は通過する儀式のようなものです。オンプレミスの Oracle をクラウドへ移すにせよ、自己管理の MySQL を RDS に載せるにせよ、高価な商用エンジンから PostgreSQL へ脱出するにせよ、最終的には同じ問いにぶつかります。サービスを止めず、データを一件も失わずに、どう移すのかという問いです。

もっとも単純な方法はダンプを取って復元することです。しかし数百 GB から数 TB に及ぶ本番データベースをダンプして復元する間、サービスを止められる組織はそう多くありません。ダンプを始めた瞬間から復元が終わるまでに発生した変更分をどう追いつくかが核心的な難題です。

AWS Database Migration Service、略して DMS はまさにこの問題を正面から扱います。初期データをまとめて移すフルロード(full load)と、その間に発生した変更をリアルタイムで追いかける変更データキャプチャ(CDC、Change Data Capture)を一つのツールの中で組み合わせ、ソースとターゲットをほぼリアルタイムで同期した状態に保ちます。その状態で短いカットオーバーの窓だけ確保すれば、無停止に近い切り替えが可能になります。

本記事では DMS の構成要素から、フルロードと CDC の動作原理、異種間移行と SCT 連携、LOB 処理とデータ検証、モニタリングとカットオーバー戦略、そしてネイティブ論理レプリケーションとの比較までを実務目線で整理します。

DMS とは何か — 三つの構成要素

DMS を一文で定義すると、ソースデータベースからターゲットデータベースへデータを移し、継続的に同期してくれるマネージドなレプリケーションサービスです。動作を理解するには、まず三つの構成要素を知る必要があります。

  • レプリケーションインスタンス(Replication Instance): 実際のレプリケーション作業を行う EC2 ベースのマネージドコンピュートです。ソースからデータを読み、変換し、ターゲットへ書き込むエンジンがここで動きます。
  • エンドポイント(Endpoint): ソースとターゲットのデータベースへの接続情報です。エンジン種別、ホスト、ポート、認証情報、追加の接続属性を保持します。
  • レプリケーションタスク(Replication Task): どのテーブルをどの方式(フルロード、CDC、または両方)で移すかを定義する単位です。テーブルマッピングとタスク設定がここに付きます。

この三つの関係を図にすると次のようになります。

+------------------+        +------------------------------+        +------------------+
|  ソース DB        |        |   レプリケーションインスタンス   |        |  ターゲット DB     |
|  (オンプレ/RDS)   |        |   (マネージド EC2)             |        |  (RDS/Aurora)     |
|                  |  read  |   +----------------------+   | write  |                  |
|  Oracle/MySQL/   | -----> |   |  レプリケーションタスク  |   | -----> |  PostgreSQL/      |
|  PostgreSQL/...  |        |   |  - テーブルマッピング    |   |        |  Aurora/...      |
|                  |        |   |  - フルロード + CDC    |   |        |                  |
|  変更ログ          |        |   |  - 変換ルール          |   |        |                  |
|  (redo/binlog/   |        |   +----------------------+   |        |                  |
|   WAL)           |        |                              |        |                  |
+------------------+        +------------------------------+        +------------------+

レプリケーションインスタンスは、ソースとターゲットの間に挟まる中継エンジンです。ソースのトランザクションログ(Oracle の redo log、MySQL の binlog、PostgreSQL の WAL)を読んで変更をキャプチャし、ターゲットエンジンが理解できる形に変換して適用します。AWS はこのインスタンスのパッチ適用、モニタリング、マルチ AZ フェイルオーバーを管理してくれます。

フルロードと CDC — 二つのフェーズの結合

DMS タスクは移行タイプ(migration type)に応じて三つのモードで動作します。

  • フルロードのみ(full-load): 現時点のデータをまとめて移して終了します。ソースが停止した状態や一回限りのコピーならこれで十分です。
  • CDC のみ(cdc): 特定の時点以降の変更だけを追いかけます。初期データを別の方法ですでに移した場合に使います。
  • フルロード + CDC(full-load-and-cdc): もっとも一般的な無停止移行のパターンです。初期データを移している間に発生した変更を記録しておき、フルロードが終わったらその変更を適用して追いつき、その後リアルタイムレプリケーションへ切り替えます。

フルロード + CDC の全体の流れを時間軸で描くと次のようになります。

時間 ───────────────────────────────────────────────────────────────────>

  [フルロード開始]              [フルロード完了]        [キャッシュ済み変更の適用完了]
       |                            |                          |
       v                            v                          v
  +---------------------------------+--------------------------+----------------------+
  |        フルロード進行中           |   キャッシュ変更の適用     |   継続レプリケーション(CDC) |
  |  (テーブル単位の並列コピー)        |   (溜まった変更)          |   (リアルタイム追従)    |
  +---------------------------------+--------------------------+----------------------+
       |                                                              |
       +-- この区間のソース変更は -------------------------------------+
           内部キャッシュまたはログで追跡され後で適用される

核心は、フルロードが進行している間もソースの変更を取りこぼさないという点です。DMS はフルロード開始時点のログ位置を覚えておき、それ以降の変更をキャッシュするかログから読み直して、フルロード完了後に適用します。これによってソースを止めずに一貫した状態に到達できます。

同種と異種 — 二つの分岐

DMS の移行は大きく二つの分岐に分かれます。この区分が作業の難易度と必要なツールを決めます。

  • 同種(homogeneous)移行: ソースとターゲットが同じエンジンの場合です。たとえばオンプレミスの PostgreSQL から RDS PostgreSQL へ、または自己管理の MySQL から Aurora MySQL へ移す場合です。スキーマ構造が同一なので、変換はほとんど必要ありません。
  • 異種(heterogeneous)移行: ソースとターゲットのエンジンが異なる場合です。Oracle から PostgreSQL へ、SQL Server から Aurora へ移すといった具合です。データ型、関数、ストアドプロシージャ、シーケンスなどエンジンごとに異なる要素を変換する必要があるため、スキーマ変換ツールが必要です。

同種移行では DMS だけでデータと変更の両方を処理できます。ただし DMS は基本的にテーブルと基本データを移すものであり、インデックスや外部キー、トリガー、シーケンスといった補助オブジェクトを完璧に移すわけではありません。そのため実務ではスキーマはネイティブツールで先に移し、データだけを DMS で移す分業がよく見られます。

異種移行では AWS Schema Conversion Tool(SCT)または DMS Schema Conversion が登場します。

SCT 連携 — スキーマ変換

異種移行の第一歩はスキーマ変換です。Oracle の NUMBER 型を PostgreSQL の numeric へ、PL/SQL プロシージャを PL/pgSQL へ、シーケンスやトリガーをターゲットの構文へ置き換える作業です。これを手作業で行うと終わりがないため、AWS は Schema Conversion Tool を提供します。

SCT の作業の流れはおおよそ次のようになります。

+---------------------+      +------------------------+      +----------------------+
|  ソーススキーマ        |      |   SCT / DMS スキーマ変換  |      |  ターゲットスキーマ      |
|  (Oracle など)       | ---> |                        | ---> |  (PostgreSQL など)    |
|                     |      |  - 自動変換             |      |                      |
|  テーブル / 型 /       |      |  - 変換不可項目レポート   |      |  変換済み DDL +        |
|  プロシージャ / トリガー |      |  - 変換難易度評価       |      |  手動補正が必要な一覧   |
+---------------------+      +------------------------+      +----------------------+

SCT の本当の価値は、自動変換そのものよりも変換不可の項目をレポートとして抽出してくれる点にあります。自動で変換される部分には手がかかりませんが、エンジン固有の機能(たとえば Oracle のパッケージ、自律トランザクション、特定のヒント)は人が再設計しなければなりません。SCT はこうした項目に変換難易度を付けて、移行工数を見積もれるようにしてくれます。

スキーマ変換が終わってターゲットにオブジェクトを作り終えると、実際のデータ移動は DMS が担当します。つまり SCT は器を作り、DMS はその器に中身を満たす分業です。

実践設定 — エンドポイントとタスク

ここから実際の設定に入ります。CLI でソースエンドポイント、ターゲットエンドポイント、レプリケーションタスクを作る骨格は次のとおりです。

# 1. ソースエンドポイントの作成 (Oracle の例)
aws dms create-endpoint \
  --endpoint-identifier source-oracle \
  --endpoint-type source \
  --engine-name oracle \
  --server-name oracle.internal.example.com \
  --port 1521 \
  --database-name ORCL \
  --username dms_user \
  --password "REPLACE_WITH_SECRET"

# 2. ターゲットエンドポイントの作成 (PostgreSQL の例)
aws dms create-endpoint \
  --endpoint-identifier target-postgres \
  --endpoint-type target \
  --engine-name postgres \
  --server-name mydb.cluster-abc.ap-northeast-2.rds.amazonaws.com \
  --port 5432 \
  --database-name appdb \
  --username dms_user \
  --password "REPLACE_WITH_SECRET"

# 3. 接続テスト
aws dms test-connection \
  --replication-instance-arn arn:aws:dms:ap-northeast-2:111122223333:rep:ABCDEF \
  --endpoint-arn arn:aws:dms:ap-northeast-2:111122223333:endpoint:SOURCE

テーブルマッピングは、どのスキーマとテーブルを移すか、そしてどう変換するかを定義する JSON です。選択ルール(selection)と変換ルール(transformation)で構成されます。

{
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "include-app-schema",
      "object-locator": {
        "schema-name": "APP",
        "table-name": "%"
      },
      "rule-action": "include"
    },
    {
      "rule-type": "transformation",
      "rule-id": "2",
      "rule-name": "schema-to-lowercase",
      "rule-target": "schema",
      "object-locator": {
        "schema-name": "APP"
      },
      "rule-action": "convert-lowercase"
    },
    {
      "rule-type": "transformation",
      "rule-id": "3",
      "rule-name": "table-to-lowercase",
      "rule-target": "table",
      "object-locator": {
        "schema-name": "APP",
        "table-name": "%"
      },
      "rule-action": "convert-lowercase"
    }
  ]
}

Oracle は識別子を大文字で保存し、PostgreSQL は小文字を好むため、上のようにスキーマ名とテーブル名を小文字に変換するルールは異種移行でほぼ必須です。

タスク設定 — task settings の要点

レプリケーションタスクの細かな動作は task settings の JSON で制御します。項目は非常に多いですが、実務で触ることになる要点だけを抜き出すと次のようになります。

{
  "TargetMetadata": {
    "SupportLobs": true,
    "FullLobMode": false,
    "LimitedSizeLobMode": true,
    "LobMaxSize": 64,
    "BatchApplyEnabled": true
  },
  "FullLoadSettings": {
    "TargetTablePrepMode": "DROP_AND_CREATE",
    "MaxFullLoadSubTasks": 8,
    "CommitRate": 10000
  },
  "Logging": {
    "EnableLogging": true,
    "LogComponents": [
      { "Id": "SOURCE_CAPTURE", "Severity": "LOGGER_SEVERITY_DEFAULT" },
      { "Id": "TARGET_APPLY", "Severity": "LOGGER_SEVERITY_DEFAULT" }
    ]
  },
  "ValidationSettings": {
    "EnableValidation": true,
    "ThreadCount": 5
  },
  "ErrorBehavior": {
    "DataErrorPolicy": "LOG_ERROR",
    "TableErrorPolicy": "SUSPEND_TABLE"
  }
}

いくつかの項目を説明するとこうなります。TargetTablePrepMode を DROP_AND_CREATE にすると、フルロード前にターゲットテーブルを空にして作り直します。すでにスキーマを SCT で作ってある場合は、TRUNCATE_BEFORE_LOAD や DO_NOTHING のほうが安全です。MaxFullLoadSubTasks は同時にロードするテーブル数で、ソースとターゲットの余力に合わせて調整します。BatchApplyEnabled を有効にすると、CDC の変更を一件ずつではなくまとめて適用するため、スループットが大きく上がります。

LOB 処理 — 大きなオブジェクトの落とし穴

DMS でもっとも足を取られやすいテーマが LOB(Large Object)、すなわち BLOB や CLOB といった大型オブジェクトの処理です。DMS が LOB を扱う方式は三つあります。

モード動作利点欠点
Full LOB Modeサイズ制限なくすべての LOB を移すデータ損失なし遅い、メモリ負荷が大きい
Limited LOB Mode指定した最大サイズまでのみ移す速い、予測可能上限超過分は切り捨て
Inline LOB Mode小さい LOB はインライン、大きいものは別処理バランスが良い設定がやや複雑

実務でもっとも一般的な選択は Limited LOB Mode です。LobMaxSize を十分大きく取りつつも、その上限を超える LOB が切り捨てられうる点を必ず把握しておく必要があります。上限を小さく取りすぎるとデータが静かに切り捨てられ、大きく取りすぎると性能が急落します。

LOB のあるテーブルにはもう一つ制約があります。DMS が LOB を移すには、そのテーブルに主キーまたは一意キーがなければならないという点です。キーがないと LOB 列は NULL として投入されるか、テーブルがまるごとスキップされます。そのため移行前に LOB テーブルのキーの有無を点検することが重要です。

LOB 処理の意思決定フロー

  LOB 列があるか?
        |
   いいえ ----> Limited/Full 設定に関わらず、速やかに進行
        |
       はい
        |
   主キーがあるか?
        |
   いいえ ----> 先にキーを追加するか別処理(そのままだと欠落リスク)
        |
       はい
        |
   LOB の最大サイズを把握しているか?
        |
   はい ----> Limited LOB Mode + LobMaxSize に余裕を持たせる
        |
   いいえ ----> Full LOB Mode(遅いが安全)または Inline を検討

データ検証 — 移したあとが本当の始まり

データを移したら終わりではありません。ソースとターゲットのデータが本当に一致しているか検証する必要があります。DMS は task settings で検証を有効にすると、行単位でソースとターゲットを比較するデータ検証機能を提供します。

検証はフルロードと CDC が完了した行を対象に、列の値をハッシュ化するか直接比較して不一致を見つけます。結果はタスク統計と検証専用テーブルで確認できます。

# タスクのテーブル別統計と検証状態の確認
aws dms describe-table-statistics \
  --replication-task-arn arn:aws:dms:ap-northeast-2:111122223333:task:MYTASK \
  --query "TableStatistics[].{Table:TableName,State:TableState,Validation:ValidationState,Failed:ValidationFailedRecords}"

検証状態が「Validated」なら一致、「Mismatched records」が出れば不一致です。不一致が出るよくある原因は、タイムゾーン処理、浮動小数点の精度差、文字エンコーディング、そして先に述べた LOB の切り捨てです。検証を有効にするとレプリケーション負荷が増えるため、運用への影響が大きい場合は検証スレッド数を調整したり、別の検証タスクとして分離したりします。

検証は「移した」と「正しく移した」の間の隙間を埋める安全装置です。移行でもっとも怖いのは失敗ではなく静かなデータ破損なので、検証を省く選択はおすすめしません。

モニタリングと再起動 — 運用の実際

DMS タスクは立ち上げて忘れるものではなく、継続的に見守る必要があります。主要な指標は CloudWatch で公開されます。

指標意味注目すべきとき
CDCLatencySourceソースから変更を読み取る遅延値が大きくなるとソースログ読み取りのボトルネック
CDCLatencyTargetターゲットへ変更を適用する遅延値が大きくなるとターゲット書き込みのボトルネック
FullLoadThroughputRowsTargetフルロードの秒間行数フルロード速度の点検
FreeableMemoryレプリケーションインスタンスの空きメモリ不足すればインスタンス増強が必要
CDCIncomingChanges待機中の変更数溜まり続けると適用が追いつかない

二つの遅延指標を分けて見ることが重要です。ソース遅延が大きければソースのトランザクションログを読む段階が遅く、ターゲット遅延が大きければターゲットへ適用する段階が遅いということです。原因が違うので処方も違います。ターゲット遅延は BatchApplyEnabled を有効にするか、移行中にターゲットのインデックスを一時的に無効化することで緩和できます。

タスクが止まったときの再起動戦略もあらかじめ決めておく必要があります。DMS タスクは最初から再開(restart)するか、停止した地点から続けて再開(resume)できます。

# 停止地点から続けて再開 (CDC 位置を維持)
aws dms start-replication-task \
  --replication-task-arn arn:aws:dms:ap-northeast-2:111122223333:task:MYTASK \
  --start-replication-task-type resume-processing

# 特定の時点から CDC を開始 (チェックポイントベース)
aws dms start-replication-task \
  --replication-task-arn arn:aws:dms:ap-northeast-2:111122223333:task:MYTASK \
  --start-replication-task-type start-replication \
  --cdc-start-position "checkpoint:V1#34#..."

resume は最後のチェックポイントから続けるためデータを移し直しません。一方、フルロードを最初からやり直すと、その間に溜まったターゲットの変更が上書きされうるので、再起動タイプの意味を正確に理解して選ぶ必要があります。

カットオーバー戦略 — 切り替えの瞬間

移行のクライマックスはカットオーバー、すなわちアプリケーションをソースからターゲットへ切り替える瞬間です。フルロード + CDC で二つのデータベースがほぼリアルタイムに同期した状態なら、カットオーバーは短い窓のうちに終えられます。

推奨するカットオーバー手順は次のとおりです。

カットオーバー手順

1. CDC 遅延がほぼ 0 か確認 (CDCLatencyTarget を監視)
2. ソースへの書き込みを一時的に遮断 (読み取り専用モードまたはトラフィック停止)
3. 残りの変更がすべてターゲットへ適用されるまで待機 (待機変更 0 を確認)
4. データ検証の最終確認 (行数、検証状態)
5. シーケンス/オートインクリメント値の補正 (DMS はシーケンス現在値を移さない)
6. アプリケーションの接続文字列をターゲットへ切り替え
7. ターゲットで正常動作を確認後にトラフィックを開放
8. 問題時にソースへロールバックできるよう一定期間ソースを保持

ここでよく抜ける 5 番の手順を強調したいです。DMS はテーブルの行データを移しますが、シーケンスやオートインクリメント列の「次の値」の状態は移しません。これを補正せずにカットオーバーすると、ターゲットで新しい行を入れるときに主キー衝突が発生します。カットオーバー直前に各シーケンスの現在の最大値を取得し、ターゲットのシーケンスをその上に再設定する作業が必須です。

また 8 番のようにロールバック経路を開けておくことが重要です。カットオーバー後に予期しない問題が起きたら素早くソースへ戻せる必要があるため、ソースを即座に破棄せず一定期間維持します。より保守的なチームは、ターゲットからソースへ逆向きにレプリケーションする逆方向 CDC をあらかじめ構成することもあります。

制限とコスト — 知って使うべきこと

DMS は強力ですが万能ではありません。知って臨むべき制限があります。

第一に、DMS はデータを移すのであってスキーマ全体を移すわけではありません。基本テーブルと主キー程度は作ってくれますが、補助インデックス、外部キー、トリガー、ストアドプロシージャ、ビュー、シーケンスなどは基本的に移しません。これらは SCT やネイティブツールで別途処理する必要があります。

第二に、フルロード中は外部キーとトリガーが妨げになります。そのため通常はフルロードの間ターゲットの外部キーとトリガーを無効化し、フルロードが終わったあとに再び有効にします。そうしないとテーブルの投入順序のせいで制約違反が発生します。

第三に、CDC はソースのトランザクションログに依存します。ソースで補助ロギング(Oracle の supplemental logging、MySQL の binlog ROW フォーマット、PostgreSQL の logical replication 設定)を有効にしておかないと CDC が動作しません。この事前設定を抜かすと、フルロードはできるのに CDC ができないという戸惑う状況に出くわします。

コストは大きく二つの軸です。レプリケーションインスタンスの時間あたり料金とデータ転送料金です。レプリケーションインスタンスはインスタンスクラスと稼働時間に比例するので、移行が終わったら忘れずにタスクとインスタンスを片付ける必要があります。同一リージョン内の転送は安価ですが、リージョン間やインターネット経由の転送はコストがかかります。コストを大まかに表すと次のようになります。

DMS コストの主な構成

  レプリケーションインスタンス料金 = インスタンスクラス単価 x 稼働時間
  ストレージ料金                 = ログ/キャッシュ用割当ストレージ x GB-月
  データ転送料金                 = リージョン間/インターネット区間転送量 x GB 単価
  (同一 AZ/リージョン内部の転送は一般に無料または安価)

もっともよくあるコストの無駄は、移行が終わったのにレプリケーションインスタンスを止めずに放置することです。CDC を恒久レプリケーション用途で使い続けるのでなければ、カットオーバー検証が終わり次第リソースを片付ける手順をチェックリストに入れておくとよいです。

代替比較 — ネイティブ論理レプリケーション

DMS が唯一の答えではありません。同種移行、とくに PostgreSQL 同士の移動では、エンジンが標準で提供する論理レプリケーション(logical replication)のほうが単純で速いことが多いです。二つのアプローチを比較するとこうなります。

基準AWS DMSネイティブ論理レプリケーション
異種サポート強み (エンジン間変換)ほぼ不可 (同じエンジン中心)
同種性能良好おおむね速く忠実
スキーマ変換SCT と連携自分で処理
運用負担マネージド、コンソール統合自前構成と監視
データ検証組み込み検証機能別ツールが必要
変換ルール豊富なマッピングルール限定的
コストインスタンス料金が発生エンジン自体の機能、追加費用は少ない
向いている状況異種、複雑な変換同種、単純なレプリケーション

大まかに要約するとこうです。Oracle や SQL Server から PostgreSQL へ行く異種移行なら、DMS と SCT の組み合わせが事実上の標準です。一方、PostgreSQL から PostgreSQL へ、MySQL から MySQL へ行く同種移行なら、エンジンネイティブの論理レプリケーションのほうが忠実でコストも低いことが多いです。PostgreSQL の publication と subscription、MySQL のレプリケーションは、シーケンスや制約を含めてより完全に追従する傾向があります。

実務では両方を混ぜることもあります。たとえばスキーマと補助オブジェクトはネイティブダンプで移し、大容量データの無停止移動だけを DMS で処理するといった具合です。ツールは目的に合わせて組み合わせるものであり、一つですべてを解決しようとする必要はありません。

よく踏む落とし穴

最後に、現場で繰り返し出くわす落とし穴をまとめます。

第一に、補助ロギングを抜かします。CDC が動作するにはソースで適切なロギングを有効にする必要がありますが、これを移行当日に気づくと予定が狂います。Oracle は supplemental logging、MySQL は binlog ROW フォーマット、PostgreSQL は wal_level を logical に設定する必要があります。

第二に、主キーのないテーブルを見落とします。主キーがないと CDC の UPDATE と DELETE が正しく動作せず、LOB も欠落しうります。移行前にキーのないテーブルを一覧化して対応策を決める必要があります。

第三に、LOB の上限を誤って設定します。Limited LOB Mode で LobMaxSize を小さく取りすぎるとデータが静かに切り捨てられます。ソースの実際の LOB 最大サイズを事前に調査する必要があります。

第四に、外部キーとトリガーを無効化しません。フルロード中にターゲットの制約とトリガーが生きていると、投入順序の問題で失敗したり意図しない副作用が生じたりします。

第五に、シーケンス補正を忘れます。カットオーバー後の主キー衝突の定番の原因です。

第六に、リソースを片付けません。終わったタスクとレプリケーションインスタンスを放置してコストが漏れることがよくあります。

実践チェックリスト

移行を段階ごとに点検できるよう、チェックリストにまとめました。

[ 事前準備 ]
[ ] ソース/ターゲットのエンジンバージョンと DMS サポートの確認
[ ] ソースに補助ロギングを有効化 (supplemental/binlog/wal_level)
[ ] 主キーのないテーブルを一覧化し対応策を決定
[ ] LOB 列の実際の最大サイズを調査
[ ] DMS 専用アカウントと最小権限の付与
[ ] ネットワーク経路とセキュリティグループ/ファイアウォールの確認

[ スキーマ準備 ]
[ ] (異種) SCT でスキーマ変換し変換不可項目を処理
[ ] ターゲットにテーブル/型を作成
[ ] フルロード用に外部キー/トリガーを無効化する計画を立てる

[ タスク構成 ]
[ ] レプリケーションインスタンスのサイズとマルチ AZ を決定
[ ] テーブルマッピング(選択/変換ルール)を作成
[ ] task settings で LOB モードと検証を設定
[ ] ロギングと CloudWatch アラームを構成

[ 実行と検証 ]
[ ] 接続テストの合格を確認
[ ] フルロードの進捗とスループットを監視
[ ] CDC 遅延(ソース/ターゲット)を監視
[ ] データ検証状態を確認し不一致を調査

[ カットオーバー ]
[ ] CDC 遅延が 0 に近いことを確認
[ ] ソース書き込みを遮断し残りの変更の適用を待機
[ ] シーケンス/オートインクリメント値を補正
[ ] 外部キー/トリガーを再び有効化
[ ] 接続文字列を切り替え正常動作を確認
[ ] ロールバック経路を維持 (ソースを保持)

[ 仕上げ ]
[ ] レプリケーションタスクの停止と削除
[ ] レプリケーションインスタンスの削除
[ ] 移行後のモニタリングと性能確認

おわりに

DMS の価値は華やかな技術ではなく、正確な問題定義にあります。無停止移行の本質は「初期データを移している間に発生した変更をどう追いつくか」であり、DMS はフルロードと CDC を一つのツールに束ねてこの問題をきれいに解決します。そこに異種変換のための SCT、整合性のためのデータ検証、運用のためのモニタリングと再起動が加わり、移行の全工程を支えます。

ただし DMS は魔法ではありません。補助ロギング、主キー、LOB 上限、シーケンス補正といったディテールを押さえなければ、静かなデータ破損というもっとも怖い結果に出くわします。そして同種移行ならネイティブ論理レプリケーションのほうが良い選択になりうる点も覚えておく価値があります。ツールの強みと制限を正確に知り、チェックリストでディテールを押さえること。結局、安全な移行はその誠実さの結果です。

参考資料

Discuss on Twitter • View on GitHub