Percona XtraBackup 物理ファイルを使用してデータベースを移行する

Percona XtraBackup for MySQL ユーティリティで作成された物理データベース バックアップ ファイルを使用して、MySQL データベースを Cloud SQL に移行できます。物理バックアップ ファイルを使用した移行は、論理バックアップ ファイルを使用した移行よりもデータの復元速度が速くなります。このため、数テラバイトのデータが存在する巨大なデータベースを移行する場合に最適な選択肢となります。

この移行フローでは、次のタスクを実行します。

  1. Percona XtraBackup for MySQL ユーティリティを使用して、移行元の MySQL インスタンスをバックアップし、物理バックアップ ファイルを準備します。

  2. バックアップ ファイルを Cloud Storage バケットにアップロードします。

  3. Database Migration Service で移行ジョブを作成し、実行します。

    シナリオに応じて、移行先インスタンスを自分で作成することも、移行ジョブの作成フローの一部として Database Migration Service に移行先インスタンスを作成してもらうこともできます。詳細については、移行ジョブを構成して実行するの手順をご覧ください。

  4. データが完全に移行された後、移行ジョブをプロモートします。

オフライン移行

このガイドでは、移行元データベース インスタンスと移行先データベース インスタンス間のネットワーク接続を確保できる環境の移行シナリオについて説明します。

Database Migration Service が移行元インスタンスに接続しないテスト移行を実行できます。代わりに、Database Migration Service は、Cloud Storage バケットにアップロードしたバックアップ ファイルのみを読み取り、その内容を Cloud SQL for MySQL の宛先に複製します。Database Migration Service ではデータ検証を完全に実行できないため、ネットワーク接続を使用しない移行フローは本番環境の移行にはおすすめしません。

オフライン移行ジョブを実行する場合は、手順を次のように調整します。

制限事項

このセクションでは、Percona XtraBackup 物理ファイルを使用する移行の制限事項について説明します。

  • 物理バックアップ ファイルを使用して MySQL 5.6 または 8.4 に移行することはできません。既知の制限事項をご覧ください。

  • バージョン間の考慮事項:

    • 移行できるのは、同じデータベースのメジャー バージョン内のみです。たとえば、MySQL 8.0.30 から MySQL 8.0.35 への移行や、MySQL 5.7.0 から MySQL 5.7.1 への移行などです。

    • MySQL 5.7 から MySQL 8.0 に移行することはできません。

    • 以前のデータベース メジャー バージョンまたはマイナー バージョンへの移行はサポートされていません。たとえば、MySQL 8.0 から 5.7 に移行することや、MySQL 8.0.36 から 8.0.16 に移行することはできません。

  • Percona XtraBackup を使用してデータを Cloud Storage バケットにバックアップする必要があります。他のバックアップ ユーティリティはサポートされていません。

  • Percona XtraBackup 物理ファイルからのデータベース移行がサポートされるのは、オンプレミスまたはセルフマネージド VM MySQL データベースのみです。Amazon Aurora や Amazon RDS 上の MySQL のデータベースからの移行はサポートされていません。

  • フル バックアップからの移行のみが可能です。他のバックアップ タイプ（増分バックアップや部分バックアップなど）はサポートされていません。

  • データベースの移行には、データベース ユーザーや権限は含まれません。

  • バイナリログ形式を ROW に設定する必要があります。バイナリログが他の形式（STATEMENT や MIXED など）となるように構成されている場合は、レプリケーションが失敗する可能性があります。

  • テーブルが 5 TB を超えるデータベースはサポートされていません。

  • Cloud Storage では、バケットにアップロードできるファイルのサイズについて 5 TB という制限があります。Percona XtraBackup 物理ファイルが 5 TB を超える場合は、バックアップ ファイルを小さなファイルに分割する必要があります。

  • 他のファイルが存在しない専用の Cloud Storage フォルダにバックアップ ファイルをアップロードしてください。

  • innodb_data_file_path パラメータは、デフォルトのデータファイル名 ibdata1 を使用するデータファイルを 1 つだけ指定して構成されている必要があります。データベースの構成で 2 つのデータファイルが指定されている場合や、データファイルの名前が異なる場合は、Percona XtraBackup 物理ファイルを使用してそのデータベースを移行することはできません。たとえば、innodb_data_file_path=ibdata01:50M:autoextend と構成されているデータベースの移行はサポートされません。

  • 移行元インスタンスの innodb_page_size パラメータは、デフォルト値 16384 を指定して構成する必要があります。

  • プラグインを外部データベースから移行することはできません。

料金

Cloud SQL への同種移行の場合、Database Migration Service は追加料金なしで利用できます。ただし、ネットワーク料金と、移行目的で作成された Cloud SQL エンティティと Cloud Storage エンティティには、Cloud SQL と Cloud Storage の料金が適用されます。

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

  • Cloud Storage
  • Cloud SQL

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。 新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

始める前に

  1. 宛先データベースを作成するリージョンを検討します。Database Migration Service は完全にリージョン ベースのサービスです。つまり、移行に関連するすべてのエンティティ（移行元と移行先の接続プロファイル、移行ジョブ、移行先データベース、ストレージ バケット）を 1 つのリージョンに保存する必要があります。

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Enable the Database Migration Service, Compute Engine, and Cloud SQL Admin APIs.

    Enable the APIs

必要なロール

物理バックアップ ファイルを使用して同種の MySQL 移行を実行するために必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

これらの事前定義ロールには、物理バックアップ ファイルを使用して同種の MySQL 移行を実行するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

物理バックアップ ファイルを使用して同種の MySQL 移行を実行するには、次の権限が必要です。

  • 移行を実行するユーザー アカウント:
    • datamigration.*
    • resourcemanager.projects.get
    • resourcemanager.projects.list
    • cloudsql.instances.create
    • cloudsql.instances.get
    • cloudsql.instances.list
    • compute.machineTypes.list
    • compute.machineTypes.get
    • compute.projects.get
    • storage.buckets.create
    • storage.buckets.list

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

ステップ 1. ネットワーク接続の要件を考慮する

移行元と Cloud SQL の移行先インスタンス間の接続を構成するために使用できるネットワーク方法はいくつかあります。使用する方法によっては、移行プロセス中に追加の手順が必要になる場合があります。

次のステップに進む前に、シナリオに適した接続方法を検討してください。選択した方法によって、使用する設定に影響する可能性があります。詳細については、 接続を構成するをご覧ください。

ステップ 2. 移行元データの準備

