Auf dieser Seite werden Best Practices für Anwendungsfälle beschrieben, in denen:
- Nutzer haben eine vorhandene Tabelle in BigQuery und müssen ihre Daten mithilfe von Change Data Capture (CDC) in dieselbe BigQuery-Tabelle replizieren.
- Nutzer müssen Daten in eine vorhandene BigQuery-Tabelle kopieren, ohne die Datastream-Backfill-Funktion zu verwenden, entweder weil dies zu lange dauern würde oder aufgrund von Produktbeschränkungen.
Problem
In einer BigQuery-Tabelle, die mit der BigQuery Storage Write API erstellt wurde, sind keine regulären DML-Vorgänge (Data Manipulation Language, Datenbearbeitungssprache) möglich. Das bedeutet, dass Sie, sobald ein CDC-Stream Daten in eine BigQuery-Tabelle schreibt, keine Verlaufsdaten mehr hinzufügen können, die nicht bereits in der Tabelle vorhanden sind.
Stellen Sie sich folgendes Szenario vor:
- TIMESTAMP 1: Der Tabellenkopiervorgang wird initiiert.
- TIMESTAMP 2: Während die Tabelle kopiert wird, führen DML-Vorgänge in der Quelle zu Änderungen an den Daten (Zeilen werden hinzugefügt, aktualisiert oder entfernt).
- TIMESTAMP 3: CDC wird gestartet. Änderungen, die in TIMESTAMP 2 vorgenommen wurden, werden nicht erfasst, was zu Datenabweichungen führt.
Lösung
Um die Datenintegrität zu gewährleisten, müssen beim CDC-Prozess alle Änderungen in der Quelle erfasst werden, die ab dem Moment unmittelbar nach der letzten Aktualisierung vorgenommen wurden, die in die BigQuery-Tabelle kopiert wurde.
Mit der folgenden Lösung können Sie dafür sorgen, dass beim CDC-Prozess alle Änderungen ab TIMESTAMP 2 erfasst werden, ohne dass der Kopiervorgang daran gehindert wird, Daten in die BigQuery-Tabelle zu schreiben.
Vorbereitung
- Die Zieltabelle in BigQuery muss genau dasselbe Schema und dieselbe Konfiguration haben, als wäre sie von Datastream erstellt worden. Dazu können Sie das Datastream BigQuery Migration Toolkit verwenden.
- Bei MySQL- und Oracle-Quellen muss der Nutzer die Logposition zum Zeitpunkt des Kopierens ermitteln können.
- Die Datenbank muss über genügend Speicherplatz und eine entsprechende Aufbewahrungsrichtlinie für Logs verfügen, damit der Tabellenkopiervorgang abgeschlossen werden kann.
MySQL- und Oracle-Quellen
- Erstellen Sie den Stream, den Sie für die laufende CDC-Replikation verwenden möchten, starten Sie ihn aber nicht. Der Stream muss den Status CREATED haben.
- Wenn Sie bereit sind, den Tabellenkopiervorgang zu starten, ermitteln Sie die aktuelle Logposition der Datenbank:
- Informationen zum Abrufen der Koordinaten des binären Replikationslogs für MySQL finden Sie in der MySQL-Dokumentation. Sobald Sie die Logposition gefunden haben, schließen Sie die Sitzung, um alle Sperren für die Datenbank aufzuheben.
- Führen Sie für Oracle die folgende Abfrage aus:
SELECT current_scn FROM V$DATABASE
- Kopieren Sie die Tabelle aus der Quelldatenbank nach BigQuery.
- Wenn der Kopiervorgang abgeschlossen ist, folgen Sie der Anleitung auf der Seite Streams verwalten, um den Stream an der zuvor ermittelten Logposition zu starten.
PostgreSQL-Quellen
- Wenn Sie bereit sind, die Tabelle zu kopieren, erstellen Sie den Replikations-Slot. Weitere Informationen finden Sie unter PostgreSQL-Quelldatenbank konfigurieren.
- Kopieren Sie die Tabelle aus der Quelldatenbank nach BigQuery.
- Wenn der Kopiervorgang abgeschlossen ist, kannst du den Stream erstellen und starten.