Probleme diagnostizieren

Im Stream können während der Laufzeit Fehler auftreten.

  • Einige Fehler, wie z. B. ein ungültiges Passwort in der Quelldatenbank, sind wiederherstellbar. Dies bedeutet, dass diese Fehler behoben werden können und der Stream anschließend automatisch fortgesetzt wird.
  • Fehler können Auswirkungen auf ein einzelnes Objekt haben, z. B. ein Ereignis, das nicht unterstützte Datentypen enthält. Fehler können sich auch auf mehrere Objekte oder den gesamten Stream auswirken, z. B. wenn Datastream keine Verbindung zur Quelldatenbank herstellen kann.
  • Je nach Fehler werden Informationen auf den Seiten Streams oder Streamdetails der Datastream-Benutzeroberfläche angezeigt. Sie können auch die APIs von Datastream verwenden, um Informationen zum Fehler abzurufen.

Zum Beheben eines Fehlers rufen Sie den Stream auf, um den Fehler anzuzeigen, und folgen dann den Schritten in der Fehlermeldung.

Diese Seite enthält Informationen zu Konfigurations-, Verbindungs-, Oracle- und MySQL-Fehlern sowie Schritte zur Fehlerbehebung.

Konfigurations- und Verbindungsfehler

Fehler Schritte zur Fehlerbehebung
Fehler beim Herstellen einer Verbindung zur Quelldatenbank (generisch).

Dieser Fehler kann verschiedene Gründe haben. Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

  1. Prüfen Sie, ob die Quelldatenbank aktiv und erreichbar ist.
  2. Rufen Sie auf den Seiten Streams oder Verbindungsprofile das Quellverbindungsprofil auf.
  3. Prüfen Sie, ob die Verbindungsinformationen für das Verbindungsprofil korrekt sind.
  4. Prüfen Sie, ob Nutzername und Passwort übereinstimmen.
  5. Prüfen Sie, ob der Nutzername in der Datenbank vorhanden ist und die erforderlichen Berechtigungen hat.
  6. Speichern Sie alle Änderungen, die Sie auf der Seite Verbindungsprofile vorgenommen haben.

Der Stream wird automatisch fortgesetzt.
Fehler beim Herstellen einer Verbindung zur Quelldatenbank (IP-Zulassungsliste). Das kann passieren, wenn als Verbindungsmethode IP-Zulassungsliste ausgewählt wurde, aber eine oder mehrere der ausgehenden IP-Adressen von Datastream nicht richtig in der Quelldatenbank hinzugefügt wurden. Achten Sie darauf, dass die ausgehenden IP-Adressen, die im Datastream-Verbindungsprofil angezeigt werden, in der Netzwerk-Firewall so konfiguriert sind, dass der Quelldatenbankserver Verbindungen von diesen IP-Adressen akzeptieren kann. Danach wird der Stream automatisch fortgesetzt.
Fehler beim Herstellen einer Verbindung zur Quelldatenbank (Weiterleitungs-SSH-Tunnel). Dies kann passieren, wenn ein Problem mit dem SSH-Tunnel vorliegt. Prüfen Sie den Status des Tunnels. Wenn der Tunnel angehalten wurde, muss er gestartet werden. Danach wird der Stream automatisch fortgesetzt.
Datastream kann über einen Weiterleitungs-SSH-Tunnel keine Verbindung zu einem Bastion Host herstellen. Prüfen Sie, ob die Konfiguration des Weiterleitungs-SSH-Tunnels im Quellverbindungsprofil richtig ist und ob der Port auf dem SSH-Tunnelserver geöffnet ist.
Fehler beim Herstellen einer Verbindung zur Quelldatenbank aufgrund von ungültigen Zertifikaten. Dies kann auftreten, wenn bei der Definition des Quellverbindungsprofils ein Problem mit den Zertifikaten auftritt. Rufen Sie die Seite Verbindungsprofile auf und wählen Sie das angegebene Verbindungsprofil aus. Prüfen Sie, ob die Zertifikate richtig eingerichtet sind. Nachdem Sie die Änderungen vorgenommen haben, speichern Sie das Verbindungsprofil. Der Stream wird dann automatisch fortgesetzt.
Fehler bei der Verwendung einer privaten Verbindung zum Herstellen einer Verbindung zur Quelldatenbank.
  1. Prüfen Sie, ob alle Voraussetzungen unter Vorbereitung erfüllt sind.

  2. Nachdem Sie die Konfiguration für private Verbindungen erstellt haben, prüfen Sie, ob die Route mit der internen IP-Adresse der Datenbank auf der Seite VPC-Netzwerk-Peering im Tab Exportierte Routen angezeigt wird.

    Rufen Sie dazu die Seite VPC-Netzwerk-Peering auf und suchen Sie nach dem hinzugefügten Peering (der Name lautet peering-[UUID]). Die Route finden Sie auf dem Tab Exportierte Routen. Wenn diese Route nicht vorhanden ist, fügen Sie sie manuell hinzu.

  3. Datastream prüft nicht, ob sich mit dynamischen Peering-Routen überschneiden. Wenn Sie ein Subnetz angeben, das sich mit einer dynamischen Route überschneidet, kann dies zu Verbindungsproblemen führen. Daher empfehlen wir, kein Subnetz zu verwenden, das Teil eines dynamischen Routes ist.
  4. Achten Sie darauf, dass die benutzerdefinierten Routen für IP-Adressbereiche von Datastreams korrekt beworben werden. Wenn die benutzerdefinierten Routen fehlen, lesen Sie den Hilfeartikel Benutzerdefinierte beworbene Routen.
  5. Wenn weiterhin Probleme beim Herstellen einer Verbindung zur Quelldatenbank auftreten, lesen Sie den Abschnitt Umgekehrten Proxy einrichten.
