Caractéristiques d’un Snowflake Connector for PostgreSQL¶

Important

Merci de votre intérêt pour le Snowflake Connector pour PostgreSQL. Notez que nous nous concentrons maintenant sur une solution de nouvelle génération qui offrira une expérience considérablement améliorée. Par conséquent, le déplacement de ce connecteur vers l’état de mise à disposition générale n’est actuellement pas sur la feuille de route de notre produit. Vous pouvez continuer à utiliser ce connecteur en tant que fonction de prévisualisation, mais notez que la prise en charge des corrections de bogues et des améliorations futures n’est pas garantie. La nouvelle solution est disponible en tant que Connecteur Openflow pour PostgreSQL et comprend de meilleures performances, une meilleure personnalisation et des options de déploiement améliorées.

Prise en charge des versions¶

Le Snowflake Connector for PostgreSQL prend en charge toute version PostgreSQL officiellement prise en charge Snowflake abandonne la prise en charge des versions plus anciennes lorsque les clients passent à des versions plus récentes. Snowflake annonce la prise en charge des nouvelles versions au fur et à mesure de leur publication.

Bien que le connecteur prenne en charge plusieurs versions du cloud PostgreSQL, certaines nécessitent des paramètres supplémentaires. Pour plus d’informations, voir Conditions préalables requises pour les sources de données Snowflake Connector for PostgreSQL.

Les versions de PostgresSQL suivantes sont prises en charge.

Versions de PostgreSQL prises en charge¶
	11	12	13	14	15	16	17
Standard	Oui	Oui	Oui	Oui	Oui	Oui	Oui
AWS RDS	Oui	Oui	Oui	Oui	Oui	Oui	Oui
Amazon Aurora	Oui	Oui	Oui	Oui	Oui	Oui
GCP Cloud SQL	Oui	Oui	Oui	Oui	Oui	Oui
Base de données Azure	Oui	Oui	Oui	Oui	Oui	Oui

Paramètres du serveur¶

Vérifiez et ajustez les paramètres suivants sur votre serveur PostgreSQL selon les besoins :

`wal_level`	Définissez sur : `logical`. Le connecteur s’appuie sur les clés primaires pour fusionner les modifications dans des tables de destination. Les paramètres suivants garantissent que les enregistrements du journal Write-Ahead (WAL) comprennent des informations sur la clé primaire :
`max_replication_slots`	Ajoutez 1 pour chaque entrée de configuration de source de données pour cette base de données dans l’agent de base de données.
`max_connections`	Ajoutez 1 pour chaque entrée de configuration de source de données pour cette base de données dans l’agent de base de données.
`max_wal_senders`	Ajoutez 1 pour chaque entrée de configuration de source de données pour cette base de données dans l’agent de base de données.

Publications¶

Le connecteur nécessite une publication PostgreSQL pour accéder aux tables de la réplication.

L’agent de base de données prend en charge exactement une publication par source de données. Si vous devez utiliser plusieurs publications dans un seul serveur PostgreSQL, vous pouvez configurer ce serveur plusieurs fois en tant que sources de données distinctes, chacune avec sa propre publication.
La publication doit inclure toutes les modifications apportées aux données, y compris INSERT, UPDATE, DELETE, et TRUNCATE.
La publication peut être configurée pour ALL TABLES ou un sous-ensemble de tables, mais pour des performances optimales, n’ajoutez que les tables qui doivent être répliquées. Le connecteur recevra uniquement les modifications des tables incluses dans la publication.
Les tables peuvent être ajoutées à la publication avec toutes leurs colonnes, ou un sous-ensemble de colonnes. Lorsque vous effectuez un ajout avec un sous-ensemble de colonnes, utilisez la procédure ADD_TABLE_WITH_COLUMNS.

Avertissement

Lorsqu’une table est ajoutée à une publication avec un sous-ensemble de colonnes, mais activée pour la réplication à l’aide de la procédure ADD_TABLES, les colonnes manquantes dans la publication seront marquées dans la table de destination comme supprimées. L’ajout ultérieur de colonnes supplémentaires à la publication entraînera l’échec définitif de la table.

Pour plus d’informations sur la configuration des connexions, voir Configurer la publication.

Emplacements de réplication¶

