この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
初めに
前回の続きとして、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検証シリーズをここまで完了させて頂きます。
このブログはどなたの助けになると幸いです。
ここまで読んでいただき、誠にありがとうございました。