Der Verbindungstyp STATIC_SERVICE_IP_CONNECTIVITY ist nicht zulässig, wenn die Organisationsrichtlinie constraints/datastream.disablePublicConnectivity aktiviert ist.

Sie haben die öffentliche Netzwerkverbindungsmethode "IP-Zulassungsliste" oder "Weiterleitungs-SSH-Tunnel" für das erstellte Verbindungsprofil ausgewählt. Die Organisationsrichtlinie Öffentliche Verbindungsmethoden blockieren für Datastream ist jedoch aktiviert. Daher können Sie keine öffentlichen Verbindungsmethoden für das Verbindungsprofil auswählen.

Wählen Sie zum Beheben dieses Problems entweder privates VPC-Peering als Netzwerkverbindungsmethode aus oder deaktivieren Sie die Organisationsrichtlinie.

So deaktivieren Sie die Organisationsrichtlinie:

  1. Rufen Sie in der Google Cloud Console die Seite Organisationsrichtlinien auf.
  2. Wählen Sie die Organisationsrichtlinie Datastream – Öffentliche Verbindungsmethoden blockieren aus.

  3. Klicken Sie auf BEARBEITEN.

  4. Wählen Sie im Abschnitt Gilt für der Seite die Option Anpassen aus.

  5. Wählen Sie im Abschnitt Erzwingung die Option Aus aus.

  6. Klicken Sie auf SPEICHERN.
  7. Kehren Sie zu dem Oracle-Verbindungsprofil zurück, das Sie gerade erstellen, und klicken Sie auf ERSTELLEN.
Bei der Konfiguration der Quelldatenbank für meinen Stream finde ich die Tabellen und Schemas, die ich übertragen möchte, nicht in der Liste der einzubeziehenden Objekte.