次の手順で、移行するデータを準備します。

  1. 移行元のインスタンスに Percona XtraBackup ユーティリティの正しいバージョンをインストールします。移行元インスタンスのバージョンと同じかそれ以降のバージョンの Percona XtraBackup を使用する必要があります。詳細については、Percona XtraBackup のドキュメントの サーバー バージョンとバックアップ バージョンの比較をご覧ください。
  2. Percona XtraBackup を使用して、移行元インスタンスの物理バックアップ ファイルをエクスポートして準備します。Percona XtraBackup の使用方法の詳細については、ツールの ドキュメントをご覧ください。次のセクションを開いて、推奨される手順の例を確認することもできます。

    Percona XtraBackup を使用して物理バックアップ ファイルを作成して準備するための推奨手順のサンプル

    後述のコマンドデータを使用する前に、次のように置き換えます。

    • TARGET_DIR は、出力バックアップ ファイルを保存するパスに置き換えます。
    • USERNAME は、ソース インスタンスに対する BACKUP_ADMIN 権限を持つユーザーに置き換えます。
    • PASSWORD は、USERNAME アカウントのパスワードに置き換えます。
    1. 移行元インスタンスの完全な物理バックアップを実行します。次のコマンドを実行します。
        xtrabackup --backup \
    --target-dir=TARGET_DIR \
    --user=USERNAME \
    --password=PASSWORD
    2. バックアップ ファイルの準備ができたら、--prepare コマンドを使用してファイルの整合性を確認します。次のコマンドを実行します。 
        xtrabackup --prepare --target-dir=TARGET_DIR
  3. バックアップ ファイルを格納するバケットを作成します。移行先の Cloud SQL for MySQL インスタンスを作成するリージョンと同じリージョンを使用してください。

    Database Migration Service は完全にリージョン ベースのサービスです。つまり、移行に関連するすべてのエンティティ（移行元と移行先の接続プロファイル、移行ジョブ、移行先データベース、バックアップ ファイル用のストレージ バケット）を 1 つのリージョンに保存する必要があります。

  4. バックアップ ファイルを Cloud Storage バケットにアップロードします。他のファイルが存在しない専用の Cloud Storage フォルダにバックアップ ファイルをアップロードしてください。Cloud Storage のドキュメントの ファイル システムからオブジェクトをアップロードするをご覧ください。
  5. 移行元データベース インスタンスのソース接続プロファイルを作成します。

    コンソール

    ソース接続プロファイルを作成する手順は次のとおりです。

    1. Google Cloud コンソールで、[接続プロファイル] ページに移動します。
    2. [プロファイルの作成] をクリックします。
    3. [接続プロファイルを作成] ページの [データベース エンジン] プルダウン メニューから、[MySQL] を選択します。
    4. [接続プロファイル名] フィールドに、接続プロファイルの読み取り可能な名前を入力します。この値は、接続プロファイルのリストに表示されます。
    5. 自動生成された接続プロファイル ID を保持します。
    6. ホスト名またはIP アドレスを入力します。

      • ソース データベースが Google Cloudでホストされている場合、またはリバース SSH トンネルを使用して宛先データベースをソース データベースに接続する場合は、ソース データベースのプライベート（内部）IP アドレスを指定します。このアドレスには、Cloud SQL の移行先からアクセスできます。詳細については、 VPC ピアリングを使用して接続を構成するをご覧ください。

        IP 許可リストなどの他の接続方法の場合は、パブリック IP アドレスを指定します。

    7. ホストへのアクセスに使用するポートを入力します。MySQL のデフォルト ポートは 3306 です。
    8. 宛先データベースのユーザー名とパスワードを入力します。ユーザー アカウントには、データにアクセスするために必要な権限が必要です。詳細については、 移行元データベースを構成するをご覧ください。
    9. ページの [接続プロファイルのリージョン] セクションで、接続プロファイルを保存するリージョンを選択します。

    10. 省略可: パブリック ネットワーク上で（IP 許可リストを使用して）接続している場合は、ソース データベースと宛先データベース間の接続に SSL/TLS 暗号化を使用することをおすすめします。

      SSL/TLS 構成には 3 つのオプションがあり、ページの [接続を保護する] セクションから選択できます。

      1. なし: Cloud SQL の宛先インスタンスは、暗号化なしでソース データベースに接続します。

      2. サーバー専用の認証: Cloud SQL の宛先インスタンスがソース データベースに接続すると、インスタンスはソースを認証し、インスタンスが正しいホストに安全に接続していることを確認します。これにより、中間者攻撃を防ぐことができます。サーバーのみの認証の場合、ソースはインスタンスを認証しません。

        サーバーのみの認証を使用するには、外部サーバーの証明書に署名した認証局（CA）の x509 PEM でエンコードされた証明書を指定する必要があります。

      3. サーバー クライアント認証: 宛先インスタンスがソースに接続すると、インスタンスはソースを認証し、ソースはインスタンスを認証します。

        サーバー クライアントは、最も強力なセキュリティを提供します。ただし、Cloud SQL 宛先インスタンスの作成時にクライアント証明書と秘密鍵を提供したくない場合は、サーバーのみの認証を使用することもできます。

        サーバー クライアント認証を使用するには、宛先接続プロファイルを作成するときに次の項目を指定する必要があります。

        • ソース データベース サーバーの証明書に署名した CA の証明書（CA 証明書）。
        • インスタンスがソース データベース サーバーに対する認証に使用する証明書（クライアント証明書）。
        • クライアント証明書に関連付けられた秘密鍵（クライアント鍵）。
    11. [Create（作成）] をクリックします。 接続プロファイルが作成されました。

    gcloud

    このサンプルでは、オプションの --no-async フラグを使用して、すべてのオペレーションが同期的に実行されます。そのため、一部のコマンドは完了するまでに時間がかかることがあります。--no-async フラグをスキップして、コマンドを非同期で実行できます。その場合は、gcloud database-migration operations describe コマンドを使用して、オペレーションが成功したかどうかを確認する必要があります。

    後述のコマンドデータを使用する前に、次のように置き換えます。

    • CONNECTION_PROFILE_ID は、接続プロファイルの機械読み取り可能な識別子に置き換えます。
    • REGION は、接続プロファイルを保存するリージョンの ID に置き換えます。
    • HOST_IP_ADDRESS は、Database Migration Service が移行元のデータベース インスタンスに到達できる IP アドレスに置き換えます。この値は、移行に使用する 接続方法によって異なる場合があります。
    • PORT_NUMBER は、ソース データベースが受信接続を受け入れているポート番号に置き換えます。MySQL のデフォルト ポートは 3306 です。
    • USERNAME は、Database Migration Service が移行元データベース インスタンスに接続するデータベース ユーザー アカウントの名前に置き換えます。
    • PASSWORD は、データベース ユーザー アカウントのパスワードに置き換えます。
    • （省略可）CONNECTION_PROFILE_NAME は、接続プロファイルのわかりやすい名前に置き換えます。この値は、 Google Cloud コンソールに表示されます。

    次のコマンドを実行します。

    Linux、macOS、Cloud Shell

    gcloud database-migration connection-profiles \
create mysql CONNECTION_PROFILE_ID \
  --no-async \
  --region=REGION \
  --host=HOST_IP_ADDRESS \
  --port=PORT_NUMBER \
  --username=USERNAME \
  --password=PASSWORD \
  --display-name=CONNECTION_PROFILE_NAME

    Windows（PowerShell）

    gcloud database-migration connection-profiles `
create mysql CONNECTION_PROFILE_ID `
  --no-async `
  --region=REGION `
  --host=HOST_IP_ADDRESS `
  --port=PORT_NUMBER `
  --username=USERNAME `
  --password=PASSWORD `
  --display-name=CONNECTION_PROFILE_NAME

    Windows（cmd.exe）

    gcloud database-migration connection-profiles ^
create mysql CONNECTION_PROFILE_ID ^
  --no-async ^
  --region=REGION ^
  --host=HOST_IP_ADDRESS ^
  --port=PORT_NUMBER ^
  --username=USERNAME ^
  --password=PASSWORD ^
  --display-name=CONNECTION_PROFILE_NAME

    次のようなレスポンスが返されます。

    Waiting for connection profile [CONNECTION_PROFILE_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]

ステップ 3. 移行ジョブを構成して実行する

Percona XtraBackup を使用して移行する場合は、Cloud SQL の移行先インスタンスを自分で作成するか、Database Migration Service に作成を依頼できます。詳細については、 移行ジョブの作成の概要をご覧ください。

