新しい移行先インスタンスへの移行ジョブを作成する

Database Migration Service で移行先インスタンスを作成すると、そのインスタンスは自動的に降格され、読み取り専用レプリカとして実行されます。つまり、一部のオペレーションが制限されます。たとえば、移行の進行中に新しい移行先にユーザーを作成する場合は、 Google Cloud コンソールで Cloud SQL を使用します。詳細については、Cloud SQL ドキュメントのユーザーを管理するをご覧ください。

Database Migration Service は、移行ジョブを使用して、移行元のデータベース インスタンスから移行先のデータベース インスタンスにデータを移行します。新しい移行先インスタンスの移行ジョブの作成には、次の操作が含まれます。

  • 移行ジョブの設定を定義します
  • ソース データベース接続プロファイルの選択
  • 移行先の Cloud SQL データベース インスタンスの設定を定義し、インスタンスを作成します
  • 移行元データベースと移行先データベースのインスタンス間の接続を設定します
  • 移行ジョブをテストして、ジョブに指定した接続情報が有効であることを確認します

始める前に

新しい移行先データベース インスタンスへの移行ジョブを作成する前に、次のことを確認してください。

  1. この移行タイプがシナリオをサポートできることを確認します。詳細については、既知の制限事項をご覧ください。
  2. ソース データベースを構成し、ネットワーク接続を確立します。移行ジョブの作成は、移行プロセス全体の手順の 1 つです。移行のステップバイステップ ガイドに沿って、移行ジョブのステップに到達したら、この手順に戻ることをおすすめします。 新しいインスタンスに移行するをご覧ください。

新しい移行先インスタンスへの移行ジョブを作成するには:

コンソール

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

  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. [ソース接続プロファイル] プルダウン メニューから、ソース データベースの接続プロファイルを選択します。
  2. [完全なダンプの構成のカスタマイズ] セクションで、[構成の編集] をクリックします。
  3. [フルダンプ構成の編集] パネルの [フルダンプ方法] プルダウン メニューから、次のいずれかを選択します。
    • 物理ベース: Percona XtraBackup ユーティリティを使用して独自のバックアップ ファイルを提供する場合は、このオプションを選択します。このアプローチでは、追加の準備手順が必要です。Percona XtraBackup で生成された物理バックアップ ファイルの使用に関する詳細なガイドについては、Percona XtraBackup 物理ファイルを使用してデータベースを移行するをご覧ください。
    • 論理ベース: mysqldump ユーティリティによって作成された論理バックアップ ファイルを使用する場合は、このオプションを選択します。Database Migration Service は、このバックアップ ファイルを自動的に生成できます。独自のコピーを指定することもできます。
  4. 残りのダンプ設定を編集します。次のいずれかを行います。
    • 物理バックアップ ファイルを使用する場合は、[フォルダを指定] で [参照] をクリックし、完全なダンプファイルをアップロードしたフォルダを選択します。ストレージ バケット自体ではなく、フル バックアップ ファイルを含む専用フォルダを選択してください。

    • 論理バックアップ ファイルを使用する場合は、データダンプの並列処理またはダンプフラグを構成します。

      このセクションを開いて、論理バックアップ ファイルの手順を確認してください。

      [ダンプファイルの生成方法の選択] セクションで、次のいずれかのオプションを使用します。

      1. 初期ダンプを自動生成する（推奨）

        Database Migration Service は、移行ジョブの作成と開始後に常に初期データベース ダンプファイルを生成するため、このオプションをおすすめします。

        Database Migration Service は、このファイルを使用して、移行元データベースの元のオブジェクト定義とテーブルデータを再現し、この情報を移行先の Cloud SQL データベース インスタンスに移行できるようにします。

        自動生成されたダンプを使用する場合は、[データ ダンプ オペレーションを構成する] セクションで、Database Migration Service が実行するオペレーションのタイプを選択します。

        • データダンプの並列処理: MySQL バージョン 5.7 または 8 に移行する場合に使用できる、高性能の並列処理オプションを使用します。

          データ並列処理の速度は、ソース データベースに発生する負荷の量に関連しています。

          • 最適（推奨）: ソース データベースへの負荷が最適な状態になり、バランスの取れたパフォーマンスが実現します。
          • 最大: ダンプ速度が最も速くなりますが、ソース データベースの負荷が増加する可能性があります。
          • 最小: ソース データベースに対して使用されるコンピューティング リソースの量は最小になりますが、ダンプ スループットが低下する可能性があります。
        • ダンプフラグ: このオプションは、データダンプの並列処理のレベルと排他的です。この設定を使用して、ダンプファイルの作成に使用される mysqldump ユーティリティのフラグを直接構成します。

          フラグを追加するには:

          1. [フラグを追加] をクリックします。

          2. 次のいずれかのフラグを選択します。

            • add-locks: このフラグは、ダンプファイルに含まれる各テーブルを LOCK TABLES ステートメントと UNLOCK TABLES ステートメントで囲みます。これにより、ダンプファイルが移行先インスタンスに読み込まれる際の挿入が高速になります。
            • ignore-error: このフラグを使用して、カンマ区切りのエラー番号のリストを入力します。これらの数字は、mysqldump ユーティリティが無視するエラーを表します。
            • max-allowed-packet: このフラグを使用して、MySQL クライアントとソース MySQL データベース間の通信用のバッファの最大サイズを設定します。バッファのデフォルトのサイズは 24 MB、最大サイズは 1 GB です。
          3. [完了] をクリックします。
          4. 追加するフラグごとに、この手順を繰り返します。

          フラグを削除するには、フラグがある行の右側のゴミ箱アイコンをクリックします。

      2. 独自に指定

        デフォルトでは、Database Migration Service は移行ジョブの実行の一部として初期ダンプを実行するため、このオプションはおすすめしません。

        独自のダンプファイルを使用する場合は、[独自に用意する] を選択し、[参照] をクリックして、ファイル（複数のファイルを使用する場合は Cloud Storage フォルダ全体）を選択し、[選択] をクリックします。

        ダンプが過去 24 時間以内に生成され、ダンプの要件に準拠していることを確認します。
  5. [保存して次へ] をクリックします。