Das kann passieren, wenn Ihre Datenbank Tausende von Tabellen und Schemas enthält. Einige davon sind möglicherweise nicht in der Liste der abzurufenden Objekte enthalten, wenn Sie die Quelle für den Stream in der Google Cloud Console konfigurieren. Wählen Sie im Bereich Objekte auswählen, die einbezogen werden sollen statt Bestimmte Schemas und Tabellen die Option Benutzerdefiniert aus. Geben Sie im Feld Objektabgleichskriterien die Schemas und Tabellen ein, die Datastream abrufen soll.
Ich habe meinem Stream über das Menü Einzuschließende Objekte mehrere Tabellen hinzugefügt. Wenn ich mir jedoch den Tab Objekte in den Streamdetails ansehe, sehe ich, dass einige Tabellen fehlen. Achten Sie darauf, dass für jede dieser Tabellen mindestens eine CDC-Aktualisierung vorhanden ist, damit Datastream die Änderungen erkennen und die Tabellen automatisch in den Stream aufnehmen kann.
Die Liste der Objekte kann nicht geladen werden, wenn Sie in der Google Cloud Console das Menü Einzuschließende Objekte verwenden. Das kann passieren,wenn Ihre Datenbank mehr als 5.000 Schemas und Tabellen enthält. Verwenden Sie eine andere Methode, um anzugeben, welche Objekte eingeschlossen werden sollen, oder verwenden Sie die Datastream API. Weitere Informationen finden Sie unter Quelldatenbanken konfigurieren.
Ereignisse, die während des Streamings gelöscht und nicht im Ziel repliziert wurden.

Datastream lässt möglicherweise nicht unterstützte Ereignisse während des Streamings aus. Sie haben folgende Möglichkeiten, das Problem zu beheben:

  • Sie können manuell einen Backfill der gesamten Tabelle auslösen. Das funktioniert nur, wenn es sich bei den verworfenen Ereignissen ausschließlich um UPSERT-Ereignisse handelt. Wenn die gelöschten Ereignisse DELETE-Ereignisse enthalten, müssen Sie die Tabelle in BigQuery kürzen, bevor Sie das Backfill ausführen.

    Informationen zum Ausführen eines Backfills finden Sie unter Backfill einleiten.

  • Wenden Sie sich an den Google-Support und bitten Sie ihn, einen teilweisen Backfill durchzuführen. Das ist nur möglich, wenn Sie die verworfenen Ereignisse mit einer SQL-WHERE-Klausel identifizieren können und keines der Ereignisse ein DELETE-Ereignis ist.
  • Ignorieren Sie das Problem, wenn die Anzahl der verworfenen Ereignisse gering ist oder die verworfenen Ereignisse nicht signifikant sind.

Oracle-Fehler

Fehler Schritte zur Fehlerbehebung
Das zusätzliche Logging ist in der Quelldatenbank falsch konfiguriert.

Wenn die Konfiguration des zusätzlichen Loggings in der Quelldatenbank nicht korrekt ist, kann beim Abrufen laufender CDC-Daten (Change Data Capture) ein Fehler auftreten. Prüfen Sie, ob die zusätzliche Protokollierung richtig konfiguriert ist. Prüfen Sie insbesondere, ob das zusätzliche Logging für die Datenbanktabellen aktiviert ist, die von der Quelle in das Ziel gestreamt werden. Der Stream wird automatisch fortgesetzt.
Die Replikation kann nicht fortgesetzt werden, wenn die Logposition verloren geht. Dieser Fehler kann auftreten, wenn der Replikationsprozess für einen längeren Zeitraum pausiert wird, wodurch die Logposition verloren geht. Streams sollten nicht für Zeiträume pausiert werden, die an die Aufbewahrungsdauer der Protokolle heranreichen. Erstellen Sie den Stream neu.
Logdateien fehlen entweder teilweise oder vollständig.

Die Logdateien wurden möglicherweise gelöscht. Oracle löscht Logdateien so schnell wie möglich, es sei denn, Sie geben einen Mindestrotationszeitraum an, um sie beizubehalten. Legen Sie auf dem Oracle-Server fest, wie lange die Logdateien aufbewahrt werden sollen. Verwenden Sie beispielsweise CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;, um die Logdateien mindestens 4 Tage lang aufzubewahren.

