システムズのマイグレーションコラム
![](../menu/img/bnr_catalog.jpg)
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のメニューから準備をしていきます。
まずは、サブネットグループを作成します。
サブネットは、2つ以上のAZをまたがるように構成してください。
![DMSのサブネットグループの作成](img/vol24-image-111.png)
DMSのレプリケーションインスタンスの作成
レプリケーションインスタンスを作成していきます。
インスタンスクラスによってコストが大きく変わってきます。
今回は小規模なDBのため、最も小さい「t2.micro」を選択しました。
![DMSのレプリケーションインスタンスの作成](img/vol24-image-109.png)
ストレージサイズは、十分に余裕をもって設定しておく事を推奨します。
少ないと移行に時間がかかってしまったり、途中でエラーになる事があります。
マルチ AZ( 冗長構成 )がベストプラクティスですが、
コストも2倍かかるため、今回は外しました。
また、同一VPC内での移行のため、
パブリックアクセスのチェックも外しています。
VPN接続を構成していないオンプレから移行する場合などは、
チェックをつけてください。
![DMSのレプリケーションインスタンスの作成](img/vol24-image-113.png)
レプリケーションインスタンスのストレージは、
KMSのデフォルトキーによる暗号化が行われます。
独自のキーを使用したい場合は、「KMS マスターキー」の項目で選択できます。
メンテナンスは、レプリケーションインスタンスのOS更新を伴うため、
インスタンスが一時的にオフラインになり、終了後に移行が再開します。
(公式ドキュメントによると、メンテナンスは通常 年1~2回程度との事)
![DMSのレプリケーションインスタンスの作成](img/vol24-image-115.png)
![DMSのレプリケーションインスタンスの作成](img/vol24-image-118.png)
右下の「作成」を押して完了です。
DMSを使用したレコードの移行
DMSのエンドポイントの作成
エンドポイントの作成を行います。
エンドポイントは、レプリケーションインスタンスが、
移行元DB(ソース)と、移行先DB(ターゲット)に接続するために必要です。
まずは、ソースエンドポイントに「oracle11g」の接続設定を行います。
「□RDS DBインスタンスの選択」に、
何故かoracle11gのインスタンスが表示されなかったので、
エンドポイント設定を手入力しました。
![DMSのエンドポイントの作成](img/vol24-image-141.png)
最後の項目で、エンドポイント接続のテストがありますが、
SCTの時と同様に、セキュリティグループの設定が許可されていないと、
接続が行えない事に注意です。「テストの実行」を押す前に、セキュリティグループ設定を確認します。
![DMSのエンドポイントの作成](img/vol24-image-142.png)
レプリケーションインスタンスのIPアドレスを直接設定しても良いのですが、
今回はセキュリティグループを指定したいと思います。
![DMSのエンドポイントの作成](img/vol24-image-143.png)
セキュリティグループの編集画面で、
ソースに「sg」と入力すると、許可するセキュリティグループを選択できます。
![DMSのエンドポイントの作成](img/vol24-image-144.png)
これはそのセキュリティグループを設定中のインスタンスからの接続を許可するという意味です。
セキュリティグループ設定後、エンドポイント接続のテストを行います。
![DMSのエンドポイントの作成](img/vol24-image-145.png)
成功するとステータスが「successful」に変わります。
![DMSのエンドポイントの作成](img/vol24-image-146.png)
同様にターゲットエンドポイントも「postgres11」の接続設定を行います。
![DMSのエンドポイントの作成](img/vol24-image-147.png)
こちらも同様に接続テストを行い、「successful」となる事を確認します。
![DMSのエンドポイントの作成](img/vol24-image-148.png)
次は、作成したエンドポイントを選択して詳細画面を表示して、
「スキーマ」タブに移動します。
![DMSのエンドポイントの作成](img/vol24-image-149.png)
右側のリフレッシュアイコンを押すと、
スキーマの更新を開始します。
![DMSのエンドポイントの作成](img/vol24-image-150.png)
![DMSのエンドポイントの作成](img/vol24-image-151.png)
少し時間をおいてから画面更新をかけると、
スキーマが表示されるようになりました。
![DMSのエンドポイントの作成](img/vol24-image-152.png)
PostgreSQLのエンドポイントも同様にスキーマを更新します。
![DMSのエンドポイントの作成](img/vol24-image-153.png)
読み込めました。これでエンドポイントの準備は完了です。
移行タスクの作成
最後にデータの移行タスクを作成します。
左側のメニューから「データベース移行タスク」を選択して、
「タスクの作成」を押します。
![移行タスクの作成](img/vol24-image-168.png)
DMSの移行タイプは、以下の選択肢があります。
1.FullLoad
2.CDC(Change Data Capture)
3.FullLoad+CDC
1.は今の断面のデータのみをロードして終わりです。
選択する理由は、もう更新されないDB(静止断面)を移行したい時です。
2.は変更差分のみのデータをロードし続けます。
選択する理由は、既に(DMSや別のプロダクトで)移行済のDBに対して、差分のみを適用していきたい場合です。
3.は、今の断面データをロードした後、変更差分をロードし続けます。
運用中のDBを移行する場合は、3.を選ぶケースが多いと思いますが、
今回は1.を選びます。
「検証の有効化」にチェックをつけると、
移行元と移行先データのレコードを比較して、不一致がある場合は表示してくれますが、
データ量によっては移行にかかる時間が大幅に増えてしまう場合があるので、
最初はチェックを外して実行してみた方が良いです。
![移行タスクの作成](img/vol24-image-163.png)
テーブルマッピングは、移行対象とするテーブルのルールを設定します。
下記の例の場合、「TESTUSER」スキーマの全テーブルを移行します。
あるテーブルだけ移行したい場合や、除外したい場合など柔軟に複数設定する事ができます。
もしPostgreSQL側にテーブルが存在しない場合、
DMSは自動的にテーブルを作成します。
![移行タスクの作成](img/vol24-image-157.png)
変換ルールを指定すれば、移行先のスキーマ・テーブル・列に対して、
一定のルールで名前を変更したり、不要になった列の削除を行いつつ移行できます。
Oracle はデフォルトでは、データディクショナリに大文字でメタデータを保存しますが、PostgreSQL は小文字で保存するため、ここでスキーマをマッピングしてやります。
テーブルも同様ですが、Oracle側で大文字、小文字のテーブルが混在している場合は、
DMSが検出した通りに移行する事が推奨されています。
詳しくはこちらをご参照ください。
![移行タスクの作成](img/vol24-image-169.png)
詳細設定も今回はデフォルトにしておきます。
テーブル数が多い場合などは、これらのパラメータをチューニングする事で移行時間を大幅に短縮する事もできます。
![移行タスクの作成](img/vol24-image-158.png)
![移行タスクの作成](img/vol24-image-159.png)
「タスク作成」を押すと、設定したルールに基づいて移行がすぐに実行されます。
即時実行したくない場合は、上の方にある「□作成時にタスクを開始」のチェックを外してください。
![移行タスクの作成](img/vol23-image-160.png)
タスクを作成すると、
一覧画面から状態を確認する事ができます。
![移行タスクの作成](img/vol24-image-164.png)
データが少ないので、1分ほどでロード完了しました。
![移行タスクの作成](img/vol24-image-167.png)
確認
移行先DB(PosgreSQL)に、
テーブル、ビュー、ファンクション、レコードがそれぞれ移行出来ているか確認してみます。
-- テーブルの確認
SELECT * FROM testuser.emp;
-- ビューの確認
SELECT * FROM testuser.test_view;
-- ファンクションの確認
SELECT testuser.tesf(3);
![確認](img/vol24-image-173.png)
![確認](img/vol24-image-172.png)
![確認](img/vol24-image-174.png)
これで完了です。
タスク実行中にエラーが発生した場合
今回はシンプルな構成のため問題なく移行できましたが、
実際の大規模なDBの移行タスク実行中に、エラーが発生する事があります。
その場合は、まずは移行タスクのログ出力をする事を検討してください。
但し、膨大なログになる可能性があるため、必ずCloudWatchの料金説明を読んでから行ってください。
![タスク実行中にエラーが発生した場合](img/vol24-image-176.png)
それと、タスクの詳細画面の方にもエラー内容が表示されている事があります。
こちらも合わせて確認するようにします。
![タスク実行中にエラーが発生した場合](img/vol24-image-177.png)
私が実際に発生した事があるエラーは、外部キー制約違反エラーと、
レプリケーションインスタンスのリソース不足によるエラーです。
DMSはアルファベット順にテーブルをインポートするため、
場合によっては、親テーブルよりも先に子テーブルを先にインポートしようとして、
外部キー制約違反となる事があります。
また、レプリケーションインスタスのリソースを低めに設定した事が原因で、
リソースが不足してしまい、数時間かかる移行タスクをやり直した事もあります。
それぞれリンク先のAWS公式ページに解決方法が記載されていますので、
必要に応じてご参照ください。
同じテーブルでエラーが発生する場合は、
そのテーブルだけ移行するようにフィルタリングした移行タスクを作成して、
検証と解決を行いながら進めるのが効率的です。
最後に
今回は、AWSの純正ツールとサービスを利用して、
簡単にOracleから、PostgreSQLに移行する事ができました。
多少の制約があったり、サービスの利用コストは発生するものの、
人が手で行うよりもはるかに低コストかつ短期間で実現できる事がわかりました。
SCT/DMSについては、今回の記事ではあまり深く掘り下げませんでしたが、
次回以降で、移行タスクのチューニングやCDCなどについての内容も書いていきたいと思います。
AWSで実践!OracleデータベースのDBマイグレーション 連載一覧
- Vol.25
- AWSで実践!DBマイグレーション時のRDS利用コスト削減
~ AWSのサービス 自動起動・停止を活用し使わない時間の料金を削減する ~ - Vol.24
- AWSで実践!異種間DBマイグレーション(Oracle to PostgreSQL編)
~ DMSでレコードを移行する ~ - Vol.23
- AWSで実践!異種間DBマイグレーション(Oracle to PostgreSQL編)
~ SCTでメタデータを移行する ~ - Vol.22
- AWSで実践!RDSへのDBマイグレーション(Oracle to Oracle編)
~ Data Pumpで移行する ~ - Vol.21
- AWSで実践!RDSへのDBマイグレーション(Oracle to Oracle編)
~ SQL Developerで移行する ~
↓↓ システムズのAWS DBマイグレーションに関する、Webページはこちらをご覧ください。 ↓↓