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

既存の移行先 AlloyDB for PostgreSQL クラスタに移行すると、Database Migration Service は移行先クラスタをデモートして外部レプリカとして構成します。クラスタを降格しても、AlloyDB for PostgreSQL は読み取り専用モードになりませんが、移行プロセス中に特定のオペレーションを実行すると、移行エラーが発生する可能性があります。既存の移行先クラスタに移行する場合は、次の運用上の考慮事項に留意してください。
  • クラスタの降格: Database Migration Service は、移行先クラスタを降格して、移行元データベースのレプリカとして構成します。
  • 移行中のデータに対する書き込みオペレーションを回避する: 移行に含まれるテーブルまたはデータベースの宛先クラスタで、書き込みオペレーション（INSERT、UPDATE、DELETE、DDL スキーマの変更など）を実行しないでください。このようなオペレーションを行うと、ソースから取得したデータとレプリケーションの競合が発生する可能性があります。
  • データベース ユーザーを管理する: データベース ユーザーは、標準の psql コマンドを使用するか、 Google Cloud コンソールの AlloyDB for PostgreSQL を使用して、いつでも作成および管理できます。詳細については、AlloyDB for PostgreSQL のドキュメントのデータベース ユーザーを管理するをご覧ください。

詳細については、既存の宛先クラスタの既知の制限事項をご覧ください。

Database Migration Service は、移行ジョブを使用して、移行元のデータベースから移行先の AlloyDB for PostgreSQL クラスタにデータを移行します。既存の宛先クラスタの移行ジョブを作成する手順は次のとおりです。

  • 移行ジョブの設定を定義します
  • ソース設定の定義と移行するデータベースの選択
  • 既存の移行先 AlloyDB for PostgreSQL クラスタを選択する
  • 既存のクラスタを降格して、ソース データベースのレプリカとして構成する
  • 移行元データベースと移行先データベースの間の接続を設定する
  • 移行ジョブをテストして、指定した接続情報が有効であることを確認します

始める前に

既存の移行先 AlloyDB for PostgreSQL クラスタへの移行ジョブを作成する前に、次のことを確認してください。

  1. この移行タイプがシナリオをサポートできることを確認します。 たとえば、Database Migration Service の外部で作成されたクラスタに移行する場合、AlloyDB for PostgreSQL の移行先クラスタは空であるか、システム構成データのみが含まれている必要があります。 詳細については、既知の制限事項をご覧ください。

  2. 移行先の AlloyDB for PostgreSQL クラスタとそのプライマリ インスタンスを作成します。AlloyDB for PostgreSQL のドキュメントのクラスタとそのプライマリ インスタンスを作成するをご覧ください。

  3. 移行元データベース インスタンスを準備します。次のページをご覧ください。
    1. ソース データベースを構成する
    2. ソース接続プロファイルを作成する
    3. 接続を構成する

既存の移行先クラスタへの移行ジョブを作成するには、次の操作を行います。

