標準の Datastream バックフィルに時間がかかりすぎる場合や、プロダクトに制限がある場合は、初期データを既存の BigQuery テーブルに個別にコピーできます。特定のログ位置から BigQuery に変更データ キャプチャ（CDC）の更新をストリーミングすると、組み込みのバックフィルを実行せずにテーブルを同期できます。
問題
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 にテーブルをコピーします。
- コピー オペレーションが完了したら、ストリームを作成して開始します。