Limitations du connecteur PostgreSQL

info

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épertorie les limitations et considérations relatives à l'ingestion PostgreSQL à l'aide de Databricks Lakeflow Connect.

Limitations générales du connecteur de base de données

Les limitations de cette section s'appliquent à tous les connecteurs de base de données dans Lakeflow Connect. Poursuivez votre lecture pour connaître les limitations spécifiques au connecteur.

• Lorsque vous exécutez un pipeline planifié, les alertes ne se Trigger pas immédiatement. Au lieu de cela, ils Trigger lors de l’exécution de la prochaine mise à jour.

• Lorsqu’une table source est supprimée, la table de destination n’est pas automatiquement supprimée. Vous devez supprimer la table de destination manuellement. Ce comportement n'est pas cohérent avec le comportement de Spark Declarative Pipelines sur Lakeflow.

• Le catalogue de préproduction ne peut pas être un catalogue étranger.

• Pendant les périodes de maintenance de la source, Databricks pourrait ne pas être en mesure d'accéder à vos données.

• Si un nom de table source entre en conflit avec un nom de table de destination existant, la mise à jour du pipeline échoue.

• La prise en charge des pipelines multi-destination est uniquement via l'API.

• Vous pouvez éventuellement renommer une table que vous ingérez. Si vous renommez une table dans votre pipeline, il devient un pipeline API uniquement, et vous ne pouvez plus modifier le pipeline dans l'interface utilisateur.

• Si vous sélectionnez une colonne après qu'un pipeline a déjà start, le connecteur ne renseigne pas automatiquement les données historiques pour la nouvelle colonne. Pour ingérer des données historiques, exécutez manuellement un refresh complet sur la table.

• Databricks ne peut pas ingérer deux tables ou plus portant le même nom dans le même pipeline, même si elles proviennent de schémas sources différents.

• Le système source suppose que les colonnes du curseur augmentent de façon monotone.

• Les instantanés de passerelle ne peuvent pas être repris. Si vous mettez à jour le pipeline pendant qu'un instantané est en cours (par exemple, en ajoutant de nouvelles tables), l'instantané actuel est annulé et un nouvel instantané start. Le nouvel instantané inclut l'union des tables de l'instantané annulé et de toutes les tables nouvellement ajoutées.

• Le connecteur ingère des données brutes sans transformations. Utilisez les Spark Declarative Pipelines en aval sur les Lakeflow Pipelines pour les transformations.

• Le connecteur ne prend en charge que la réplication à partir d'instances PostgreSQL principales.

Authentification

• Le connecteur ne prend en charge que l'authentification par nom d'utilisateur et mot de passe.

Variations de base de données

• Le connecteur prend en charge PostgreSQL 13 ou une version supérieure.
• 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. Le connecteur prend également en charge PostgreSQL on-premise via Azure ExpressRoute, AWS Direct Connect et la connexion VPN. Pour plus de détails sur la connectivité inter-cloud, consultez Connectivité réseau.

pipeline

• Chaque pipeline d'ingestion doit être associé à exactement une passerelle d'ingestion. Les passerelles ne peuvent pas être partagées entre les pipelines.
• Bien que le pipeline d'ingestion s'exécute sur un compute serverless, la passerelle d'ingestion doit s'exécuter sur un compute classique.
• La passerelle d'ingestion doit fonctionner en mode continu pour éviter le gonflement du Write-Ahead Log (WAL) et l'accumulation d'emplacements de réplication.

Réplication

• Pour AWS RDS et Aurora, définissez le paramètre rds.logical_replication sur 1.

• Chaque table que vous répliquez doit avoir son identité de réplica définie sur FULL ou DEFAULT. Databricks recommande d'utiliser l'identité de réplica FULL pour les tables sans clés primaires ou avec des colonnes TOASTables.

• Les emplacements de réplication ne sont pas automatiquement supprimés lorsque vous supprimez des pipelines. Vous devez nettoyer manuellement les emplacements de réplication pour éviter l'accumulation de WAL. Consultez Nettoyer les emplacements de réplication.

• Le connecteur utilise la position de l'emplacement de réplication pour le point de contrôle. Si le nœud PostgreSQL primaire est rétrogradé ou remplacé (par exemple, lors d'un basculement), les informations d'emplacement de réplication sont perdues. Cela entraîne une erreur d'emplacement introuvable qui nécessite une refresh complète de toutes les tables du pipeline. La connexion à un autre nœud source n'est pas prise en charge.

évolution des schémas

Les comportements décrits dans cette section s'appliquent uniquement si vous activez le DDL en ligne. Lorsque le DDL en ligne est désactivé, le connecteur détecte toujours les changements de schéma, mais les tables affectées nécessitent un refresh complet. Pour activer le DDL en ligne, consultez Facultatif : Configurer le suivi du DDL en ligne.

Lorsque le DDL en ligne est activé, le connecteur gère automatiquement les colonnes nouvelles et supprimées.

• Lorsqu'une nouvelle colonne apparaît dans la source, le connecteur l'ingère automatiquement lors de la prochaine exécution du pipeline.
• Lorsque vous supprimez une colonne de la source, le connecteur ne la supprime pas automatiquement. Au lieu de cela, le connecteur utilise une propriété de table pour définir la colonne supprimée sur inactive dans la cible. Si une autre colonne apparaît ultérieurement avec un nom qui entre en conflit avec la colonne inactive, le pipeline échoue. Dans ce cas, exécutez un refresh complet de la table ou supprimez manuellement la colonne inactive.