Pour répliquer les modifications des données et des schémas, le connecteur crée un emplacement de réplication. L’emplacement est créé lorsque la première table d’une source de données donnée est ajoutée à la réplication et utilisée pour toutes les tables de cette source de données.

Le nom de l’emplacement est structuré comme suit : sf_db_conn_rs_kbmd_<data-source-name>, où <data-source-name> est l’identificateur de la source de données dans la configuration de l’agent de base de données.

Si vous configurez l’agent de base de données pour qu’il se connecte plusieurs fois à la même base de données, en ajoutant plusieurs sources de données, le connecteur créera plusieurs emplacements de réplication.
Si vous configurez plusieurs agents de base de données pour qu’ils se connectent au même serveur PostgreSQL, vous devez fournir des noms de sources de données uniques à chaque agent de base de données.

Prudence

L’agent de base de données ne supprime pas les emplacements de réplication inutilisés. Si vous déconnectez l’agent de base de données d’une instance PostgreSQL ou supprimez toutes ses tables de la réplication, vous devez également détruire manuellement l’emplacement de réplication pour l’empêcher de bloquer le découpage WAL.

Position de l’emplacement de croissance et de réplication WAL¶

Une fois créé, l’emplacement de réplication obligera PostgreSQL à conserver les données WAL depuis la position détenue par l’emplacement de réplication, jusqu’à ce que le connecteur confirme et fasse avancer cette position. Le connecteur confirme périodiquement la position une fois que les enregistrements ont été stockés dans ses tables de journal, même s’ils n’ont pas encore été fusionnés dans les tables de destination.

En mode continu, le connecteur confirme la position toutes les minutes.
En mode planifié, le connecteur confirme la position en fonction de la planification configurée. Gardez à l’esprit que des planifications plus longues * entraîneront une augmentation de la taille des WAL*.

Vous devez vérifier qu’il y a assez d’espace disque sur votre serveur PostgreSQL pour le WAL. Si vous détectez que le WAL grandit en continu, vérifiez les points suivants :

L’agent de base de données est-il connecté et le connecteur réplique-t-il activement les données ? Si ce n’est pas le cas, l’emplacement de réplication n’est pas avancé et bloque le découpageWAL.
La réplication suit-elle les changements de données dans les tables répliquées ? Si ce n’est pas le cas, ce qui signifie que le décalage entre une modification des données dans la source et son apparition dans la table de destination Snowflake ne cesse de s’étendre, donc le compartiment de réplication avance trop lentement. Vous devez retirer certaines tables de la réplication ou augmenter la taille de l’entrepôt de calcul.

Le paramétrage:code:max_wal_size dans PostgreSQL n’aura aucun effet sur la croissance WAL lorsqu’elle est causée par un emplacement de réplication qui n’avance p

Astuce

Dans les situations critiques, vous pouvez supprimer manuellement le emplacement de réplication utilisé par le connecteur. Cela interrompra toute réplication en cours d’exécution dans le connecteur, mais activera PostgreSQL pour découper le WAL et récupérer de l’espace disque.

Clés primaires et identité de réplique de table¶

Le connecteur s’appuie sur les clés primaires pour fusionner les modifications dans les tables de destination. En conséquence :

Chaque table activée pour la réplication doit avoir une clé primaire. La clé peut être une colonne unique ou un composite.
Les tables doivent également avoir leur REPLICA IDENTITY définies sur DEFAULT. Ceci permet de s’assurer que les clés primaires sont représentées dans le WAL, et que le connecteur peut les lire.

Authentification de l’agent¶

La seule méthode d’authentification actuellement prise en charge est le nom d’utilisateur et le mot de passe. Chaque entrée de source de données dans la configuration de l’agent de base de données comprend son propre ensemble d’identifiants de connexion, et celles-ci peuvent varier d’une source de données à l’autre.

Les utilisateurs de l’agent de base de données doivent avoir un rôle avec l’attribut REPLICATION, ou SUPERUSER si le premier ne peut pas être appliqué.

Pour obtenir des instructions sur la création d’un utilisateur pour l’agent de base de données, voir Créer l’utilisateur requis.

Pour plus d’informations sur la sécurisation de l’accès de l’agent de base de données aux bases de données sources, voir la`documentation PostgreSQL <https://www.postgresql.org/docs/current/logical-replication-security.html>`_.