Probleme diagnostizieren

Übersicht

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). Dies kann passieren, wenn Sie als Verbindungsmethode IP-Zulassungsliste ausgewählt haben. aber mindestens eine der ausgehenden IP-Adressen von Datastream in die Quelldatenbank richtig eingefü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. Sobald das Problem behoben ist, wird der Stream automatisch fortgesetzt.
Fehler beim Herstellen einer Verbindung zur Quelldatenbank (Weiterleitungs-SSH-Tunnel). Dies kann passieren, wenn ein Problem mit dem Weiterleitungs-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 raten wir davon ab, ein Subnetz zu verwenden, das Teil einer dynamischen Route ist.
  4. Achten Sie darauf, dass die benutzerdefinierten Routen für Datastream-IP-Adressbereiche korrekt beworben werden. Wenn die benutzerdefinierten Routen fehlen, finden Sie weitere Informationen unter 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.

Dies 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. Anstatt im Bereich Einzubeziehende Objekte auswählen die Option Bestimmte Schemas und Tabellen auszuwählen, wählen Sie Benutzerdefiniert aus. Geben Sie im Feld Kriterien für Objektabgleich die Schemas und Tabellen ein, die Datastream abrufen soll.
Ich habe meinem Stream mehrere Tabellen über das Menü Einzuschließende Objekte hinzugefügt. Wenn ich mir jedoch den Tab Objekte unter Streamdetails ansehe, sehe ich, dass einige Tabellen fehlen. Achten Sie darauf, dass für jede dieser Tabellen mindestens ein CDC-Update vorliegt, 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. Legen Sie mit einer anderen Methode fest, welche Objekte eingeschlossen werden sollen, oder verwenden Sie die Datastream API. Weitere Informationen finden Sie unter Quelldatenbanken konfigurieren.
Ereignisse, die während des Streamings verworfen und nicht im Ziel repliziert wurden.

Datastream lässt möglicherweise nicht unterstützte Ereignisse während des Streamings aus. Sie können die folgenden Maßnahmen ergreifen, um das Problem zu beheben:

  • Lösen Sie manuell einen Backfill für die gesamte Tabelle aus. Dies funktioniert, wenn die verworfenen Ereignisse nur UPSERT-Ereignisse sind. 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.

  • Bitten Sie den Google-Support, 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. Dies kann auf das Caching auf dem Oracle-Server zurückzuführen sein. Durch das Neuerstellen des Datenbanknutzers 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 Richtlinie für das Logarchiv oder erzwingen Sie manuell einen Logwechsel. Weitere Informationen finden Sie unter Mit Redo-Logdateien für Oracle-Datenbanken 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 lange pausiert wurde, geht die binlog-Position verloren. Streams sollten nicht pausiert werden für Zeiträume, die sich der binlog-Aufbewahrungsdauer nähern. 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 mehrere PEM-codierte SSL-Zertifikate im Menü Verschlüsselungstyp nicht 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 Datastream-Fähigkeit, aus der Quelldatenbank zu lesen:
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.
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 Replikationsslot 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 einzigen 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 Publikation nicht so konfiguriert ist, dass die in der Streamkonfiguration enthaltenen Tabellen offengelegt werden. 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. Siehe 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. Achten Sie darauf, dass 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 verursachen einen geringen CDC-Durchsatz. Datastream unterstützt kein Multithread-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 Replikationsslot 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, daher müssen Sie überlegen, was für Ihr spezifisches 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 Einschränkungen der CDC für BigQuery und verursacht den 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 zur 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 Transaktionslogs, um Änderungen in Echtzeit an der Quelldatenbank zu replizieren und vollständige Loginformationen abzurufen. 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

CDC muss für alle im Stream enthaltenen Tabellen aktiviert sein. Datastream benötigt direkten Lesezugriff auf Transaktionslogs, um Änderungen in Echtzeit an Quelltabellen zu replizieren und vollständige Loginformationen abzurufen. 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, mit dem Sie eine Verbindung zur Datenbank herstellen, die entsprechenden Berechtigungen und versuchen Sie es noch einmal.
Die SQL Server-Version EDITION_NAME wird nicht unterstützt. Datastream unterstützt diese SQL Server-Version nicht. 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 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-Zieltabelle enthält deutlich mehr Datensätze als die Quelltabelle. Dies 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 anfügen für den Stream auswählen, werden die 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. Zur Behebung des Problems empfehlen wir, regelmäßig eine Deduplizierungsabfrage wie die folgende auszuführen:

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

Prüfen Sie, ob in Ihrer Quelltabelle ein Primärschlüssel vorhanden ist. BigQuery benötigt sie, um die Änderungen in die Zieltabelle einzufügen.

Wenn kein Primärschlüssel vorhanden ist, sollten Sie gegebenenfalls einen Schlüssel in der Quell- oder Zieltabelle hinzufügen. So fügen Sie Ihrer 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. Setze den Stream fort.
  5. Lösen Sie den Backfill für die Tabelle aus.
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 DDL-Befehl CREATE TABLE (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. Fügen Sie die Partitions- und Clusterschlüssel sowie den max_staleness OPTION ein: 
        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 Kennzeichnung 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. Setze den Stream fort.
  8. Backfill für die Tabelle initiieren

Nächste Schritte

  • Informationen dazu, wie Sie potenzielle Probleme mit Ihrem Stream erkennen können, finden Sie im Hilfeartikel Probleme mit Streams beheben.
  • Informationen zum Konfigurieren der Quelldatenbank finden Sie unter Quellen.
  • Informationen zum Konfigurieren des BigQuery- oder Cloud Storage-Ziels finden Sie unter Ziele.