これらのアプローチでは、それぞれ異なる手順が必要になります。プルダウン メニューを使用して、シナリオに関連する手順を表示します。

  • Database Migration Service に移行先データベースの作成を任せる場合は、[新しい移行先インスタンスに移行] を選択します。
  • Database Migration Service の外部に作成された移行先データベースに移行する場合は、[既存の移行先インスタンスに移行] を選択します。

  • 新しい移行先インスタンスに移行する場合、Database Migration Service は移行ジョブの作成フロー中に移行先の Cloud SQL for MySQL インスタンスを作成します。

    ステップ 3a. 新しい移行先インスタンスへの移行ジョブを作成する

    新しい移行先インスタンスへの移行ジョブを作成する手順は次のとおりです。

    コンソール

    移行ジョブの設定を定義する

    1. Google Cloud コンソールで、[移行ジョブ] ページに移動します。

      [移行ジョブ] に移動

    2. [移行ジョブを作成] をクリックします。

      移行ジョブ構成ウィザードのページが開きます。このウィザードには、各構成ステップを案内する複数のパネルがあります。

      [保存して終了] をクリックすると、移行ジョブの作成を一時停止できます。その時点で入力したデータはすべて、下書きの移行ジョブに保存されます。下書きの移行ジョブは後で完了できます。

    3. [開始] ページで、次の情報を入力します。
      1. 移行ジョブ名

        これは、移行ジョブのわかりやすい名前です。この値は、 Google Cloud コンソールに表示されます。

      2. 移行ジョブ ID

        これは、移行ジョブの機械読み取り可能な識別子です。この値は、Database Migration Service の Google Cloud CLI コマンドまたは API を使用して移行ジョブを操作する場合に使用します。

      3. [移行元データベース エンジン] リストから [MySQL] を選択します。

        [移行先のデータベース エンジン] フィールドには自動的に入力され、変更できません。

      4. 移行ジョブを保存するリージョンを選択します。

        Database Migration Service は完全にリージョン ベースのサービスです。つまり、移行に関連するすべてのエンティティ（移行元と移行先の接続プロファイル、移行ジョブ、移行先データベース）を 1 つのリージョンに保存する必要があります。Compute Engine インスタンス、App Engine アプリ、その他のサービスなど、データを必要とするサービスのロケーションに基づいてリージョンを選択します。宛先リージョンを選択した後、この選択を変更することはできません。

    4. [保存して次へ] をクリックします。

    ソース接続プロファイルに関する情報の指定

    1. [ソースを定義する] ページで、次の操作を行います。
      1. [ソース接続プロファイル] プルダウン メニューから、移行元データベースの接続プロファイルを選択します。
      2. [完全なダンプの構成のカスタマイズ] セクションで、[構成の編集] をクリックします。
      3. [完全ダンプ構成を編集] パネルで、[完全ダンプ方法] プルダウン メニューから [物理ベース] を選択します。
      4. [フォルダを指定] で [参照] をクリックし、完全なダンプファイルをアップロードしたフォルダを選択します（ソースデータを準備するセクションの手順 3）。
      5. [保存] をクリックします。
    2. [保存して次へ] をクリックします。

    移行先の Cloud SQL インスタンスを構成して作成する

    1. [宛先を定義する] ページで、[宛先インスタンスのタイプ] プルダウン メニューから [新しいインスタンス] を選択します。関連するすべての設定を定義します。
      1. [宛先インスタンス ID] フィールドに、Cloud SQL インスタンスの ID を指定するか、自動生成された ID を使用します。

        識別子には機密情報や個人を特定できる情報を含めないでください。インスタンス名にプロジェクト ID を含める必要はありません。この処理は必要に応じて自動的に行われます（ログファイルの場合など）。

      2. [パスワード] フィールドに、移行先の Cloud SQL インスタンスの英数字のパスワードを入力します。これは、インスタンスの root 管理者アカウントのパスワードです。

        手動でパスワードを入力するか、[生成] をクリックして Database Migration Service にパスワードを自動生成してもらいます。

      3. [データベースのバージョン] プルダウン メニューから、移行先インスタンスのデータベース バージョンを選択します。

        [マイナー バージョンを表示] をクリックして、すべてのマイナー バージョンを表示します。 クロスバージョンの移行サポートについて詳しくは、 こちらをご覧ください。

      4. 宛先インスタンスの Cloud SQL for MySQL エディションを選択します。利用可能なオプションは、Cloud SQL for MySQL Enterprise エディションと Cloud SQL for MySQL Enterprise Plus エディションの 2 つです。

        Cloud SQL for MySQL のエディションには、異なる機能セット、使用可能なマシンタイプ、料金が用意されています。ニーズに適したエディションを選択するには、Cloud SQL のドキュメントをご覧ください。詳細については、 Cloud SQL for MySQL のエディションの概要をご覧ください。

      5. [リージョン] メニューには、[使ってみる] ページで選択したのと同じリージョンが表示されます。

        高可用性を目的とするインスタンスを構成する場合は、[複数のゾーン（高可用性）] を選択します。プライマリ ゾーンとセカンダリ ゾーンの両方を選択できます。セカンダリ ゾーンがインスタンスの作成中に使用される場合は、次の条件が適用されます。

        • ゾーンのデフォルトは、プライマリ ゾーンは 任意、セカンダリ ゾーンは 任意（プライマリとは異なる）です。
        • プライマリ ゾーンとセカンダリ ゾーンの両方を指定する場合は、別々のゾーンにする必要があります。
      6. [接続] セクションで、宛先インスタンスにパブリック IP アドレスとプライベート IP アドレスのどちらを追加するかを選択します。両方のタイプの IP アドレスを持つようにインスタンスを構成できますが、移行には少なくとも 1 つのタイプが必要です。次のいずれかを選択してください。
        • VPC ピアリングまたはリバース SSH トンネルを使用して移行する場合は、[ プライベート IP] を選択します。

          • プライベート IP 接続を有効にするには、追加のネットワーク要件をすべて満たしていることを確認してください。

            プライベート IP の完全な要件については、このセクションを展開してください。
          • ピアリングする関連付けられた VPC ネットワークを選択します。VPC ピアリングを使用して移行元に接続する場合は、インスタンスが存在する VPC を選択します。
          • 選択した VPC にマネージド サービス ネットワークが構成されていない場合は、IP 範囲を選択して [接続] をクリックするか、自動的に選択された IP 範囲を使用して [割り振りと接続] をクリックします。
        • IP 許可リストを使用してインターネット経由で移行する場合は、[ パブリック IP] を選択します。

          必要に応じて、[パブリック IP] で [承認済みネットワーク] フィールドをクリックし、Cloud SQL インスタンスに接続するネットワークまたはプロキシを承認します。ネットワークは、指定したアドレスでのみ承認されます。Cloud SQL ドキュメントのパブリック IP を構成するをご覧ください。

        移行ジョブの接続は後で構成します。使用可能なネットワーキング方法の詳細については、 接続を構成するをご覧ください。

    2. Cloud SQL インスタンスのマシンタイプを選択します。ディスクサイズは移行元データベースのサイズ以上である必要があります。MySQL マシンタイプの詳細を確認する。
    3. Cloud SQL for MySQL Enterprise Plus エディションの場合: 移行先データベースでデータ キャッシュ機能を使用する場合、[データ キャッシュを有効にする] チェックボックスをオンにします。

      データ キャッシュは、Cloud SQL for MySQL Enterprise Plus エディションのインスタンスで使用できるオプション機能です。高速ローカル ソリッド ステート ドライブを移行先データベースに追加します。この機能を使用すると、Cloud SQL の追加費用が発生する可能性があります。データ キャッシュの詳細については、Cloud SQL ドキュメントのデータ キャッシュの概要をご覧ください。

    4. Cloud SQL インスタンスのストレージ タイプを指定します。 ソリッド ステート ドライブ（SSD）またはハードディスク ドライブ（HDD）を選択できます。
    5. Cloud SQL インスタンスのストレージ容量（GB）を指定します。

      ソース データベースのデータを処理するのに十分なストレージ容量がインスタンスにあることを確認します。この容量はいつでも増やすことができますが、減らすことはできません。

    6. （省略可）宛先インスタンスのデータ暗号化オプションまたはリソースラベルを構成します。

      このセクションを展開すると、省略可能な手順が表示されます。

      [オプションの構成を表示] をクリックし、次のようにします。

      1. 移行元から移行先に移行されるデータの暗号化を管理するかどうかを指定します。デフォルトでは、データは Google Cloudによって管理される鍵で暗号化されます。ご自身で暗号化を管理する場合は、顧客管理の暗号鍵（CMEK）を使用できます。手順は次のとおりです。

        1. [顧客管理の暗号鍵（CMEK）を使用する] チェックボックスをオンにします。
        2. [顧客管理の暗号鍵を選択] メニューから CMEK を選択します。

        鍵が表示されない場合は、[鍵のリソース名を入力] をクリックして、使用する鍵のリソース名を指定します。鍵リソース名の例: projects/my-project-name/locations/my-location/keyRings/my-keyring/cryptoKeys/my-key。

      2. データベース サーバーに適用する必要なフラグを追加します。可能であれば、作成した移行先の Cloud SQL インスタンスのデータベース フラグが移行元データベースのデータベース フラグと同じであることを確認します。MySQL でサポートされているデータベース フラグの詳細を確認する。
      3. Cloud SQL インスタンスに固有の ラベルを追加します。

        ラベルはインスタンスの整理に役立ちます。たとえば、コストセンターや環境別にラベルを整理できます。ラベルは請求書にも記載されるため、ラベル間のコストの分布を確認できます。
    7. [移行先を作成して続行] をクリックします。 Database Migration Service が Cloud SQL の移行先インスタンスを作成します。この処理には数分かかることがあります。

    移行元データベースと移行先データベースのインスタンス間の接続を設定する

    [接続方法] プルダウン メニューから、ネットワーク接続方法を選択します。この方法により、新しく作成された Cloud SQL インスタンスがソース データベースに接続される方法が定義されます。現在のネットワーク接続方法には、IP 許可リスト、リバース SSH トンネル、VPC ピアリングがあります。

    使用したい場合方法
    IP 許可リストのネットワーク接続方法 移行先インスタンスの送信 IP アドレスを指定する必要があります。作成した Cloud SQL インスタンスが高可用性インスタンスの場合は、プライマリ インスタンスとセカンダリ インスタンスの両方の送信 IP アドレスを含めます。
    リバース SSH トンネル ネットワーク接続方法 トンネルをホストする Compute Engine VM インスタンスを選択する必要があります。

    インスタンスを指定すると、ソース データベースと移行先データベースの間にトンネルを設定する手順を実行するスクリプトが提供されます。スクリプトは Google Cloud CLI で実行する必要があります。

    ソース データベースと Google Cloudの両方に接続できるマシンからコマンドを実行します。
    VPC ピアリング ネットワーク接続方法。 移行元データベースが存在する VPC ネットワークを選択する必要があります。このネットワークに接続するように Cloud SQL インスタンスが更新されます。

    ネットワーク接続を選択して構成したら、[構成して続行] をクリックします。

    移行ジョブを作成する

    [移行ジョブのテストと作成] で、移行ジョブの設定を確認します。この時点で、Cloud SQL の移行先インスタンスに関連付けられているサービス アカウントに必要な権限がないため、移行ジョブのテストは失敗します。

    ジョブ構成を検証するには、ジョブをテストする前に次のいずれかの操作を行います。

    • 宛先インスタンスのサービス アカウントに権限を割り当てた後、 Google Cloud コンソールを使用して移行ジョブをテストする場合は、[保存して終了] をクリックします。この操作により、移行ジョブが下書きとして保存されます。後でこの画面に戻って、移行ジョブをテストして実行できます。
    • 宛先インスタンスのサービス アカウントに権限を割り当てた後、Google Cloud CLI を使用して移行ジョブをテストする場合は、[作成] をクリックします。Google Cloud CLI を使用すると、作成済みだがまだ開始されていない移行ジョブをテストできます。

    gcloud

    1. 宛先接続プロファイルを作成します。
      Google Cloud CLI を使用して新しい移行先インスタンスに移行する場合は、移行先インスタンスと接続プロファイルを 1 つのアクションで作成します。
      次のコマンドを実行します（リンクをクリックして展開）。

      gcloud database-migration connection-profiles create cloudsql

      このサンプルでは、オプションの --no-async フラグを使用して、すべてのオペレーションが同期的に実行されます。そのため、一部のコマンドは完了するまでに時間がかかることがあります。--no-async フラグをスキップして、コマンドを非同期で実行できます。その場合は、gcloud database-migration operations describe コマンドを使用して、オペレーションが成功したかどうかを確認する必要があります。

      後述のコマンドデータを使用する前に、次のように置き換えます。

      • CONNECTION_PROFILE_ID は、接続プロファイルの機械読み取り可能な識別子に置き換えます。
      • DATABASE_VERSION は、移行先インスタンスで使用する MySQL バージョンに置き換えます。データベース バージョンは、メジャー バージョンとマイナー バージョンの両方を含む文字列として指定します。例: MYSQL_8_0、MYSQL_8_0_32、MYSQL_8_0_36。

        使用可能なすべての MySQL バージョンについては、 --database-version フラグ リファレンスをご覧ください。

      • （省略可）EDITION デフォルトでは、Google Cloud CLI で作成する新しいインスタンスは Cloud SQL for MySQL Enterprise Plus エディションを使用します。Cloud SQL for MySQL Enterprise Plus エディションを使用する場合は、そのエディションでリージョンがサポートされていることを確認してください。Cloud SQL for MySQL Enterprise Plus エディションのリージョン サポートをご覧ください。

        エディションを変更するには、--edition フラグに次のいずれかの値を指定します。

        • enterprise-plus（Cloud SQL for MySQL Enterprise Plus エディションの場合）
        • enterprise（Cloud SQL for MySQL Enterprise エディションの場合）
      • TIER は、使用する Cloud SQL マシンタイプの名前に置き換えます。マシンタイプは、Cloud SQL の規則に従う文字列として指定します（db-n1-standard-1、db-perf-optimized-N-2 など）。Google Cloud CLI で使用できるマシンタイプとその ID の完全なリストについては、Cloud SQL for MySQL ドキュメントの マシンタイプをご覧ください。

        Google Cloud CLI で作成されたインスタンスは、デフォルトで、使用可能なマシンタイプが異なる Cloud SQL for MySQL Enterprise Plus エディションを使用します。Cloud SQL for MySQL Enterprise エディションでのみ使用可能なマシンタイプを使用する場合は、省略可能な --edition=enterprise フラグを使用してエディションを指定します。

      • REGION は、接続プロファイルを保存するリージョンの ID に置き換えます。

        デフォルトでは、Google Cloud CLI で作成する新しいインスタンスは Cloud SQL for MySQL Enterprise Plus エディションを使用します。Cloud SQL for MySQL Enterprise Plus エディションを使用する場合は、そのエディションでリージョンがサポートされていることを確認してください。Cloud SQL for MySQL Enterprise Plus エディションのリージョン サポートをご覧ください。エディションは、オプションの --edition フラグを使用して変更できます。

      • （省略可）CONNECTION_PROFILE_NAME は、接続プロファイルのわかりやすい名前に置き換えます。この値は、 Google Cloud コンソールに表示されます。
      • ネットワーク構成

        デフォルトでは、Google Cloud CLI で作成した新しいインスタンスにはパブリック IP アドレスが割り当てられ、パブリック IP 接続を使用するように構成されます。他の接続方法を使用できます。詳細については、接続を構成するをご覧ください。

        パブリック IP 接続を使用する場合は、追加のフラグを使用する必要はありません。VPC ネットワーク ピアリングまたはリバース SSH トンネルでプライベート IP 接続を使用する場合は、プライベート IP 接続を有効にするための次の追加のネットワーク要件を満たしていることを確認し、コマンドに追加のフラグを追加します。

        プライベート IP の完全な要件については、このセクションを展開してください。

        プライベート IP 接続（VPC ネットワーク ピアリングを使用または Compute Engine VM でリバース SSH トンネルを使用）を使用する場合は、次のフラグを追加します。

        • --no-enable-ip-v4: （省略可）宛先インスタンスにパブリック IP アドレスを割り当てない。宛先インスタンスにパブリック IP アドレスとプライベート IP アドレスの両方を割り当てることができますが、プライベート IP 接続を使用する場合はパブリック IP アドレスを使用しない場合もあります。
        • --private-network: 宛先インスタンスにプライベート IP アドレスを割り当てるには、プライベート IP アドレスを割り当てる Virtual Private Cloud の名前を指定します。

      次のコマンドを実行します。

      Linux、macOS、Cloud Shell

      gcloud database-migration connection-profiles \
