Aller au contenu principal
Dernière mise à jour le

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

Trouvez des réponses aux questions fréquemment posées concernant le connecteur MySQL.

Quelles versions et plateformes MySQL sont prises en charge ?​

Le connecteur MySQL prend en charge les versions et plateformes 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 (pour les configurations HA, la prise en charge n'est disponible qu'à partir de l'instance principale)
  • 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 pour MySQL : Version 5.7.44 et versions ultérieures
  • MySQL sur EC2 : Version 5.7.44 et ultérieure

Quelles méthodes d'authentification sont prises en charge ?​

Le connecteur MySQL prend en charge les plug-ins d'authentification suivants en fonction de votre version de MySQL :

  • **MySQL 5.7.44** : Seul sha256_password est pris en charge. L'utilisateur de réplication doit être créé en utilisant ce plug-in d'authentification.
  • MySQL 8.0 et versions ultérieures :sha256_password et sont tous deux caching_sha2_password pris en charge.

Le connecteur prend-il en charge la réplication basée sur GTID ?​

Non, le connecteur MySQL ne prend pas en charge la réplication basée sur le GTID (identifiant de transaction global). Le connecteur utilise la réplication binlog basée sur la position.

Vous pouvez toujours utiliser le connecteur si GTID est activé sur votre serveur MySQL, mais le connecteur utilise un fichier binlog et une réplication basée sur la position quoi qu'il arrive.

Les transactions XA sont-elles prises en charge ?​

Non, le connecteur MySQL ne prend pas en charge les transactions XA (transactions distribuées). Si une transaction XA est effectuée, la table est ignorée du pipeline.

Puis-je ingérer des tables avec des types de données spatiales ?​

Non, les types de données spatiales (GEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION) ne sont pas pris en charge.

Si une table contient des colonnes spatiales, vous devez exclure la table entière de l'ingestion. Les tables avec des types spatiaux sont ignorées lorsqu'elles sont détectées ou lorsqu'une nouvelle colonne avec des types spatiaux est ajoutée.

Puis-je créer plusieurs pipelines avec la même table de destination ?​

Non, une seule table de destination ne peut être gérée que par un seul pipeline d'ingestion géré. Vous ne pouvez pas créer deux pipelines d'ingestion gérés différents avec des tables de destination qui se chevauchent.

Puis-je ingérer des tables portant le même nom à partir de différents schémas ?​

Non, vous ne pouvez pas ingérer deux tables portant le même nom dans le même pipeline, même si elles proviennent de schémas source différents. Par exemple, vous ne pouvez pas ingérer à la fois schema1.customers et schema2.customers dans un seul pipeline.

Pour contourner ce problème, voir Créer des pipelines multi-destinations.

Comment faire pivoter les identifiants MySQL ?​

Pour renouveler les identifiants d’une connexion existante :

  1. Mettez à jour le mot de passe dans MySQL
  2. Dans Databricks, allez dans l'Explorateur de catalogues.
  3. Accédez à la connexion.
  4. Cliquez sur Modifier et mettez à jour le mot de passe.
  5. Enregistrer les modifications

La passerelle d'ingestion et le pipeline utiliseront automatiquement les nouvelles identifiants lors de la prochaine exécution.

Les noms de table et de colonne sont-ils sensibles à la casse ?​

Oui, les noms de table et de schéma MySQL sont sensibles à la casse dans le connecteur MySQL. Les noms de schémas et de tables MySQL sont sensibles à la casse, tandis que les noms de catalogues, de schémas et de tables Unity Catalog ne le sont pas. S'il y a un conflit de casse (par exemple, mytable contre MyTable), utilisez la fonctionnalité de destinations multiples pour résoudre les conflits.

Pour plus de détails, consultez la sensibilité à la casse des identificateurs dans la documentation MySQL.

Quelle Monter en charge a été testée pour le connecteur MySQL ?​

Le connecteur a été testé pour 100 tables dans un seul pipeline avec des données d'instantané totales inférieures à 1 To.

Recommandations de type de machine pour la passerelle d'ingestion :

Voici les types de machines default :

  • AWS: r5n.xlarge
  • Azure : Standard_E4d_v4
  • GCP: n2-highmem-4

Envisagez d'utiliser r5n.2xlarge, Standard_E8d_v4 ou n2-highmem-8 pour de meilleures performances d'instantanés.

Limites des pipelines :

  • Databricks recommande 250 tables ou moins par pipeline
  • Limite stricte : 1 000 flux par pipeline (qui prend en charge jusqu'à 500 tables)

Remarque : Bien que la limite absolue prenne en charge jusqu'à 500 tables, Databricks recommande 250 ou moins pour des performances optimales.

La passerelle d'ingestion prend-elle en charge l'exécution en mode Trigger ?​

Non, la passerelle d’ingestion ne prend pas en charge le mode Trigger et doit s’exécuter en continu pour éviter la nécessité de refresh complètes en raison des nettoyages de Logs.

Le pipeline d'ingestion peut s'exécuter selon une planification ou être Trigger, mais la passerelle doit rester opérationnelle en continu.

Quand faut-il effectuer un full refresh ?​

Effectuez un full refresh dans les scénarios suivants :

  • Lorsqu'un flux de table est marqué comme ayant échoué dans le pipeline d'ingestion.
  • Lorsqu'un changement de schéma incompatible provoque l'échec du flux de table.
  • Lorsque les fichiers binlog sont nettoyés avant que la passerelle d'ingestion ne les rejoue.
  • Lorsque vous devez resynchroniser manuellement une table.

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

Que dois-je faire si les fichiers binlog sont nettoyés avant que la passerelle d’ingestion ne les rejoue ?​

Si les fichiers binlog sont purgés avant que la passerelle d’ingestion ne les traite :

  1. La passerelle d'ingestion détectera cet événement et ignorera toutes les tables affectées.
  2. Chaque table ignorée aura des logs d'événements DLT appropriés indiquant le problème
  3. Vous devez Trigger une refresh complète pour toutes les tables affectées dans le pipeline

Pour éviter que cela ne se produise :

  • Configurez une rétention binlog adéquate (un jour minimum, sept jours recommandés).
  • Assurez-vous que la passerelle d'ingestion fonctionne en continu.

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 déploiements MySQL on-premise ?​

Oui, les déploiements MySQL on-premise sont pris en charge lorsqu'ils sont connectés à un Workspace Databricks via :

  • Azure ExpressRoute
  • AWS Direct Connect
  • Connexion VPN

Veillez à ce que :

  • Une bande passante réseau suffisante est disponible pour le transfert de données.
  • La connectivité réseau est stable et fiable
  • Les règles du pare-feu autorisent le trafic sur le port MySQL (default 3306)
  • La rétention des binlogs est configurée correctement.

Pour plus d'informations, contactez l'équipe du support Databricks. Pour plus de détails sur la connectivité entre les clouds, consultez Connectivité réseau.

Sur cette page