レガシー・マイグレーションのノウハウ＆ドゥハウ。 計画時サービスからメインサービスまでシステムズの業務をご案内。

Vol.24　OracleからPostgreSQLへの異種間 DB移行　(その2)

2020.03.31

AWSで実践！異種間DBマイグレーション（Oracle to PostgreSQL編）

DMS(AWS Database Migration Service)を使用したレコードの移行

Database Migration Service(以下、DMS)は、AWSが提供しているデータベースの移行サービスです。
AWS DMS は、広く普及しているほとんどの商用データベースとオープンソースデータベース間のデータ移行で利用が可能で、Oracle から Oracle のような同種のデータベース間の移行も、Oracle またはMicrosoft SQL から Amazon Aurora といった異なるデータベースプラットフォーム間の移行もサポートしています。

本項では、AWS DMSを使用したテーブル内のレコードの移行手順について紹介していきます。

準備（DMS活用編）

DMSのサブネットグループの作成

AWSコンソールで、DMSのメニューから準備をしていきます。
まずは、サブネットグループを作成します。

サブネットは、２つ以上のAZをまたがるように構成してください。

DMSのレプリケーションインスタンスの作成

レプリケーションインスタンスを作成していきます。

インスタンスクラスによってコストが大きく変わってきます。
今回は小規模なDBのため、最も小さい「t2.micro」を選択しました。

ストレージサイズは、十分に余裕をもって設定しておく事を推奨します。
少ないと移行に時間がかかってしまったり、途中でエラーになる事があります。

マルチ AZ（ 冗長構成 ）がベストプラクティスですが、
コストも2倍かかるため、今回は外しました。

また、同一VPC内での移行のため、
パブリックアクセスのチェックも外しています。

VPN接続を構成していないオンプレから移行する場合などは、
チェックをつけてください。

レプリケーションインスタンスのストレージは、
KMSのデフォルトキーによる暗号化が行われます。
独自のキーを使用したい場合は、「KMS マスターキー」の項目で選択できます。

メンテナンスは、レプリケーションインスタンスのOS更新を伴うため、
インスタンスが一時的にオフラインになり、終了後に移行が再開します。
（公式ドキュメントによると、メンテナンスは通常 年１～２回程度との事）

右下の「作成」を押して完了です。

DMSを使用したレコードの移行

DMSのエンドポイントの作成

エンドポイントの作成を行います。
エンドポイントは、レプリケーションインスタンスが、
移行元DB（ソース）と、移行先DB（ターゲット）に接続するために必要です。

まずは、ソースエンドポイントに「oracle11g」の接続設定を行います。

「□RDS DBインスタンスの選択」に、
何故かoracle11gのインスタンスが表示されなかったので、
エンドポイント設定を手入力しました。

最後の項目で、エンドポイント接続のテストがありますが、
SCTの時と同様に、セキュリティグループの設定が許可されていないと、
接続が行えない事に注意です。「テストの実行」を押す前に、セキュリティグループ設定を確認します。

レプリケーションインスタンスのIPアドレスを直接設定しても良いのですが、
今回はセキュリティグループを指定したいと思います。

セキュリティグループの編集画面で、
ソースに「sg」と入力すると、許可するセキュリティグループを選択できます。

これはそのセキュリティグループを設定中のインスタンスからの接続を許可するという意味です。

セキュリティグループ設定後、エンドポイント接続のテストを行います。

成功するとステータスが「successful」に変わります。

同様にターゲットエンドポイントも「postgres11」の接続設定を行います。

こちらも同様に接続テストを行い、「successful」となる事を確認します。

次は、作成したエンドポイントを選択して詳細画面を表示して、
「スキーマ」タブに移動します。

右側のリフレッシュアイコンを押すと、
スキーマの更新を開始します。

少し時間をおいてから画面更新をかけると、
スキーマが表示されるようになりました。

PostgreSQLのエンドポイントも同様にスキーマを更新します。

読み込めました。これでエンドポイントの準備は完了です。

移行タスクの作成

最後にデータの移行タスクを作成します。
左側のメニューから「データベース移行タスク」を選択して、
「タスクの作成」を押します。

DMSの移行タイプは、以下の選択肢があります。
１．FullLoad
２．CDC(Change Data Capture)
３．FullLoad+CDC

