Base de données MySQL source

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

  • Comportement de Datastream concernant les 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 comme 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 le journal binaire ou la réplication basée sur l'identifiant de transaction global (Preview). 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 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 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 dans les bases de données et les 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).

Un identifiant de transaction globale (GTID) est un identifiant unique créé et associé à chaque transaction effectué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 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 et de numéros binlogs distincts peut poser problème en cas de défaillance ou d'arrêt planifié, car la continuité du binlog est interrompue et la réplication basée sur le binlog échoue.

La réplication basée sur les GTID est compatible avec les basculements, 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 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 dans les bases de données et les tables spécifiées, sont répliquées.
  • Seules les modifications validées sont répliquées.
  • Prise en charge fluide des basculements.

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 :

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 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 nulle.
    3. L'index n'est pas décroissant.
    4. Toutes les colonnes de l'index sont incluses dans le flux.
  • Datastream extrait régulièrement le dernier schéma de la source à mesure que les événements sont traités. Si un schéma change, Datastream le détecte et déclenche une récupération de schéma. Toutefois, certains événements peuvent être traités de manière incorrecte ou supprimés entre les récupérations de schéma, ce qui peut entraîner des divergences 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. Les valeurs de ces colonnes sont remplacées par des valeurs NULL.
  • Datastream n'est pas compatible avec 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 de journaux binaires.
  • Datastream n'est pas compatible avec les chaînes de certificats SSL dans les profils de connexion MySQL source. Seuls les certificats X.509 encodés au format PEM sont acceptés.
  • Datastream n'est pas compatible avec les suppressions en cascade. Ces événements ne sont pas écrits dans le journal binaire et ne sont donc pas propagés vers la destination.
  • Lorsque vous utilisez la réplication basée sur les journaux binaires, Datastream n'est pas compatible avec les basculements vers des réplicas. C'est pourquoi nous vous déconseillons d'utiliser Datastream pour la réplication à partir de sources Cloud SQL pour MySQL Enterprise Plus. Les instances de l'édition Cloud SQL Enterprise Plus sont soumises à une maintenance planifiée avec un temps d'arrêt quasi nul et basculent vers un réplica lors de la maintenance. Cela interrompt la continuité du journal binaire. Par conséquent, les flux concernés échouent définitivement.

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

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

Étape suivante