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

クロスリージョン データセット レプリケーションを使用すると、Datastream の宛先データセットを別の BigQuery リージョンまたはマルチリージョンに移動できます。このワークフローは、アクティブな変更データ キャプチャ（CDC）データセットのロケーションを更新しながら、ストリームのダウンタイムを最小限に抑え、ソース データベースからの完全な履歴バックフィルを回避します。

移行中にセカンダリ リージョンに対してクエリを実行すると、不完全または不正確な結果が返されることがあります。移行の制限事項の詳細については、クロスリージョン データセット レプリケーションをご覧ください。

始める前に

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

  • 移行には時間がかかります。移行中はストリームを一時停止する必要があります。データの完全性を維持するため、ストリームが一時停止されたときに、ソース データベースは変更ログを保持する必要があります。ストリームの一時停止時間を見積もるには、データセット内の 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. 必要に応じて、元のストリームを削除します。