AWS DMS を使って Amazon RDS for Db2 からオンプレミスの AIX Db2 へフェイルバックする

本記事は 2026 年 7 月 8 日 に公開された「Fail back from Amazon RDS for Db2 to on-premises AIX Db2 using DMS」を翻訳したものです。

本記事では、AWS Database Migration Service (AWS DMS) を使って、Amazon Relational Database Service (Amazon RDS) for Db2 からオンプレミスの AIX Db2 インスタンスへ、CDC のみのリバースレプリケーションを構成する方法を説明します。

Db2 ワークロードをオンプレミスの AIX から Amazon RDS for Db2 に移行した後は、カットオーバー後の重要な検証期間に問題が発生した場合でもデータの整合性を保てる、検証済みのフェイルバック経路が必要です。検証済みのフェイルバック戦略があれば、カットオーバー後にアプリケーションがコミットしたトランザクションを保持したまま、迅速にロールバックできます。標準的なバックアップとリストアの手法では数時間かかることがあり、最新の変更を取り込めない場合もあります。本記事で紹介する構成は、設定と検証におよそ 2〜3 時間かかります。

DMS を使えば、Amazon Relational Database Service (Amazon RDS) for Db2 からオンプレミスの AIX Db2 インスタンスへ、変更データキャプチャ (CDC) のみのリバースレプリケーション経路を構成できます。この方法は、AWS への移行中だけ機能する一時的なセーフティネットとして設計されており、本番ワークロードの切り替え後に問題が発生した場合にオンプレミス環境へ戻す助けとなります。

オンプレミス Db2 から Amazon RDS へのフォワード移行パターンには豊富なドキュメントがあります。詳しくは、Migrate from self managed Db2 to Amazon RDS using DMS および Migrate from self managed Db2 to Amazon RDS using native tools を参照してください。Db2 のリバースレプリケーションパターンは、フォワード移行に比べてドキュメントが少ないのが現状です。本記事の方法を使えば、AIX 環境を起点とする Db2 ワークロード向けに、検証済みのフェイルバック戦略を実装できます。Rolling back from a migration with AWS DMS。

移行時のロールバック戦略の概念的な枠組みについては、basic fallback、fall forward、dual write、bidirectional replication という 4 つの戦略を解説した「Rolling back from a migration with DMS」を参照してください。本記事では、検証済みのフェイルバック経路を維持するため、CDC のみのタスクで Db2 の単方向リバースレプリケーションパターンを実装する方法に焦点を当てます。

ソリューションの概要

移行の検証中は、問題が発生しても安全にロールバックできるという確信が必要です。このリバースレプリケーションは、そのセーフティネットを提供するために設計されています。AWS へのデータベース移行はすべて、plan(計画)、migrate(移行)、validate(検証)、complete(完了)というライフサイクルをたどります。リバースレプリケーションが支えるのは validate フェーズです。カットオーバー後の検証期間(通常は 2〜4 週間)のみ稼働し、検証が成功した時点で廃止します。継続的なレプリケーションパターンではなく、移行を完了させる確信を得るための一時的な安全策です。コストの詳細は、本記事後半の「コストに関する考慮事項」セクションを参照してください。

この方法では、Amazon RDS をソース、オンプレミスの自己管理型 AIX Db2 インスタンスをターゲットとして AWS DMS の CDC のみのレプリケーションタスクを実行し、検証済みのフェイルバック経路を維持します。レプリケーションするのは進行中の変更のみ(フルロードなし)であり、冗長なデータ転送を回避します。オンプレミスのデータベースには、カットオーバー前の完全なデータセットがすでに含まれています。接続はプライベートのままで、パブリックサブネット、パブリック IP アドレス、インターネットゲートウェイのいずれも使用しません。データは AWS Direct Connect だけを経由して流れます。

データがインターネットゲートウェイを使わずプライベート接続を経由して流れる点に注目してください。次の図はこのアーキテクチャを示しています。

図 1: CDC のみのリバースレプリケーションのソリューションアーキテクチャ(プライベートネットワークのみ)

主要な設計上の決定

