既存の移行先インスタンスへの移行ジョブを作成する

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

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

• 移行ジョブの設定を定義します
• ソース データベース接続プロファイルを選択する
• 既存の移行先データベース インスタンスを選択する
• 既存のインスタンスを降格してリードレプリカに変換する
• 移行元データベースと移行先データベースのインスタンス間の接続を設定します
• 移行ジョブをテストして、ジョブに指定した接続情報が有効であることを確認します

Database Migration Service の外部で作成された移行先インスタンスに移行する場合は、考慮すべき制限事項があります。たとえば、Cloud SQL の宛先インスタンスは空であるか、システム構成データのみが含まれている必要があります。詳細については、既知の制限事項をご覧ください。

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

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 アプリなどのサービスや、その他のサービスなど、データを必要とするサービスのロケーションに基づいてリージョンを選択します。宛先リージョンを選択すると、この選択を変更することはできません。

      重要: Cloud SQL for MySQL Enterprise Plus エディションを使用する場合は、そのエディションでリージョンがサポートされていることを確認してください。 Cloud SQL for MySQL Enterprise Plus エディションのリージョン サポートをご覧ください。
4. [保存して次へ] をクリックします。

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

[ソースを定義する] ページで、次の操作を行います。

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

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

     このセクションを開くと、完全な論理バックアップ ファイルの手順が表示されます

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

     1. 自動生成（推奨）

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

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

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

        • データダンプの並列処理: MySQL バージョン 5.7 または 8 に移行する場合に使用できる、高パフォーマンスの並列処理オプションを使用します。
          データダンプの並列処理を使用する場合は、シナリオに必要な権限（LOCK_TABLES など）を移行元データベースに付与してください。移行元データベースに必要な権限の詳細については、 移行元データベースを構成するをご覧ください。

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

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

          フラグを追加するには:

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

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

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

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

     2. 独自に指定

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

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

        ダンプが 24 時間以内に作成され、 ダンプ要件に準拠していることを確認してください。

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

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

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

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

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

使用したい場合	方法
IP 許可リストのネットワーク接続方法。	移行先インスタンスの送信 IP アドレスを指定する必要があります。作成した Cloud SQL インスタンスが高可用性インスタンスの場合は、プライマリ インスタンスとセカンダリ インスタンスの両方の送信 IP アドレスを含めます。
リバース SSH トンネル ネットワーク接続方法。	トンネルをホストする Compute Engine VM インスタンスを選択する必要があります。 インスタンスを指定すると、移行元データベースと移行先データベースの間にトンネルを設定する手順を実行するスクリプトが提供されます。Google Cloud CLI でスクリプトを実行する必要があります。 移行元データベースと Google Cloudの両方に接続できるマシンからコマンドを実行します。
Private Service Connect インターフェースの接続方法。	Database Migration Service は、必要な接続を自動的に確立します。この接続方法は、ネットワーク アタッチメントを含む Private Service Connect 対応インスタンスがある場合にのみ使用できます。Private Service Connect インターフェースの詳細については、Cloud SQL ドキュメントの Private Service Connect アウトバウンド接続をご覧ください。
VPC ピアリング ネットワーク接続方法。	移行元データベースが存在する VPC ネットワークを選択する必要があります。このネットワークに接続するために Cloud SQL インスタンスが更新されます。

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

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

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

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

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

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

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

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

   注意: Terraform を使用して移行先データベースをプロビジョニングした場合、移行ジョブの実行中に構成のドリフトが発生する可能性があります。移行が完了する前に Terraform 設定を再適用しないでください。詳細については、 Terraform 構成のドリフトをご覧ください。
3. 移行ジョブを確認するに進みます。

Google Cloud CLI を使用して移行ジョブを作成する

Google Cloud CLI を使用して既存のインスタンスに移行する場合は、移行先インスタンスの接続プロファイルを自分で作成する必要があります。 Google Cloud コンソールを使用する場合、Database Migration Service が移行先の接続プロファイルの作成と削除を行うため、この操作は必要ありません。

始める前に

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

