Partager via


Ajouter une source CDC de base de données MySQL à un Eventstream

Remarque

Cet article contient des références au terme SLAVE, un terme que Microsoft n’utilise plus. Lorsque le terme sera supprimé du logiciel, nous le supprimerons de cet article.

Cet article vous montre comment ajouter une source de capture de données modifiées MySQL à un flux d’événements. Actuellement, mySQL Database CDC est pris en charge à partir des services suivants où les bases de données sont accessibles publiquement :

  • Azure Database pour MySQL
  • Amazon RDS pour MySQL
  • Amazon Aurora MySQL
  • Google Cloud SQL pour MySQL (GCP).

Ce guide utilise CDC (capture de données modifiées) Azure Database pour MySQL comme exemple.

Une fois la source cdc de base de données MySQL ajoutée au flux d’événements, elle capture les modifications au niveau des lignes apportées aux tables spécifiées. Ces modifications peuvent ensuite être traitées en temps réel et envoyées à différentes destinations pour une analyse plus approfondie.

Prérequis

  • Accès à un espace de travail en mode licence de capacité Fabric ou en mode licence d’évaluation avec des autorisations Collaborateur ou supérieures.
  • Accès à une instance de base de données MySQL, par exemple : une base de données dans Azure Database pour MySQL - Serveur flexible.
  • Votre base de données MySQL doit être accessible au public et ne doit ni se trouver derrière un pare-feu, ni être sécurisée dans un réseau virtuel.
  • Si vous n’avez pas d’eventstream, créez-en un.

Configurez MySQL DB

Le connecteur utilise le connecteur Debezium MySQL pour capturer les modifications dans votre base de données MySQL. Vous devez définir un utilisateur MySQL disposant de privilèges appropriés sur toutes les bases de données dans lesquelles le connecteur de messagerie peut capturer les modifications. Vous pouvez utiliser directement l’utilisateur administrateur pour vous connecter à la base de données qui dispose normalement des privilèges appropriés, ou vous pouvez suivre ces étapes pour créer un utilisateur :

Remarque

Le nouveau compte d’utilisateur ou d’administrateur et le mot de passe correspondant seront utilisés ultérieurement pour se connecter à la base de données dans Eventstream.

  1. À l’invite de commande mysql, créez l’utilisateur MySQL :

    mysql> CREATE USER 'user'@'%' IDENTIFIED BY 'password';
    
  2. Accordez les privilèges nécessaires à l’utilisateur :

    mysql> GRANT SELECT, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user'@'%';
    

    Remarque

    Lorsqu’un verrou de lecture global n’est pas disponible, comme avec des options hébergées telles qu’Amazon RDS ou Aurora, des verrous au niveau des tables sont utilisés pour créer l’instantané cohérent. Dans ce cas, vous devez accorder l'autorisation LOCK TABLES à l'utilisateur. En outre, pour prendre en charge les opérations FLUSH pendant l’instantané, vous devrez peut-être accorder également des privilèges RELOAD ou FLUSH_TABLES.

  3. Finalisez les autorisations de l’utilisateur :

    mysql> FLUSH PRIVILEGES;
    

Pour vérifier si l’utilisateur ou l’administrateur dispose des privilèges requis accordés, exécutez cette commande, puis les privilèges requis à l’étape 2 doivent être affichés :

SHOW GRANTS FOR user;

Pour plus d’informations sur l’octroi des autorisations requises à l’utilisateur, consultez le connecteur Debezium pour MySQL : Documentation Debezium.

Activer le binlog

Vous devez activer la journalisation binaire pour la réplication MySQL. Les journaux binaires enregistrent les mises à jour des transactions pour que les outils de réplication propagent les modifications. Cette section utilise Azure Database pour MySQL CDC comme exemple pour montrer les étapes de configuration.

  1. Sur la page du portail Azure pour votre compte Azure Database pour MySQL, sélectionnez Paramètres du serveur sous Paramètres dans la navigation de gauche.

  2. Sur la page Paramètres du serveur, configurez les propriétés suivantes, puis sélectionnez Enregistrer.

    • Pour binlog_row_image, sélectionnez complet.

    • Pour binlog_expire_logs_seconds, définissez le nombre de secondes pendant lesquelles le service attend que le fichier journal binaire soit supprimé définitivement. Définissez la valeur pour qu’elle corresponde aux besoins de votre environnement, par exemple 86400.

    Capture d’écran des paramètres binlog pour la réplication sous paramètres du serveur.

Ajouter MySQL DB (CDC) en tant que source

Si vous n’avez pas encore ajouté de source à votre flux d’événements, sélectionnez la vignette Utiliser la source externe .

Capture d’écran montrant la sélection de la vignette pour l’utilisation d’une source externe.

Si vous ajoutez la source à un flux d’événements déjà publié, basculez vers le mode Édition. Dans le ruban, sélectionnez Ajouter> dessources externes.

Capture d’écran montrant les sélections pour l’ajout de sources externes.

Sur la page Sélectionner une source de données, recherchez et sélectionnez Se connecter dans la vignette Base de données MySQL (CDC).

Capture d’écran montrant la sélection de la base de données MySQL (CDC) comme type de source dans l’Assistant Obtenir les événements.