create mysql CONNECTION_PROFILE_ID \
  --no-async \
  --region=REGION \
  --database-version=DATABASE_VERSION \
  --tier=TIER \
  --display-name=CONNECTION_PROFILE_NAME

      Windows（PowerShell）

      gcloud database-migration connection-profiles `
create mysql CONNECTION_PROFILE_ID `
  --no-async `
  --region=REGION `
  --database-version=DATABASE_VERSION `
  --tier=TIER `
  --display-name=CONNECTION_PROFILE_NAME

      Windows（cmd.exe）

      gcloud database-migration connection-profiles ^
create mysql CONNECTION_PROFILE_ID ^
  --no-async ^
  --region=REGION ^
  --database-version=DATABASE_VERSION ^
  --tier=TIER ^
  --display-name=CONNECTION_PROFILE_NAME

      次のようなレスポンスが返されます。

      Waiting for connection profile [CONNECTION_PROFILE_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]
    2. ネットワーク構成の設定を完了します。

      使用するネットワーク接続によっては、移行ジョブを作成する前に追加の手順が必要になることがあります。

    3. 移行ジョブを作成します。
      次のコマンドを実行します（リンクをクリックして展開）。

      gcloud database-migration migration-jobs create

      このサンプルでは、オプションの --no-async フラグを使用して、すべてのオペレーションが同期的に実行されます。そのため、一部のコマンドは完了するまでに時間がかかることがあります。--no-async フラグをスキップして、コマンドを非同期で実行できます。その場合は、gcloud database-migration operations describe コマンドを使用して、オペレーションが成功したかどうかを確認する必要があります。

      後述のコマンドデータを使用する前に、次のように置き換えます。

      • MIGRATION_JOB_ID は、移行ジョブの機械読み取り可能な識別子に置き換えます。この値は、Database Migration Service の Google Cloud CLI コマンドまたは API を使用して移行ジョブを操作する場合に使用します。
      • REGION は、移行ジョブを保存するリージョン ID に置き換えます。
      • MIGRATION_JOB_NAME は、移行ジョブのわかりやすい名前に置き換えます。この値は、 Google Cloud コンソールの Database Migration Service に表示されます。
      • SOURCE_CONNECTION_PROFILE_ID は、ソース接続プロファイルの機械読み取り可能な識別子に置き換えます。
      • DESTINATION_CONNECTION_PROFILE_ID は、移行先接続プロファイルの機械読み取り可能な ID に置き換えます。
      • MIGRATION_JOB_TYPE は、移行ジョブのタイプに置き換えます。使用できる値は ONE_TIME または CONTINUOUS の 2 つです。詳細については、 移行のタイプをご覧ください。
      • PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES は、Cloud Storage バケット内のフォルダに保存されている物理バックアップ ファイルのパスに置き換えます。gs://<bucket_name>/<path_to_backup_file_folder> の形式を使用します。
      • ネットワーク構成

        VPC ネットワーク ピアリングまたはリバース SSH トンネルでプライベート IP 接続を使用する場合は、次のフラグをコマンドに追加します。

        VPC ネットワーク ピアリングを使用したプライベート IP 接続
        --peer-vpc フラグを使用して、ピアリングするネットワークの名前を指定します。
        Compute Engine VM のリバース SSH トンネル
        Compute Engine のネットワークの詳細を指定するには、次のフラグを使用します。 --vm-ip、 --vm-port、 --vpc。省略可能な --vm フラグを使用して VM の名前を指定することもできます。

        その他の使用例については、 Google Cloud CLI の例をご覧ください。

      次のコマンドを実行します。

      Linux、macOS、Cloud Shell

      gcloud database-migration migration-jobs \
