Einschränkungen des PostgreSQL-Connectors

Von Bedeutung

Der PostgreSQL-Connector für Lakeflow Connect befindet sich in der öffentlichen Vorschau. Wenden Sie sich an Ihr Databricks-Kontoteam, um sich für die Public Preview zu registrieren.

Auf dieser Seite werden die Einschränkungen und Überlegungen für die Aufnahme von PostgreSQL mithilfe von Databricks Lakeflow Connect aufgeführt.

Allgemeine Einschränkungen des Datenbankkonnektors

Die Einschränkungen in diesem Abschnitt gelten für alle Datenbankkonnektoren in Lakeflow Connect. Lesen Sie weiter, um verbindungsspezifische Einschränkungen zu erfahren.

  • Wenn Sie eine geplante Pipeline ausführen, werden Warnungen nicht sofort ausgelöst. Stattdessen werden sie ausgelöst, wenn das nächste Update ausgeführt wird.
  • Wenn eine Quelltabelle gelöscht wird, wird die Zieltabelle nicht automatisch gelöscht. Sie müssen die Zieltabelle manuell löschen. Dieses Verhalten entspricht nicht dem Verhalten von Spark Declarative Pipelines on Lakeflow.
  • Bei dem Staging-Katalog kann es sich nicht um einen externen Katalog handeln.
  • Während der Quellwartungszeiträume können Databricks möglicherweise nicht auf Ihre Daten zugreifen.
  • Wenn ein Quelltabellenname mit einem vorhandenen Zieltabellennamen in Konflikt steht, schlägt die Pipelineaktualisierung fehl.
  • Die Unterstützung für Multi-Destination-Pipelines erfolgt ausschließlich über die API.
  • Sie können nach Belieben eine Tabelle umbenennen, die Sie importieren. Wenn Sie eine Tabelle in Ihrer Pipeline umbenennen, wird sie zu einer nur API-Pipeline, und Sie können die Pipeline nicht mehr in der Benutzeroberfläche bearbeiten.
  • Wenn Sie eine Spalte auswählen, nachdem eine Pipeline bereits gestartet wurde, füllt der Verbinder die Daten für die neue Spalte nicht automatisch aus. Um historische Daten zu erfassen, führen Sie manuell eine vollständige Aktualisierung der Tabelle aus.
  • Databricks können nicht zwei oder mehr Tabellen mit demselben Namen in derselben Pipeline aufnehmen, auch wenn sie aus verschiedenen Quellschemas stammen.
  • Das Quellsystem geht davon aus, dass die Cursorspalten monoton steigen.
  • Gateway-Snapshots können nicht wieder aufgenommen werden. Wenn Sie die Pipeline aktualisieren, während eine Momentaufnahme ausgeführt wird (z. B. durch Hinzufügen neuer Tabellen), wird die aktuelle Momentaufnahme abgebrochen und eine neue Momentaufnahme gestartet. Die neue Momentaufnahme enthält die Vereinigung der Tabellen aus der abgebrochenen Momentaufnahme und allen neu hinzugefügten Tabellen.
  • Verwaltete Erfassungspipelines werden für FedRAMP High- oder FedRAMP Moderate-Arbeitsbereiche nicht unterstützt.
  • Der Connector erfasst rohe Daten ohne Transformationen. Verwenden Sie downstream Spark Declarative Pipelines auf Lakeflow-Pipelines für Transformationen.
  • Der Connector unterstützt nur die Replikation von primären PostgreSQL-Instanzen.

Authentifizierung

  • Der Connector unterstützt nur die Benutzernamen- und Kennwortauthentifizierung.

Datenbankvarianten

  • Der Connector unterstützt PostgreSQL 13 oder höher.
  • Der Connector unterstützt AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Azure-Datenbank für PostgreSQL, virtuelle Azure-Computer und GCP Cloud SQL für PostgreSQL. Der Connector unterstützt auch lokale PostgreSQL mit Azure ExpressRoute, AWS Direct Connect und VPN-Netzwerk. Ausführliche Informationen zur cloudübergreifenden Konnektivität finden Sie unter "Netzwerkkonnektivität".

Pipelines

  • Jede Aufnahmepipeline muss genau einem Aufnahmegateway zugeordnet sein. Gateways können nicht über Pipelines hinweg freigegeben werden.
  • Obwohl die Pipeline zum Einbinden von Daten auf Serverless-Compute ausgeführt wird, muss das Gateway zum Einbinden von Daten auf klassischem Compute ausgeführt werden.
  • Das Erfassungsgateway muss im kontinuierlichen Modus ausgeführt werden, um eine Aufblähung des Write-Ahead-Protokolls (WAL) und eine Ansammlung von Replikationsslots zu verhindern.

