サイトアイコン 協栄情報ブログ

AWS DMSを使ってみた③データ移行


この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。

初めに

前回の続きとして、今日は実際のデータ移行に入ります。

前回:AWS DMSを使ってみた⓶移行タスクの作成
    https://cloud5.jp/aws-dms-20220519/

⓷データ移行

Step1 移行前評価レポート確認

さて、データ移行を進む前に、移行前評価の結果を確認します。
ここが問題ないことは移行の大前提なので。

すべて合格なので、問題なさそうですね。

続いて、レポートを見てみます。
なるほど、バケットの下にレポート単位でフォルダを分けています。フォルダ名はレポートIDに一致し、ランダムで作成されますね。

確認したら特に問題ないようでしたらので、ほんちゃの移行に入りましょう。

Step2 移行開始

異種RDSの移行のため、ソースとターゲットのスキーマ構成が違うことで移行に失敗する可能性があります。基本的に、移行前にDDLやSCTツールを使って、ターゲットRDSにスキーマ、移行テーブルなどを作成する必要があります。
ただし、今回の場合ですと、テストソースはOracleとpostgreの共通の構成で作成したので、事前にターゲットRDSにスキーマ作成しなくても移行タスク中に作ってもらえます。

ステータスが「ロード完了」になりました。
データ量が少ないので、すぐ終わりましたね。
エラーがなく無事終了することはありがたいです。

Step3 移行確認

まずは、テーブル統計から確認します。

テーブル統計で移行したテーブルと行数を確認できます。
問題なさそうですね。テストソースはすべて移行されています。

そして、エンドポイントから最新のスキーマ情報を確認できますので、ターゲットRDSのスキーマ情報を確認しましょう。

何もないようなので、右上の更新ボタンを押してみましょう。

「スキーマを更新する」を押しますと、スキーマリストを取得できます。ここから少し時間がかかります。

更新できました!スキーマがありましたね!

確実にデータが移行されたことの確認はもちろんターゲットRDSに接続して、テーブルとデータまでの確認は必要とはありますが、ここで手順を割愛します。

Step4 移行ログ確認

移行として完了していますが、移行の中にエラーが発生していないかはログで確認します。

なるほど、移行ログのロググループはレプリケーションインスタンス単位で作成されていますね。タスク単位ではないので、すべてのタスクログはこのロググループに保存されますね。

ログストリームを確認しましたら、infoしか出ていなく、エラーがないですね。

CLIでDMS操作

CLIでDMSを操作したい時に、以下の条件を満たす必要があります。

・ロール作成

まず、DMSユーザーズガイドに記載がありました、「dms-vpc-role」 と 「dms-cloudwatch-logs-role」の作成が必要です。

https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Security.html#CHAP_Security.APIRole

ロール「dms-vpc-role」
 ーポリシー「AmazonDMSVPCManagementRole」

ロール「dms-cloudwatch-logs-role」
 ーポリシー「AmazonDMSCloudWatchLogsRole」

・VPCエンドポイント

そして、サービス間の連携としてDMSのエンドポイントが作成が必要です。

終わりに

エラーなく移行できたことを確認できました!
ここまで移行は完了となります!

次回からおまけとして、SCT使用した移行をやってみたいと思います!

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

モバイルバージョンを終了