Verwenden Sie für eine RDS-Bereitstellung exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',96);.
Die Ausschlussliste subsumiert die Einschlussliste. Die Einschlussliste ist vollständig in der Ausschlussliste enthalten. Daher ist die Liste der Objekte, die Datastream aus der Quelle abruft, leer. Ändern Sie die Objektauswahl und versuchen Sie es noch einmal.
Der Logging-Modus für die Oracle-Datenbank ist nicht auf ARCHIVELOG festgelegt. Ändern Sie den Logging-Modus und versuchen Sie es noch einmal.
Datastream gibt die Fehlermeldung ORA-00942: table or view does not exist zurück, aber alles ist richtig konfiguriert. Das kann auf das Caching auf dem Oracle-Server zurückzuführen sein. Wenn Sie den Datenbanknutzer neu erstellen, sollte das Caching-Problem behoben werden.
Änderungen an einer Oracle-Quelle werden nicht im Ziel übernommen, wenn der Stream bereits läuft. Da Datastream aus archivierten Redo-Logdateien liest, werden die Änderungen, die Sie an der Quelle vornehmen, erst im Ziel berücksichtigt, wenn das Protokoll archiviert wurde. Wenn Sie die Änderungen am Ziel sehen möchten, ändern Sie die Protokollarchivierungsrichtlinie oder erzwingen Sie manuell einen Protokollwechsel. Weitere Informationen finden Sie unter Mit Redo-Logdateien der Oracle-Datenbank arbeiten.
Es ist ein unerwarteter interner Fehler aufgetreten. Weitere Informationen erhalten Sie vom Google-Support.

MySQL-Fehler

Fehler Schritte zur Fehlerbehebung
Der Binlog ist in der Quelldatenbank falsch konfiguriert.

Dies kann bei kontinuierlichen MySQL-Streams auftreten, wenn die binlog-Konfiguration in der Quelldatenbank falsch ist. Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

  1. Prüfen Sie, ob binlog richtig konfiguriert ist.
  2. Prüfen Sie, ob das binäre Logformat der MySQL-Datenbank auf ROW gesetzt ist.
  3. Starten Sie den Stream neu.
Die Replikation kann nicht fortgesetzt werden, wenn die Binlog-Position verloren geht. Dieser Fehler kann auftreten, wenn der Replikationsprozess für einen längeren Zeitraum pausiert wird, wodurch die Binlog-Position verloren geht. Streams sollten nicht für Zeiträume pausiert werden, die an die Aufbewahrungsdauer der Binärprotokolle heranreichen. Erstellen Sie den Stream neu.
Fehler beim Ausführen des Streams aufgrund inkompatibler Versionen von Quelldatenbank und Ziel.

Das kann passieren, wenn die Quelldatenbank nicht der Supportmatrix für Versionen entspricht. Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

  1. Sorgen Sie dafür, dass die Quelldatenbank der Matrix entspricht.
  2. Erstellen Sie den Stream mit der aktualisierten Quelldatenbank neu.
Die MySQL-Quell-Binlogs von AWS RDS fehlen entweder teilweise oder vollständig. Die Binlogs wurden möglicherweise gelöscht. AWS RDS löscht Binlogs so schnell wie möglich, es sei denn, Sie geben einen Mindestrotationszeitraum an, um sie beizubehalten. Legen Sie in der MySQL-Quellinstanz von AWS RDS fest, wie lange (in Stunden) die Binlogs aufbewahrt werden sollen. Verwenden Sie beispielsweise mysql.rds_set_configuration('binlog retention hours', 168);, um die Binlogs mindestens 7 Tage lang aufzubewahren.
Die Ausschlussliste subsumiert die Einschlussliste. Die Einschlussliste ist vollständig in der Ausschlussliste enthalten. Daher ist die Liste der Objekte, die Datastream aus der Quelle abruft, leer. Ändern Sie die Objektauswahl und versuchen Sie es noch einmal.
Datastream kann keine MySQL-Datenbank replizieren. Prüfen Sie, ob Datastream die Berechtigungen zum Replizieren der Datenbank hat.
Beim Erstellen eines Verbindungsprofils für eine MySQL-Quelle werden im Menü Verschlüsselungstyp keine mehreren PEM-codierten SSL-Zertifikate akzeptiert. Datastream unterstützt keine SSL-Zertifikatsketten in MySQL-Verbindungsprofilen. Es werden nur einzelne, x509-PEM-codierte Zertifikate unterstützt.
Hohe Latenz beim Streamen von einer MySQL-Quelle

