Diffuser des données depuis des bases de données MySQL

Datastream vous permet de répliquer les données historiques et les modifications en cours d'une base de données MySQL source vers votre destination pour l'analyse en temps réel et la synchronisation de la base de données.

Avant de configurer une source MySQL, consultez le comportement de réplication, les versions et types de bases de données compatibles, les bonnes pratiques et les limites connues dans Datastream.

Comportement

Cette section décrit le comportement des sources MySQL lorsque vous répliquez des données à l'aide de Datastream. Lorsque vous ingérez des données à partir de bases de données MySQL, vous pouvez utiliser la réplication basée sur le journal binaire ou la réplication basée sur l'identifiant de transaction global (GTID). Vous sélectionnez votre méthode CDC lorsque vous créez un flux.

Réplication basée sur les binlogs

Datastream peut utiliser des fichiers de journal binaire pour conserver un enregistrement des modifications de données dans les bases de données MySQL. Les informations contenues dans ces fichiers journaux sont ensuite répliquées vers la destination pour reproduire les modifications apportées à la source.

Voici les principales caractéristiques de la réplication basée sur le binlog dans Datastream :

  • Vous pouvez sélectionner toutes les bases de données ou des bases de données spécifiques d'une source MySQL donnée, ainsi que toutes les tables des bases de données ou des tables spécifiques.
  • Toutes les données historiques sont répliquées.
  • Toutes les modifications du langage de manipulation de données (LMD), telles que les insertions, les mises à jour et les suppressions des bases de données et des tables spécifiées, sont répliquées.
  • Seules les modifications validées sont répliquées.

Réplication basée sur l'identifiant de transaction global (GTID)

Datastream est également compatible avec la réplication basée sur l'identifiant global (GTID).

L'identifiant de transaction global (GTID) est un identifiant unique créé et associé à chaque transaction validée sur une source MySQL. Cet identifiant est unique non seulement pour la source d'origine, mais aussi pour tous les serveurs d'une topologie de réplication donnée, contrairement à la réplication basée sur les journaux binaires, où chaque nœud du cluster de base de données gère ses propres fichiers binlog, avec sa propre numérotation. La gestion de fichiers binlog et d'une numérotation distincts peut poser problème en cas de défaillance ou d'indisponibilité planifiée, car la continuité du binlog est interrompue et la réplication basée sur le binlog échoue.

La réplication basée sur GTID est compatible avec les basculements et les clusters de bases de données autogérés, et continue de fonctionner quelles que soient les modifications apportées au cluster de bases de données.

Voici les principales caractéristiques de la réplication basée sur GTID dans Datastream :

  • Vous pouvez sélectionner toutes les bases de données ou des bases de données spécifiques d'une source MySQL donnée, ainsi que toutes les tables des bases de données ou des tables spécifiques.
  • Toutes les données historiques sont répliquées.
  • Toutes les modifications du langage de manipulation de données (LMD), telles que les insertions, les mises à jour et les suppressions des bases de données et des tables spécifiées, sont répliquées.
  • Seules les modifications validées sont répliquées.
  • Prise en charge fluide des basculements.

Passer de la réplication basée sur le binlog à la réplication basée sur le GTID

Si vous souhaitez mettre à jour votre flux et passer d'une réplication basée sur binlog à une réplication basée sur GTID sans avoir à effectuer de remplissage, procédez comme suit :

  1. Assurez-vous que toutes les exigences de la réplication basée sur GTID sont respectées. Pour en savoir plus, consultez Configurer une base de données MySQL source.
  2. Vous pouvez également créer et exécuter un flux test basé sur les GTID. Pour en savoir plus, consultez Créer un flux.
  3. Créez un flux basé sur GTID. Ne le démarrez pas tout de suite.
  4. Arrêtez le trafic de l'application vers la base de données source.
  5. Mettez en pause le flux existant basé sur le binlog. Pour en savoir plus, consultez Mettre le flux en pause.
  6. Attendez quelques minutes pour vous assurer que Datastream a rattrapé la base de données. Pour ce faire, utilisez les métriques de l'onglet Surveillance sur la page Détails du flux de votre flux. Les valeurs de Fraîcheur des données et de Débit doivent être 0.
  7. Démarrez le flux basé sur GTID. Pour en savoir plus, consultez Démarrer le flux.
  8. Reprenez le trafic vers la base de données source.

Si l'exécution d'un backfill ne pose pas de problème, vous pouvez tronquer vos tables dans BigQuery, supprimer l'ancien flux et en démarrer un nouveau avec backfill. Pour en savoir plus sur la gestion du backfill, consultez Gérer le backfill pour les objets d'un flux.

Versions

Datastream est compatible avec les versions suivantes de la base de données MySQL :

  • MySQL 5.6
  • MySQL 5.7
  • MySQL 8.0

  • MySQL 8.4 (compatible uniquement avec la réplication basée sur GTID)

Datastream est compatible avec les types de base de données MySQL suivants :

Bonnes pratiques