Replikation

  • Für die logische Replikation ist PostgreSQL 13 oder höher erforderlich, wobei der wal_level-Parameter auf logical gesetzt ist.
  • Jede Tabelle, die Sie replizieren, muss die Replikatidentität auf FULL oder DEFAULT festgelegt haben. Databricks empfiehlt die Verwendung der FULL Replikatidentität für Tabellen ohne Primärschlüssel oder mit TOASTable-Spalten.
  • Replikationsplätze werden nicht automatisch entfernt, wenn Sie Pipelines löschen. Sie müssen Replikationsplätze manuell bereinigen, um die WAL-Akkumulation zu verhindern. Siehe Replikations-Slots bereinigen.
  • Der Konnektor verwendet die Position des Replikationsslots für das Checkpointing. Wenn der primäre PostgreSQL-Knoten herabgestuft oder ersetzt wird (z. B. während eines Failovers), gehen die Replikationsplatzinformationen verloren. Dies führt zu einem Fehler „Slot nicht gefunden“, der eine vollständige Aktualisierung aller Tabellen in der Pipeline erfordert. Das Herstellen einer Verbindung mit einem anderen Quellknoten wird nicht unterstützt.

Schemaentwicklung

Die in diesem Abschnitt beschriebenen Verhaltensweisen gelten nur, wenn Sie Inline-DDL aktivieren. Wenn inline-DDL deaktiviert ist, erkennt der Connector weiterhin Schemaänderungen, betroffene Tabellen erfordern jedoch eine vollständige Aktualisierung. Informationen zum Aktivieren von Inline-DDL finden Sie unter Optional: Konfigurieren der Inline-DDL-Nachverfolgung.

Wenn inline-DDL aktiviert ist, verarbeitet der Verbinder automatisch neue und gelöschte Spalten.

  • Wenn in der Quelle eine neue Spalte angezeigt wird, erfasst der Connector diese automatisch bei der nächsten Pipelineausführung.
  • Wenn Sie eine Spalte aus der Quelle löschen, wird sie vom Verbinder nicht automatisch gelöscht. Stattdessen verwendet der Konnektor eine Tabelleneigenschaft, um im Ziel die gelöschte Spalte auf inactive festzulegen. Wenn später eine weitere Spalte mit einem Namen angezeigt wird, der mit der inactive Spalte in Konflikt steht, schlägt die Pipeline fehl. Führen Sie in diesem Fall eine vollständige Aktualisierung der Tabelle aus, oder legen Sie die inaktive Spalte manuell ab.

Der Connector kann die folgenden DDLs verarbeiten, erfordert jedoch eine vollständige Aktualisierung der Zieltabellen.

DDLs, die eine vollständige Aktualisierung erfordern

  • Ändern des Datentyps einer Spalte
  • Umbenennen einer Spalte
  • Ändern des Primärschlüssels einer Tabelle
  • Konvertieren einer Tabelle von nicht protokolliert in protokolliert oder umgekehrt
  • Hinzufügen oder Entfernen von Partitionen (für partitionierte Tabellen)

Staging

Der Stagingkatalog kann kein fremder Katalog sein.

Tabellen

  • Databricks empfiehlt, maximal 250 Tabellen pro Pipeline zu erfassen. Es gibt jedoch keine Beschränkung für die Anzahl von Zeilen oder Spalten, die in diesen Tabellen unterstützt werden.
  • Databricks kann nicht zwei Tabellen, deren Namen sich nur in der Groß-/Kleinschreibung unterscheiden (z. B. mytable und MyTable), mithilfe einer einzigen Pipeline erfassen. Um solche Fälle zu unterstützen, erstellen Sie zwei Paare aus Gateway und Erfassungspipeline zur Veröffentlichung in verschiedenen Zielschemas.
  • Die source_catalog, source_schema und source_table Namen sind für den Datenbanknamen groß-/kleinschreibungssensitiv, aber für Schema- und Tabellennamen wird die Groß-/Kleinschreibung nicht beachtet (gemäß dem Standardverhalten von PostgreSQL). Wenn die Quelldatenbank z. B. MyDatabase benannt ist, müssen Sie sie als MyDatabase in der ingestion_definition angeben.
  • Obwohl Sie aus mehreren Quelldatenbanken oder Schemas in einer Pipeline aufnehmen können, können Sie nicht zwei Tabellen mit demselben Namen aufnehmen. Sie können beispielsweise weder schema1.orders noch schema2.orders in derselben Pipeline aufnehmen.
  • Sie können mehrere Tabellen- oder Schemaspezifikationen in das objects Feld der ingestion_definition. Die Quelltabellennamen in verschiedenen Quellschemas können sich jedoch nicht überlappen. Überlappende Namen führen zu einem Fehler bei der Erfassungspipeline.

