Questions fréquentes sur le connecteur PostgreSQL
Aperçu
Le connecteur PostgreSQL pour Lakeflow Connect est en aperçu public. Contactez votre équipe de compte Databricks pour vous inscrire à l'aperçu public.
Cette page répond aux questions fréquemment posées concernant le connecteur PostgreSQL dans Databricks Lakeflow Connect.
FAQ générales sur les connecteurs gérés
Les réponses dans les FAQ sur les connecteurs gérés s'appliquent à tous les connecteurs gérés dans Lakeflow Connect. Continuez à lire pour les FAQ spécifiques au connecteur.
Comment Databricks se connecte-t-il à PostgreSQL ?
Databricks se connecte à PostgreSQL à l’aide du protocole TLS (transport layer security) et d’une connexion JDBC. Les pipelines nouvellement créés valident également le certificat TLS du serveur pour vérifier l'identité du serveur. Pour plus de détails et d'options de configuration, veuillez consulter la validation du certificat de serveur TLS. Les identifiants sont stockés de manière sécurisée dans Unity Catalog et ne peuvent être récupérés que si l'utilisateur qui exécute le flux d'ingestion dispose des autorisations appropriées. Databricks recommande de créer un utilisateur de réplication distinct dans PostgreSQL pour ingérer des données. S'il y a des bases de données ou des tables que vous ne souhaitez pas exposer à cet utilisateur, vous pouvez utiliser les permissions PostgreSQL intégrées.
Si le pipeline échoue, l'ingestion reprend-elle sans perte de données ?
Oui. Databricks suit ce que le connecteur a extrait de la source et appliqué à la destination. Si un problème survient, Databricks peut reprendre à ce point tant que l’emplacement de réplication et les données du journal de transactions (WAL) restent sur la base de données source. Cela peut être impacté si le pipeline ne s'exécute pas avant que la période de rétention WAL ou les limites d'emplacements de réplication ne soient atteintes, ce qui nécessite un refresh complet sur les tables cibles.
Quelles variations de PostgreSQL le connecteur prend-il en charge ?
Le connecteur prend en charge AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Azure Database pour PostgreSQL, les machines virtuelles Azure et GCP Cloud SQL pour PostgreSQL. Cela inclut PostgreSQL fonctionnant sur des machines virtuelles. Le connecteur prend également en charge PostgreSQL on-premise en utilisant Azure ExpressRoute, AWS Direct Connect et un VPN si une bande passante suffisante est disponible. Pour plus de détails sur la connectivité inter-cloud, consultez Connectivité réseau.
Comment le connecteur extrait-il les données de manière incrémentielle ?
Le connecteur utilise la réplication logique PostgreSQL avec le plug-in pgoutput. La réplication logique capture toutes les Opérations de modification des données (insertions, mises à jour et suppressions) via le Write-Ahead Log sans impact significatif sur les performances de la base de données source.
Le connecteur capture-t-il les fuseaux horaires pour les colonnes de date et d'heure ?
Le connecteur préserve les informations de fuseau horaire pour les TIMESTAMP WITH TIME ZONE colonnes. Les colonnes TIMESTAMP WITHOUT TIME ZONE et TIME sont ingérées sous forme de chaînes de caractères dans leur format d'origine sans conversion de fuseau horaire.
Puis-je personnaliser la planification de la passerelle d'ingestion ?
Non, la passerelle d'ingestion doit fonctionner en mode continu. Ceci est essentiel pour PostgreSQL afin d'éviter l'engorgement du journal WAL (Write-Ahead Log) et de garantir que les emplacements de réplication n'accumulent pas de modifications non consommées. Si la passerelle est arrêtée pendant une période prolongée, l'emplacement de réplication peut entraîner l'accumulation de fichiers WAL sur la base de données source, remplissant potentiellement l'espace disque.
Comment le connecteur gère-t-il une table sans clé primaire ?
Le connecteur peut répliquer des tables sans clé primaire si l'identité de la réplique est définie sur FULL. Dans ce cas, le connecteur traite toutes les colonnes, à l'exception des objets volumineux, comme une clé primaire groupée. S'il y a des lignes en double dans la table source, ces lignes sont ingérées comme une seule ligne dans la table de destination, sauf si vous activez le suivi de l'historique.
À quelle fréquence peut-on planifier l'exécution du pipeline d'ingestion ?
Il n'y a aucune limite quant à la fréquence à laquelle vous pouvez planifier l'exécution du pipeline d'ingestion. Cependant, Databricks recommande au moins 5 minutes entre les intervalles, car il faut un certain temps pour que le compute serverless start up. Databricks ne prend pas en charge l'exécution du pipeline d'ingestion en mode continu.
Pourquoi est-ce que je ne vois pas toutes les lignes de ma base de données lors de la première exécution du pipeline ?
La passerelle d’ingestion extrait les données historiques et CDC dès qu’elle commence à s’exécuter. Le pipeline d’ingestion peut s'exécuter avant que toutes ces données n’aient été extraites, ce qui entraînerait une application partielle des données dans les tables cibles. Quelques exécutions du pipeline d'ingestion peuvent être nécessaires pour que toutes les données soient extraites et appliquées aux tables cibles.
Puis-je ingérer à partir d'un réplica en lecture ou d'une instance de secours ?
Non. Le support est limité aux instances PostgreSQL principales, car la réplication logique n'est pas prise en charge sur les réplicas en lecture ou les instances de secours.
Que se passe-t-il pour l'emplacement de réplication lorsque je supprime un pipeline ?
Lorsque vous supprimez un pipeline d'ingestion, l'emplacement de réplication n'est pas automatiquement supprimé de la base de données PostgreSQL source. Vous devez supprimer manuellement l'emplacement de réplication pour éviter l'accumulation du Write-Ahead Log (WAL). Consultez Nettoyer les emplacements de réplication pour obtenir des instructions sur le nettoyage des emplacements de réplication.
Quelle version de PostgreSQL est requise ?
PostgreSQL 13 ou supérieur est requis.
Le wal_level = logical est-il obligatoire pour l'ingestion CDC ?
Oui. Pour AWS RDS et Aurora, définissez le paramètre rds.logical_replication sur 1 pour activer la réplication logique.
Puis-je répliquer des tables à partir de plusieurs bases de données PostgreSQL dans un seul pipeline ?
Oui. Vous pouvez spécifier plusieurs bases de données source dans le champ source_catalog du ingestion_definition. Cependant, chaque base de données source nécessite sa propre connexion Unity Catalog et sa configuration de publication.
Combien de tables puis-je ingérer dans un seul pipeline ?
Databricks recommande d'ingérer 250 tables ou moins par pipeline pour des performances optimales. Cependant, il n'y a pas de limite stricte quant au nombre de lignes ou de colonnes prises en charge dans ces objets.
Mon portail d'ingestion met du temps à start. Comment le corriger ?
Les passerelles s'exécutent sur un compute classique et provisionnent une machine virtuelle (VM) à chaque start. Si le démarrage de la Startup prend plus de quelques minutes, veuillez prendre en considération ce qui suit :
- Passer au canal de distribution actuel du pipeline. Il s'agit de la correction la plus courante. Les builds du canal de distribution en aperçu ont des temps de Startup plus longs. Vous pouvez modifier ce paramètre dans l'interface utilisateur (dans les paramètres avancés du pipeline sous Canal de distribution ), le fichier de ressources groupées ou la spécification du pipeline.
- Ne redémarrez pas la passerelle entre les exécutions d'ingestion. La passerelle est conçue pour fonctionner en continu. L'arrêter et le redémarrer reprovisionne la VM à chaque redémarrage et risque de manquer des logs de modification si la source les tronque pendant que la passerelle est hors service.
Si la passerelle reste bloquée dans un état de démarrage pendant 15 minutes ou plus, créez un ticket d'assistance.
Ceci s'applique uniquement aux passerelles. Les pipelines d'ingestion s'exécutent sur des compute Serverless et start rapidement.
Le connecteur prend-il en charge les types et extensions définis par l'utilisateur ?
Le connecteur prend en charge la plupart des types de données PostgreSQL, y compris les tableaux et JSONB. Les types définis par l'utilisateur et les types d’extensions tiers sont ingérés en tant que chaînes. Consulter la référence du connecteur PostgreSQL pour une liste complète des mappages de types pris en charge.