この記事は公開されてから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/