Snowflake Connector for PostgreSQL-Eigenschaften¶

Versionsunterstützung¶

Snowflake Connector for PostgreSQL unterstützt jede offiziell unterstützte PostgreSQL Version. Snowflake stellt die Unterstützung für ältere Versionen ein, wenn Kunden auf neuere Versionen umsteigen. Snowflake kündigt Unterstützung für neue Versionen an, sobald diese veröffentlicht werden.

Der Konnektor unterstützt zwar eine Reihe von PostgreSQL-Cloud-Versionen, aber einige erfordern zusätzliche Einstellungen. Weitere Informationen dazu finden Sie unter Voraussetzungen für Snowflake Connector for PostgreSQL-Datenquellen.

Im Folgenden finden Sie die unterstützten PostgresSQL-Versionen.

Unterstützte PostgreSQL-Versionen¶
	11	12	13	14	15	16	17
Standard	Ja	Ja	Ja	Ja	Ja	Ja	Ja
AWS RDS	Ja	Ja	Ja	Ja	Ja	Ja	Ja
Amazon Aurora	Ja	Ja	Ja	Ja	Ja	Ja
GCP Cloud SQL	Ja	Ja	Ja	Ja	Ja	Ja
Azure Database	Ja	Ja	Ja	Ja	Ja	Ja

Server-Einstellungen¶

Überprüfen Sie die folgenden Einstellungen auf Ihrem PostgreSQL-Server und passen Sie sie bei Bedarf an:

`wal_level`	Auf `logical` setzen. Der Konnektor stützt sich auf Primärschlüssel, um Änderungen in Zieltabellen zusammenzuführen. Die folgenden Einstellungen stellen sicher, dass Write-Ahead Log (WAL)-Datensätze Primärschlüsselinformationen enthalten:
`max_replication_slots`	Fügen Sie für jeden Datenquellenkonfigurationseintrag für diese Datenbank im Datenbankagenten 1 hinzu.
`max_connections`	Fügen Sie für jeden Datenquellenkonfigurationseintrag für diese Datenbank im Datenbankagenten 1 hinzu.
`max_wal_senders`	Fügen Sie für jeden Datenquellenkonfigurationseintrag für diese Datenbank im Datenbankagenten 1 hinzu.

Veröffentlichungen¶

Der Konnektor benötigt eine PostgreSQL-Veröffentlichung, um auf Tabellen für die Replikation zuzugreifen.

Der Datenbankagent unterstützt genau eine Veröffentlichung pro Datenquelle. Wenn Sie mehrere Publikationen auf einem einzigen PostgreSQL-Server verwenden müssen, können Sie diesen Server mehrmals als separate Datenquellen konfigurieren, wobei jede ihre eigene Publikation hat.
Die Veröffentlichung sollte alle an den Daten vorgenommenen Änderungen enthalten, einschließlich INSERT, UPDATE, DELETE und TRUNCATE.
Die Veröffentlichung kann für ALL TABLES oder eine Teilmenge von Tabellen eingerichtet werden, aber für eine optimale Leistung sollten Sie nur die Tabellen hinzufügen, die repliziert werden sollen. Der Konnektor erhält nur Änderungen aus den in der Veröffentlichung enthaltenen Tabellen.
Tabellen können der Veröffentlichung mit allen Spalten oder mit einer Teilmenge von Spalten hinzugefügt werden. Wenn Sie eine Teilmenge von Spalten hinzufügen möchte , verwenden Sie die Prozedur ADD_TABLE_WITH_COLUMNS.

Warnung

Wenn eine Tabelle mit einer Teilmenge von Spalten zu einer Veröffentlichung hinzugefügt wird, dann aber mit der Prozedur ADD_TABLES für die Replikation aktiviert wird, werden Spalten, die in der Veröffentlichung fehlen, in der Zieltabelle als gelöscht markiert. Wenn Sie der Veröffentlichung später zusätzliche Spalten hinzufügen, wird die Tabelle als dauerhaft fehlgeschlagen markiert.