Datentypen

  • Benutzerdefinierte Typen und Erweiterungstypen von Drittanbietern werden als Zeichenfolgen aufgenommen.
  • Die Datentypen TIME und TIMETZ werden als Zeichenfolgen importiert.
  • Für NUMERIC und DECIMAL Datentypen:
    • Wenn die Genauigkeit 38 oder kleiner ist, wird NaN zu null zugeordnet.
    • Wenn die Genauigkeit größer als 38 ist, wird der Wert als Zeichenfolge gespeichert und NaN als Zeichenfolge beibehalten.
    • Inf und -Inf werden nur für ungebundene numerische Typen unterstützt. Bei einer Genauigkeit, die größer als 38 ist, wird der Wert als Zeichenfolge gespeichert, und der Unendlichkeitswert wird beibehalten.
  • Für DATE Datentyp: Der vollständige PostgreSQL-Datumsbereich wird unterstützt. Inf und -Inf werden in null umgewandelt. BC-Datumsangaben werden mithilfe der astronomischen Jahresnummerierung gespeichert. Beispielsweise wird 1 v. Chr. dem Jahr 0 und 2 v. Chr. dem Jahr -1 zugeordnet.
  • Für TIMESTAMP (ohne Zeitzone) Datentyp: Werte werden als Zeichenfolgen aufgenommen. Inf und -Inf werden als Zeichenfolgen beibehalten.
  • Für den TIMESTAMP WITH TIME ZONE Datentyp: Der unterstützte PostgreSQL-Bereich reicht von 4713-01-01 00:00:00.000000 BC bis 294276-12-31 23:59:59.999999 AD, während der von Databricks unterstützte Bereich von -290308-12-21 BCE 19:59:06 GMT bis +294247-01-10 CE 04:00:54 GMT reicht. Zeitstempel, die den maximal von Databricks unterstützten Zeitstempel überschreiten, werden in null konvertiert. BC-Datumsangaben werden mithilfe der astronomischen Jahresnummerierung gespeichert. Beispielsweise wird 1 v. Chr. dem Jahr 0 und 2 v. Chr. dem Jahr -1 zugeordnet. Inf und -Inf werden in null umgewandelt.
  • Für den Datentyp INTERVAL: Unendlichkeitswerte werden 0 years 0 mins 0 days 0 hours 0 mins 0.0 secs zugeordnet.
  • MONEY Werte werden als Zeichenfolgen aufgenommen.
  • Binäre Spalten (z. B BYTEA. ) können nicht als Clusterschlüssel verwendet werden.
  • Jeder integrierte PostgreSQL-Datentyp, der nicht in der Tabelle "Automatische Datentransformationen" aufgeführt ist, wird als Zeichenfolge aufgenommen.

Partitionierte Tabellen

  • PostgreSQL partitionierte Tabellen werden unterstützt.
  • Jede Partition wird als separate Tabelle für Replikationszwecke behandelt.
  • Zum Hinzufügen oder Entfernen von Partitionen ist eine vollständige Aktualisierung der Tabelle erforderlich.

Einschränkungen für bestimmte PostgreSQL-Variationen

Amazon RDS und Aurora

  • Der rds.logical_replication Parameter muss auf 1.

Azure-Datenbank für PostgreSQL

  • Die logische Replikation muss in den Serverparametern aktiviert sein.
  • Für Einzelserver-Bereitstellungen ist die logische Replikation nur in den Ebenen "Allgemeiner Zweck" und "Arbeitsspeicheroptimiert" verfügbar.
  • Für flexible Serverbereitstellungen wird die logische Replikation auf allen Ebenen unterstützt.
  • Der max_slot_wal_keep_size Parameter ist schreibgeschützt, fest bei -1 (unendlich) und kann nicht konfiguriert werden.

Google Cloud SQL für PostgreSQL

  • Das cloudsql.logical_decoding Flag muss aktiviert sein.
  • Cloud SQL lässt die Konfiguration max_slot_wal_keep_sizenicht zu. Sie ist standardmäßig mit -1 (unendlich) behoben.
  • Last updated on