Cette section décrit les bonnes pratiques recommandées pour configurer votre source MySQL afin de l'utiliser avec Datastream.

Utiliser le GTID pour les configurations à haute disponibilité

Si votre source MySQL de production utilise des instances répliquées ou toute autre configuration de haute disponibilité, utilisez la réplication basée sur GTID.

La réplication basée sur le fichier binlog et la position peut échouer lors d'un basculement de base de données, car lorsque l'instance principale échoue, la nouvelle instance principale possède un historique binlog différent. Dans ce cas, Datastream perd sa position et ne peut pas reprendre.

Le GTID attribue un identifiant unique à chaque transaction dans l'ensemble de votre topologie de réplication (instance principale et instances répliquées). Après un basculement, Datastream peut reprendre à partir du dernier GTID enregistré sur la nouvelle instance principale, sans avoir besoin de connaître le fichier binlog ni la position.

Recommandation : Pour toute source MySQL de production avec une instance répliquée ou une configuration de haute disponibilité, l'utilisation de la méthode CDC GTID est obligatoire pour une réplication des données résiliente et fiable.

Dimensionner correctement votre instance répliquée avec accès en lecture

Si vous configurez Datastream pour répliquer à partir d'une instance dupliquée avec accès en lecture, vous pouvez rencontrer un double décalage, qui est une combinaison du décalage de réplication MySQL (de l'instance principale vers l'instance dupliquée) et du décalage de réplication Datastream (de l'instance dupliquée vers la destination). Les instances dupliquées avec accès en lecture sont souvent provisionnées avec moins de ressources (processeur, RAM, IOPS) que les instances principales pour réduire les coûts, ce qui peut entraîner un retard par rapport à l'instance principale pendant les périodes d'écriture intensive.

Recommandation : Lorsque vous utilisez une instance dupliquée avec accès en lecture comme source pour Datastream, provisionnez-la avec des ressources comparables à l'instance principale, afin que l'instance dupliquée puisse suivre le débit d'écriture de l'instance principale.

Augmenter le débit pour la méthode CDC binlog

Si vous utilisez la réplication basée sur binlog et que vous rencontrez une latence élevée en raison de volumes d'écriture source importants qui génèrent des fichiers binlog plus rapidement qu'une seule tâche ne peut les traiter, augmentez le débit en ajustant le paramètre maxConcurrentCdcTasks. Ce paramètre contrôle le nombre de tâches CDC qu'un flux exécute en parallèle. L'augmentation de la valeur de ce paramètre permet à Datastream de traiter davantage de fichiers binlog simultanément.

Recommandation : Pour déterminer la valeur appropriée pour la fraîcheur des données, surveillez le taux de génération de journaux binaires de votre serveur MySQL pendant les heures pleines. Pour ce faire, vous pouvez observer la fréquence à laquelle les nouveaux fichiers binlog sont créés et alternés dans le répertoire de données MySQL, ou utiliser des outils de surveillance MySQL pour suivre la croissance des journaux binaires. Par exemple, si votre source génère 10 fichiers binlog par minute pendant les heures de pointe, définir maxConcurrentCdcTasks sur une valeur telle que 10-15 permet à Datastream de traiter ces fichiers en parallèle, ce qui évite un backlog.

Vous pouvez augmenter la valeur de maxConcurrentCdcTasks jusqu'à la valeur maximale acceptée de 50, à condition que la charge sur la base de données source reste sous contrôle. Pour en savoir plus, consultez Contrôles de simultanéité des flux.

Dimensionner correctement le paramètre max_allowed_packet

Le paramètre max_allowed_packet par défaut dans MySQL (par exemple, 16 Mo-64 Mo) peut être trop petit. Si une seule ligne contenant des champs de type BLOB, JSON ou TEXT volumineux, ou une seule transaction volumineuse dépasse cette taille, MySQL met fin à la connexion Datastream, ce qui entraîne l'échec du flux avec des erreurs telles que Packet for query is too large ou Got a packet bigger than 'max_allowed_packet' bytes.

Recommandation : Définissez le paramètre max_allowed_packet sur votre serveur MySQL sur sa valeur maximale autorisée de 1 Go. Cela garantit que le serveur peut gérer les lignes ou transactions volumineuses que Datastream doit lire à partir du binlog.

Limitations connues