Weitere Informationen zur Konfiguration von Veröffentlichungen finden Sie unter Veröffentlichung konfigurieren.

Replikationsslots¶

Um Daten und Schemaänderungen zu replizieren, erstellt der Konnektor einen Replikationsslot. Der Slot wird erstellt, wenn die erste Tabelle einer bestimmten Datenquelle zur Replikation hinzugefügt wird, und für alle Tabellen dieser Datenquelle verwendet.

Der Name des Slots ist wie folgt aufgebaut: sf_db_conn_rs_kbmd_<data-source-name>, 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 jedem Datenbankagenten eindeutige Datenquellennamen zuweisen.

Vorsicht

Der Datenbank-Agent entfernt keine ungenutzten Replikationsslots. Wenn Sie den Datenbankagenten von einer PostgreSQL-Instanz trennen oder alle seine Tabellen aus der Replikation entfernen, müssen Sie auch den Replikationsslot manuell löschen, um zu verhindern, dass er das WAL-Trimmen blockiert.

WAL-Wachstum und Replikationsslotposition¶

Sobald ein Replikations-Slot erstellt wurde, sorgt er dafür, dass PostgreSQL die WAL-Daten aus der Position des Replikationsslots beibehält, bis der Konnektor diese Position bestätigt und weiterleitet. Der Konnektor bestätigt regelmäßig die Position, 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 Zeitplanmodus bestätigt der Konnektor die Position auf der Grundlage des konfigurierten Zeitplans. Beachten Sie, dass längere Zeitpläne dazu führen, dass WAL größer wird.

Sie müssen sicherstellen, dass auf Ihrem PostgreSQL-Server genügend Speicherplatz für die WAL vorhanden ist. Wenn Sie feststellen, dass die WAL kontinuierlich wächst, überprüfen Sie Folgendes:

Ist der Datenbankagent verbunden und repliziert der Konnektor aktiv Daten? Wenn nicht, wird der Replikationsslot nicht weitergeschaltet und das Trimmen der WAL wird blockiert.
Hält die Replikation mit den Datenänderungen in den replizierten Tabellen Schritt? Wenn nicht, d. h. wenn die Verzögerung zwischen einer Datenänderung in der Quelle und deren Anzeige in der Snowflake-Zieltabelle immer größer wird, wird der Replikationsslot zu langsam vorgerückt. Sie müssen einige Tabellen aus der Replikation entfernen oder die Größe des Compute Warehouse erhöhen.

Die Einstellung max_wal_size in PostgreSQL hat keine Auswirkung auf das Wachstum von WAL, wenn es durch einen nicht fortschreitenden Replikationsslot verursacht wird.

Tipp

In kritischen Situationen können Sie den vom Konnektor verwendeten Replikationsslot manuell löschen. Dies unterbricht jede Replikation, die im Konnektor läuft, ermöglicht es aber PostgreSQL, die WAL zu kürzen und Speicherplatz zurückzugewinnen.

Primärschlüssel und Tabellenreplikatidentitä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 oder eine zusammengesetzte Spalte sein.
Für die Tabellen muss außerdem REPLICA IDENTITY auf DEFAULT eingestellt sein. Dadurch wird sichergestellt, dass die Primärschlüssel in der WAL dargestellt werden und der Konnektor sie lesen kann.

Agent-Authentifizierung¶

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 von Datenquelle zu Datenquelle unterschiedlich sein können.

Die Benutzer des Datenbankagenten müssen über eine Rolle mit dem Attribut REPLICATION verfügen, oder SUPERUSER, wenn Ersteres nicht angewendet werden kann.

Eine Anleitung zum Anlegen eines Benutzers für den Datenbankagenten finden Sie unter Erforderlichen Benutzer erstellen.

Weitere Informationen zur Sicherung des Zugriffs des Datenbankagenten auf die Quelldatenbanken finden Sie in der Dokumentation PostgreSQL.