CDC テーブルを別のリージョンに移行する

このページでは、BigQuery への Datastream レプリケーションを設定したものの、宛先データセットを誤ったリージョンに構成したユースケースのベスト プラクティスについて説明します。次に、ソース データベースから BigQuery にすべてのデータを再同期することなく、データセットを別のリージョン（またはマルチリージョン）に移動する必要があります。

準備

データを別のリージョンに移行することを開始する前に、次の点を考慮してください。

  • 移行には時間がかかります。また、オペレーション中はストリームを一時停止する必要があります。データの整合性を維持するために、ストリームが一時停止したときには、ソース データベースで変更ログを保持する必要があります。ストリームの一時停止時間を見積もるには、データセット内の max_staleness の値と最長実行のマージ オペレーションを組み合わせます。
    • マージ オペレーションの完了に要する時間については、推奨されるテーブル max_staleness 値をご覧ください。
    • データセット内の最大 max_staleness を確認するには、テーブルの現在の max_staleness 値を特定するを参照し、特定のニーズに合わせてクエリを調整します。
    • 推定される一時停止がソース データベースでサポートするには過剰に長時間にわたる場合は、データセット内のテーブルの max_staleness の値を一時的に小さくすることを検討してください。
  • 移行を実行するユーザーに、移行先リージョンに十分な BigQuery リソース（クエリ予約とバックグラウンド予約）があることを確認します。予約の詳細については、予約の割り当てをご覧ください。
  • 移行を実行するユーザーに、Identity and Access Management（IAM）コントロールや VPC Service Controls などこのオペレーションを実行するための十分な権限が付与されていることを確認します。

移行手順

データセットの移行を開始するには、BigQuery データ レプリケーションを使用します。

  1. Google Cloud コンソールで [BigQuery Studio] ページに移動します。

    BigQuery Studio に移動

  2. 新しいリージョンに BigQuery データセット レプリカを作成します。

    ALTER SCHEMA DATASET_NAME
ADD REPLICA 'NEW_REGION'
OPTIONS(location='NEW_REGION');

    次のように置き換えます。

    • DATASET_NAME: 作成するデータセットの名前。
    • NEW_REGION: データセットを作成するリージョンの名前。例: region-us

  3. 移行の進行状況をモニタリングし、レプリカのコピー ウォーターマークがプライマリから数分以内になるまで待ちます。BigQuery INFORMATION_SCHEMA でこのクエリを実行して、移行の進行状況を確認できます。

    SELECT
catalog_name as project_id,
schema_name as dataset_name,
replication_time as dataset_replica_staleness
FROM
'NEW_REGION'.INFORMATION_SCHEMA.SCHEMATA_REPLICAS
WHERE
catalog_name = PROJECT_ID
AND schema_name = DATASET_NAME
AND location = NEW_REGION;

    次のように置き換えます。

    • PROJECT_ID: Google Cloud プロジェクトの ID。
    • DATASET_NAME: データセット名。
    • DATASET_REPLICA_STALENESS: 作成したデータセット レプリカ内のテーブルのステイルネス構成。
    • NEW_REGION: データセットを作成したリージョン。

  4. 既存の Datastream のストリームを一時停止します。詳細については、ストリームを一時停止するをご覧ください。

  5. ストリームがドレインするまで待ち、ストリームが PAUSED 状態になった時間をメモします。

  6. テーブルの upsert_stream_apply_watermark をチェックして、最新の CDC の変更が BigQuery テーブルに適用されていることを確認します。次のクエリを実行して、ウォーターマークのタイムスタンプがストリームが一時停止された時点から 10 分後であることを確認します。

    SELECT table_name, upsert_stream_apply_watermark
FROM DATASET_NAME.INFORMATION_SCHEMA.TABLES

    特定のテーブルに対してのみクエリを実行するには、次の WHERE 句を追加します。

    WHERE table_name = 'TABLE_NAME'

    次のように置き換えます。

    • DATASET_NAME: データセット名。
    • TABLE_NAME: 省略可。upsert_stream_apply_watermark を確認するテーブル。

  7. ステップ 3 のクエリを使用して、新しいリージョン コピー ウォーターマークがステップ 6 で取得した upsert_stream_apply_watermark より後であることを確認します。

  8. 必要に応じて、元のリージョンのプライマリ データセットの複数のテーブルと新しいリージョンのレプリカを手動により比較して、すべてのデータが正しくコピーされていることを確認します。

  9. BigQuery Studio で次のコマンドを実行して、BigQuery データセット レプリカを昇格させます。

    ALTER SCHEMA DATASET_NAME
SET OPTIONS(primary_replica = 'NEW_REGION');

    次のように置き換えます。

    • DATASET_NAME: データセット名。
    • NEW_REGION: データセットを作成したリージョン。

  10. 必要に応じて、元のデータセット（現在のレプリカ）が不要になった場合に、追加料金が発生しないようにするには、BigQuery Studio に移動して、元の BigQuery データセットを削除します。

    ALTER SCHEMA DATASET_NAME DROP REPLICA IF EXISTS ORIGINAL_REGION;

    次のように置き換えます。

    • DATASET_NAME: 元のデータセットの名前。
    • ORIGINAL_REGION: 元のデータセットのリージョン。

  11. まったく同じ構成で新しい BigQuery の宛先のロケーションを使用して、新しいストリームを作成します。

  12. 新しいストリームを開始します。

    重複したイベントが複製されないようにするには、特定の位置からストリームを開始します。

    • MySQL と Oracle のソースの場合: 元のストリームのログを調べて、ストリームが正常に読み取られた最後の位置を見つけることで、ログの位置を特定できます。特定の位置からストリームを開始する場合については、ストリームを管理するをご覧ください。
    • PostgreSQL ソースの場合: 新しいストリームは、レプリケーション スロットの最初のログシーケンス番号（LSN）から変更の読み取りを開始します。元のストリームでこれらの変更の一部がすでに処理されている可能性があるため、レプリケーション スロットのポインタを、Datastream が読み取る最後の LSN に手動で変更します。この LSN は、Datastream のコンシューマ ログで確認できます。

  13. 必要に応じて、元のストリームを削除します。