Erhöhen Sie die Lesefähigkeit von Datastream aus der Quelldatenbank:
Die Validierung der MySQL-CDC-Konfiguration ist fehlgeschlagen. Ihre Quelldatenbank wurde nicht für die von Ihnen ausgewählte CDC-Methode konfiguriert. Wählen Sie eine andere Methode aus oder schließen Sie die Konfiguration für die CDC-Methode ab. Weitere Informationen finden Sie unter MySQL-Quelldatenbank konfigurieren.
Es ist ein unerwarteter interner Fehler aufgetreten. Weitere Informationen erhalten Sie vom Google-Support.

PostgreSQL-Fehler

Fehler Schritte zur Fehlerbehebung
Die logische Decodierung ist in der Quelldatenbank falsch konfiguriert.

Prüfen Sie, ob die logische Decodierung richtig konfiguriert ist. Weitere Informationen finden Sie unter PostgreSQL-Quelldatenbank konfigurieren.
Der Replikationsslot ist nicht vorhanden. Wenn der Replikations-Slot in der Datenbank nicht vorhanden ist, kann beim Abrufen laufender CDC-Daten (Change Data Capture) ein Fehler auftreten. Prüfen Sie, ob der Replikationsslot richtig konfiguriert ist. Weitere Informationen finden Sie unter PostgreSQL-Quelldatenbank konfigurieren.
Der Replikationsslot ist mit dem falschen Plug-in konfiguriert. Dieser Fehler kann auftreten, wenn der Replikationsslot mit einem anderen Plug-in als pgoutput konfiguriert ist. Prüfen Sie, ob der Replikationsslot richtig konfiguriert ist. Weitere Informationen finden Sie unter PostgreSQL-Quelldatenbank.
Der Replikations-Slot ist in einem anderen Prozess aktiv. Dieser Fehler kann auftreten, wenn der Replikations-Slot von einem anderen Prozess verwendet wird. Replikationsslots können jeweils nur von einem Prozess verwendet werden. Achten Sie darauf, dass Sie denselben Replikationsslot nicht in anderen Prozessen als Datastream verwenden.
Die Publikation ist nicht richtig konfiguriert. Dieser Fehler kann auftreten, wenn die Veröffentlichung nicht so konfiguriert ist, dass die Tabellen freigegeben werden, die in der Streamkonfiguration enthalten sind. Prüfen Sie, ob die Publikation richtig konfiguriert ist. Weitere Informationen finden Sie unter Informationen zur Quelldatenbank für den Stream konfigurieren.
Die Publikation ist nicht vorhanden. Dieser Fehler kann auftreten, wenn die Publikation in der Datenbank nicht vorhanden ist. Prüfen Sie, ob die Publikation richtig konfiguriert ist. Weitere Informationen finden Sie unter PostgreSQL-Quelldatenbank konfigurieren.
Die Replikation kann nicht fortgesetzt werden, da WAL-Dateien verloren gegangen sind. Dieser Fehler kann auftreten, wenn der Replikationsprozess für eine lange Zeit pausiert wird, wodurch die WAL-Dateien verloren gehen. Streams sollten nicht für Zeiträume pausiert werden, die an die Aufbewahrungsdauer der WAL-Dateien heranreichen. Erstellen Sie den Stream neu.
Die Ausschlussliste subsumiert die Einschlussliste. Die Einschlussliste ist vollständig in der Ausschlussliste enthalten. Daher ist die Liste der Objekte, die Datastream aus der Quelle abruft, leer. Ändern Sie die Objektauswahl und versuchen Sie es noch einmal.
Datastream kann kein PostgreSQL-Schema replizieren. Prüfen Sie, ob Datastream die Berechtigungen zum Replizieren des Schemas hat.
Große Transaktionen in der Quelldatenbank führen zu Problemen bei der Datenreplikation und -synchronisierung. Wenn Sie eine große Anzahl von Datensätzen in die Quelldatenbank einfügen, aktualisieren oder löschen, wird der Replikationszeitplan möglicherweise durch die entsprechenden Ereignisse überlastet. Datastream benötigt Zeit, um diese Ereignisse zu lesen und zu verarbeiten. Da PostgreSQL-Replikationsslots nur einen Thread haben, werden andere Änderungen im Replikationsslot, einschließlich Änderungen an Daten in anderen Tabellen, verzögert verarbeitet, bis Datastream alle Änderungen im Replikationsslot nachgeholt hat.
Große Transaktionen in der Quelldatenbank führen zu einem niedrigen CDC-Durchsatz. Datastream unterstützt keine mehrstufige CDC in PostgreSQL. Um diese Einschränkung zu umgehen und den CDC-Durchsatz zu erhöhen, können Sie die Quelle in mehrere Streams aufteilen, die jeweils einen eigenen Veröffentlichungs- und Replikationszeitpunkt haben. Sie können beispielsweise einen Stream für die größte Tabelle in Ihrer Datenbank und einen anderen für alle anderen Tabellen oder einen Stream für die Tabellen mit höchster Priorität und einen anderen für die verbleibenden Tabellen erstellen. Die Anwendungsfälle können variieren. Sie müssen daher überlegen, was in Ihrem spezifischen CDC-Szenario am sinnvollsten ist. Informationen zum Erstellen einer Publikation finden Sie unter PostgreSQL-Quelldatenbank konfigurieren.
Nicht unterstützte Ereignisse wurden mit dem Grundcode BIGQUERY_TOO_MANY_PRIMARY_KEYS gelöscht. Wenn die PostgreSQL-Replikatidentität für eine Tabelle auf FULL festgelegt ist, behandelt Datastream alle Spalten in dieser Tabelle als Primärschlüssel. Wenn die Tabelle mehr als 16 Spalten enthält, verstößt dies gegen die BigQuery-Begrenzung für die kontinuierliche Datenübertragung und führt zu diesem Fehler. So beheben Sie das Problem:
  1. Ändern Sie die Replikat-ID in DEFAULT: 
    ALTER TABLE TABLE_NAME REPLICA IDENTITY DEFAULT
     Ersetzen Sie TABLE_NAME durch den Namen der Tabelle, für die Sie die Replikaidentität ändern möchten.
  2. Entfernen Sie die Tabelle aus der Liste der einzubeziehenden Objekte im Stream. Weitere Informationen finden Sie unter Konfigurationsinformationen über die Quelldatenbank ändern.
  3. Löschen Sie die Tabelle aus BigQuery. Weitere Informationen finden Sie unter Tabellen löschen.
  4. Fügen Sie die Tabelle in Datastream wieder dem Stream hinzu, indem Sie die Quellkonfiguration bearbeiten.