• CDC のみ、フルロードなし: オンプレミスのデータベースにはカットオーバー前の完全なデータセットがすでに保持されているため、データの再ロードにかかる時間とコストを回避できます。カットオーバー後に Amazon RDS で行われた増分変更のみが戻されます。
• プライベートのみのネットワークアーキテクチャ: データがパブリックインターネットを経由しません。DMS や Amazon RDS インスタンスにパブリックサブネットもパブリック IP アドレスもありません。AWS サービスへのアクセスは Amazon Virtual Private Cloud (Amazon VPC) エンドポイント (AWS PrivateLink) を経由し、データは AWS Direct Connect のプライベート VIF を通過します。
• 単方向リバースレプリケーション: カットオーバー後の検証期間中、アプリケーションは Amazon RDS にのみ書き込みます。リバース CDC タスクが変更をオンプレミスのデータベースにレプリケーションします。
• 接続には AWS Direct Connect: Amazon VPC とオンプレミスデータセンターの間の専用のプライベート接続で、インターネット経路は一切含まれません。

前提条件

このチュートリアルには、Db2 管理と AWS ネットワークに関する中級レベルの知識が必要です。構成全体の設定と検証には、およそ 2〜3 時間を見込んでください。リバースレプリケーションを構成する前に、次の要件を満たしていることを確認してください。

開始前に必要なもの

• フォワード移行が完了していること: DMS(フルロード + CDC)またはネイティブツールを使って、Db2 ワークロードをオンプレミスの AIX から Amazon RDS へ移行済みであること。
• Amazon RDS インスタンス: Amazon Virtual Private Cloud (Amazon VPC) 内で稼働し、PubliclyAccessible が false に設定された(プライベートエンドポイントのみの)Amazon RDS インスタンス。
• オンプレミスの AIX Db2 インスタンス: 元のソースデータベースが破損せず利用可能な状態で、Db2 LUW バージョン 10.5 以降が稼働していること。
• AWS Direct Connect: オンプレミスデータセンターと AWS の間で、プライベート仮想インターフェイス (VIF) を備えた AWS Direct Connect 接続が確立されていること。パブリックインターネット経由の VPN は使用しません。

このチュートリアルで作成するもの

• DMS レプリケーションインスタンス: バージョン 3.5.4 以降で、Publicly Accessible を false に設定したプライベートサブネットにデプロイします。
• VPC エンドポイント: AWS Secrets Manager、Amazon CloudWatch Logs、DMS のインターフェイスエンドポイント。これにより、DMS インスタンスはインターネットゲートウェイなしで AWS サービスにアクセスできます。
• AWS Identity and Access Management (IAM) の権限: DMS に Amazon RDS for Db2、AWS Secrets Manager、Amazon CloudWatch へのアクセスを付与する IAM ロール。
• データベースユーザーの権限: ソース (Amazon RDS for Db2) とターゲット (オンプレミスの AIX Db2) の両方のエンドポイントに対する適切な権限付与。

ネットワークアーキテクチャ: AWS Direct Connect によるプライベートのみの接続

ネットワークアーキテクチャ全体でプライベート接続のみを使用します。アーキテクチャにインターネットゲートウェイは含まれません。DMS レプリケーションインスタンスと Amazon RDS は、パブリック IP アドレスを持たないプライベートサブネットにデプロイします。Amazon VPC エンドポイント (AWS PrivateLink) が、Amazon CloudWatch や AWS Secrets Manager などの AWS サービスに接続します。データは、プライベート仮想インターフェイスを使い、AWS Direct Connect だけを経由してオンプレミス環境へ流れます。

セキュリティグループの設定

通信をプライベートサブネットのみに制限するため、次のセキュリティグループを作成します。

DMS レプリケーションインスタンスのセキュリティグループ (dms-reverse-repl-sg):

# Create security group for DMS replication instance
aws ec2 create-security-group \
  --group-name dms-reverse-repl-sg \
  --description "SG for DMS reverse replication (private only)" \
  --vpc-id vpc-<vpc-id>

# Allow outbound to on-premises Db2 (port <db-port>) through AWS Direct Connect
aws ec2 authorize-security-group-egress \
  --group-id sg-dms-xxxxxxxxx \
  --protocol tcp --port <db-port> \
  --cidr <on-premises-db2-ip>/32

# Allow outbound to RDS for Db2 (port <db-port>) - private subnet
aws ec2 authorize-security-group-egress \
  --group-id sg-dms-xxxxxxxxx \
  --protocol tcp --port <db-port> \
  --cidr <private-subnet-cidr>