Le connecteur peut gérer les DDL suivants, mais nécessite un refresh complet des tables cibles.

Instructions DDL nécessitant une complète refresh

• Modification du type de données d'une colonne
• Renommer une colonne
• Modification de la clé primaire d’une table
• Conversion d'une table d'unlogged à logged ou vice versa
• Ajout ou suppression de partitions (pour les tables partitionnées)

Mise en scène

Le catalogue de préproduction ne peut pas être un catalogue étranger.

Tables

• Databricks recommande d'ingérer 250 tables ou moins par pipeline. Cependant, il n'y a aucune limite quant au nombre de lignes ou de colonnes prises en charge dans ces tables.
• Databricks ne peut pas ingérer deux tables dont les noms ne diffèrent que par la casse (par exemple, mytable et MyTable) en utilisant un seul pipeline. Pour prendre en charge de tels cas, créez deux paires de pipelines de passerelle-ingestion qui publient vers différents schémas cibles.
• Les noms source_catalog, source_schema et source_table respectent la casse pour le nom de la base de données, mais ne la respectent pas pour les noms de schémas et de tables (conformément au comportement default de PostgreSQL). Par exemple, si la base de données source est nommée MyDatabase, vous devez la spécifier comme MyDatabase dans le ingestion_definition.
• Bien que vous puissiez ingérer à partir de plusieurs bases de données ou schémas source dans un seul pipeline, vous ne pouvez pas ingérer deux tables du même nom. Par exemple, vous ne pouvez pas ingérer à la fois schema1.orders et schema2.orders dans le même pipeline.
• Vous pouvez inclure plusieurs spécifications de table ou de schéma dans le champ objects du ingestion_definition. Cependant, les noms des tables sources dans différents schémas sources ne peuvent pas se chevaucher. Des noms qui se chevauchent entraînent un échec du pipeline d'ingestion.

Types de données

• Les types définis par l'utilisateur et les types d'extension tiers sont ingérés en tant que chaînes.

• Les types de données TIME et TIMETZ sont ingérés comme des chaînes de caractères.

• Pour les types de données NUMERIC et DECIMAL :

  • Si la précision est inférieure ou égale à 38, NaN est mappé sur null.
  • Si la précision est supérieure à 38, la valeur est stockée sous forme de chaîne et NaN est préservée sous forme de chaîne.
  • Inf et -Inf sont pris en charge uniquement pour les types numériques non bornés. Pour une précision supérieure à 38, la valeur est stockée sous forme de chaîne et la valeur infinie est préservée.

• Pour le type de données DATE : La plage de dates complète de PostgreSQL est prise en charge. Inf et -Inf sont convertis en null. Les dates av. J.-C. sont stockées à l’aide de la numérotation astronomique des années. Par exemple, 1 av. J.-C. correspond à l'année 0 et 2 av. J.-C. correspond à -1.

• Pour le type de données TIMESTAMP (sans fuseau horaire) : Les valeurs sont ingérées sous forme de chaînes de caractères. Inf et -Inf sont conservés en tant que chaînes de caractères.

• Pour le type de données TIMESTAMP WITH TIME ZONE : la plage PostgreSQL prise en charge est de 4713-01-01 00:00:00.000000 BC à 294276-12-31 23:59:59.999999 AD, tandis que la plage prise en charge par Databricks est de -290308-12-21 BCE 19:59:06 GMT à +294247-01-10 CE 04:00:54 GMT. Les Timestamps supérieurs à l’horodatage maximal pris en charge par Databricks sont convertis en null. Les dates av. J.-C. sont stockées à l’aide de la numérotation astronomique des années. Par exemple, 1 av. J.-C. correspond à l’année 0 et 2 av. J.-C. correspond à -1. Inf et -Inf sont convertis en null.

• Pour le type de données INTERVAL : Les valeurs d'infini sont mappées à 0 years 0 mins 0 days 0 hours 0 mins 0.0 secs.

• MONEY Les valeurs sont ingérées sous forme de chaînes.

• Les colonnes binaires (par exemple, BYTEA) ne peuvent pas être utilisées comme clés de clustering.

• Tout type de données PostgreSQL intégré non listé dans la table Transformations automatiques de données est ingéré en tant que chaîne de caractères.

Tables partitionnées

• Les tables partitionnées PostgreSQL sont prises en charge.
• Chaque partition est traitée comme une table distincte à des fins de réplication.
• L'ajout ou la suppression de partitions nécessite un refresh complet de la table.

Limitations pour des variations spécifiques de PostgreSQL

Amazon RDS et Aurora

• Le paramètre rds.logical_replication doit être défini sur 1.

Base de données Azure pour PostgreSQL

• La réplication logique doit être activée dans les paramètres du serveur.
• Pour les déploiements à serveur unique, la réplication logique n'est disponible que dans les niveaux General Purpose et Memory Optimized.
• Pour les déploiements de serveurs flexibles, la réplication logique est prise en charge sur tous les niveaux.
• Le paramètre max_slot_wal_keep_size est en lecture seule, fixe à -1 (infini) et ne peut pas être configuré.

Google Cloud SQL pour PostgreSQL

• Le drapeau cloudsql.logical_decoding doit être activé.
• Cloud SQL ne permet pas de configurer max_slot_wal_keep_size; il est fixé à -1 (infini) par default.