このページでは、次のようなユースケースのベスト プラクティスについて説明します。
- 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 Migration Toolkit を使用して、これを実現できます。
- MySQL ソースと Oracle ソースの場合、コピー オペレーションが開始された時点で、ユーザーはログの位置を特定できる必要があります。
- データベースには、テーブルのコピープロセスを完了するのに十分なストレージとログの保持ポリシーが必要です。
MySQL と Oracle のソース
- 継続的な CDC レプリケーションに使用するストリームを作成しますが、開始しないでください。ストリームが CREATED 状態になっている必要があります。
- テーブルのコピー オペレーションを開始する準備ができたら、データベースの現在のログ位置を特定します。
- MySQL のレプリケーション バイナリログ座標の取得方法については、MySQL のドキュメントをご覧ください。ログの位置を特定したら、セッションを閉じて、データベースのロックを解放します。
- Oracle の場合は、
SELECT current_scn FROM V$DATABASEクエリを実行します。
- ソース データベースから BigQuery にテーブルをコピーします。
- コピー オペレーションが完了したら、ストリームの管理ページの手順に沿って、前に特定したログの位置からストリームを開始します。
PostgreSQL ソース
- テーブルのコピーを開始する準備ができたら、レプリケーション スロットを作成します。詳細については、ソース PostgreSQL データベースの構成をご覧ください。
- ソース データベースから BigQuery にテーブルをコピーします。
- コピー オペレーションが完了したら、ストリームを作成して開始します。