Les limites connues d'utilisation de la base de données MySQL en tant que source incluent les suivantes :

  • Les flux sont limités à 10 000 tables.
  • Les tables répliquées doivent utiliser le moteur de stockage InnoDB. Les tables utilisant le moteur de stockage MyISAM ne sont pas compatibles et échouent à la validation du flux.
  • Les tables dont la clé primaire est définie sur INVISIBLE ne peuvent pas être remplies.
  • Une table contenant plus de 500 millions de lignes ne peut pas être remplie, sauf si les conditions suivantes sont remplies :
    1. La table possède un index unique.
    2. Aucune des colonnes de l'index ne peut être nullable.
    3. L'index n'est pas décroissant.
    4. Toutes les colonnes de l'index sont incluses dans le flux.
  • Datastream récupère régulièrement le dernier schéma de la source à mesure que les événements sont traités. Si un schéma change, Datastream détecte la modification et déclenche une récupération du schéma. Toutefois, certains événements peuvent être traités de manière incorrecte ou être supprimés entre les récupérations de schéma, ce qui peut entraîner des écarts de données.
  • Certaines modifications apportées au schéma source ne peuvent pas être détectées automatiquement, ce qui peut provoquer une corruption des données. Les modifications de schéma suivantes peuvent entraîner une corruption des données ou l'échec du traitement des événements en aval :
    • Supprimer des colonnes
    • Ajout de colonnes au milieu d'une table
    • Changement du type de données d'une colonne
    • Réorganisation des colonnes
    • Suppression de tables (pertinente si la même table est ensuite recréée avec de nouvelles données ajoutées)
    • Troncation de tables
  • Datastream n'est pas compatible avec la réplication des vues.
  • Datastream n'est pas compatible avec les colonnes de types de données spatiales, par exemple GEOMETRY, POINT, LINESTRING, POLYGON. Les valeurs de ces colonnes sont remplacées par des valeurs NULL.
  • Datastream n'accepte pas la valeur zéro (0000-00-00 00:00:00) dans les colonnes des types de données DATETIME, DATE ou TIMESTAMP. La valeur zéro est remplacée par la valeur NULL.
  • Datastream ne permet pas de répliquer les lignes qui incluent les valeurs suivantes dans les colonnes JSON : DECIMAL, NEWDECIMAL, TIME, TIME2, DATETIME, DATETIME2, DATE, TIMESTAMP ou TIMESTAMP2. Les événements contenant de telles valeurs sont supprimés.
  • Datastream n'est pas compatible avec la compression des transactions du journal binaire.
  • Datastream n'accepte pas les fichiers journaux binaires de plus de 4 Gio. Étant donné que MySQL écrit chaque transaction dans un seul fichier journal binaire, limitez les transactions individuelles à moins de 4 Gio afin que les fichiers journaux binaires ne dépassent pas cette limite.
  • Datastream n'accepte pas les chaînes de certificats SSL dans les profils de connexion MySQL sources. Seuls les certificats uniques encodés au format PEM x509 sont acceptés.
  • Datastream n'accepte pas les opérations en cascade : ON UPDATE CASCADE et ON DELETE CASCADE. Ces événements ne sont pas écrits dans le journal binaire et ne sont donc pas propagés vers la destination. Pour contourner ce problème, vous pouvez remplacer les opérations en cascade par des déclencheurs de base de données.
  • Datastream n'accepte pas les opérations DROP PARTITION. Ces opérations sont des opérations exclusivement de métadonnées et ne sont pas répliquées. Les autres événements ne sont pas affectés et le flux s'exécute correctement.
  • Vous pouvez rencontrer des problèmes de connectivité lors de la réplication de tables FEDERATED. Si cela se produit, supprimez toutes les tables FEDERATED de la configuration de la base de données source et augmentez les valeurs des paramètres connect_timeout, net_read_timeout et max_allowed_packet pour limiter les problèmes de délai avant expiration lors du backfill.
  • Les instances Cloud SQL Enterprise Plus doivent utiliser la réplication basée sur les GTID, car elles sont soumises à une maintenance avec un temps d'arrêt quasi nul. La réplication basée sur les journaux binaires s'interrompt lors des basculements. Nous vous recommandons donc d'utiliser la réplication basée sur les GTID pour les cas d'utilisation de haute disponibilité.
  • Pour MySQL 8.0 et versions ultérieures, la variable binlog_row_value_options doit être définie sur une valeur vide. Il s'agit de la valeur par défaut pour la plupart des versions, mais pour certaines, par exemple les sources MySQL sur Oracle Cloud Infrastructure (OCI), vous devez la définir explicitement. Pour en savoir plus, consultez Configurer une base de données MySQL autogérée.
  • Limites de MariaDB :
    • La réplication basée sur GTID n'est pas compatible avec MariaDB. Vous devez configurer les flux MariaDB pour utiliser la réplication basée sur le binlog.
    • Pour les versions 11.4 à 12.2 de MariaDB, vous devez activer la variable système binlog_legacy_event_pos sur la base de données source pour assurer la compatibilité avec Datastream.
    • Datastream n'est pas compatible avec le type de données UUID (introduit dans MariaDB 10.7). Vous devez exclure les colonnes du type de données UUID de la configuration du flux.

Limites supplémentaires pour la réplication basée sur GTID

  • La récupération des flux qui utilisent la réplication basée sur GTID n'est disponible que lorsque vous utilisez l'API Datastream.
  • La création de tables à partir d'autres tables à l'aide des instructions CREATE TABLE ... SELECT n'est pas possible.
  • Datastream n'est pas compatible avec les GTID tagués.
  • Pour connaître les restrictions MySQL qui s'appliquent à la réplication basée sur les GTID, consultez la documentation MySQL.

Étapes suivantes