Spanner スキーマを最適化してアプリケーションを移行したら、空の本番環境規模の Spanner データベースにデータを移動し、Spanner データベースを使用するようにアプリケーションを切り替えます。
ユースケースによっては、最小限のダウンタイムでライブデータ移行を実行できる場合もあれば、データ移行を実行するために長時間のダウンタイムが必要になる場合もあります。
アプリケーションで大幅なダウンタイムを許容できない場合は、ライブデータ移行の実施を検討してください。アプリケーションがダウンタイムを処理できる場合は、ダウンタイムありで移行することを検討してください。
ライブデータ移行では、ソース データベース、ターゲット Spanner データベース、データ移行に使用するツール間でデータが転送されるために必要なネットワーク インフラストラクチャを構成する必要があります。組織のコンプライアンス要件に応じて、プライベート ネットワーク接続またはパブリック ネットワーク接続を決定する必要があります。インフラストラクチャの設定には、組織のネットワーク管理者のサポートが必要になる場合があります。
ライブデータ移行
ライブデータ移行は、次の 2 つのコンポーネントで構成されます。
- ソース データベースの一貫したスナップショットでデータを移行します。
- そのスナップショット以降の変更（挿入、更新、削除）のストリームを移行します（変更データ キャプチャ（CDC）と呼びます）。
ライブデータ移行はデータの保護に役立ちますが、このプロセスには次のような課題があります。
- スナップショットの移行中に CDC データを保存する。
- 受信 CDC ストリームをキャプチャしながら、CDC データを Spanner に書き込む。
- CDC データの Spanner への移行が、受信 CDC ストリームよりも高速であることを確認する。
ダウンタイムを伴う移行
ソース データベースを CSV または Avro にエクスポートできる場合は、ダウンタイムありで Spanner に移行できます。詳細については、Spanner のインポートとエクスポートの概要をご覧ください。
ダウンタイムありでの移行は、数時間のダウンタイムを処理できるテスト環境やアプリケーションに使用できます。ライブ データベースでダウンタイムありでの移行を行うと、データが失われる可能性があります。
ダウンタイム移行を行うには、次の大まかなアプローチを検討してください。
- アプリケーションを停止し、ソース データベースからデータのダンプファイルを生成します。
- ダンプファイルを MySQL、PostgreSQL、Avro、CSV のダンプ形式で Cloud Storage にアップロードします。
- Dataflow または Spanner 移行ツールを使用して、ダンプファイルを Spanner に読み込みます。
複数の小さなダンプファイルを生成すると、Spanner は複数のダンプファイルを並列に読み取ることができるため、Spanner への書き込みが速くなります。
ソース データベースからダンプファイルを生成する場合は、データの一貫したスナップショットを生成するために、次の点に注意してください。
- ダンプを行う前に、ソース データベースに読み取りロックを適用して、ダンプファイルの生成中にデータが変更されないようにします。
- または、レプリケーションが無効になっているソース データベースのリードレプリカを使用して、ダンプファイルを生成します。
ソース固有のガイド
- MySQL: MySQL のライブデータ移行。