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. 必要に応じて、元のストリームを削除します。