# Allow outbound HTTPS to Amazon VPC Endpoints (443)
aws ec2 authorize-security-group-egress \
  --group-id sg-dms-xxxxxxxxx \
  --protocol tcp --port 443 \
  --cidr <vpc-cidr>

Amazon RDS のセキュリティグループ (rds-db2-sg):

# Allow inbound from DMS replication instance on port <db-port>
aws ec2 authorize-security-group-ingress \
  --group-id sg-rds-xxxxxxxxx \
  --protocol tcp --port <db-port> \
  --source-group sg-dms-xxxxxxxxx

プライベートな AWS サービスアクセス用の VPC エンドポイント

Amazon VPC にはインターネットゲートウェイがないため、DMS レプリケーションインスタンスが AWS サービスにプライベートにアクセスできるよう、Amazon VPC エンドポイントを作成します。

# Create Interface Amazon VPC Endpoints for DMS service access
for SERVICE in secretsmanager monitoring logs dms; do
  aws ec2 create-vpc-endpoint \
    --vpc-id vpc-<vpc-id> \
    --service-name com.amazonaws.<aws-region>.${SERVICE} \
    --vpc-endpoint-type Interface \
    --subnet-ids subnet-aaaaaaaaaa \
    --security-group-ids sg-vpce-xxxxxxxxx \
    --private-dns-enabled
done

VPC ルートテーブルの設定

# Add route to on-premises network through VGW (private routing)
aws ec2 create-route \
  --route-table-id rtb-<route-table-id> \
  --destination-cidr-block <on-premises-cidr> \
  --gateway-id vgw-<vgw-id>

# Note: No route to internet gateway - traffic stays private

接続の検証

DMS タスクを作成する前に、DMS インスタンス、ソース、ターゲット間のプライベート接続を検証します。

1. 到達性をテストする: Amazon VPC Reachability Analyzer を使い、DMS サブネットからオンプレミス IP () へのポート <db-port> 経由のネットワーク経路を検証します。
2. ファイアウォールルールを確認する: オンプレミスのファイアウォールが、Amazon VPC の CIDR 範囲 () からのポート <db-port> 宛て受信 TCP トラフィックを許可していることを確認します。
3. エンドポイント接続をテストする: エンドポイントを作成した後、DMS の接続テストを使用します。

aws dms test-connection \
  --replication-instance-arn arn:aws:dms:<aws-region>:<aws-account-id>:rep:my-instance \
  --endpoint-arn arn:aws:dms:<aws-region>:<aws-account-id>:endpoint:my-target

期待される出力:

{
  "Connection": {
    "ReplicationInstanceArn": "arn:aws:dms:<aws-region>:<aws-account-id>:rep:my-instance",
    "EndpointArn": "arn:aws:dms:<aws-region>:<aws-account-id>:endpoint:my-target",
    "Status": "testing",
    "LastFailureMessage": "",
    "EndpointIdentifier": "my-target",
    "ReplicationInstanceIdentifier": "my-instance"
  }
}

Amazon RDS for Db2 を CDC ソースとして構成する

Amazon RDS を CDC ソースとして準備するため、次の 3 つの設定手順を実施します。

マスターユーザー(インスタンス作成時に指定した管理ユーザー)を使って Amazon RDS for Db2 インスタンスに接続します。次のコマンドには rdsadmin の権限が必要なため、標準的なデータベースユーザーでは権限が不足します。

アーカイブログ保持を有効にする

-- Increase archive log retention to 24 hours
CALL rdsadmin.set_archive_log_retention(?, 'PRODDB', '24');

重要: アーカイブログの保持期間は最低でも 24 時間に設定してください。DMS タスクの処理が遅延し、必要なログがすでに削除されている場合、タスクは失敗し、新しい位置から再開する必要があります。

DATA CAPTURE CHANGES を有効にする

ALTER TABLE SCHEMA_NAME.TABLE_NAME DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS;

DMS ユーザーに権限を付与する

GRANT DBADM ON DATABASE TO USER dms_user;
GRANT DATAACCESS ON DATABASE TO USER dms_user;

オンプレミスの AIX Db2 をターゲットとして構成する

AWS DMS からの CDC 変更を受け取れるよう、オンプレミスのターゲットデータベースを準備します。