Es ist ein unerwarteter interner Fehler aufgetreten. Weitere Informationen erhalten Sie vom Google-Support.

SQL Server-Fehler

Fehler Schritte zur Fehlerbehebung
CDC ist für die Datenbank DATABASE_NAME deaktiviert.

Change Data Capture (CDC) muss für die Datenbank aktiviert sein. Datastream benötigt direkten Lesezugriff auf Transaktionsprotokolle, um Änderungen in Echtzeit in der Quelldatenbank zu replizieren und vollständige Protokollinformationen zu erhalten. Aktivieren Sie CDC für die Datenbank und versuchen Sie es noch einmal.

Informationen zum Aktivieren von CDC für eine Datenbank finden Sie unter SQL Server-Quelldatenbank konfigurieren.
Tabellen mit deaktiviertem CDC

Die Funktion „Change Data Capture“ (CDC) muss für alle im Stream enthaltenen Tabellen aktiviert sein. Datastream benötigt direkten Lesezugriff auf Transaktionsprotokolle, um Änderungen in Echtzeit an Quelltabellen zu replizieren und vollständige Protokollinformationen zu erhalten. Aktivieren Sie CDC für die im Stream enthaltenen Tabellen und versuchen Sie es noch einmal.

Informationen zum Aktivieren von CDC für Quelltabellen finden Sie unter SQL Server-Quelldatenbank konfigurieren.
Fehlende Berechtigungen. Datastream fehlen die erforderlichen Berechtigungen zum Lesen aus der Quelle. Gewähren Sie dem Nutzerkonto, das für die Verbindung zur Datenbank verwendet wird, die entsprechenden Berechtigungen und versuchen Sie es noch einmal.
Die SQL Server-Version EDITION_NAME wird nicht unterstützt. Diese SQL Server-Version wird von Datastream nicht unterstützt. Weitere Informationen zu unterstützten SQL Server-Versionen finden Sie unter SQL Server als Quelle.
Die SQL Server-Version VERSION_NAME der Standard Edition wird nicht unterstützt. Diese Version der SQL Server-Standardversion wird von Datastream nicht unterstützt. Weitere Informationen zu unterstützten SQL Server-Versionen finden Sie unter SQL Server als Quelle.
SQL Server-CDC-Konfiguration: fehlgeschlagen. Die von Ihnen ausgewählte CDC-Methode entspricht nicht Ihrer Datenbankkonfiguration. Ändern Sie die CDC-Methode und versuchen Sie es noch einmal.

