Aller au contenu principal
Dernière mise à jour le

Limitations du connecteur MySQL

info

Aperçu

Le connecteur MySQL est en préversion publique. Contactez votre équipe de compte Databricks pour demander l'accès.

Découvrez les limitations et les considérations pour le connecteur MySQL.

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 des LakeFlow Pipelines.

  • 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.

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

  • Les pipelines d'ingestion gérés ne sont pas pris en charge pour les workspaces des régions AWS GovCloud (FedRAMP High).

  • Les pipelines d'ingestion gérés ne sont pas pris en charge pour les workspaces FedRAMP Moderate dans les régions us-east-2 ou us-west-1.

Versions et variantes de MySQL​

Le connecteur prend en charge les versions et plateformes MySQL suivantes :

  • Amazon RDS pour MySQL : Version 5.7.44 et versions ultérieures (pour les déploiements autonomes et HA)
  • Amazon Aurora MySQL : Version 5.7.mysql_aurora.2.12.2 et ultérieure (instance primaire uniquement pour les configurations HA)
  • Amazon Aurora MySQL Serverless : pris en charge
  • Azure Database pour MySQL Flexible Servers : Version 5.7.44 et ultérieure (déploiements autonomes et HA)
  • Google Cloud SQL for MySQL : versions 5.7.44 et ultérieures, versions 8.0 et ultérieures.
  • MySQL sur EC2 : Version 5.7.44 et ultérieure

Le connecteur ne prend pas en charge MariaDB ni d’autres bases de données compatibles MySQL.

Authentification​

  • Le connecteur prend en charge l’authentification par nom d’utilisateur et mot de passe avec les plug-ins d’authentification suivants :

    • MySQL 5.7.44 : L'utilisateur de réplication doit être créé à l'aide du plug-in d'authentification sha256_password.
    • MySQL 8.0.x et versions ultérieures : les plugins sha256_password et caching_sha2_password sont pris en charge.

  • Le bouton Tester la connexion dans l'interface utilisateur peut échouer pour les utilisateurs utilisant sha256_password ou caching_sha2_password, même lorsque les identifiants sont corrects. Il s'agit d'un problème connu. Vous pouvez toujours créer la connexion et procéder à la configuration du pipeline.

Exigences des Logs binaires​

  • La journalisation binaire doit être activée avec binlog_format=ROW et binlog_row_image=FULL.
  • Si le binlog est purgé avant que la passerelle ne traite les modifications, vous devez effectuer un refresh complet de toutes les tables du pipeline.
  • Databricks recommande 7 jours de rétention des journaux binaires. La définition d'une valeur inférieure pourrait entraîner le nettoyage des journaux binaires avant que la passerelle d'ingestion ne les rejoue.