SYSADM または SECADM 権限を持つユーザーを使って、オンプレミスの AIX Db2 インスタンスに接続します。次の GRANT ステートメントには、ターゲットデータベースの管理者権限が必要です。

ターゲットデータベースの権限を付与する

GRANT DBADM ON DATABASE TO USER dms_user;
GRANT DATAACCESS ON DATABASE TO USER dms_user;

ターゲットテーブルを準備する

1. 外部キー制約を削除または無効化する: AWS DMS は、親子関係の順序ではなくトランザクションログの順序で変更を適用します。外部キーを無効化しないと、子テーブルへの INSERT が対応する親行より先に到着し、参照整合性違反を引き起こしてレプリケーションタスクが失敗する可能性があります。フェイルバックを検証した後に制約を再度有効化します。
2. トリガーを無効化する: CDC の適用による意図しない副作用を防ぎます。

ALTER TABLE TARGET_SCHEMA.TABLE_NAME DEACTIVATE TRIGGERS;

3. シーケンスをリセットする: RDS ソースから現在の値を取得し、ターゲットでリセットします。

SELECT 'ALTER SEQUENCE ' || TRIM(SEQSCHEMA) || '.' || TRIM(SEQNAME)
  || ' RESTART WITH ' || NEXTCACHEFIRSTVALUE || ';'
FROM SYSCAT.SEQUENCES
WHERE SEQSCHEMA IN ('APP_SCHEMA') AND SEQTYPE = 'S';

ステップバイステップ: CDC のみのリバースレプリケーションを作成する

次の 7 つのステップでは、CDC のみのリバースレプリケーション用の DMS リソースを作成する手順を説明します。以降のコマンドでは、プレースホルダーの値(vpc-xxxxxxxxx や sg-dms-xxxxxxxxx など)を実際のリソース識別子に置き換えてください。

ステップ 1: IAM ロールを作成する

aws iam create-role --role-name dms-vpc-role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{"Effect": "Allow",
      "Principal": {"Service": "dms.amazonaws.com"},
      "Action": "sts:AssumeRole"}]}'

aws iam attach-role-policy --role-name dms-vpc-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AmazonDMSVPCManagementRole

ステップ 2: DMS レプリケーションインスタンスを作成する(プライベート)

aws dms create-replication-subnet-group \
  --replication-subnet-group-identifier db2-reverse-repl-subnet-group \
  --replication-subnet-group-description "Private subnets for reverse replication" \
  --subnet-ids subnet-aaaaaaaaaa subnet-bbbbbbbbbb

aws dms create-replication-instance \
  --replication-instance-identifier db2-reverse-repl-instance \
  --replication-instance-class dms.c6i.xlarge \
  --allocated-storage 100 \
  --vpc-security-group-ids sg-dms-xxxxxxxxx \
  --replication-subnet-group-identifier db2-reverse-repl-subnet-group \
  --no-multi-az --engine-version 3.5.4 \
  --no-publicly-accessible

重要: --no-publicly-accessible フラグは非常に重要です。DMS インスタンスは、パブリック IP を持たないプライベートサブネットにデプロイされます。オンプレミスへの接続は、仮想プライベートゲートウェイ (VGW) を経由した AWS Direct Connect を通じて行われます。

ステップ 3: ソースエンドポイントを作成する (Amazon RDS for Db2)

aws dms create-endpoint \
  --endpoint-identifier rds-db2-source-for-reverse \
  --endpoint-type source --engine-name db2 \
  --server-name mydb2instance.xxxx.<aws-region>.rds.amazonaws.com \
  --port <db-port> --database-name PRODDB \
  --username dms_user --password '<your-password>' \
  --ibm-db2-settings '{"CurrentLsn":"scan","SetDataCaptureChanges":true}' \
  --extra-connection-attributes "StartFromContext=NOW;"

ステップ 4: ターゲットエンドポイントを作成する(オンプレミスの AIX Db2)

aws dms create-endpoint \
  --endpoint-identifier aix-db2-target-for-reverse \
  --endpoint-type target --engine-name db2 \
  --server-name <on-premises-db2-ip> \
  --port <db-port> --database-name PRODDB \
  --username dms_user --password '<your-password>' \
  --ibm-db2-settings '{"LoadTimeout":1200,"MaxFileSize":1048576,"WriteBufferSize":1024}'

ステップ 5: エンドポイント接続をテストする

