このページでは、次のユースケースのベスト プラクティスについて説明します。
- BigQuery に既存のテーブルがあり、変更データ キャプチャ（CDC）を使用して同じ BigQuery テーブルにデータを複製する必要がある。
- 時間がかかるため、またはプロダクトの制限があるため、Datastream バックフィル機能を使用せずに、既存の BigQuery テーブルにデータをコピーする必要があります。
問題
BigQuery Storage Write API を使用して入力された BigQuery テーブルでは、通常のデータ操作言語（DML）オペレーションは許可されません。つまり、CDC ストリームが BigQuery テーブルへの書き込みを開始すると、テーブルに事前入力されていない過去のデータを追加する方法はありません。
次のシナリオを考えてみます。
- TIMESTAMP 1: テーブル コピー オペレーションが開始されます。
- TIMESTAMP 2: テーブルのコピー中に、ソースでの DML オペレーションによりデータが変更されます（行の追加、更新、削除）。
- TIMESTAMP 3: CDC が開始され、TIMESTAMP 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 にテーブルをコピーします。
- コピー オペレーションが完了したら、ストリームを作成して開始します。