移行先の 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. [リージョン] メニューには、[スタートガイド] ページで選択したリージョンと同じリージョンが表示されます。

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

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

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

          このセクションを開いて、プライベート IP の要件の詳細を確認してください。

          • Service Networking API が有効になっている。Service Networking API は、 Google Cloud コンソールを使用して有効にできます。
          • servicenetworking.services.addPeering IAM 権限が付与されている。
          • プロジェクトにプライベート サービス アクセスが構成されている。これには、compute.networkAdmin IAM ロールが必要です。
          • プロジェクトに、1 つ以上の非レガシー VPC ネットワークまたは共有 VPC ネットワークがある。
          • 共有 VPC ネットワークを使用している場合は、次のことも行う必要があります。
            • ホスト プロジェクトで Service Networking API を有効にします。
            • ユーザーをホスト プロジェクトに追加します。
            • ホスト プロジェクトの compute.networkAdmin IAM ロールをユーザーに付与します。
        • ピアリングする関連付けられた 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 ピアリング、Cloud SQL for MySQL ソース専用の特殊な VPC ピアリングなどがあります。

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

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

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

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

移行データベースを構成する

ソース インスタンスからすべてのデータベースを移行することも、特定のデータベースのみを選択することもできます。移行先に選択したデータベースと同じ名前のデータベースを移行先に含めることはできません。Database Migration Service でデータベース名の競合が発生すると、移行前に移行先で問題のあるデータベースが削除されます。

  1. [移行するデータベース] リストから、次のいずれかのオプションを選択します。
    • すべてのデータベース: ソースに存在するすべてのデータベースを選択します。
    • 特定のデータベース: ソースに存在するすべてのデータベースから特定のデータベースを選択できます。

  2. 特定のデータベースを移行する場合は、表示されるリストをフィルタして、Database Migration Service で移行先に移行するデータベースを選択します。

    リストが表示されず、データベース検出エラーが表示された場合は、[再読み込み] をクリックします。データベースの検出に失敗すると、ジョブはすべてのデータベースを移行します。移行ジョブの作成を続行し、後で接続エラーを修正できます。

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

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

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

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

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

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

    ジョブが作成時に開始されない場合は、[移行ジョブ] ページで [開始] をクリックして開始できます。移行ジョブの開始時期に関係なく、移行先インスタンスの存在に対して組織に課金されます。

    移行が開始されました。移行ジョブを開始すると、Database Migration Service が完全なダンプを開始し、移行元データベースを一時的にロックします。移行元が Amazon RDS または Amazon Aurora にある場合、Database Migration Service では、移行の開始時に短時間（約 1 分未満）の書き込みダウンタイムが必要です。詳細については、既知の制限事項をご覧ください。

  3. 移行ジョブを確認するに進みます。

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 で使用できるマシンタイプとその識別子の完全なリストについては、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. 移行ジョブを作成します。
    VPC ピアリングまたはリバース SSH トンネル接続を使用する場合は、--peer-vpc、--vm、--vm-ip、--vm-port、--vpc などの必要なフラグを追加してください。詳細については、接続を構成すると Google Cloud CLI の例をご覧ください。
    次のコマンドを実行します（リンクをクリックして展開します）。

    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。移行先接続プロファイルの機械で読み取り可能な識別子。

    • 省略可: Database Migration Service は、デフォルトで移行元のすべてのデータベースを移行します。特定のデータベースのみを移行する場合は、--databases-filter フラグを使用して、それらの識別子をカンマ区切りのリストとして指定します。

      例: --databases-filter=my-business-database,my-other-database

      --databases-filter フラグを使用して作成した移行ジョブは、後で gcloud database-migration migration-jobs update コマンドを使用して編集できます。

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

    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

    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

    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

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

    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]