Oracle® から Cloud SQL for MySQL へのデータの移行

このドキュメントは、Oracle から Cloud SQL for MySQL にデータを移行する方法を説明するシリーズの一部です。このシリーズの次のドキュメントで、さらに詳しく説明されています。

データ移行の準備

このセクションでは、Oracle から Cloud SQL for MySQL にデータを移行する方法について説明します。ライブ マイグレーション中の問題を回避するには、次の前提条件を満たす必要があります。

  • Oracle から Cloud SQL for MySQL へのスキーマ変換は、テーブル、ビュー、ストアド プロシージャ、関数を含むすべてのデータベース オブジェクトに対して実行されています。
  • ターゲット スキーマは、ソーススキーマと同じデータを保持できるように一部のサンプルデータでテストされています。

データ移行には、1 回限りの読み込みとリアルタイム レプリケーションという 2 つの基本的な方法があります。1 回限りの読み込みは、Oracle から既存のデータをエクスポートし、MySQL にインポートする方法です。リアルタイム レプリケーションでは、データは生成時にすぐに Oracle から MySQL にコピーされます。

1 回限りの読み込みの方法の場合、ソース データベースは、このプロセスにおける書き込みのためだけに開いている必要があります。そのため、この手法はオフライン データ移行とも呼ばれます。Oracle からデータをエクスポートするためによく使用されるツールの一つが Oracle SQL Developer です。このツールを使用すると、CSV や SQL INSERT ステートメントなど、さまざまな形式で Oracle テーブルからデータをエクスポートできます。または、SQL*Plus を使用してデータを選択してフォーマットしてから、ファイルにスプールできます。データが Oracle からフラット ファイルにエクスポートされたら、LOAD DATA INFILE コマンドを使用して MySQL に読み込めます。この方法がしばしば最もコストのかからない移行手法になりますが、手動による入力が必要な場合があり、また、移行ツールを使用する場合よりも時間がかかる可能性があります。また、移行中のアプリケーションのダウンタイムも必要です。

一方、リアルタイム レプリケーションは、変更データキャプチャとも呼ばれるオンライン データ移行方法です。最初のデータコピー中、ソース データベースは開いたままになります。レプリケーション プロダクトは、ソース データベースで発生したデータの変更をキャプチャし、その変更をターゲット データベースに転送して適用します。本番環境のデータの移行では、この方法を使用して、必要なダウンタイムを最小限に抑え、カットオーバーの開始までほぼゼロのダウンタイムを確保できます。この方法では、GoldenGate、Striim、Informatica の Data Replication などのサードパーティの変更データ キャプチャ（CDC）プロダクトを使用します。

Oracle の CDC をソース データベースとして許可するには、次のコマンドを使用して、データベース レベルで追加ロギングを有効にすることをおすすめします。

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Database altered.

このコマンドにより、REDO ログファイルで、通常の主キー列または一意のインデックス列に加えて、追加の列データが記録されます。

サードパーティの CDC プロダクトを使用して、2 つのプラットフォーム間の切り替えを実行する前の、最初の読み込みのステップ（ソース Oracle データベース環境から既存のすべてのデータの転送、最大で数 TB のデータ）と、両方の環境が同期するまでの進行中のデータ変更のキャプチャの両方を行えます。通常、CDC プロダクトでは、データ型の変換やその他の簡単な変換などの追加機能が提供されています。

データ移行の実行

データを移行する際には、次のガイドラインを参考にしてください。ほとんどの内容は、これは 1 回限りの読み込みとリアルタイム レプリケーション メソッドの両方に適用できます。

  • 文字セット: ソース Oracle データベースとターゲット MySQL データベース間で文字セットの互換性を確保してください。
  • 外部キー: 取り込みを高速化するには、ターゲット MySQL データベースの外部キー制約を一時的に無効にします。読み込みが完了したら、外部キー制約を有効にします。
  • インデックス: 外部キーと同様に、ターゲット MySQL データベースに対するインデックスによって初期読み込みが大幅に遅くなる可能性があります。初期読み込みが完了するまで、ターゲット データベースにインデックスが作成されないようにします。
  • Oracle シーケンス: MySQL はシーケンスではなく AUTO_INCREMENT をサポートします。Oracle のシーケンスで生成された値を上書きしないように、最初の読み込み時に AUTO_INCREMENT 属性を無効にします。最初の読み込みが完了したら、主キー列に AUTO_INCREMENT 属性を追加します。
  • ネットワーク接続: CDC を使用している場合は、移行元と移行先の環境の両方で CDC プロダクトとのネットワーク接続が確立され、Oracle 側でのデータ キャプチャと、Cloud SQL for MySQL 側でのデータ読み込みが可能となるようにします。