Prise en charge des réplicas en lecture​

  • La prise en charge des réplicas en lecture est uniquement disponible pour Amazon RDS pour MySQL, Azure Database pour MySQL et MySQL sur EC2.
  • Le connecteur ne prend pas en charge l'ingestion à partir des réplicas en lecture Aurora MySQL. Vous devez vous connecter à l'instance principale Aurora (endpoint d'écriture).
  • Lorsque vous utilisez des réplicas en lecture, le décalage de réplication peut affecter la fraîcheur des données.

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 s’exécute en continu pour capturer les modifications avant que les binlogs ne puissent être tronqués ou purgés.
  • Ne reconnectez pas un pipeline d'ingestion à une réplique source ou un nœud différent. Le point de contrôle est local au nœud source initial. Le passage à un autre réplica ou nœud nécessite un full refresh de toutes les tables du pipeline.

Évolution des schémas et opérations DDL​

Le connecteur gère automatiquement les colonnes nouvelles et supprimées.

  • Lorsqu’une nouvelle colonne non spatiale apparaît dans la source, Databricks l’ingère automatiquement lors de la prochaine exécution du pipeline.
  • Les colonnes de type de données spatiales ne sont pas prises en charge et ne peuvent pas être ingérées.
  • 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.

Gestion des opérations DDL​

Le connecteur peut gérer certaines Opérations DDL, mais beaucoup nécessitent un refresh complet de la table :

  • TRUNCATE TABLE : Vous devez refresh la table.

  • RENAME TABLE : La table renommée est ignorée dans la passerelle d’ingestion, avec une erreur dans le log des événements. Le flux de cette table est marqué comme ayant échoué dans le pipeline d'ingestion.

  • DROP TABLE : La table est retirée de la passerelle d'ingestion, avec une erreur dans le log des événements. Le flux de cette table est marqué comme ayant échoué dans le pipeline d'ingestion.

  • **ADD PRIMARY KEY ou contrainte UNIQUE** : Vous devez refresh la table.

  • DROP PRIMARY KEY constraint : Vous devez refresh la table.

  • Supprimer la contrainte UNIQUE : s'il s'agit de la seule contrainte UNIQUE sur la table source, vous devez refresh la table. Si ce n'est pas le cas, aucune action n'est nécessaire.

  • DROP COLUMN / MODIFY COLUMN / CHANGE COLUMN : Vous devez refresh la table.

  • AJOUTER UNE COLONNE :

    • Si la colonne est de type non spatial : Aucune action n'est nécessaire. La colonne est automatiquement ingérée lors de la prochaine mise à jour du pipeline.
    • Si la colonne est de type spatial : l'ajout de la colonne suspend l'ingestion ultérieure de cette table. La table est ignorée dans la passerelle d'ingestion, avec une erreur dans le log d'événements. Le flux pour cette table est marqué comme ayant échoué dans le pipeline d'ingestion.

  • AJOUTER UNE TABLE (lors de l'ingestion du schéma entier) :

    • Si la table ne contient aucun type spatial : aucune action n'est requise. La table est automatiquement ingérée lors de la prochaine mise à jour du pipeline.
    • Si la table a des types spatiaux : La table est ignorée dans la passerelle d'ingestion, avec une erreur dans le log des événements. Le flux pour cette table est marqué comme échoué dans le pipeline d'ingestion.

Quand effectuer un refresh complet​

Effectuez un refresh complet d'une table dans les scénarios suivants :

  • Après une opération TRUNCATE TABLE sur la source.
  • Après une modification du type de données de colonne (MODIFY COLUMN).
  • Après avoir renommé une colonne (CHANGE COLUMN).
  • Après une DROP COLUMN Opération (pour supprimer les colonnes inactives).
  • Lorsque des colonnes spatiales sont ajoutées (avant de les supprimer de la sélection).

Pour effectuer un full refresh, consultez refresh entièrement les tables cibles.

Mise en scène​

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

Tables et types de données​

  • 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.
  • MySQL est un espace de noms à deux niveaux. Les noms source_schema et source_table sont sensibles à la casse.
  • Bien que vous puissiez ingérer à partir de plusieurs schémas sources dans un seul pipeline, vous ne pouvez pas ingérer deux tables du même nom vers le même schéma de destination. Par exemple, vous ne pouvez pas ingérer schema1.customers et schema2.customers vers le même schéma de destination. Cependant, vous pouvez les ingérer vers différents schémas de destination à l'aide d'un pipeline multi-destination.
  • Les types de données spatiales (GEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION) ne sont pas pris en charge. Si des colonnes spatiales sont présentes dans les tables sélectionnées, la table est ignorée dans la passerelle d'ingestion, avec une erreur dans le log des événements.

Jeux de caractères et classement​

Le connecteur ne réplique actuellement que les séquences d'octets compatibles UTF-8. Cela signifie que la réplication fonctionne correctement lorsque la représentation d'octets stockée dans MySQL correspond à l'encodage UTF-8.

Jeux de caractères pris en charge​

Les jeux de caractères MySQL suivants sont entièrement ou partiellement pris en charge :

  • Entièrement pris en charge (les octets correspondent toujours à UTF-8) :

    • utf8
    • utf8mb4
    • ascii

  • **Partiellement pris en charge** (plage ASCII uniquement) :

    • latin1 - La plupart des données du monde réel stockées au format latin1 sont compatibles ASCII et fonctionnent correctement. MySQL 5.7.44 utilise latin1 comme jeu de caractères par default.

  • Jeux de caractères default par version :

    • MySQL 5.7.44 : latin1 (default)
    • MySQL 8.0 et versions ultérieures : utf8mb4 (default)

Limitations du jeu de caractères​

  • Le connecteur ne convertit pas entre les jeux de caractères. Il transfère des octets bruts et s'attend à ce qu'ils représentent un UTF-8 valide.
  • Les caractères non compatibles UTF-8 dans des jeux de caractères non pris en charge pourraient apparaître brouillés ou incorrects dans la destination.
  • Pour les données non-ASCII dans des jeux de caractères autres que ceux énumérés ci-dessus, envisagez de convertir vos tables en utf8mb4 avant l'ingestion.

Problèmes connus​

  • Le bouton Test de connexion échoue pour les utilisateurs MySQL avec l'authentification sha256_password ou caching_sha2_password, même lorsque les identifiants sont valides. Il s'agit d'une limitation connue. Vous pouvez toujours créer des connexions et des pipelines.
Sur cette page