create MIGRATION_JOB_ID \
  --no-async \
  --region=REGION \
  --display-name=MIGRATION_JOB_NAME \
  --source=SOURCE_CONNECTION_PROFILE_ID \
  --destination=DESTINATION_CONNECTION_PROFILE_ID \
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Windows（PowerShell）

      gcloud database-migration migration-jobs `
create MIGRATION_JOB_ID `
  --no-async `
  --region=REGION `
  --display-name=MIGRATION_JOB_NAME `
  --source=SOURCE_CONNECTION_PROFILE_ID `
  --destination=DESTINATION_CONNECTION_PROFILE_ID `
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Windows（cmd.exe）

      gcloud database-migration migration-jobs ^
create MIGRATION_JOB_ID ^
  --no-async ^
  --region=REGION ^
  --display-name=MIGRATION_JOB_NAME ^
  --source=SOURCE_CONNECTION_PROFILE_ID ^
  --destination=DESTINATION_CONNECTION_PROFILE_ID ^
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      次のようなレスポンスが返されます。

      Waiting for migration job [MIGRATION_JOB_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created migration job MIGRATION_JOB_ID [OPERATION_ID]

    ステップ 3b. Cloud SQL インスタンス サービス アカウントに必要な権限を付与する

    新しいインスタンスへの移行ジョブを作成するときに、Database Migration Service によって移行先の Cloud SQL インスタンスも作成されます。移行を実行する前に、インスタンスのサービス アカウントに Cloud Storage 権限を割り当てる必要があります。

    宛先インスタンスに関連付けられたサービス アカウントに Cloud Storage の権限を付与する手順は次のとおりです。

    1. Cloud SQL インスタンスの詳細ページで、Cloud SQL インスタンスのサービス アカウントのメールアドレスを探します。このアドレスの形式は <project-identifier>@gcp-sa-cloud-sql.iam.gserviceaccount.com です。Cloud SQL のドキュメントの インスタンス情報を表示するをご覧ください。
    2. サービス アカウントに Storage オブジェクト閲覧者（roles/storage.objectViewer）IAM ロールを追加します。Identity and Access Management でアクセス権を管理する方法については、IAM のドキュメントで プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

    ステップ 3c. （省略可）移行ジョブをテストする

    移行ジョブを実行する前に、テスト オペレーションを実行して、Database Migration Service が必要なすべての移行元エンティティと移行先エンティティに到達できるかどうかを確認できます。gcloud CLI を使用すると、作成済みだがまだ開始されていない移行ジョブをテストできます。

    コンソール

    Google Cloud コンソールでテストできるのは、移行ジョブ作成ウィザードで作成したドラフト移行ジョブのみです。ジョブを下書きとして保存せず、ウィザードで完全に作成した場合は、Google Cloud CLI を使用してのみテストを実行できます。

    ドラフト移行ジョブをテストする手順は次のとおりです。

    1. Google Cloud コンソールで、[移行ジョブ] ページに移動します。

      [移行ジョブ] に移動

    2. [下書き] タブで、作成を完了する移行ジョブの表示名をクリックします。

      移行ジョブの作成ウィザードが開きます。

    3. [移行ジョブのテストと作成] ページで、[ジョブをテスト] をクリックします。 Database Migration Service は、移行先インスタンスに必要なすべての権限があり、移行元データベースに接続できるかどうかを確認します。
    4. テストが完了したら、[作成] をクリックします。

      これで移行ジョブが作成され、開始できるようになりました。

    gcloud

    後述のコマンドデータを使用する前に、次のように置き換えます。

    • MIGRATION_JOB_ID は、移行ジョブ ID に置き換えます。

      ID がわからない場合は、 gcloud database-migration migration-jobs list コマンドを使用して、特定のリージョン内のすべての移行ジョブを一覧表示し、ID を表示できます。

    • REGION は、接続プロファイルが保存されているリージョンの ID に置き換えます。

    次のコマンドを実行します。

    Linux、macOS、Cloud Shell

    gcloud database-migration migration-jobs \
verify MIGRATION_JOB_ID \
  --region=REGION

    Windows（PowerShell）

    gcloud database-migration migration-jobs `