コンソール

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

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

    [移行ジョブ] に移動する

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

    移行ジョブ構成ウィザードのページが開きます。 このウィザードには、各構成手順を説明する複数のパネルが含まれています。

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

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

      これは、移行ジョブの人が読める形式の名前です。この値は Google Cloud コンソールに表示されます。

    2. 移行ジョブ ID

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

    3. [移行元データベース エンジン] リストから [PostgreSQL] を選択します。
    4. [移行先データベース エンジン] リストから [AlloyDB for PostgreSQL] を選択します。
    5. 移行ジョブを保存するリージョンを選択します。

      Database Migration Service は、完全にリージョンに依存するプロダクトです。つまり、移行に関連するすべてのエンティティ（移行元と移行先の接続プロファイル、移行ジョブ、移行先クラスタ）を 1 つのリージョンに保存する必要があります。既存の宛先クラスタが配置されているリージョンを選択します。宛先リージョンを選択すると、この選択は変更できません。

    6. 移行サービスの種類として 継続的（スナップショット + 進行中の変更）を選択します。AlloyDB for PostgreSQL への同種移行では、継続的な移行のみがサポートされます。
  4. [保存して次へ] をクリックします。

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

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

  1. [ソース接続プロファイル] プルダウン メニューから、ソース データベースの接続プロファイルを選択します。
  2. [並列処理構成をカスタマイズする] セクションで、[並列処理構成を表示] をクリックします。

    最初の完全ダンプ中、pglogical 拡張機能はテーブルレベルでデータを複製し、個々の非パーティション分割テーブル、リーフ パーティション、主キーのないテーブルを複数のサブスクリプションに分割しません。つまり、強化されたデータダンプの並列処理では、1 つの大きな非パーティション分割テーブルの初期ダンプ速度を向上させることはできません。これは、そのテーブルが 1 つのサブスクリプション内でコピーされるためです。詳細については、データダンプの並列処理に関する考慮事項をご覧ください。

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

    • 最適（推奨）: ソース データベースへの負荷が最適な状態になり、バランスの取れたパフォーマンスが実現します。Database Migration Service は、データベースごとに最大 2 つのサブスクリプションを作成します（すべてのデータベースで合計最大 2 つ、移行されたデータベースごとに少なくとも 1 つのサブスクリプション）。
    • 最大: ダンプ速度が最も速くなりますが、ソース データベースの負荷が増加する可能性があります。Database Migration Service は、データベースごとに最大 4 つのサブスクリプションを作成します（すべてのデータベースで最大 4 つ、移行されたデータベースごとに少なくとも 1 つのサブスクリプション）。
    • 最小: ソース データベースに対して最小量のコンピューティング リソースが使用されますが、ダンプのスループットが低下する可能性があります。Database Migration Service は、データベースごとに 1 つのサブスクリプションを作成します。

    調整されたデータダンプ並列処理設定を選択する場合は、ソース データベースの max_replication_slots、max_wal_senders、max_worker_processes パラメータを必ず増やしてください。

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

移行先の AlloyDB for PostgreSQL クラスタを選択する

  1. [移行先インスタンスのタイプ] メニューから [既存のクラスタ] を選択します。
  2. [移行先クラスタを選択] セクションで、移行先の AlloyDB for PostgreSQL クラスタを選択します。

  3. [クラスタの詳細] セクションの情報を確認し、[選択して続行] をクリックします。

    既存の移行先データベースに移行するために、Database Migration Service はターゲット クラスタを降格し、レプリカとして構成します。デモートを安全に実行できることを示すには、確認ウィンドウで宛先クラスタ ID を入力します。

  4. [確認して次へ] をクリックします。

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

[接続方法] プルダウン メニューから、ネットワーク接続方法を選択します。この方法により、移行先の AlloyDB for PostgreSQL クラスタとソース データベースとの接続方法が定義されます。現在のネットワーク接続方法には、IP 許可リスト、リバース SSH トンネル、Private Service Connect インターフェース、VPC ピアリング、クラウドホスト型 VM を介した TCP プロキシがあります。

使用したい場合...方法
IP 許可リストのネットワーク接続方法 移行先クラスタのプライマリ インスタンスのアウトバウンド パブリック IP アドレスを両方コピーし、それらを使用して、移行元データベース サーバーと pg_hba.conf ファイルでネットワーク ファイアウォールを構成します。
リバース SSH トンネル ネットワーク接続方法 トンネルをホストする Compute Engine VM インスタンスを選択します。

インスタンスを指定すると、移行元データベースと移行先データベースの間にトンネルを設定する手順を実行するスクリプトが提供されます。ソース データベースと Google Cloudの両方に接続できるマシンから、Google Cloud CLI でスクリプトを実行します。
Private Service Connect インターフェースの接続方法 Database Migration Service は、必要な接続を自動的に確立します。この接続方法は、Private Service Connect が有効で、ネットワーク アタッチメントがある宛先クラスタがある場合にのみ使用できます。Private Service Connect の詳細については、AlloyDB for PostgreSQL のドキュメントの Private Service Connect を構成するをご覧ください。
VPC ピアリング ネットワーク接続方法 移行元データベースが存在する VPC ネットワークを選択します。AlloyDB for PostgreSQL クラスタは、プライベート サービス アクセスを使用してこのネットワークに接続します。
クラウドでホストされている VM の接続方式を使用した TCP プロキシ TCP プロキシをホストする新しい Compute Engine VM インスタンスに必要な詳細情報を入力します。

詳細を指定すると、 Google Cloud コンソールに、移行元データベースと移行先データベースの間にプロキシを設定するスクリプトが表示されます。更新された Google Cloud CLI がインストールされているマシンでスクリプトを実行します。

スクリプトを実行したら、新しく作成した VM のプライベート IP アドレスを入力し、[構成して続行] をクリックします。

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

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