BigQuery-Fehler

Fehler Schritte zur Fehlerbehebung
BIGQUERY_UNSUPPORTED_PRIMARY_KEY_CHANGE, details: Failed to write to BigQuery due to an unsupported primary key change: adding primary keys to existing tables is not supported. Wenn sich der Primärschlüssel in der Quelle ändert, müssen Sie die Tabelle in BigQuery löschen und den Backfill noch einmal starten. Das ist eine Einschränkung von BigQuery, da nicht sichergestellt werden kann, dass neue Ereignisse mit vorhandenen Zeilen korrekt zusammengeführt werden, wenn sich der Primärschlüssel unterscheidet. Weitere Informationen finden Sie unter BigQuery-Ziel konfigurieren.
Die BigQuery-Tabelle enthält deutlich mehr Datensätze als die Quelltabelle. Das kann passieren, wenn die Quelltabelle keinen Primärschlüssel hat. In diesem Fall verarbeitet Datastream die Tabelle im Schreibmodus „Nur Anfügen“. Jedes Ereignis für eine bestimmte Zeile wird in BigQuery als separate Zeile angezeigt.
Daten werden dupliziert, wenn ein Backfill im Schreibmodus Nur anhängen ausgeführt wird.

Wenn Sie den Schreibmodus Nur anhängen für Ihren Stream auswählen, werden Ihre Daten in BigQuery als Stream von INSERT-, UPDATE-INSERT-, UPDATE-DELETE- und DELETE-Ereignissen ohne Konsolidierung angehängt. Dies kann dazu führen, dass beim Backfill oder bei einem Problem, bei dem der BigQuery-Writer die Schreibvorgänge noch einmal versucht, doppelte Zeilen in BigQuery geschrieben werden. Um das Problem zu beheben, empfehlen wir Ihnen, regelmäßig eine Abfrage zur Deduplizierung auszuführen, die der folgenden ähnelt:

SELECT * FROM (SELECT *, row_number() OVER (PARTITION BY datastream_metadata.uuid) AS num FROM TABLE_NAME) WHERE num=1
Datastream ist für den Merge-Write-Modus konfiguriert, aber Änderungen werden nicht in BigQuery zusammengeführt.

