このページでは、オンライン トランザクション処理（OLTP）データベースを MySQL から Spanner に移行する方法の概要について説明します。Spanner への移行プロセスは、データサイズ、ダウンタイム要件、アプリケーション コードの複雑さ、シャーディング スキーマ、カスタム関数、フェイルオーバーとレプリケーション戦略、などの要因によって異なる場合があります。
Spanner の移行は次の手順で構成されています。
- 移行を評価する。
- スキーマを移行し、SQL クエリを変換する。
- MySQL に加えて Spanner を使用するようにアプリケーションを移行する。
- サンプルデータを読み込んでパフォーマンスを最適化する。
- データを移行する。
- 移行を検証する。
- カットオーバーとフォールバックのメカニズムを構成する。
移行を評価する
移行元の MySQL データベースから Spanner への移行を評価するには、ビジネス、技術、運用、財務のニーズを評価する必要があります。詳細については、移行を評価するをご覧ください。
スキーマを移行する
Spanner 移行ツールを使用して、既存のスキーマを Spanner のスキーマに変換します。
詳細については、MySQL からスキーマを移行する概要をご覧ください。
Spanner を使用するようにアプリケーションを移行する
Spanner は、さまざまな言語用のクライアント ライブラリを備えています。また、データの読み取りや書き込みには、Spanner 固有の API 呼び出しを使用することも、SQL クエリやデータ変更言語（DML）ステートメントを使用することもできます。キーによって行を直接読み取る場合など、一部のクエリでは、API 呼び出しを使用したほうが処理が速くなることがあります（SQL ステートメントの変換が不要であるため）。
Spanner には、Java アプリケーション用の JDBC ドライバが用意されています。
移行プロセスの一環として、前述の Spanner で利用できない機能をアプリケーションに実装する必要があります。たとえば、データ値を検証して関連テーブルを更新するトリガーは、既存の行の読み取り、制約の検証、更新された行の両方のテーブルへの書き込みという一連の処理を実行する読み取りまたは書き込みトランザクションを使用して、アプリケーションに実装する必要があります。
Spanner に備えられた読み取りまたは書き込みトランザクションと読み取り専用トランザクションによってデータの外部整合性が確実化されます。さらに、読み取りトランザクションには、次の方法で指定した整合性のあるデータ バージョンを読み取るようにタイムスタンプ バウンドを適用できます。
- 過去の正確な時刻（最大 1 時間前まで）。
- 将来の時刻（その時間になるまで読み取りがブロックされる）。
- 許容範囲内のバウンド ステイルネス。最新のデータが別のレプリカで利用可能かどうかをチェックすることなく、過去の特定の時点までの整合性のあるビューが返されます。この方法を使用すると、パフォーマンス上の利点が得られる代わりに、データが古くなる可能性があります。
サンプルデータを Spanner に読み込む
完全なデータ移行を実行する前に、サンプルデータを Spanner に読み込んで、スキーマ、クエリ、アプリケーションをテストできます。
BigQuery リバース ETL ワークフローと Google Cloud CLI を使用して、少量のデータを CSV ファイル形式で Spanner に読み込むことができます。
詳細については、サンプルデータを読み込むをご覧ください。
MySQL から Spanner にデータを転送するには、MySQL データベースをポータブル ファイル形式（XML など）にエクスポートしてから、Dataflow を使用してそのデータを Spanner にインポートすることもできます。
データを Spanner に移行する
Spanner スキーマを最適化してサンプルデータを読み込んだら、空の本番環境規模の Spanner データベースにデータを移動できます。
詳細については、MySQL からのデータのライブ移行をご覧ください。
データの移行を検証する
データが Spanner データベースにストリーミングされるときに、Spanner データと MySQL データを定期的に比較して、データの整合性を検証できます。整合性を検証する際には、両方のデータソースに対してクエリを実行し、その結果を比較します。
Dataflow では、Join 変換を使用して大規模なデータセットに対して詳細な比較を行うことができます。この変換に 2 つのキー付きデータセットを渡すと、対応する値がキー別に照合されます。その後、対応する値を比較して、等しいかどうかを確認できます。整合性のレベルがビジネス要件を満たすまで、この検証を定期的に実行できます。
詳細については、データ移行を検証するをご覧ください。
カットオーバーとフォールバックのメカニズムを構成する
リバース レプリケーションを使用して、MySQL のカットオーバーとフォールバックを設定できます。カットオーバーとフォールバックとは、Spanner で問題が発生した場合にソース MySQL データベースに戻すための予備計画があることを意味します。
リバース レプリケーションは、Spanner で予期しない問題が発生し、サービスを中断せずに元の MySQL データベースにフォールバックする必要がある場合に便利です。リバース レプリケーションにより、Spanner に書き込まれたデータをソースの MySQL データベースにレプリケートすることで、フォールバックが可能になります。
リバース レプリケーション フローは、Spanner to SourceDB Dataflow テンプレートによって実行される次のステップで構成されます。
Spanner 変更ストリームを使用して Spanner から変更を読み取る。
転送された移行済みの変更を除外する。
Spanner データを変換して、移行元のデータベース スキーマとの互換性を維持する。
指定された主キーの新しいデータがソース データベースにすでに含まれているかどうか確認する。
データをソース データベースに書き込む。
次のステップ
- スキーマ設計のベスト プラクティス。
- Spanner スキーマを最適化する。
- Dataflow をより複雑な状況で使用する方法を確認する。