移行元インスタンスからすべてのデータベースを移行することも、特定のデータベースのみを選択することもできます。

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

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

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

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

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

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

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

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

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

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

    移行が進行中です。移行ジョブを開始すると、Database Migration Service は最初の完全ダンプと継続的なレプリケーションを開始します。詳細については、既知の制限事項をご覧ください。

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

Google Cloud CLI

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

  1. 宛先接続プロファイルを作成します。
    gcloud database-migration connection-profiles create コマンドを実行して、既存の宛先クラスタの宛先接続プロファイルを作成します（リンクをクリックして展開）。

    gcloud database-migration connection-profiles create postgresql

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

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

    • DEST_CONN_ID は、宛先接続プロファイルの識別子に置き換えます。
    • REGION は、接続プロファイルを保存するリージョンに置き換えます。このリージョンは、宛先クラスタのリージョンと同じにする必要があります。
    • DEST_CLUSTER は、事前に作成した移行先の AlloyDB for PostgreSQL クラスタの ID に置き換えます。
    • DEST_USER は、移行先データベースの移行ユーザーのユーザー名に置き換えます。
    • DEST_PASSWORD は、移行先データベースの移行ユーザーのパスワードに置き換えます。

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

    Linux、macOS、Cloud Shell

    gcloud database-migration connection-profiles create postgresql DEST_CONN_ID \
  --region=REGION \
  --alloydb-cluster=DEST_CLUSTER \
  --username=DEST_USER \
  --password=DEST_PASSWORD \
  --role=DESTINATION \
  --no-async

    Windows（PowerShell）

    gcloud database-migration connection-profiles create postgresql DEST_CONN_ID `
  --region=REGION `
  --alloydb-cluster=DEST_CLUSTER `
  --username=DEST_USER `
  --password=DEST_PASSWORD `
  --role=DESTINATION `
  --no-async

    Windows（cmd.exe）

    gcloud database-migration connection-profiles create postgresql DEST_CONN_ID ^
  --region=REGION ^
  --alloydb-cluster=DEST_CLUSTER ^
  --username=DEST_USER ^
  --password=DEST_PASSWORD ^
  --role=DESTINATION ^
  --no-async

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

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

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

Created connection profile DEST_CONN_ID [OPERATION_ID]

  2. 移行ジョブを作成します。
    次の例は、移行元データベースと移行先データベースの間でプライベート IP 接続を使用する移行シナリオを示しています。別の接続タイプ（IP 許可リスト、VPC ピアリング、リバース SSH トンネルなど）を使用する場合は、--static-ip、--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=CONTINUOUS

    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=CONTINUOUS

    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=CONTINUOUS

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

    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]

  3. 移行先データベースを降格する。
    Database Migration Service では、移行ジョブを開始する前に、既存の移行先クラスタをデモートして外部レプリカとして構成する必要があります。gcloud database-migration migration-jobs demote-destination コマンドを実行します（リンクをクリックして展開）。

    gcloud database-migration migration-jobs demote-destination

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

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

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

    • 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

    結果

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

    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

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

  4. 省略可: 移行ジョブを確認します。
    この時点で、移行ジョブが構成され、移行先クラスタに接続されています。これは、verify、start、stop、restart、resume オペレーションを使用して管理できます。まず、gcloud database-migration migration-jobs verify コマンドを実行して、移行ジョブを確認することをおすすめします（リンクをクリックして展開）。

    gcloud database-migration migration-jobs verify

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

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

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

    • 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

    結果

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

    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

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

  5. 移行ジョブを開始します。
    gcloud database-migration migration-jobs start コマンドを実行して、移行ジョブを開始します（リンクをクリックして展開）。

    gcloud database-migration migration-jobs start

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

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

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

    • 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

    結果

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

    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

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

  6. 移行ジョブをプロモートする。
    移行が変更データ キャプチャ（CDC）フェーズに達すると、移行先クラスタをレプリカからスタンドアロンのプライマリ クラスタにプロモートできます。gcloud database-migration migration-jobs promote コマンドを実行します（リンクをクリックして展開）。

    gcloud database-migration migration-jobs promote

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

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

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

    • REGION は、移行ジョブが保存されているリージョンの ID に置き換えます。

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

    Linux、macOS、Cloud Shell

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

    Windows（PowerShell）

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

    Windows（cmd.exe）

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

    結果

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

    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: promote
name: OPERATION_ID

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