AWS Database Migration ServiceのDB移行の設定

DMS構築

データベース移行ツールのDMSは、DBのデータを含めた移行を自動化するツールです。
構成としては、「レプリケーション・インスタンス」(サーバーインスタンスタイプ)と「サーバレスレプリケーション」(サーバレスタイプ)があります。当記事では、構成がしやすいインスタンスタイプのフルロード(全データ移行)を例に説明します。続編としてAWS DMS CDC(差分反映構成)、AWS DMS サーバレスレプリケーションの記事があります。これらの記事では、ソースがOracle、ターゲットがRDS for PostgreSQLの前提で解説します。
当検証で利用した移行用サンプルのDBの構成については、以下の記事をご参照ください。
テスト用RDS for Oracleの管理と操作
テスト用RDS for PostgreSQL

DMSの主要な設定

DMSの設定のうち、当構成において重要な要素は以下の通り。
①エンドポイント・・・対象DB(ソースとターゲット)への接続を定義
➁サブネットグループ・・・DMSのネットワーク定義
③レプリケーションインスタンス・・・DMSの移行サーバを含めたEC2インスタンス
④データベース移行タスク・・・③て実行する移行の方式を定義したタスク
上記以外にも、構成や問題判別のために必要な設定(ログ出力用のS3、CloudWatch、権限設定のためのIAMの定義等)があります。各手順中で記載します。

エンドポイント

まず、変換前後のDBへの接続をエンドポイントに設定します。

ソースDBへの接続

DMSのメニューの「エンドポイント」から「エンドポイントの作成」を選択し、ソースエンドポイントを定義します。

入力が終わったら、「エンドポイントの作成」で保管します。
エンドポイントの接続テストは、後述する「レプリケーションインスタンス」が利用できる場合に実行できます。

    接続先のDB固有の確認や設定も必要です。[Using an Oracle database as a source for AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.Oracle.html)を参照してください。

ターゲットDBへの接続

DMSのメニューの「エンドポイント」から「エンドポイントの作成」を選択し、ターゲットエンドポイントを定義します。

入力が終わったら、「エンドポイントの作成」で保管します。
接続先のDB固有の確認や設定も必要です。Using a PostgreSQL database as a target for AWS Database Migration Serviceを参照してください。

サブネットグループ

DMSのメニューの「サブネットグループ」から「サブネットグループの作成」を選択し、名前、DMSから接続するDBが入ったサブネット、VPCを指定します。

差し替え予定 変更画面→新規登録画面

レプリケーションインスタンス

DMSのメニューの「データを移行する」から「レプリケーションインスタンス」を選択し、レプリケーションインスタンスの情報を入力します。

できるまで、しばらく待ちます。(記事の環境では15分)

エンドポイントの接続テスト

エンドポイント作成時にテストをしていなかった場合は、エンドポイントの設定かテストを実行します。

データベース移行タスク

DMSのメニューの「データを移行する」から「データベース移行タスク」を選択し、「タスクの作成」を押し、データベース移行タスクを作成します。

データ移行のフルロード

作成されるまで待機します。

比較的すぐに終わります。(1-2分)

タスクを開くと「概要の詳細」等が確認できます。

移行タスク作成の画面でスキップした「移行前評価」はここで作成ます。
DMS設定の流れを説明するため、実は前提として接続先のDBに対する追加の設定が必要で、これらの設定や確認が不足しているとエラーが発生する。

前提の設定

このケースでの設定内容については、投稿では細かく触れず、リンクの掲載に留めておく。

ソースDB Oracleの確認と変更

Using a PostgreSQL database as a target for AWS Database Migration Service

ターゲットDB RDS for PostgreSQLの確認と変更

Using an Oracle database as a source for AWS DMS

移行前評価

前提の確認は、前述のリンクに記載の事項を確実に設定できれば良いのだが、細かい内容の確認には、移行前評価を利用すると便利である。

移行前評価の設定

移行前評価はログ出力にS3を使うため、S3バケットの定義、DMSがS3に書き込むためのIAMロールを設定の上、DMSに接続する必要がある。

S3バケットの作成

管理コンソールからS3に移動し、「バケットの作成」します。

DMSで書き込むためのバケットを作成します。

必要に応じて、フォルダーを作成しておきます。

IAMの設定

AWSコンソールからIAMを選択

ポリシーの作成

IAM > ポリシーからポリシーを作成します。
S3に書き込めるポリシーを作成します。

この画面では、全てのリソースにフルアクセスのポリシーを作ってます。ご利用になる環境に合わせて、細かく設定してください。

IAMロールの作成

IAM > ロールからロールを作成します。

AWSのサービスから「DMS」のサービス、「DMS」のユースケースを選択、

前述のポリシーを追加します。

ロール名を指定して保管します。

データベース移行タスクの変更

DMS移行タスク

DMSの移行タスクを開きます。

移行前評価の実行と確認

利用中の移行タスクを選択し、「移行前評価の作成」を選択します。

移行前評価で使うS3バケットのパスとIAMロールを設定し、
移行用の評価を選択します。Prerequisiteと必須は追加しておきます。

移行前評価実行中。

移行前評価が終わった例。サマリー「1 failed 19 passed」が表示されている。

エラーメッセージの対応例

サマリーをクリックすると、各評価の内容が表示されます。

エラーになっているメッセージをクリックすると対応方法が書かれており、これを元に対応する。

ソース Oracle DBの拡張属性

alter table table_name add supplemental log data (PRIMARY KEY) columns;
exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');
exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');

アーカイブログの時間

RDS Oracle のアーカイブログ保持を検証
Archived logs retention period is set to value lower than 24 hours, It is recommend to ensure that the source database is configured to retain archived logs for a sufficient time 24 hours is usually enough.

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

当記事の検証の環境の都合上、ソースのOracleはRDS for Oracleで構築しているため、この場合は操作手順が多少異なります。

CDC対応テーブル毎のエラー

通常サーバ

GRANT READ ON DIRECTORY ONLINELOG_DIR TO dms_user;
GRANT READ ON DIRECTORY ARCHIVELOG_DIR TO dms_user;

RDS用コマンド

exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;
exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;

CDC対応テーブル毎のエラー

プライマリまたは一意のキーがあるテーブルで補足ロギングが有効になっているかどうかを検証

ALTER TABLE TBLnnnn ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

すべての列に補足ログが必要かどうかを検証します

ALTER TABLE TBLnnnn ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

対応を実施した後、移行前評価を実施し、全部がpassedになるまで対応する。

データベース移行タスクの実行

DMSのメニューの「データを移行する」から「データベース移行タスク」を選択し、作成した移行タスクを開き、「アクション」→「再起動/再開」でタスクを実行します。

しばらく待機します。

終了とデータ反映の確認

検証環境では、移行データが少なかったため、1時間程度で終了しましたが、データが多い場合、もっとかかります。レプリケーションインスタンスの性能を上げればある程度解消されます。

移行タスクが正常に実行された場合、「テーブル統計」で各テーブルのデータ移行状況が確認できます。

また、ログを確認し、エラーが発生してないことも確認できます。
(実行したタスクの「概要の詳細」タブの「タスクログ」にあるCloudWatchログを表示のリンクより遷移

移行後の確認

移行後には、ターゲットDBにデータが移行されていることを、コマンドラインツール等で確認します。
筆者は、ツール(A5SQL)を使って確認した。