Limitations du connecteur SQL Server

Cette page répertorie les limitations et les considérations relatives à l’ingestion SQL Server à 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 support est limité aux instances SQL Server primaires. En effet, le suivi des modifications et la capture des données modifiées ne sont pas pris en charge sur les répliques en lecture seule ou les instances secondaires.

Authentification

• Le connecteur prend en charge l'authentification de base (nom d'utilisateur et mot de passe). Pour Azure SQL Database et Azure SQL Managed Instance, le connecteur prend également en charge l'authentification Microsoft Entra ID.
• Les configurations de clusters de basculement multi-sous-réseaux doivent fournir une seule adresse IP frontale.

Variations de base de données

• Le connecteur prend en charge Azure SQL Database, Azure SQL Managed Instance et les bases de données SQL Amazon RDS. Cela inclut SQL Server s'exécutant sur des machines virtuelles Azure (VM) et Amazon EC2. Le connecteur prend également en charge SQL Server on-premise à l’aide de la mise en réseau Azure ExpressRoute et AWS Direct Connect. Pour plus de détails sur la connectivité inter-cloud, consultez Connectivité réseau.

• Pour utiliser la capture de données modifiées (CDC) de Microsoft :

  • Vous devez disposer de SQL Server 2012 Service Pack 1 (SP1) Cumulative Update package 3 (CU3) ou supérieur.

    Cette mise à jour a introduit la colonne __$command_id. Sans cette colonne, la passerelle d'ingestion ne peut pas distinguer de manière fiable les types d'opérations de modification de données (par exemple, les UPDATE opérations qui se manifestent sous forme de DELETE-INSERT paires avec des valeurs __$seqval identiques). Cela peut entraîner des incohérences de données.

  • Pour les versions antérieures à SQL Server 2016, l'édition Entreprise est également requise.

  • Pour les groupes de disponibilité SQL Server (AG) : les points de contrôle LSN sont portables sur les répliques. Si vous vous connectez en utilisant l'adresse d'écouteur AG, le pipeline peut reprendre après un basculement AG imprévu sans perte de données.

• Pour utiliser le suivi des modifications Microsoft, vous devez disposer de SQL Server 2012 ou d'une version ultérieure.

  • Les données de suivi des modifications ne sont pas répliquées sur les nœuds secondaires. Tout changement de nœud source, y compris un basculement AG, nécessite un refresh complet de toutes les tables du pipeline.

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 s’exécuter en mode continu pour éviter que les modifications ne soient supprimées en raison de la rétention des logs. N’arrêtez pas la passerelle manuellement. Si des modifications ont été abandonnées, un refresh complet est requis pour toutes les tables affectées.

évolution des schémas

Le connecteur gère automatiquement les nouvelles colonnes et les colonnes supprimées, sauf si vous vous désabonnez.

• Lorsqu'une nouvelle colonne apparaît dans la source, Databricks l'ingère automatiquement lors de la prochaine exécution du pipeline. Toutefois, vous pouvez vous en désinscrire.
• Quand une colonne est supprimée de la source, Databricks 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 destination. Si une autre colonne apparaît ultérieurement avec un nom en conflit avec la colonne inactive, le pipeline échoue. Dans ce cas, vous pouvez exécuter un refresh complet de la table ou supprimer manuellement la colonne inactive.

Cela s'applique aux nouvelles tables et aux tables supprimées au sein d'un schéma si vous ingérez l'intégralité du schéma.

Enfin, le connecteur peut gérer les renommages de colonnes, bien que cela nécessite un refresh complet de la table.

Les modifications de schéma supplémentaires (par exemple, les modifications de type de données) nécessitent également un refresh complet des tables cibles.

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 sur le nombre de lignes ou de colonnes prises en charge au sein de ces objets.
• Databricks ne peut pas ingérer deux tables dont les noms ne diffèrent que par la casse (par exemple, MyTable et MYTABLE) à l'aide d'un seul pipeline. Pour prendre en charge de tels cas, créez deux paires de pipelines de passerelle-ingestion qui publient vers des schémas cibles.
• Les noms source_catalog, source_schema et source_table sont sensibles à la casse. Par exemple, si le catalogue de la base de données source est spécifié en tant que Marketing dans sys.databases, vous ne pouvez pas le spécifier en tant que marketing dans le ingestion_definition.
• Bien que vous puissiez ingérer à partir de plusieurs catalogues ou schémas source dans un pipeline, vous ne pouvez pas ingérer deux tables portant le même nom. Par exemple, vous ne pouvez pas ingérer à la fois schema1.Marketing et schema2.Marketing dans le même pipeline.
• Plusieurs spécifications de table ou de schéma peuvent être incluses dans le champ objects du ingestion_definition. Cependant, les noms des tables sources dans différents schémas sources ne peuvent pas se chevaucher. Cela entraîne l’échec du pipeline d’ingestion.