Google Cloud の DMS を使って Oracle Database から Cloud SQL にデータ移行する
はじめに
こんにちは、クラウドエース第一開発部に所属している荒木です。
最近の動向として、コスト削減やベンダーロックインの回避を理由に、Oracle データベースからオープンソースのデータベースへ移行するケースが増えています。また、オンプレミス環境で稼働しているデータベースをクラウド環境のマネージドサービスへ移行して、スケーラビリティ、高可用性、障害復旧、管理工数削減などのメリットを享受しようとする流れも活発化しています。
今回は、Database Migration Service（以下 DMS）を使用して、Oracle データベースを Google Cloud 環境へ移行する方法を検証したので、その内容を画像を用いながら具体的に説明します。実際に私が移行作業をする中で直面したエラーとその解決策も紹介していますので、皆さんが DMS で移行する際の一助となれば幸いです。
説明すること
- DMS の概要
- 汎用的な DMS の使用手順
- 移行の途中で直面したエラーとその解決策
説明しないこと
- ケースに合わせた移行プラクティス
- データベース設計
- 移行元、移行先データベースの選定・構築
DMS とは
DMS は、データベースを異なるプラットフォームや環境間へ移行するためのサービスです。例えば、オンプレミス環境の Oracle データベースを Google Cloud 環境へ移行する際に使用します。
DMS を使用すると、連続的なデータ同期（CDC）によってダウンタイムを最小限に抑えながら、移行することができます。また、移行作業の間にもデータベースを稼働させることができ、システムはデータベースの移行を行っていることを意識する必要がないといったメリットもあります。
移行手順
0. 移行前の準備
検証するにあたり、移行元のデータベースとして Google Cloud の Compute Engine インスタンス上に Oracle Database XE を構築し、サンプルデータをインストールしました。
- Oracle Database XE の構築手順 (当社のブログ記事)：https://zenn.dev/cloud_ace/articles/444ad5aad95121
- サンプルデータ：https://github.com/oracle-samples/db-sample-schemas/releases/tag/v23.2
また、移行先のデータベースとして Cloud SQL for PostgreSQL インスタンスを作成しました。このときの注意として、DMS と外部 IP アドレスで接続する場合は Cloud SQL Auth Proxy を使用する必要があり、内部 IP アドレスを使用して接続する場合は Private Service Connect（以下 PSC）を使用する必要があります。今回の検証では移行元と移行先がどちらも Google Cloud 上にあるため、PSC を使用して内部 IP アドレスで DMS と接続しました。
- PSC が有効なインスタンスの作成：https://cloud.google.com/sql/docs/postgres/configure-private-service-connect?hl=ja#create-cloud-sql-instance-psc-enabled
1. プライベート接続構成の作成
Google Cloud コンソールで [データベースの移行] > [プライベート接続] に移動します。ここで API の有効化を求められた場合は有効化してください。
プライベート接続構成を作成すると、VPC ネットワークと DMS のプライベートネットワーク間でピアリング接続が定義されます。これによって、DMS は内部 IP アドレスを介して各データベースが属している VPC ネットワークと通信できるようになります。この通信では、専用接続が確立されるため、他の Google Cloud ユーザと接続を共有することはなく、安全にデータの移行を行うことができます。
移行先データベースと DMS リソースが同じリージョンにある必要があるため、接続構成の作成時にはリージョン指定に注意しましょう。また、今回は内部 IP アドレスを介して移行するため、移行元データベースがある VPC（default）を選択し、他のサブネットと重複しない IP アドレス範囲を設定しました。
ちなみに、ここで設定した IP アドレス範囲が他の予約済み IP アドレス範囲と重複しているとエラーが出ます。
2. 接続プロファイルの作成
プライベート接続構成の作成が完了したら、[データベースの移行] > [接続プロファイル] に移動します。ここでは DMS がデータベースに接続するためのユーザ情報やネットワーク設定を登録します。
まずは移行元データベースへの接続プロファイルを作成します。ユーザ名とパスワードは、サンプルスキーマをインストールしたときに作成したユーザの情報を入力しました。
暗号化のタイプは「なし」にします。
接続方法は「プライベート接続（VPC ピアリング）」を選択し、プライベート接続構成は先ほど作成したものを選択します。
接続プロファイルの作成を完了する前にテストを実行し、成功することを確認します。テストに失敗した場合、接続に使用するユーザ情報やネットワーク設定が正しいか確認してください。
次に同様の手順で移行先データベースの接続プロファイルを作成します。今回は内部 IP アドレスで PSC を使用して接続するため、「ホスト名または IP」の表示が特殊です。
ここでも接続プロファイルの作成を完了する前にテストを実行し、成功することを確認します。
3. コンバージョンワークスペースの作成
DMS ではコンバージョンワークスペースという機能によって、移行元データベースのスキーマやコードオブジェクトの変換を自動化することが可能です。
[データベースの移行] > [コンバージョン ワークスペース] に移動し、コンバージョンワークスペースを新規作成します。
移行元データベースのスキーマのスナップショットを PULL したら、移行対象のスキーマをすべて選択し、[変換と続行] をクリックします。
コンバージョンワークスペースの作成が完了すると、左ペインにスキーマのリストと変換ステータスが表示されます。
右ペインには対象のオブジェクトと確認すべき理由の詳細が表示されます。
コンバージョンワークスペースの変換はすべて自動で行われますが、変換結果を GUI のエディター上で確認・変更することも可能です。
変換結果を確認し、問題なければ [対象に適用] を選択して、移行先データベースに適用します。
4. 移行ジョブの作成
ここまでの作業で、移行に必要な接続設定と互換対応が完了しました。ここからは実際にデータを移行するステップに入ります。
[データベースの移行] > [移行ジョブ] に移動し、移行ジョブを新規作成します。
移行ジョブの下書きは自動で保存されるため、移行ジョブの作成で長時間詰まってしまいセッションが切れた場合にも、最初からやり直すことなく再開できて安心です。
移行先と移行元のデータベースを選択します。
移行元データベース用の接続プロファイルを選択します。
移行先データベース用の接続プロファイルを選択します。
先ほど作成したコンバージョンワークスペースを選択し、移行対象のオブジェクトをすべて選択します。
最後の確認画面で移行ジョブのテストを実行することができます。
テストを実行し、成功することを確認します。
今回の検証で私が直面したエラーとその対処法をご紹介します。
DMS が使用する Oracle XE ユーザの権限不足
エラー内容：
We're missing the necessary permissions to read from the source. Grant the appropriate privileges to the user account that is used to connect to your database, and try again.
対処法：
移行元の Oracle Database XE に接続し、DMS が使用するユーザに読み取り権限を付与することで解決しました。
トリガーに関する警告
エラー内容：
Triggers enabled in the destination database might result in data differences between the source and destination. Allow DMS to skip triggers by assigning the REPLICATION option to the migration user account on the destination database or alternatively drop all triggers in the destination database, and re-create them when the migration is completed. The following tables have triggers: hr.employees.
対処法：
移行先の PostgreSQL に接続し、DMS が使用するユーザに REPLICATION 権限を付与することで解決しました。
外部キー制約に関する警告
エラー内容：
DMS doesn't replicate data in a transactional manner, so foreign keys cannot be enforced during the migration. Allow DMS to skip foreign keys by assigning the REPLICATION option to the migration user account on the destination database or alternatively drop all foreign keys and re-create them after the migration is completed. The following tables have foreign keys: hr.countries,hr.departments,hr.employees,hr.job_history,hr.locations.
対処法：
トリガーに関する警告と同様に、移行先の PostgreSQL に接続し、DMS が使用するユーザに REPLICATION 権限を付与することで解決しました。
- PSC を使用してインスタンスに接続：https://cloud.google.com/sql/docs/postgres/configure-private-service-connect?hl=ja
5. 移行ジョブの実行
いよいよデータを移行します。移行作業中は CDC によって常にデータが同期されるため、移行を完了する時点で最新のデータが移行先データベースにも存在することになります。
移行ジョブの作成が完了したら、[データベースの移行] > [移行ジョブ] に移動します。作成したジョブにチェックを付けて、[▶ 開始] をクリックします。「移行ジョブを開始しますか？」というポップアップが出るので、[開始] をクリックします。
移行中のログを Logging で確認することが可能です。
移行ジョブのステータスが「実行中」かつフェーズが「CDC」になれば、プロモート（移行の完了）ができるようになります。この時点で、移行元データベースと宛先データベースでデータが一致しているのかを確認します。今回の検証では、オープンソースツールとして Google Cloud 公式が公開しているデータ検証ツール（DVT）を使用しました。（使用方法の詳細については割愛します。）
データが一致していれば、[プロモート] をクリックします。「Promote migration job?」というポップアップが出るので、[PROMOTE] をクリックします。
しばらく待っているとステータスが「完了」に変わります。
これで DMS による移行が完了しました。お疲れ様でした。
終わりに
この記事では、Oracle Database XE から Cloud SQL for PostgreSQL への移行における具体的な手順を、DMS を使ったプロセスを中心に説明しました。特に、移行途中で発生する可能性のあるエラーやその解決策についても詳しく解説しました。移行後はデータの整合性を再確認し、必要に応じてパフォーマンスチューニングを行うことをお勧めします。また、継続的なバックアップの設定やモニタリングの強化も検討してください。
この記事が、皆様のデータベース移行の成功に寄与することを願っております。今後も弊社の Zenn ブログにて最新の技術情報をお届けしますので、ぜひご期待ください。
Discussion