Prüfen Sie, ob Ihre Quelltabelle einen Primärschlüssel hat. BigQuery benötigt sie, um die Änderungen in die Zieltabelle einzufügen.

Wenn kein Primärschlüssel vorhanden ist, sollten Sie einen in der Quell- oder Zieltabelle hinzufügen. So fügen Sie der Ziel-BigQuery-Tabelle einen Primärschlüssel hinzu:

  1. Pausieren Sie den Stream.
  2. Kürzen Sie die Tabelle in BigQuery.
  3. Fügen Sie der Tabellendefinition den Primärschlüssel hinzu.
  4. Setzen Sie den Stream fort.
  5. Auslösen eines Backfills für die Tabelle.
Es ist nicht möglich, einen Primärschlüssel hinzuzufügen, einen Primärschlüssel zu entfernen oder die Definition des Primärschlüssels für eine Tabelle zu ändern, die bereits in BigQuery repliziert wurde.

Standardmäßig unterstützt Datastream nicht, dass einer Tabelle, die bereits ohne Primärschlüssel in BigQuery repliziert wurde, ein Primärschlüssel hinzugefügt oder ein Primärschlüssel aus einer Tabelle entfernt wird, die mit einem Primärschlüssel in BigQuery repliziert wurde. Sie können jedoch die Primärschlüsseldefinition für eine Quelltabelle ändern, die nach BigQuery repliziert wurde und bereits einen Primärschlüssel hat:

  1. Prüfen Sie den Messwert „Gesamtlatenz“ für den Stream und warten Sie mindestens so lange wie die aktuelle Latenz, damit alle laufenden Ereignisse an das Ziel geschrieben werden. So können alle Ereignisse mit dem ursprünglichen Primärschlüssel gestreamt werden.
  2. Pausieren Sie den Stream.
  3. Kopieren Sie den CREATE TABLE-DDL-Befehl (Data Definition Language) für die Tabelle in BigQuery: 
        SELECT ddl FROM PROJECT_ID.DATASET.INFORMATION_SCHEMA.TABLES
      WHERE table_name='TABLE_NAME';

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Kennung Ihres Google Cloud-Projekts.
    • DATASET_ID: die ID des Datasets in BigQuery.
    • TABLE_NAME: der Name der Tabelle, für die Sie den DDL-Befehl kopieren möchten.
  4. Lege die Tabelle in BigQuery ab.
  5. Passen Sie den DDL-Befehl CREATE TABLE an die neuen Primärschlüssel an. Geben Sie die Partitions- und Clusterschlüssel sowie die max_staleness OPTION an: 
        CREATE TABLE `[PROJECT_ID].[DATASET_ID].[TABLE_NAME]`
    (
      product_id INT64 NOT NULL,
      product_name STRING,
      datastream_metadata STRUCT,
      PRIMARY KEY (product_id) NOT ENFORCED
    )
    CLUSTER BY dept_no
    OPTIONS(
      max_staleness=INTERVAL '0-0 0 0:MINS:0' YEAR TO SECOND
    );
    ;

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Kennung Ihres Google Cloud-Projekts.
    • DATASET_ID: die ID des Datasets in BigQuery.
    • TABLE_NAME: der Name der Tabelle, für die Sie den DDL-Befehl kopiert haben.
    • MINS: die Anzahl der Minuten, die Sie für die Option max_staleness festlegen möchten, z. B. 15.
  6. Führen Sie die angepasste Abfrage aus, um die Tabelle in BigQuery neu zu erstellen.
  7. Setzen Sie den Stream fort.
  8. Starten Sie den Backfill für die Tabelle.

Nächste Schritte

  • Informationen dazu, wie du nach potenziellen Problemen mit deinem Stream suchen kannst, findest du unter Fehlerbehebung bei Streams.
  • Weitere Informationen zum Konfigurieren der Quelldatenbank finden Sie unter Quellen.
  • Informationen zum Konfigurieren des BigQuery- oder Cloud Storage-Ziels finden Sie unter Ziele.