１．は今の断面のデータのみをロードして終わりです。
選択する理由は、もう更新されないDB(静止断面)を移行したい時です。

２．は変更差分のみのデータをロードし続けます。
選択する理由は、既に（DMSや別のプロダクトで）移行済のDBに対して、差分のみを適用していきたい場合です。

３．は、今の断面データをロードした後、変更差分をロードし続けます。

運用中のDBを移行する場合は、３．を選ぶケースが多いと思いますが、
今回は１．を選びます。

「検証の有効化」にチェックをつけると、
移行元と移行先データのレコードを比較して、不一致がある場合は表示してくれますが、
データ量によっては移行にかかる時間が大幅に増えてしまう場合があるので、
最初はチェックを外して実行してみた方が良いです。

テーブルマッピングは、移行対象とするテーブルのルールを設定します。
下記の例の場合、「TESTUSER」スキーマの全テーブルを移行します。

あるテーブルだけ移行したい場合や、除外したい場合など柔軟に複数設定する事ができます。

もしPostgreSQL側にテーブルが存在しない場合、
DMSは自動的にテーブルを作成します。

変換ルールを指定すれば、移行先のスキーマ・テーブル・列に対して、
一定のルールで名前を変更したり、不要になった列の削除を行いつつ移行できます。

Oracle はデフォルトでは、データディクショナリに大文字でメタデータを保存しますが、PostgreSQL は小文字で保存するため、ここでスキーマをマッピングしてやります。

テーブルも同様ですが、Oracle側で大文字、小文字のテーブルが混在している場合は、
DMSが検出した通りに移行する事が推奨されています。
詳しくはこちらをご参照ください。

詳細設定も今回はデフォルトにしておきます。
テーブル数が多い場合などは、これらのパラメータをチューニングする事で移行時間を大幅に短縮する事もできます。

「タスク作成」を押すと、設定したルールに基づいて移行がすぐに実行されます。
即時実行したくない場合は、上の方にある「□作成時にタスクを開始」のチェックを外してください。

タスクを作成すると、
一覧画面から状態を確認する事ができます。

データが少ないので、1分ほどでロード完了しました。

確認

移行先DB(PosgreSQL）に、
テーブル、ビュー、ファンクション、レコードがそれぞれ移行出来ているか確認してみます。

-- テーブルの確認
SELECT * FROM testuser.emp;
-- ビューの確認
SELECT * FROM testuser.test_view;
-- ファンクションの確認
SELECT testuser.tesf(3);

これで完了です。

タスク実行中にエラーが発生した場合

今回はシンプルな構成のため問題なく移行できましたが、
実際の大規模なDBの移行タスク実行中に、エラーが発生する事があります。

その場合は、まずは移行タスクのログ出力をする事を検討してください。
但し、膨大なログになる可能性があるため、必ずCloudWatchの料金説明を読んでから行ってください。

それと、タスクの詳細画面の方にもエラー内容が表示されている事があります。
こちらも合わせて確認するようにします。

私が実際に発生した事があるエラーは、外部キー制約違反エラーと、
レプリケーションインスタンスのリソース不足によるエラーです。

DMSはアルファベット順にテーブルをインポートするため、
場合によっては、親テーブルよりも先に子テーブルを先にインポートしようとして、
外部キー制約違反となる事があります。

また、レプリケーションインスタスのリソースを低めに設定した事が原因で、
リソースが不足してしまい、数時間かかる移行タスクをやり直した事もあります。

それぞれリンク先のAWS公式ページに解決方法が記載されていますので、
必要に応じてご参照ください。

同じテーブルでエラーが発生する場合は、
そのテーブルだけ移行するようにフィルタリングした移行タスクを作成して、
検証と解決を行いながら進めるのが効率的です。

最後に

今回は、AWSの純正ツールとサービスを利用して、
簡単にOracleから、PostgreSQLに移行する事ができました。

多少の制約があったり、サービスの利用コストは発生するものの、
人が手で行うよりもはるかに低コストかつ短期間で実現できる事がわかりました。

SCT/DMSについては、今回の記事ではあまり深く掘り下げませんでしたが、
次回以降で、移行タスクのチューニングやCDCなどについての内容も書いていきたいと思います。