Configurer et se connecter à MySQL DB (CDC)

  1. Dans l’écran Connecter, sous Connexion, sélectionnez Nouvelle connexion pour créer une liaison de connexion cloud.

    Capture d’écran montrant la page Se connecter.

  2. Entrez les Paramètres de connexion suivants et les Informations d’identification de connexion pour votre base de données MySQL, puis sélectionnez Se connecter.

    • Server : l’adresse du serveur de votre base de données MySQL, par exemple my-mysql-server.mysql.database.azure.com.

    • Base de données : nom de la base de données, par exemple my_database.

    • Nom de connexion : généré automatiquement, ou vous pouvez entrer un nouveau nom pour cette connexion.

    • nom d’utilisateur et mot de passe: entrez les informations d’identification de votre base de données MySQL. Veillez à entrer le compte d’administrateur de serveur ou le compte d’utilisateur créé avec les privilèges nécessaires.

      Capture d’écran des paramètres de connexion pour Azure MySQL DB (CDC).

  3. Entrez les informations suivantes pour configurer la source de données MySQL CDC, puis sélectionnez Suivant.

    • Port : la valeur par défaut est 3306. Si votre connexion cloud sélectionnée est configurée dans Gérer les connexions et les passerelles, vérifiez que le numéro de port correspond à celui défini ici. S’ils ne correspondent pas, le numéro de port dans la connexion cloud dans Gérer les connexions et les passerelles est prioritaire.

    • table : sélectionnez toutes les tables ou entrez le ou les noms de table. Si vous sélectionnez ce dernier, spécifiez des tables à l’aide d’une liste séparée par des virgules d’identificateurs de table complets (databaseName.tableName) ou d’expressions régulières valides. Par exemple:

      • Permet databaseName.test.* de sélectionner toutes les tables dont les noms commencent par databaseName.test.
      • Permet databaseName\.(test1|test2) de sélectionner databaseName.test1 et databaseName.test2.

      Vous pouvez combiner les deux formats à l’aide de virgules. La limite de caractères totale de l’entrée entière est de 102 400 caractères.

    • ID de serveur : saisissez une valeur unique pour chaque serveur et client de réplication dans le cluster MySQL. La valeur par défaut est 1000.

    Remarque

    Définissez un ID de serveur différent pour chaque lecteur. Chaque client de base de données MySQL pour la lecture du binlog doit avoir un ID unique, appelé ID de serveur. MySQL Server utilise cet ID pour maintenir la connexion réseau et la position du binlog. Différents travaux partageant le même ID de serveur peuvent entraîner la lecture à partir de la position de binlog incorrecte. Par conséquent, il est recommandé de définir un ID de serveur différent pour chaque lecteur.

  4. Vous pouvez étendre les paramètres avancés pour accéder à d'autres options de configuration pour la source CDC de base de données MySQL :

    • Mode de verrouillage d’instantané : les options sont les suivantes :
      • Minimal (default): contient un verrou de lecture global uniquement pendant la phase initiale pour capturer le schéma et les métadonnées. Le reste de l’instantané utilise une transaction REPEATABLE READ, ce qui autorise les mises à jour pendant la lecture des données.
      • Extended: conserve un verrou de lecture global pour toute la durée de l’instantané, bloquant toutes les écritures. Utiliser pour obtenir une cohérence complète si le blocage de l'écriture est accepté.
      • None: ignore l’acquisition de verrous de table pendant l’instantané. Sécurisé uniquement si aucune modification de schéma ne se produit pendant le processus.
    • Mode de gestion décimal : spécifie la façon dont le connecteur gère les valeurs des colonnes DECIMAL et NUMERIC.
      • Precise: représente des valeurs utilisant des types décimaux exacts (par exemple, Java BigDecimal) pour garantir une précision et une précision complètes dans la représentation des données.
      • Double: convertit les valeurs en nombres à virgule flottante de double précision. Cela améliore la facilité d’utilisation et les performances, mais peut entraîner une perte de précision.
      • String: encode les valeurs sous forme de chaînes mises en forme. Cela facilite leur consommation dans les systèmes en aval, mais perd des informations sémantiques sur le type numérique d’origine.
    • Mode instantané : spécifiez les critères d’exécution d’un instantané au démarrage du connecteur :
      • Initial: le connecteur exécute un instantané uniquement lorsqu’aucun décalage n’a été enregistré pour le nom du serveur logique, ou s’il détecte qu’un instantané antérieur n’a pas pu être terminé. Une fois l’instantané terminé, le connecteur commence à diffuser en continu les enregistrements d’événements pour les modifications de base de données suivantes.
      • InitialOnly: le connecteur exécute un instantané uniquement quand aucun décalage n’a été enregistré pour le nom du serveur logique. Une fois que l’instantané est terminé, le connecteur s’arrête. Il ne passe pas en mode streaming pour lire les événements de modification du binlog.
      • NoData: le connecteur exécute un instantané qui capture uniquement le schéma, mais pas les données de table. Définissez cette option si vous n'avez pas besoin d'un instantané cohérent des données, mais que vous avez uniquement besoin des modifications depuis le démarrage du connecteur.

    Vous pouvez également modifier le nom de la source en sélectionnant le bouton Crayon pour le nom de la source dans la section Détails du flux à droite.

    Capture d’écran de la sélection de tables, d’ID de serveur et de port pour la connexion de la dB d’Azure MySQL (CDC).

  5. Dans la page Vérifier + se connecter, après avoir examiné le résumé de la source CDC MySQL DB, sélectionnez Ajouter pour terminer la configuration.

    Capture d’écran montrant la page Vérifier + se connecter avec le bouton Ajouter sélectionné.

Afficher l’Eventstream mis à jour

  1. Vous consultez la source de base de données MySQL (CDC) qui a été ajoutée à votre Eventstream en mode Édition.

    Capture d’écran de la source de la CDC de la dB d’Azure MySQL ajoutée en mode Édition avec le bouton Publier mis en surbrillance.

  2. Sélectionnez Publier pour publier les modifications et commencer la diffusion en continu des données MySQL DB CDC dans le flux d'événements.

    Capture d’écran de la source CDC Azure MySQL DB ajoutée en mode live.

Autres connecteurs :