Caractéristiques de Snowflake Connector for PostgreSQL¶

Prise en charge des versions¶

Snowflake Connector for PostgreSQL prend en charge toute version officiellement prise en charge de PostgreSQL. Snowflake supprime la prise en charge des anciennes versions à mesure que les clients passent à des versions plus récentes. Snowflake annonce la prise en charge des nouvelles versions à mesure de leur publication.

Bien que le connecteur prenne en charge un certain nombre de versions Cloud PostgreSQL, certaines nécessitent des paramètres supplémentaires. Voir Conditions préalables requises pour les sources de données Snowflake Connector for PostgreSQL pour plus d’informations.

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 de serveur¶

Passez en revue les paramètres suivants sur votre serveur PostgreSQL et ajustez-les, si nécessaire :

`wal_level`	Définissez sur : `logical`. Le connecteur s’appuie sur les clés primaires pour fusionner les modifications dans les tables de destination. Les paramètres suivants garantissent que les enregistrements Write-Ahead Log (WAL) contiennent les informations de clé primaire :
`max_replication_slots`	Ajoutez 1 pour chaque entrée de configuration de source de données de 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 de 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 de 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 pour 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 sur un seul serveur PostgreSQL, vous pouvez configurer ce serveur plusieurs fois comme 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 pour un sous-ensemble de tables, mais, pour des performances optimales, n’ajoutez que les tables à répliquer. Le connecteur ne recevra que les modifications des tables incluses dans la publication.
Les tables peuvent être ajoutées à la publication avec toutes leurs colonnes ou avec un sous-ensemble de colonnes. Lors de l’ajout d’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 qu’elle est ensuite activée pour la réplication à l’aide de la procédure ADD_TABLES, les colonnes manquantes dans la publication seront marquées comme supprimées dans la table de destination. Si vous ajoutez ultérieurement des colonnes supplémentaires à la publication, la table sera marquée comme étant en échec permanent.

Pour plus d’informations sur la configuration de publications, voir Configurer la publication.

Emplacements de réplication¶

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

Le nom d’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 source 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 si vous supprimez toutes ses tables de la réplication, vous devez également supprimer manuellement l’emplacement de réplication pour éviter qu’il n’empêche la réduction de WAL.

Augmentation de la taille de WAL et position d’emplacement de réplication¶

Une fois créé, un emplacement de réplication fait en sorte que PostgreSQL conserve les données WAL de la position occupée par l’emplacement de réplication, jusqu’à ce que le connecteur confirme et avance cette position. Le connecteur confirme périodiquement la position après que le stockage des enregistrements 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 de WAL.

Vous devez vous assurer qu’il existe suffisamment d’espace sur le disque de votre serveur PostgreSQL pour WAL. Si vous constatez que WAL augmente continuellement, 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’avance pas et bloque la réduction de WAL.
La réplication suit-elle le rythme des modifications des données dans les tables répliquées ? Si ce n’est pas le cas, c’est-à-dire si le délai entre une modification des données dans la source et son apparition dans la table de destination Snowflake ne cesse de s’allonger, cela signifie que l’emplacement de réplication avance trop lentement. Vous devez retirer certaines tables de la réplication ou augmenter la taille d’entrepôt de calcul.

Le paramètre max_wal_size dans PostgreSQL n’aura aucun effet sur l’augmentation de la taille de WAL si elle est due à un emplacement de réplication qui n’avance pas.

Astuce

Dans les situations critiques, vous pouvez supprimer manuellement l’emplacement de réplication utilisé par le connecteur. Cela interrompra toute réplication en cours dans le connecteur, mais permettra à PostgreSQL de réduire WAL et de récupérer de l’espace sur le disque.

Clés primaires et identité des répliques 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 pour laquelle la réplication est activée doit avoir une clé primaire. La clé peut être une colonne unique ou composite.
La valeur REPLICA IDENTITY des tables doit également être définie sur DEFAULT. Cela permet de s’assurer que les clés primaires sont représentées dans 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, qui 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.