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

Cette section contient des informations sur les éléments suivants :

  • Comportement de Datastream lors du traitement des données extraites d'une base de données MySQL source
  • Versions de la base de données MySQL compatibles avec Datastream
  • Limites connues de l'utilisation de la base de données MySQL en tant que source
  • Présentation de la configuration d'une base de données MySQL source afin que les données puissent être diffusées en streaming vers une destination

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 binlog 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 journaux binaires

Datastream peut utiliser des fichiers de journal binaire pour enregistrer les modifications apportées aux 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 journal binaire dans Datastream :

  • Vous pouvez sélectionner toutes les bases de données ou certaines bases de données d'une source MySQL donnée, ainsi que toutes les tables des bases de données ou de tables spécifiques.
  • Toutes les données historiques sont répliquées.
  • Toutes les modifications apportées au 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 globale (GTID, Global Transaction Identifier) est un identifiant unique créé et associé à chaque transaction validée sur une source MySQL. Cet identifiant est unique non seulement pour la source à partir de laquelle il a été créé, mais aussi pour tous les serveurs d'une topologie de réplication donnée, contrairement à la réplication basée sur le journal binaire où chaque nœud du cluster de base de données conserve ses propres fichiers binlog, avec sa propre numérotation. La maintenance de fichiers binlog distincts et de leur numérotation peut poser problème en cas de défaillance ou de temps d'arrêt planifié, car la continuité des binlogs est interrompue et la réplication basée sur les binlogs échoue.

La réplication basée sur les GTID est compatible avec les basculements et les clusters de bases de données autogérés. Elle 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 certaines bases de données d'une source MySQL donnée, ainsi que toutes les tables des bases de données ou de tables spécifiques.
  • Toutes les données historiques sont répliquées.
  • Toutes les modifications apportées au 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 transparente des basculements.

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

Si vous souhaitez mettre à jour votre flux et passer de la réplication basée sur le journal binaire à la réplication basée sur GTID sans avoir à effectuer de remplissage, procédez comme suit :

  1. Assurez-vous que toutes les exigences concernant 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 de test basé sur les GTID. Pour en savoir plus, consultez Créer un flux.
  3. Créez un flux basé sur un GTID. Ne le lancez pas encore.
  4. Arrêtez le trafic d'application vers la base de données source.
  5. Mettez en veille le flux existant basé sur le journal binaire. Pour en savoir plus, consultez Mettre en veille le flux.
  6. Attendez quelques minutes pour vous assurer que Datastream a rattrapé la base de données. Pour le vérifier, consultez les métriques de l'onglet Surveillance sur la page Détails du flux. Les valeurs de Fraîcheur des données et de Débit doivent être 0.
  7. Démarrez le flux basé sur les GTID. Pour en savoir plus, consultez Démarrer le flux.
  8. Reprenez le trafic vers la base de données source.

Si vous pouvez effectuer un remplissage, vous pouvez tronquer vos tables dans BigQuery, supprimer l'ancien flux et en démarrer un nouveau avec remplissage. Pour en savoir plus sur la gestion du remplissage, consultez Gérer le remplissage 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 GTID pour les configurations à haute disponibilité

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

La réplication basée sur les fichiers binlog et les positions peut être interrompue lors d'un basculement de base de données, car lorsque le nœud principal échoue, le nouveau nœud principal dispose d'un historique binlog différent. Dans ce cas, Datastream perd sa position et ne peut pas reprendre.

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

Recommandation : pour toute source MySQL de production avec une configuration de réplication ou 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 réplica en lecture

Si vous configurez Datastream pour répliquer les données à partir d'une instance répliqué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 la source à l'instance répliquée) et du décalage de réplication Datastream (de l'instance répliquée à la destination). Les instances répliquées avec accès en lecture sont souvent provisionnées avec moins de ressources (CPU, RAM, IOPS) que les instances principales pour réduire les coûts, ce qui peut les amener à être en retard sur l'instance principale pendant les périodes de forte écriture.

Recommandation : lorsque vous utilisez une instance répliquée avec accès en lecture comme source pour Datastream, provisionnez-la avec des ressources comparables à celles de l'instance principale, afin que l'instance répliqué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 le journal binaire et que vous constatez une latence élevée en raison de volumes d'écriture source importants générant des fichiers journaux binaires 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. Augmenter la valeur de ce paramètre permet à Datastream de traiter plus de fichiers journaux binaires 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 de pointe. Pour ce faire, vous pouvez observer la fréquence à laquelle de nouveaux fichiers journaux binaires sont créés et permuté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 périodes 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 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 la 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 avec de grands champs de type BLOB, JSON ou TEXT, 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 toute ligne ou transaction volumineuse que Datastream doit lire à partir du fichier binaire journalisé.

Limites 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 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 comporte un index unique.
    2. Aucune des colonnes de l'index ne peut être nulle.
    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 supprimés entre les extractions 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'accepte pas la réplication des vues.
  • Datastream n'accepte pas les colonnes de types de données spatiales. 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 n'est pas compatible avec la réplication des 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'accepte pas la compression des transactions de journaux binaires.
  • Datastream n'est pas compatible avec les chaînes de certificats SSL dans les profils de connexion MySQL sources. Seuls les certificats uniques encodés au format PEM X.509 sont acceptés.
  • Datastream n'accepte pas les suppressions en cascade. Ces événements ne sont pas écrits dans le journal binaire et, par conséquent, ne sont pas propagés à la destination.
  • Datastream n'accepte pas les opérations DROP PARTITION. Ces opérations sont des opérations de métadonnées uniquement 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é lorsque vous répliquez des tables FEDERATED. Dans ce cas, 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 atténuer les problèmes de délai avant expiration lors du remplissage.
  • 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 est interrompue en cas de basculement. Nous vous recommandons donc d'utiliser la réplication basée sur les GTID pour les cas d'utilisation à haute disponibilité.
  • Pour les versions 8.0 et ultérieures de MySQL, la variable binlog_row_value_options doit être définie sur une valeur vide. Cette valeur est définie 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 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 possible qu'avec l'API Datastream.
  • La création de tables à partir d'autres tables à l'aide des instructions CREATE TABLE ... SELECT n'est pas prise en charge.
  • Datastream n'accepte pas 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.

Étape suivante