Snowflake Connector for PostgreSQL-Merkmale¶
Wichtig
Vielen Dank für Ihr Interesse an Snowflake Connector für PostgreSQL. Wir konzentrieren uns momentan auf eine Lösung der nächsten Generation, die ein deutlich verbessertes Benutzererlebnis bieten wird. Daher ist die Veröffentlichung dieses Konnektors mit dem Status „Allgemeine Verfügbarkeit“ derzeit nicht teil unserer Produkt-Roadmap. Sie können diesen Konnektor weiterhin als Vorschau-Feature verwenden. Beachten Sie aber, dass die Unterstützung von zukünftigen Fehlerkorrekturen und Verbesserungen nicht garantiert ist. Die neue Lösung ist als Openflow-Konnektor für PostgreSQL verfügbar und umfasst bessere Performance, Anpassbarkeit und erweiterte Bereitstellungsoptionen.
Versionsunterstützung¶
Der Snowflake Connector for PostgreSQL unterstützt alle offiziell unterstützten Versionen von PostgreSQL. Snowflake stellt die Unterstützung von älteren Versionen ein, da die Kunden auf neuere Versionen umsteigen. Snowflake kündigt die Unterstützung für neue Versionen an, sobald diese veröffentlicht werden.
Der Konnektor unterstützt zwar eine Reihe von PostgreSQL-Cloudversionen, bei einigen sind jedoch zusätzliche Einstellungen erforderlich. Weitere Informationen dazu finden Sie unter Voraussetzungen für Snowflake Connector for PostgreSQL-Datenquellen.
Im Folgenden finden Sie die unterstützten PostgresSQL-Versionen.
11 |
12 |
13 |
14 |
15 |
16 |
17 |
|
---|---|---|---|---|---|---|---|
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
||
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
||
Ja |
Ja |
Ja |
Ja |
Ja |
Ja |
Servereinstellungen¶
Überprüfen Sie die folgenden Einstellungen auf Ihrem PostgreSQL-Server, und passen Sie diese wie erforderlich an:
|
Auf Der Konnektor stützt sich auf Primärschlüssel, um Änderungen in Zieltabellen zusammenzuführen. Die folgenden Einstellungen stellen sicher, dass Write-Ahead-Protokoll (WAL)-Datensätze Primärschlüsselinformationen enthalten: |
|
Fügen Sie „1“ für jeden Datenquellenkonfigurationseintrag für diese Datenbank im Datenbankagenten hinzu. |
|
Fügen Sie „1“ für jeden Datenquellenkonfigurationseintrag für diese Datenbank im Datenbankagenten hinzu. |
|
Fügen Sie „1“ für jeden Datenquellenkonfigurationseintrag für diese Datenbank im Datenbankagenten hinzu. |
Veröffentlichungen¶
Der Konnektor erfordert eine PostgreSQL-Veröffentlichung für den Zugriff auf Tabellen für die Replikation.
Der Datenbankagent unterstützt genau eine Veröffentlichung pro Datenquelle. Wenn Sie mehrere Veröffentlichungen für einen einzigen PostgreSQL-Server verwenden müssen, können Sie diesen Server mehrfach als separate Datenquellen konfigurieren, jede mit einer eigenen Veröffentlichung.
Die Veröffentlichung sollte alle an den Daten vorgenommenen Änderungen enthalten, einschließlich
INSERT
,UPDATE
,DELETE
undTRUNCATE
.Die Veröffentlichung kann für
ALL TABLES
eingerichtet werden oder eine Teilmenge von Tabellen, aber für eine optimale Leistung fügen Sie nur die Tabellen hinzu, die repliziert werden sollen. Der Konnektor erhält nur Änderungen von den Tabellen, die in der Veröffentlichung enthalten sind.Tabellen können der Veröffentlichung mit allen ihren Spalten oder einer Teilmenge von Spalten zur Publikation hinzugefügt werden. Wenn Sie das Hinzufügen mit einer Teilmenge von Spalten vornehmen, verwenden Sie die ADD_TABLE_WITH_COLUMNS-Prozedur.
Warnung
Wenn eine Tabelle zu einer Veröffentlichung mit einer Teilmenge von Spalten hinzugefügt wird, aber dann für die Replikation unter Verwendung der Prozedur ADD_TABLES aktiviert wird, werden in der Veröffentlichung fehlende Spalten in der Zieltabelle als gelöscht markiert. Das spätere Hinzufügen weiterer Spalten zur Veröffentlichung führt dazu, dass die Tabelle als dauerhaft fehlgeschlagen markiert wird.
Weitere Informationen zur Veröffentlichungskonfiguration finden Sie unter Veröffentlichung konfigurieren.
Replikations-Slots¶
Um Daten- und Schemaänderungen zu replizieren, erstellt der Konnektor einen Replikations-Slot. Der Slot wird erstellt, wenn die erste Tabelle in einer bestimmten Datenquelle zur Replikation hinzugefügt wird, und er wird für alle Tabellen aus dieser Datenquelle verwendet.
Der Name des Slots ist als sf_db_conn_rs_kbmd_<data-source-name>
strukturiert, wobei <data-source-name>
der Bezeichner der Datenquelle in der Konfiguration des Datenbankagenten ist.
Wenn Sie den Datenbankagenten so konfigurieren, dass er sich mehrfach mit derselben Datenbank verbindet, indem Sie mehrere Datenquellen hinzufügen, erstellt der Konnektor mehrere Replikations-Slots.
Wenn Sie mehrere Datenbankagenten für die Verbindung mit demselben PostgreSQL-Server konfigurieren, müssen Sie für jeden Datenbankagenten eindeutige Datenquellennamen angeben.
Vorsicht
Der Datenbankagent entfernt nicht ungenutzte Replikations-Slots. Wenn Sie den Datenbankagenten von einer PostgreSQL-Instanz trennen oder alle seine Tabellen aus der Replikation entfernen, dann müssen Sie auch den Replikations-Slot manuell löschen, damit verhindert wird, dass er das WAL-Kürzen aufhält.
WAL-Wachstum und Position von Replikations-Slots¶
Einmal erstellt, führt ein Replikations-Slot dazu, dass PostgreSQL die WAL-Daten an der Position des Replikations-Slots beibehält, bis der Konnektor diese bestätigt und fortschreitet. Der Konnektor bestätigt die Position regelmäßig, nachdem Datensätze in seinen Journaltabellen gespeichert wurden, auch wenn sie noch nicht in Zieltabellen zusammengeführt wurden.
Im kontinuierlichen Modus bestätigt der Konnektor die Position jede Minute.
Im geplanten Modus bestätigt der Konnektor die Position auf der Grundlage des konfigurierten Zeitplans. Denken Sie daran, dass längere Zeitpläne dazu führen, dass das WAL anwächst.
Sie müssen sicherstellen, dass auf dem PostgreSQL-Server ausreichend Speicherplatz für das WAL vorhanden ist. Wenn Sie die erkennen, dass das WAL kontinuierlich wächst, überprüfen Sie Folgendes:
Ist der Datenbankagent verbunden, und der Konnektor repliziert aktiv Daten? Wenn nicht, wird der Replikations-Slot nicht fortgesetzt und blockiert so das WAL-Kürzen.
Hält die Replikation mit den Datenänderungen in den replizierten Tabellen Schritt? Wenn nicht, d. h. die Verzögerung zwischen einer Datenänderung in der Quelle und ihrem Auftreten in der Snowflake-Zieltabelle wird immer größer, dann wird der Replikations-Slot zu langsam fortgesetzt. Sie müssen einige Tabellen aus der Replikation entfernen oder das Compute-Warehouse vergrößern.
Die max_wal_size
-Einstellung in PostgreSQL hat keine Auswirkungen auf das WAL-Wachstum, wenn es durch einen Replikations-Slot verursacht wird, der nicht fortgesetzt wird.
Tipp
In kritischen Situationen können Sie den vom Konnektor verwendeten Replikations-Slot manuell löschen. Dadurch wird jede im Konnektor laufende Replikation unterbrochen, PostgreSQL jedoch ermöglicht, das WAL zu kürzen und Festplattenspeicher freizugeben.
Primärschlüssel und Tabellenreplikationsidentität¶
Der Konnektor stützt sich auf Primärschlüssel, um Änderungen in den Zieltabellen zusammenzuführen. Dies hat folgende Auswirkungen:
Jede für die Replikation aktivierte Tabelle muss einen Primärschlüssel haben. Der Schlüssel kann eine einzelne Spalte oder eine Zusammensetzung sein.
Für Tabellen muss außerdem REPLICA IDENTITY auf
DEFAULT
festgelegt sein. Dadurch wird sichergestellt, dass die Primärschlüssel im WAL dargestellt werden , und der Konnektor kann sie lesen.
Agentenauthentifizierung¶
Die einzige derzeit unterstützte Authentifizierungsmethode ist Benutzername und Kennwort. Jeder Datenquelleneintrag in der Konfiguration des Datenbankagenten enthält einen eigenen Satz von Anmeldeinformationen, die zwischen den Datenquellen variieren können.
Die Benutzer des Datenbankagenten müssen eine Rolle mit dem Attribut REPLICATION
oder SUPERUSER
verfügen, wenn ersteres nicht angewendet werden kann.
Eine Anleitung zum Erstellen eines Benutzers für den Datenbankagenten finden Sie unter Erforderlichen Benutzer erstellen.
Weitere Informationen zum Sichern des Zugriffs des Datenbankagenten auf die Quelldatenbanken finden Sie in der PostgreSQL-Dokumentation.