verify MIGRATION_JOB_ID `
  --region=REGION

    Windows（cmd.exe）

    gcloud database-migration migration-jobs ^
verify MIGRATION_JOB_ID ^
  --region=REGION

    結果

    アクションは非同期で実行されます。そのため、このコマンドは長時間実行オペレーションを表す オペレーション エンティティを返します。

    done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: verify
name: OPERATION_ID

    オペレーションが成功したかどうかを確認するには、返されたオペレーション オブジェクトをクエリするか、移行ジョブのステータスを確認します。

    ステップ 3d. 移行ジョブを開始する

    移行ジョブが完全に作成されたら（つまり、下書きの状態で保存されていない場合）、いつでも開始してデータの移行を開始できます。

    移行ジョブを開始する手順は次のとおりです。

    コンソール

    1. Google Cloud コンソールで、[移行ジョブ] ページに移動します。

      [移行ジョブ] に移動

    2. [ジョブ] タブで、開始する移行ジョブの表示名をクリックします。

      移行ジョブの詳細ページが開きます。

    3. [Start] をクリックします。
    4. ダイアログで [開始] をクリックします。

    gcloud

    後述のコマンドデータを使用する前に、次のように置き換えます。

    • MIGRATION_JOB_ID は、移行ジョブ ID に置き換えます。

      ID がわからない場合は、 gcloud database-migration migration-jobs list コマンドを使用して、特定のリージョン内のすべての移行ジョブを一覧表示し、ID を表示できます。

    • REGION は、接続プロファイルが保存されているリージョンの ID に置き換えます。

    次のコマンドを実行します。

    Linux、macOS、Cloud Shell

    gcloud database-migration migration-jobs \
start MIGRATION_JOB_ID \
  --region=REGION

    Windows（PowerShell）

    gcloud database-migration migration-jobs `
start MIGRATION_JOB_ID `
  --region=REGION

    Windows（cmd.exe）

    gcloud database-migration migration-jobs ^
start MIGRATION_JOB_ID ^
  --region=REGION

    結果

    アクションは非同期で実行されます。そのため、このコマンドは長時間実行オペレーションを表す オペレーション エンティティを返します。

    done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: start
name: OPERATION_ID

    オペレーションが成功したかどうかを確認するには、返されたオペレーション オブジェクトをクエリするか、移行ジョブのステータスを確認します。


  • 既存の移行先インスタンスに移行するには、まず移行先インスタンスを作成して構成する必要があります。

    ステップ 3a. 移行先インスタンスの準備

    移行先の Cloud SQL インスタンスを構成するには、次の操作を行います。

    1. Cloud SQL for MySQL の移行先インスタンスを作成します。移行のニーズを満たすのに十分なコンピューティング リソースとメモリ リソースを使用していることを確認します。Cloud SQL ドキュメントのインスタンスを作成するをご覧ください。

      移行に使用する接続方法によっては、宛先インスタンスにパブリック IP アドレスまたはプライベート IP アドレスを追加する必要があります。接続方法の詳細については、 接続を構成するをご覧ください。

    2. 宛先インスタンスに関連付けられたサービス アカウントに Cloud Storage の権限を付与します。このアカウントは、移行先インスタンスの作成後に作成します。
      1. Cloud SQL インスタンスの詳細ページで、Cloud SQL インスタンスのサービス アカウントのメールアドレスを探します。このアドレスの形式は <project-identifier>@gcp-sa-cloud-sql.iam.gserviceaccount.com です。Cloud SQL のドキュメントの インスタンス情報を表示するをご覧ください。
      2. サービス アカウントに Storage オブジェクト閲覧者（roles/storage.objectViewer）IAM ロールを追加します。Identity and Access Management でアクセス権を管理する方法については、IAM のドキュメントで プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
    3. Cloud SQL インスタンスの宛先接続プロファイルを作成します。

      コンソール

      宛先接続プロファイルを作成する必要はありません。 Google Cloud コンソールで移行ジョブを作成する場合は、宛先インスタンス ID を使用し、Database Migration Service が接続プロファイルを管理します。

      移行ジョブを作成して実行するセクションに進みます。

      gcloud

      このサンプルでは、オプションの --no-async フラグを使用して、すべてのオペレーションが同期的に実行されます。そのため、一部のコマンドは完了するまでに時間がかかることがあります。--no-async フラグをスキップして、コマンドを非同期で実行できます。その場合は、gcloud database-migration operations describe コマンドを使用して、オペレーションが成功したかどうかを確認する必要があります。

      後述のコマンドデータを使用する前に、次のように置き換えます。

      • CONNECTION_PROFILE_ID は、接続プロファイルの機械読み取り可能な識別子に置き換えます。
      • REGION は、接続プロファイルを保存するリージョンの ID に置き換えます。
      • DESTINATION_INSTANCE_ID は、宛先インスタンスのインスタンス ID に置き換えます。
      • （省略可）CONNECTION_PROFILE_NAME は、接続プロファイルのわかりやすい名前に置き換えます。この値は、 Google Cloud コンソールに表示されます。

      次のコマンドを実行します。

      Linux、macOS、Cloud Shell

      gcloud database-migration connection-profiles \
create mysql CONNECTION_PROFILE_ID \
  --no-async \
  --cloudsql-instance=DESTINATION_INSTANCE_ID \
  --region=REGION \
  --display-name=CONNECTION_PROFILE_NAME

      Windows（PowerShell）

      gcloud database-migration connection-profiles `