# Test both endpoints (must return "successful")
aws dms test-connection \
  --replication-instance-arn arn:aws:dms:...rep:db2-reverse-repl-instance \
  --endpoint-arn arn:aws:dms:...endpoint:rds-db2-source-for-reverse

aws dms test-connection \
  --replication-instance-arn arn:aws:dms:...rep:db2-reverse-repl-instance \
  --endpoint-arn arn:aws:dms:...endpoint:aix-db2-target-for-reverse

ステップ 6: CDC のみのレプリケーションタスクを作成する

aws dms create-replication-task \
  --replication-task-identifier db2-reverse-cdc-task \
  --source-endpoint-arn arn:aws:dms:...endpoint:rds-db2-source-for-reverse \
  --target-endpoint-arn arn:aws:dms:...endpoint:aix-db2-target-for-reverse \
  --replication-instance-arn arn:aws:dms:...rep:db2-reverse-repl-instance \
  --migration-type cdc \
  --table-mappings '{"rules":[
    {"rule-type":"selection","rule-id":"1","rule-name":"exclude-sys",
     "object-locator":{"schema-name":"SYS%","table-name":"%"},
     "rule-action":"exclude"},
    {"rule-type":"selection","rule-id":"2","rule-name":"include-app",
     "object-locator":{"schema-name":"APP_SCHEMA","table-name":"%"},
     "rule-action":"include"}]}' \
  --cdc-start-position "scan"

レプリケーションタスクの主要な設定

注: これらの設定は、タスク作成時に --replication-task-settings の JSON パラメータで渡します。ステップ 6 の CLI コマンドは簡略化した形式を使用しているため、JSON の構成を自分の環境に合わせて調整してください。

ステップ 7: レプリケーションタスクを開始する

aws dms start-replication-task \
  --replication-task-arn arn:aws:dms:...task:db2-reverse-cdc-task \
  --start-replication-task-type start-replication

モニタリングと検証

レプリケーションタスクを開始した後は、次の主要な Amazon CloudWatch メトリクスをモニタリングします。次の表は、メトリクス、しきい値、推奨されるアクションを示しています。メトリクスがしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) で通知を送信する Amazon CloudWatch アラームを設定することもできます。

aws cloudwatch put-metric-alarm \
  --alarm-name db2-reverse-cdc-latency \
  --metric-name CDCLatencySource --namespace AWS/DMS \
  --statistic Average --period 300 --threshold 120 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 3 \
  --alarm-actions arn:aws:sns:<aws-region>:<aws-account-id>:dms-alerts

フェイルバック手順

オンプレミス環境へフェイルバックする必要がある場合は、ダウンタイムを最小限に抑え、データの整合性を維持するために次の手順に従います。

図 3: フェイルバックの実行手順

フェイルバック前のチェックリスト

1. CDC のレイテンシーがほぼゼロであることを確認する: CDCLatencySource と CDCLatencyTarget が ≈ 0
2. データ検証が合格することを確認する: テーブルが Validated 状態になっている
3. RDS へのアプリケーション書き込みを停止する: アプリケーション層を静止させる
4. CDC タスクが排出済みであることを確認する: CDCIncomingChanges = 0

フェイルバックの実行

1. リバース CDC タスクを停止します。
2. ターゲットの外部キー制約を再度有効化します。
3. ターゲットテーブルのトリガーを再度有効化します。
4. シーケンスを Amazon RDS for Db2 の現在の値にリセットします。
5. アプリケーションの接続文字列を、オンプレミスの Db2 (:) を指すように更新します。
6. オンプレミスのデータベースに対してスモークテストを実行します。
7. 任意: 再移行のために、フォワードレプリケーションを再度セットアップします。

リソースをクリーンアップする

このリバースレプリケーションは、移行の検証フェーズを支えるためだけに存在します。継続的な利用を想定したものではありません。アプリケーションが 2〜4 週間問題なく稼働し、関連チームが承認し、変更管理が承認した時点で廃止する計画を立てます。廃止後は、課金を止めるために DMS レプリケーションインスタンス、エンドポイント、関連する IAM ロールを削除します。

aws dms stop-replication-task --replication-task-arn arn:aws:dms:...
aws dms delete-replication-task --replication-task-arn arn:aws:dms:...
aws dms delete-endpoint --endpoint-arn arn:aws:dms:...
aws dms delete-replication-instance --replication-instance-arn arn:aws:dms:...

