このページでは、次のようなユースケースに関するベスト プラクティスについて説明します。
- ユーザーは BigQuery に既存のテーブルがあり、変更データ キャプチャ（CDC）を使用してデータを同じ BigQuery テーブルに複製する必要があります。
- ユーザーは、時間やプロダクトの制限により、Datastream のバックフィル機能を使用せずに、既存の BigQuery テーブルにデータをコピーする必要があります。
問題
BigQuery Storage Write API を使用して作成された BigQuery テーブルでは、通常のデータ操作言語（DML）オペレーションは許可されません。つまり、CDC ストリームが BigQuery テーブルへの書き込みを開始すると、テーブルに事前入力されていない過去のデータを追加することはできません。
次のシナリオを考えてみます。
- TIMESTAMP 1: テーブルコピー オペレーションが開始されます。
- TIMESTAMP 2: テーブルのコピー中に、ソースの DML オペレーションによってデータが変更されます（行の追加、更新、削除）。
- タイムスタンプ 3: CDC が開始され、タイムスタンプ 2 で発生した変更がキャプチャされず、データに不一致が生じます。
解決策
データの完全性を確保するには、CDC プロセスで、BigQuery テーブルにコピーされた最後の更新直後から発生したソースのすべての変更をキャプチャする必要があります。
次のソリューションを使用すると、コピー オペレーションが BigQuery テーブルにデータを書き込むのをブロックすることなく、CDC プロセスが TIMESTAMP 2 からのすべての変更をキャプチャできます。
前提条件
- BigQuery のターゲット テーブルは、Datastream によってテーブルが作成された場合とまったく同じスキーマと構成である必要があります。これを行うには、Datastream BigQuery 移行ツールキットを使用します。
- MySQL と Oracle のソースの場合、ユーザーはコピー オペレーションが開始された時点のログ位置を特定できる必要があります。
- データベースには、テーブル コピー プロセスを完了できるだけの十分なストレージとログ保持ポリシーが必要です。
MySQL と Oracle のソース
- 継続的な CDC レプリケーションに使用するストリームを作成しますが、開始はしません。ストリームは CREATED 状態である必要があります。
- テーブルのコピー オペレーションを開始する準備ができたら、データベースの現在のログ位置を特定します。
- MySQL の場合は、MySQL のドキュメントでレプリケーション バイナリログの座標を取得する方法を確認してください。ログの位置を特定したら、セッションを閉じてデータベースのロックを解除します。
- Oracle の場合は、次のクエリを実行します。
SELECT current_scn FROM V$DATABASE
- ソース データベースから BigQuery にテーブルをコピーします。
- コピー オペレーションが完了したら、ストリームの管理ページに記載されている手順に沿って、前に特定したログ位置からストリームを開始します。
PostgreSQL ソース
- テーブルのコピーを開始する準備ができたら、レプリケーション スロットを作成します。詳細については、ソース PostgreSQL データベースを構成するをご覧ください。
- ソース データベースから BigQuery にテーブルをコピーします。
- コピー オペレーションが完了したら、ストリームを作成して開始します。