• 移行先データベース インスタンスを作成します。
• 移行元データベース インスタンスを準備します。以下をご覧ください。
  • ソースを構成する
  • 移行元の接続プロファイルを作成します（移行ジョブの作成には移行元の接続プロファイル ID が必要です）。
  • 接続を構成する

移行先接続プロファイルを作成する

gcloud database-migration connection-profiles create コマンドを実行して、既存の宛先インスタンスの宛先接続プロファイルを作成します。

このサンプルでは、すべてのオペレーションが同期的に実行されるように、オプションの --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

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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]

移行ジョブを作成する

注: 次の例は、移行元データベースと移行先データベース間でプライベート IP 接続を使用する移行シナリオを表しています。別の接続タイプ（VPC ピアリングやリバース SSH トンネルなど）を使用する場合は、--peer-vpc や --vm, --vm-ip, --vm-port, --vpc などの必要なフラグを追加してください。詳細については、接続を構成すると Google Cloud CLI の例をご覧ください。

このサンプルでは、すべてのオペレーションが同期的に実行されるように、オプションの --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 は、移行先接続プロファイルの機械可読形式の識別子に置き換えます。

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

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

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

• MIGRATION_JOB_TYPE: 移行ジョブのタイプ。使用できる値は ONE_TIME または CONTINUOUS の 2 つです。詳細については、 移行のタイプをご覧ください。

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

Linux、macOS、Cloud Shell

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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]

移行先データベースを降格する

Database Migration Service では、移行時に移行先データベース インスタンスがリードレプリカとして機能する必要があります。移行ジョブを開始する前に、gcloud database-migration migration-jobs demote-destination コマンドを実行して移行先データベース インスタンスを降格します。

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

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

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

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

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

Linux、macOS、Cloud Shell

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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

Windows（PowerShell）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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

Windows（cmd.exe）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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

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

• gcloud database-migration migration-jobs describe コマンドを使用して、移行ジョブのステータスを表示します。
• gcloud database-migration operations describe と OPERATION_ID を使用して、オペレーション自体のステータスを確認します。

移行ジョブの管理

この時点で、移行ジョブが構成され、移行先データベース インスタンスに接続されます。verify、start、stop、restart、resume オペレーションを使用して管理できます。

移行ジョブを確認する

最初に gcloud database-migration migration-jobs verify コマンドを実行して、移行ジョブを確認することをおすすめします。

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

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

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

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

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

Linux、macOS、Cloud Shell

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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

Windows（PowerShell）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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

Windows（cmd.exe）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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

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

• gcloud database-migration migration-jobs describe コマンドと MIGRATION_JOB_ID を使用して、移行ジョブのステータスを表示します。
• gcloud database-migration operations describe コマンドと OPERATION_ID を使用して、オペレーション自体のステータスを確認します。

移行ジョブを開始する

gcloud database-migration migration-jobs start コマンドを実行して、移行ジョブを開始します。

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

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

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

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

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

Linux、macOS、Cloud Shell

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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

Windows（PowerShell）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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

Windows（cmd.exe）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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

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

• gcloud database-migration migration-jobs describe コマンドと MIGRATION_JOB_ID を使用して、移行ジョブのステータスを表示します。
• gcloud database-migration operations describe コマンドと OPERATION_ID を使用して、オペレーション自体のステータスを確認します。

移行ジョブを昇格させる

移行が変更データ キャプチャ（CDC）フェーズに達すると、移行先データベース インスタンスをリードレプリカからスタンドアロン インスタンスに昇格できます。gcloud database-migration migration-jobs promote コマンドを実行します。

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

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

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

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

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

Linux、macOS、Cloud Shell

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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

Windows（PowerShell）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

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

Windows（cmd.exe）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud database-migration migration-jobs ^
promote 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

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

• gcloud database-migration migration-jobs describe コマンドと MIGRATION_JOB_ID を使用して、移行ジョブのステータスを表示します。
• gcloud database-migration operations describe コマンドと OPERATION_ID を使用して、オペレーション自体のステータスを確認します。