AWS DMSを使ってみた⑤継続レプリケート(CDC)で移行

初めに

前回の続きとして、SCTで変換したスキーマにCDCの移行タスクでデータ移行します。

前回：AWS DMSを使ってみた⓸SCTツールでスキーマ移行
　　　 https://cloud5.jp/aws-dms-20220521/

検証の流れ的に、初心者に誤解しやすそうなので、一応、SCTの使用はCDC利用可否に関連性がないことを説明します。

【スキーマ変換方式】
・DDL作成
・SCTツール(でDDL作成)

【データ移行の方式】
・全ロード
・継続レプリケート（CDC）

前章で説明しましたが、データベースの移行は、スキーマ移行してからデータ移行する方式となっています。⓵章～⓷章までは、「DDL作成のスキーマ変換方式」+「全ロードのデータ移行方式」でDMS移行を検証しましたので、⓸章からは「SCTツール」＋「CDC」でDMS移行を検証したいとのことです。別にDDL+CDCでも移行可能です。実際のお客様の要件に合わせて検討にしましょう。

⓹継続レプリケート(CDC)で移行

エンドポイント、レプリケーションインスタンス、移行スキーマなどのリソースは、前の検証で作成完了していますので、そのまま利用してCDC検証を行います。

Step1 CDCの移行タスク作成

移行タイプ「データ変更のみをレプリケートする」を選択する。

ソースがOracleのため、継続レプリケートには事前設定が必要ですね。それは、タスク作成が終わったら設定しましょう。

他の設定は全ロードとそっくりだから、割愛します。
全ロード：⓶移行タスクの作成

Step2 ソースRDS(Oracle)のパラメータ設定

・サプリメンタル有効化の設定

サプリメンタル有効化はプライマリキー、インデックスによって設定が違うので、具体的の設定方法は以下に参照できます。

https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.Oracle.html
ー　サプリメンタル ロギングの設定

まずは、データベースレベルで有効に設定します。

SQL> SELECT supplemental_log_data_min FROM v$database;

SQL> exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');

そして、テーブル単位で有効化に設定します。
SQL> ALTER TABLE dmsuser2.dmstable2 ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

・アーカイブログ設定

アーカイブログの保持期間を24時間に設定する。

SQL> exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours', 24);

Step3 CDC移行

準備作業完了しているので、タスクを起動します。

少し時間を経ちましたら、ステータスが「レプリケーション進行中」になりました。
テーブル統計で見ると、スキーマとテーブルは導入されていることを確認できました。

それで、ソースRDSに100件のテストデータを挿入します。

コンソールから確認すると、100件の挿入がありました！

コマンドで確認しても同じですね。
良かった、それで成功です！

終わりに

すべてのデータ移行方式を検証し、問題なく手順を確認できましたので、DMS検証シリーズをここまで完了させて頂きます。
このブログはどなたの助けになると幸いです。
ここまで読んでいただき、誠にありがとうございました。