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 に移行することはできません。

  • クロス アーキテクチャに関する考慮事項: Cloud SQL は ARM アーキテクチャをサポートしています。データベースを移行できるのは、同じアーキテクチャ タイプのマシン間のみです。たとえば、データベースが ARM64 マシンでホストされている場合は、ARM64 マシンに移行する必要があります。

  • 移行先データベースのディスクサイズは、移行元データベースのサイズ以上である必要があります。詳細については、Cloud SQL エディションの MySQL マシンタイプをご覧ください。

  • 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 は完全にリージョン プロダクトです。つまり、移行に関連するすべてのエンティティ（移行元と移行先の接続プロファイル、移行ジョブ、移行先のデータベース、ストレージ バケット）は、単一のリージョンに保存する必要があります。

  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 は完全にリージョン プロダクトです。つまり、移行に関連するすべてのエンティティ（移行元と移行先の接続プロファイル、移行ジョブ、移行先データベース、バックアップ ファイルのストレージ バケット）は、単一のリージョンに保存する必要があります。

  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. [作成] をクリックします。これで接続プロファイルが作成されました。

    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 は完全にリージョンに依存するプロダクトです。つまり、移行に関連するすべてのエンティティ（移行元と移行先の接続プロファイル、移行ジョブ、移行先のデータベース）は、単一のリージョンに保存する必要があります。Compute Engine インスタンスや App Engine アプリなどのサービスや、その他のサービスなど、データを必要とするサービスのロケーションに基づいてリージョンを選択します。宛先リージョンを選択すると、この選択を変更することはできません。

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

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

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

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

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

        識別子には機密情報や個人を特定できる情報を含めないでください。インスタンス名にプロジェクト 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 インスタンスのマシンタイプを選択します。

      詳細については、制限事項をご覧ください。

    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 を使用すると、作成済みでまだ開始されていない移行ジョブをテストできます。

    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 フラグを使用します。

        • Cloud SQL for MySQL Enterprise Plus エディションの enterprise-plus
        • Cloud SQL for MySQL Enterprise エディションの enterprise
      • TIER は、使用する Cloud SQL マシンタイプの名前で置き換えます。マシンタイプは、Cloud SQL の規則に従った文字列として指定します（例: db-n1-standard-1、db-perf-optimized-N-2）。Google Cloud CLI で使用できるマシンタイプとその識別子の完全なリストについては、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 は、移行元接続プロファイルの機械可読 ID に置き換えます。
      • DESTINATION_CONNECTION_PROFILE_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 は、接続プロファイルが保存されているリージョンの識別子に置き換えます。

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

    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. [開始] をクリックします。
    4. ダイアログで [開始] をクリックします。

    gcloud

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

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

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

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

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

    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 コンソールで移行ジョブを作成する場合は、移行先インスタンスの識別子を使用します。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 は完全にリージョンに依存するプロダクトです。つまり、移行に関連するすべてのエンティティ（移行元と移行先の接続プロファイル、移行ジョブ、移行先のデータベース）は、単一のリージョンに保存する必要があります。Compute Engine インスタンスや App Engine アプリなどのサービスや、その他のサービスなど、データを必要とするサービスのロケーションに基づいてリージョンを選択します。宛先リージョンを選択すると、この選択を変更することはできません。

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

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

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

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

    1. [宛先インスタンスのタイプ] メニューから、[既存のインスタンス] を選択します。
    2. [宛先インスタンスを選択] セクションで、宛先インスタンスを選択します。
    3. [インスタンスの詳細] セクションの情報を確認し、[選択して続行] をクリックします。
    4. 既存の移行先データベースに移行する場合、Database Migration Service はターゲット インスタンスを降格させ、レプリカに変換します。降格を安全に実行できることを示すため、確認ウィンドウで移行先インスタンスの識別子を入力します。
    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 は、移行元接続プロファイルの機械可読 ID に置き換えます。
      • DESTINATION_CONNECTION_PROFILE_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 は、接続プロファイルが保存されているリージョンの識別子に置き換えます。

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

      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 は、接続プロファイルが保存されているリージョンの識別子に置き換えます。

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

      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 は、接続プロファイルが保存されているリージョンの識別子に置き換えます。

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

      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 回限りの移行の場合: 移行ジョブのステータスが [完了] に変わります。これ以上の操作は必要ありません。移行ジョブと接続プロファイルのリソースをクリーンアップできます。

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