GoldenGate のユースケース

このセクションでは、Oracle の CDC サービスである GoldenGate を使用した Cloud SQL へのオンライン移行の詳細を説明します。最初のステップは、ソースシステムとターゲット システムの両方に GoldenGate をインストールして、GoldenGate の環境を準備することです。ソース側では、アプリケーションを Oracle サーバーにインストールすることも、SQL*Net 接続を介して Oracle データベースに接続するリモート サーバーにインストールすることもできます。ターゲット側では、Cloud SQL マシンに GoldenGate を直接インストールできないため、Google Cloud でステージング VM を使用して GoldenGate アプリケーションを実行する必要があります。GoldenGate には GGSCI というコマンドライン ユーティリティが備わっており、これにより、さまざまな GoldenGate プロセスを構成して実行できます。

環境を設定したら、EXTRACT プロセスを構成して追加し、データの変更をキャプチャします。この処理は、読み込みの実行中に進行中のトランザクションの変更が失われないように、最初のデータ読み込みを開始する前に行う必要があります。前で説明したように、CDC では、ソース Oracle データベースで補足ロギングを有効にする必要があります。コミットされたトランザクションは、REDO ログからキャプチャされ、logical change records (LCRs) に変換され、ローカルおよびリモート ステージング エリア（Google Cloud VM）の追跡ファイルに書き込まれます。追跡ファイルのサイズを設定して、使用可能なすべてのディスク領域を消費せずに十分な長さを維持できるようにする方法を見つける必要があります。

次のステップでは、EXTRACT と呼ばれる GoldenGate キャプチャ プロセスを構成して、最初のデータ読み込みを行います。これには、Oracle のソーステーブルと MySQL のターゲット テーブル（MAP schema/table to TARGET database.table など）の間のマッピングのリストを指定するパラメータ ファイルの作成も含まれます。CDC と異なり、最初の読み込みは REDO ログではなくソーステーブルを使用してソースデータを取得します。EXTRACT プロセスを開始し、結果を確認することにより、最初の読み込みプロセスを実行します。最初の読み込みの期間は、データ量とネットワーク スループットの要因になります。

最初のデータ読み込みが正常に完了したら、変更配信を構成します。これは、LCRs をターゲット MySQL データベースに適用するプロセスです。REPLICAT プロセスが、これらのレコードをリモート追跡ファイルから読み取り、DML および DDL ステートメントに変換して、ターゲット MySQL データベースに適用します。REPLICAT プロセスには独自のパラメータ ファイルがあり、競合やその他の例外を処理する方法に関するセクションが含まれています。

データ レプリケーションが機能していることを確認する最も簡単な方法は、ソーステーブルで行数を実行し、結果をターゲット テーブルと比較します。GGSCI には、レプリケーションの統計情報とエラーを表示するレポートと stats コマンドがあります。

成功基準

オフライン、オンラインを問わず、次の基準を満たす場合に限り、データの移行が成功とみなされます。

  • エラーの発生や処理の失敗なしでデータ移転が行われた。
  • 1 回限りの読み込みを使用していた場合は、読み込み時間が、ビジネスの許容可能なダウンタイム時間枠を超えなかった。
  • CDC を使用していた場合、アプリケーション ユーザーは初期読み込み時にパフォーマンス ヒットを観測しなかった。
  • CDC を使用していた場合、ターゲット データベースが最終的にソース データベースに追いつくように、レプリケーション ラグが次第に小さくなった。

移行後のデータの整合性の検証

このフェーズでは、データ間のあらゆる不一致を迅速に解決できるように、ターゲット MySQL 環境に関する問題と不整合を特定する必要があります。手順は次のとおりです。

  1. ソース データベース テーブルとターゲット データベース テーブルの間の行数を比較して、ギャップを特定します。count の実行に加え、同じテーブルセットで sum、avg、min、max も実行します。
  2. ターゲット MySQL 環境に対して頻繁に使用される SQL ステートメントを実行して、データがソース Oracle データベースと一致することを確認します。
  3. アプリケーションをソース データベースとターゲット データベースの両方に接続して、結果が一致していることを確認します。

次のステップ