create mysql CONNECTION_PROFILE_ID `
  --no-async `
  --cloudsql-instance=DESTINATION_INSTANCE_ID `
  --region=REGION `
  --display-name=CONNECTION_PROFILE_NAME

      Windows（cmd.exe）

      gcloud database-migration connection-profiles ^
create mysql CONNECTION_PROFILE_ID ^
  --no-async ^
  --cloudsql-instance=DESTINATION_INSTANCE_ID ^
  --region=REGION ^
  --display-name=CONNECTION_PROFILE_NAME

      次のようなレスポンスが返されます。

      Waiting for connection profile [CONNECTION_PROFILE_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]

    ステップ 3b. 移行ジョブを作成して実行する

    コンソール

    移行ジョブの設定を定義する

    1. Google Cloud コンソールで、[移行ジョブ] ページに移動します。

      [移行ジョブ] に移動

    2. [移行ジョブを作成] をクリックします。

      移行ジョブ構成ウィザードのページが開きます。このウィザードには、各構成ステップを案内する複数のパネルがあります。

      [保存して終了] をクリックすると、移行ジョブの作成を一時停止できます。その時点で入力したデータはすべて、下書きの移行ジョブに保存されます。下書きの移行ジョブは後で完了できます。

    3. [開始] ページで、次の情報を入力します。
      1. 移行ジョブ名

        これは、移行ジョブのわかりやすい名前です。この値は、 Google Cloud コンソールに表示されます。

      2. 移行ジョブ ID

        これは、移行ジョブの機械読み取り可能な識別子です。この値は、Database Migration Service の Google Cloud CLI コマンドまたは API を使用して移行ジョブを操作する場合に使用します。

      3. [移行元データベース エンジン] リストから [MySQL] を選択します。

        [移行先のデータベース エンジン] フィールドには自動的に入力され、変更できません。

      4. 移行ジョブを保存するリージョンを選択します。

        Database Migration Service は完全にリージョン ベースのサービスです。つまり、移行に関連するすべてのエンティティ（移行元と移行先の接続プロファイル、移行ジョブ、移行先データベース）を 1 つのリージョンに保存する必要があります。Compute Engine インスタンス、App Engine アプリ、その他のサービスなど、データを必要とするサービスのロケーションに基づいてリージョンを選択します。宛先リージョンを選択した後、この選択を変更することはできません。

    4. [保存して次へ] をクリックします。

    ソース接続プロファイルに関する情報の指定

    1. [ソースを定義する] ページで、次の操作を行います。
      1. [ソース接続プロファイル] プルダウン メニューから、移行元データベースの接続プロファイルを選択します。
      2. [完全なダンプの構成のカスタマイズ] セクションで、[構成の編集] をクリックします。
      3. [完全ダンプ構成を編集] パネルで、[完全ダンプ方法] プルダウン メニューから [物理ベース] を選択します。
      4. [フォルダを指定] で [参照] をクリックし、完全なダンプファイルをアップロードしたフォルダを選択します（ソースデータを準備するセクションの手順 4）。
      5. [保存] をクリックします。
    2. [保存して次へ] をクリックします。

    宛先の Cloud SQL インスタンスを選択する

    1. [宛先インスタンスのタイプ] メニューから、[既存のインスタンス] を選択します。
    2. [宛先インスタンスの選択] セクションで、宛先インスタンスを選択します。
    3. [インスタンスの詳細] セクションで情報を確認して、[選択して続行] をクリックします。
    4. 既存の移行先データベースに移行するには、Database Migration Service はターゲット インスタンスを降格させ、レプリカに変換します。降格を安全に実行できることを示すには、確認ウィンドウで移行先インスタンス ID を入力します。
    5. [確認して次へ] をクリックします。

    移行元データベースと移行先データベースのインスタンス間の接続を設定する

    [接続方法] プルダウン メニューから、ネットワーク接続方法を選択します。この方法により、新しく作成された Cloud SQL インスタンスがソース データベースに接続される方法が定義されます。現在のネットワーク接続方法には、IP 許可リスト、リバース SSH トンネル、VPC ピアリングがあります。

    使用したい場合方法
    IP 許可リストのネットワーク接続方法 移行先インスタンスの送信 IP アドレスを指定する必要があります。作成した Cloud SQL インスタンスが高可用性インスタンスの場合は、プライマリ インスタンスとセカンダリ インスタンスの両方の送信 IP アドレスを含めます。
    リバース SSH トンネル ネットワーク接続方法 トンネルをホストする Compute Engine VM インスタンスを選択する必要があります。

    インスタンスを指定すると、ソース データベースと移行先データベースの間にトンネルを設定する手順を実行するスクリプトが提供されます。スクリプトは Google Cloud CLI で実行する必要があります。

    ソース データベースと Google Cloudの両方に接続できるマシンからコマンドを実行します。
    VPC ピアリング ネットワーク接続方法。 移行元データベースが存在する VPC ネットワークを選択する必要があります。このネットワークに接続するように Cloud SQL インスタンスが更新されます。

    ネットワーク接続を選択して構成したら、[構成して続行] をクリックします。

    移行ジョブをテスト、作成、実行する

    この最後のステップでは、移行ジョブの設定、ソース、移行先、接続方法の概要を確認し、移行ジョブの設定の有効性をテストします。問題が発生した場合は、移行ジョブの設定を変更できます。すべての設定を編集できるわけではありません。

    1. [移行ジョブのテストと作成] ページで、[ジョブをテスト] をクリックします。

      テストに失敗した場合は、フローの適切な部分で問題に対処してから、再テストに戻ることができます。失敗した移行ジョブのテストに関するトラブルシューティングについては、 MySQL の問題を診断するをご覧ください。

    2. 移行ジョブのテストが完了したら、[ジョブを作成して開始] をクリックします。

      移行が開始されました。移行ジョブを開始すると、Database Migration Service は完全なダンプを行い、移行元データベースを一時的にロックします。

    gcloud

    移行を構成して実行する手順は次のとおりです。

    1. 移行ジョブを作成します。
      次のコマンドを実行します（リンクをクリックして展開）。

      gcloud database-migration migration-jobs create

      このサンプルでは、オプションの --no-async フラグを使用して、すべてのオペレーションが同期的に実行されます。そのため、一部のコマンドは完了するまでに時間がかかることがあります。--no-async フラグをスキップして、コマンドを非同期で実行できます。その場合は、gcloud database-migration operations describe コマンドを使用して、オペレーションが成功したかどうかを確認する必要があります。

      後述のコマンドデータを使用する前に、次のように置き換えます。

      • MIGRATION_JOB_ID は、移行ジョブの機械読み取り可能な識別子に置き換えます。この値は、Database Migration Service の Google Cloud CLI コマンドまたは API を使用して移行ジョブを操作する場合に使用します。
      • REGION は、移行ジョブを保存するリージョン ID に置き換えます。
      • MIGRATION_JOB_NAME は、移行ジョブのわかりやすい名前に置き換えます。この値は、 Google Cloud コンソールの Database Migration Service に表示されます。
      • SOURCE_CONNECTION_PROFILE_ID は、移行元の接続プロファイルの機械読み取り可能な識別子に置き換えます。
      • DESTINATION_CONNECTION_PROFILE_ID は、移行先接続プロファイルの機械読み取り可能な ID に置き換えます。
      • MIGRATION_JOB_TYPE は、移行ジョブのタイプに置き換えます。使用できる値は ONE_TIME または CONTINUOUS の 2 つです。詳細については、 移行のタイプをご覧ください。
      • PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES は、Cloud Storage バケット内のフォルダに保存されている物理バックアップ ファイルのパスに置き換えます。gs://<bucket_name>/<path_to_backup_file_folder> の形式を使用します。
      • ネットワーク構成

        VPC ネットワーク ピアリングまたはリバース SSH トンネルでプライベート IP 接続を使用する場合は、次のフラグをコマンドに追加します。

        VPC ネットワーク ピアリングを使用したプライベート IP 接続
        --peer-vpc フラグを使用して、ピアリングするネットワークの名前を指定します。
        Compute Engine VM のリバース SSH トンネル
        Compute Engine のネットワークの詳細を指定するには、次のフラグを使用します。 --vm-ip、 --vm-port、 --vpc。省略可能な --vm フラグを使用して VM の名前を指定することもできます。

        その他の使用例については、 Google Cloud CLI の例をご覧ください。

      次のコマンドを実行します。

      Linux、macOS、Cloud Shell

      gcloud database-migration migration-jobs \