廃止後、延長した保持期間が不要になった場合は、Amazon RDS for Db2 インスタンスのアーカイブログ保持期間をデフォルト値に戻します。これにより、保持されたアーカイブログによるストレージコストを削減できます。

-- Revert archive log retention to default (1 hour)
CALL rdsadmin.set_archive_log_retention(?, 'PRODDB', '1');

制限事項

• DMS は IBM Db2 for LUW を CDC ソースとしてサポートします。このアーキテクチャでは、オンプレミスの AIX Db2 インスタンスをターゲットエンドポイントとして構成し、標準的な Db2 接続を通じて変更を受け取ります。
• DMS は Db2 LUW ターゲットに対して完全な大規模オブジェクト (LOB) モードをサポートしません。代わりに制限付き LOB モードを使用します。
• DMS は Db2 LUW ソースの Boolean データ型をサポートしません。
• DMS はレプリケーション中に DECFLOAT 列の変更を無視します。
• DMS は一部の DDL 操作(パーティション表の ALTER、RENAME COLUMN)をレプリケーションしません。これらはターゲットで手動で適用します。
• 多次元クラスタリング (MDC) 表の更新は、INSERT と DELETE のペアとして現れます。
• DMS はシーケンス値をレプリケーションしません。フェイルバック前に手動で同期します。
• CDC は Db2 の LOAD ユーティリティによるページレベルのロードをキャプチャしません。代わりに IMPORT を使用します。

コストに関する考慮事項

リバースレプリケーションの構成を計画する際は、次のコスト要因を考慮してください。

• DMS レプリケーションインスタンスの稼働時間(インスタンスクラスに基づく)。
• AWS Direct Connect 経由のデータ転送。
• アベイラビリティーゾーンごと、1 時間あたりの VPC エンドポイント料金。
• Amazon CloudWatch のメトリクスとアラーム。
• AWS Secrets Manager のシークレットストレージと API 呼び出し。

最新の料金については、DMS pricing page、AWS Direct Connect pricing ページ、AWS PrivateLink pricing ページを参照してください。これは一時的な移行の安全策であるため、検証期間の終了後にレプリケーション基盤を廃止することでコストを最小限に抑えられます。

ベストプラクティス

• 本番のカットオーバー前に、非本番環境でフェイルバック手順全体をドライランし、各ステップを検証します。
• データベースの認証情報は、自動ローテーションを有効にした AWS Secrets Manager に保存します。これにより、ハードコードされたパスワードをなくし、セキュリティ体制を強化できます。
• CDCLatencySource と CDCLatencyTarget メトリクスに Amazon CloudWatch アラームを設定し、レプリケーションの遅延が許容できるしきい値を超えたときに通知を受け取れるようにします。
• アーカイブログの保持期間は 24 時間以上を維持します。DMS が読み取る前に必要なログが削除されると、タスクは失敗し、新しい位置から再開する必要があります。
• レプリケーションが 48〜72 時間安定したら、DMS のログ詳細度を DETAILED_DEBUG から DEFAULT に下げ、Amazon CloudWatch Logs のコストを削減します。
• サイジングの目安として、c6i.xlarge インスタンスは 1 秒あたり 1,000 トランザクション (TPS) 未満を処理できます。ワークロードがこれを超える場合は、c6i.2xlarge にスケールアップします。
• ソースとターゲットのデータベース間で、独立した行数とチェックサムの比較による週次のデータ検証をスケジュールします。

まとめ

本記事では、プライベートのみのネットワーク上で AWS DMS を使い、Amazon RDS for Db2 からオンプレミスの AIX Db2 インスタンスへ CDC のみのリバースレプリケーションを構成する方法を説明しました。VPC インターフェイスエンドポイントをセットアップし、ソースとターゲットの Db2 エンドポイントを構成し、CDC のみのレプリケーションタスクを作成して、AWS Direct Connect 経由のデータフローを検証しました。この一時的なフェイルバック経路により、移行カットオーバー期間中の厳しい RTO および RPO 要件を満たしやすくなります。移行が安定した後は、リバースレプリケーションを廃止し、AWS 上の恒久的なアーキテクチャへ移行します。

著者について

この記事は Solutions Architect の 矢木 覚 が翻訳しました。