create MIGRATION_JOB_ID \
  --no-async \
  --region=REGION \
  --display-name=MIGRATION_JOB_NAME \
  --source=SOURCE_CONNECTION_PROFILE_ID \
  --destination=DESTINATION_CONNECTION_PROFILE_ID \
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Windows（PowerShell）

      gcloud database-migration migration-jobs `
create MIGRATION_JOB_ID `
  --no-async `
  --region=REGION `
  --display-name=MIGRATION_JOB_NAME `
  --source=SOURCE_CONNECTION_PROFILE_ID `
  --destination=DESTINATION_CONNECTION_PROFILE_ID `
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Windows（cmd.exe）

      gcloud database-migration migration-jobs ^
create MIGRATION_JOB_ID ^
  --no-async ^
  --region=REGION ^
  --display-name=MIGRATION_JOB_NAME ^
  --source=SOURCE_CONNECTION_PROFILE_ID ^
  --destination=DESTINATION_CONNECTION_PROFILE_ID ^
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      次のようなレスポンスが返されます。

      Waiting for migration job [MIGRATION_JOB_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created migration job MIGRATION_JOB_ID [OPERATION_ID]

    2. Cloud SQL の移行先インスタンスを降格します。
      次のコマンドを実行します（リンクをクリックして展開）。

      gcloud database-migration migration-jobs demote-destination

      後述のコマンドデータを使用する前に、次のように置き換えます。

      • MIGRATION_JOB_ID は、移行ジョブ ID に置き換えます。

        ID がわからない場合は、 gcloud database-migration migration-jobs list コマンドを使用して、特定のリージョン内のすべての移行ジョブを一覧表示し、ID を表示できます。

      • REGION は、接続プロファイルが保存されているリージョンの ID に置き換えます。

      次のコマンドを実行します。

      Linux、macOS、Cloud Shell

      gcloud database-migration migration-jobs \
demote-destination MIGRATION_JOB_ID \
  --region=REGION

      Windows（PowerShell）

      gcloud database-migration migration-jobs `
demote-destination MIGRATION_JOB_ID `
  --region=REGION

      Windows（cmd.exe）

      gcloud database-migration migration-jobs ^
demote-destination MIGRATION_JOB_ID ^
  --region=REGION

      結果

      アクションは非同期で実行されます。そのため、このコマンドは長時間実行オペレーションを表す オペレーション エンティティを返します。

      done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: demote-destination
name: OPERATION_ID

      オペレーションが成功したかどうかを確認するには、返されたオペレーション オブジェクトをクエリするか、移行ジョブのステータスを確認します。

    3. （省略可）移行ジョブテストを実行する
      チェックを実行して、Database Migration Service が必要なすべての移行元エンティティと移行先エンティティに到達できるかどうかを確認できます。次のコマンドを実行します（リンクをクリックして展開）。

      gcloud database-migration migration-jobs verify

      後述のコマンドデータを使用する前に、次のように置き換えます。

      • MIGRATION_JOB_ID は、移行ジョブ ID に置き換えます。

        ID がわからない場合は、 gcloud database-migration migration-jobs list コマンドを使用して、特定のリージョン内のすべての移行ジョブを一覧表示し、ID を表示できます。

      • REGION は、接続プロファイルが保存されているリージョンの ID に置き換えます。

      次のコマンドを実行します。

      Linux、macOS、Cloud Shell

      gcloud database-migration migration-jobs \
verify MIGRATION_JOB_ID \
  --region=REGION

      Windows（PowerShell）

      gcloud database-migration migration-jobs `
verify MIGRATION_JOB_ID `
  --region=REGION

      Windows（cmd.exe）

      gcloud database-migration migration-jobs ^
verify MIGRATION_JOB_ID ^
  --region=REGION

      結果

      アクションは非同期で実行されます。そのため、このコマンドは長時間実行オペレーションを表す オペレーション エンティティを返します。

      done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: verify
name: OPERATION_ID

      オペレーションが成功したかどうかを確認するには、返されたオペレーション オブジェクトをクエリするか、移行ジョブのステータスを確認します。

    4. 移行ジョブを開始します。
      次のコマンドを実行します（リンクをクリックして展開します）。

      gcloud database-migration migration-jobs start

      後述のコマンドデータを使用する前に、次のように置き換えます。

      • MIGRATION_JOB_ID は、移行ジョブ ID に置き換えます。

        ID がわからない場合は、 gcloud database-migration migration-jobs list コマンドを使用して、特定のリージョン内のすべての移行ジョブを一覧表示し、ID を表示できます。

      • REGION は、接続プロファイルが保存されているリージョンの ID に置き換えます。

      次のコマンドを実行します。

      Linux、macOS、Cloud Shell

      gcloud database-migration migration-jobs \
start MIGRATION_JOB_ID \
  --region=REGION

      Windows（PowerShell）

      gcloud database-migration migration-jobs `
start MIGRATION_JOB_ID `
  --region=REGION

      Windows（cmd.exe）

      gcloud database-migration migration-jobs ^
start MIGRATION_JOB_ID ^
  --region=REGION

      結果

      アクションは非同期で実行されます。そのため、このコマンドは長時間実行オペレーションを表す オペレーション エンティティを返します。

      done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: start
name: OPERATION_ID

      オペレーションが成功したかどうかを確認するには、返されたオペレーション オブジェクトをクエリするか、移行ジョブのステータスを確認します。

      移行ジョブを開始すると、移行先の Cloud SQL インスタンスは読み取り専用モードになり、Database Migration Service によって完全に管理されます。データが完全に移行されたら、スタンドアロン インスタンスに昇格できます。

      注: 移行の進行状況と移行先インスタンスの状態は、Database Migration Service のオブザーバビリティ機能を使用してモニタリングできます。[移行ジョブの指標](/database-migration/docs/mysql/migration-job-metrics) をご覧ください。

ステップ 4. （省略可）移行を停止する

データ移行プロセスをキャンセルする場合は、移行ジョブをいつでも停止して削除できます。移行ジョブは、 Google Cloud コンソールまたは Google Cloud CLI で管理できます。

ステップ 5. 移行を完了する

移行ジョブが正常に完了したら、次のいずれかの手順で移行ジョブを確定します。

  • 1 回限りの移行の場合: 移行ジョブのステータスが [Complete] に変わります。移行ジョブと接続プロファイルのリソースをクリーンアップできます。

  • 継続的な移行の場合: 移行ジョブを昇格して、アプリケーションを新しいデータベース インスタンスに切り替えます。