Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette section contient des informations sur les éléments suivants :
Comportement de Datastream lors de la gestion 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 le journal binaire
Datastream peut utiliser des fichiers 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 de transaction (GTID).
Un 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 sur 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 :
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.
Créez un flux basé sur un GTID. Ne le lancez pas encore.
Arrêtez le trafic d'application vers la base de données source.
Mettez en veille le flux existant basé sur le journal binaire. Pour en savoir plus, consultez Mettre en veille le flux.
Patientez quelques minutes pour vous assurer que Datastream a rattrapé la base de données. Pour le vérifier, utilisez 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.
Démarrez le flux basé sur GTID. Pour en savoir plus, consultez Démarrer le flux.
Reprenez le trafic vers la base de données source.
Si le remplissage n'est pas un problème, 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 :
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 de type 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'est pas compatible avec les chaînes de certificats SSL dans les profils de connexion MySQL sources. Seuls les certificats X.509 encodés au format PEM 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.
Étant donné que Datastream n'est pas compatible avec les basculements vers des répliques lorsque vous utilisez la réplication basée sur les journaux binaires, nous vous recommandons d'utiliser la réplication basée sur les GTID pour les sources Cloud SQL pour MySQL Enterprise Plus. Les instances Cloud SQL Enterprise Plus sont soumises à une maintenance avec un temps d'arrêt quasiment nul et basculent vers un réplica pendant la maintenance.
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 disponible.
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.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[[["\u003cp\u003eDatastream replicates data from MySQL sources using either binlog-based or GTID-based replication, supporting historical data and DML changes for selected databases and tables.\u003c/p\u003e\n"],["\u003cp\u003eSupported MySQL versions include 5.6, 5.7, 8.0, and 8.4 (GTID-based only), with compatibility for self-hosted, Cloud SQL, Amazon RDS, Amazon Aurora, MariaDB, Alibaba Cloud PolarDB, and Percona Server.\u003c/p\u003e\n"],["\u003cp\u003eLimitations exist, including a 10,000-table limit, restrictions on tables with invisible primary keys or more than 500 million rows, and potential data discrepancies from schema changes.\u003c/p\u003e\n"],["\u003cp\u003eSpecific data types like spatial data and zero values in \u003ccode\u003eDATETIME\u003c/code\u003e, \u003ccode\u003eDATE\u003c/code\u003e, or \u003ccode\u003eTIMESTAMP\u003c/code\u003e columns, and certain JSON values are not supported, and are thus replaced with null or discarded.\u003c/p\u003e\n"],["\u003cp\u003eGTID-based replication, currently in preview, offers failover support, but has additional limitations like only being recoverable through the Datastream API and not supporting \u003ccode\u003eCREATE TABLE ... SELECT\u003c/code\u003e statements.\u003c/p\u003e\n"]]],[],null,["# Source MySQL database\n\nThis section contains information about:\n\n- The behavior of how Datastream handles data that's being pulled from a source MySQL database\n- The versions of MySQL database that Datastream supports\n- Known limitations for using MySQL database as a source\n- An overview of how to setup a source MySQL database so that data can be streamed from it to a destination\n\nBehavior\n--------\n\nThis section describes the behavior of MySQL sources when you replicate data\nusing Datastream. When you ingest data from MySQL databases, you can\nuse binlog-based replication or global transaction identifier (GTID)-based\nreplication. You select your CDC method when you\n[create a stream](/datastream/docs/create-a-stream).\n\n### Binlog-based replication\n\nDatastream can use\n[binary log](https://dev.mysql.com/doc/refman/5.6/en/binary-log.html) files to\nkeep a record of data changes in MySQL databases. The information contained in\nthese log files is then replicated to the destination to reproduce the changes\nmade on the source.\n\nThe key characteristics of binlog-based replication in Datastream are:\n\n- All databases or specific databases from a given MySQL source, as well as all tables from the databases or specific tables, can be selected.\n- All historical data is replicated.\n- All data manipulation language (DML) changes, such as inserts, updates, and deletes from the specified databases and tables, are replicated.\n- Only committed changes are replicated.\n\n### Global transaction identifier (GTID)-based replication\n\nDatastream also supports global identifier (GTID)-based replication.\n\nGlobal transaction identifier (GTID) is a unique identifier created and\nassociated with each transaction committed on a MySQL source. This identifier is\nunique not only to the source on which it originated, but also across all servers\nin a given replication topology, as opposed to the binary log-based\nreplication where each node in the database cluster maintains its own binlog\nfiles, with its own numbering. Maintaining separate binlog files and numbering\nmight become an issue in the event of a failure or planned downtime, because the\nbinlog continuity is broken and the binlog-based replication fails.\n\nGTID-based replication supports failovers, self-managed database clusters, and\ncontinues to work irrespective of changes in the database cluster.\n\nThe key characteristics of GTID-based replication in Datastream are:\n\n- All databases or specific databases from a given MySQL source, as well as all tables from the databases or specific tables, can be selected.\n- All historical data is replicated.\n- All data manipulation language (DML) changes, such as inserts, updates, and deletes from the specified databases and tables, are replicated.\n- Only committed changes are replicated.\n- Seamless support for failovers.\n\n### Switch from binlog-based to GTID-based replication\n\nIf you want to update your stream and switch from binlog-based to GTID-based\nreplication without the need to do a backfill, perform the following steps:\n| **Note:** These steps require database downtime. Similar steps might also be useful when you want to upgrade the major version of your MySQL source.\n\n1. Ensure that all requirements for GTID-based replication are satisfied. For more information, see [Configure a source MySQL database](/datastream/docs/configure-your-source-mysql-database).\n2. Optionally, create and run a *test* GTID-based stream. For more information, see [Create a stream](/datastream/docs/create-a-stream#expandable-2).\n3. Create a GTID-based stream. Don't start it yet.\n4. Stop application traffic to the source database.\n5. Pause the existing binlog-based stream. For more information, see [Pause the stream](/datastream/docs/run-a-stream#pauseastream).\n6. Wait for a few minutes to ensure that Datastream has caught up with the database. You can check this using the metrics in the **Monitoring** tab, on the **Stream details** page for your stream. The values for *Data freshness* and *Throughput* need to be `0`.\n7. Start the GTID-based stream. For more information, see [Start the stream](/datastream/docs/run-a-stream#startstream).\n8. Resume traffic to the source database.\n\nIf performing a backfill isn't an issue, you can truncate your tables in\nBigQuery, delete the old stream, and start a new one with backfill. For\nmore information about managing backfill, see\n[Manage backfill for the objects of a stream](/datastream/docs/manage-backfill-for-the-objects-of-a-stream).\n\nVersions\n--------\n\nDatastream supports the following versions of MySQL database:\n\n- MySQL 5.6\n- MySQL 5.7\n- MySQL 8.0\n- MySQL 8.4 (supported only for GTID-based replication)\n\n | Global transaction identifier (GTID)-based replication is only supported for versions 5.7 and later.\n\nDatastream supports the following types of MySQL database:\n\n- [Self-hosted MySQL](/datastream/docs/configure-self-managed-mysql)\n- [Cloud SQL for MySQL](/datastream/docs/configure-cloudsql-mysql) Cloud SQL for MySQL Enterprise Plus sources are supported when using the GTID-based replication.\n- [Amazon RDS for MySQL](/datastream/docs/configure-amazon-rds-mysql)\n- [Amazon Aurora MySQL](/datastream/docs/configure-amazon-aurora-mysql)\n- [MariaDB](/datastream/docs/configure-self-managed-mysql)\n- [Alibaba Cloud PolarDB](/datastream/docs/configure-self-managed-mysql)\n- [Percona Server for MySQL](/datastream/docs/configure-self-managed-mysql)\n\nKnown limitations\n-----------------\n\nKnown limitations for using MySQL database as a source include:\n\n- Streams are limited to 10,000 tables.\n- Tables that have a primary key defined as `INVISIBLE` can't be backfilled.\n- A table that has more than 500 million rows can't be backfilled unless the following conditions are met:\n 1. The table has a unique index.\n 2. None of the columns of the index are nullable.\n 3. The index isn't [descending](https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html).\n 4. All columns of the index are included in the stream.\n- Datastream periodically fetches the latest schema from the source as events are processed. If a schema changes, Datastream detects the schema change and triggers a schema fetch. However, some events might get processed incorrectly or get dropped between the schema fetches, which can cause data discrepancies.\n- Not all changes to the source schema can be detected automatically, in which case data corruption may occur. The following schema changes may cause data corruption or failure to process the events downstream:\n - Dropping columns\n - Adding columns to the middle of a table\n - Changing the data type of a column\n - Reordering columns\n - Dropping tables (relevant if the same table is then recreated with new data added)\n - Truncating tables\n- Datastream doesn't support replicating views.\n- Datastream doesn't support columns of [spatial data types](https://dev.mysql.com/doc/refman/8.0/en/spatial-type-overview.html). The values in these columns are replaced with `NULL` values.\n- Datastream doesn't support the zero value (`0000-00-00 00:00:00`) in columns of the `DATETIME`, `DATE`, or `TIMESTAMP` data types. The zero value is replaced with the `NULL` value.\n- Datastream doesn't support replicating rows which include the following values in `JSON` columns: `DECIMAL`, `NEWDECIMAL`, `TIME`, `TIME2` `DATETIME`, `DATETIME2`, `DATE`, `TIMESTAMP` or `TIMESTAMP2`. Events containing such values are discarded.\n- Datastream doesn't support [binary log transaction compression](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html).\n- Datastream doesn't support SSL certificate chains in the source MySQL connection profiles. Only single, x509 PEM-encoded certificates are supported.\n- Datastream doesn't support cascading deletes. Such events aren't written to the binary log, and as a result, aren't propagated to the destination.\n- Datastream doesn't support `DROP PARTITION` operations. Such operations are metadata only operations and aren't replicated. Other events aren't affected and the stream runs successfully.\n- Because Datastream doesn't support failovers to replicas when using the binary log-based replication, we recommend using GTID-based replication for Cloud SQL for MySQL Enterprise Plus sources. Cloud SQL Enterprise Plus instances are subject to [near-zero downtime maintenance](/sql/docs/mysql/maintenance#nearzero) and fail over to a replica during maintenance.\n\nAdditional limitations for the GTID-based replication\n-----------------------------------------------------\n\n- Recovering streams that use GTID-based replication is only available when using the Datastream API.\n- Creating tables from other tables using the `CREATE TABLE ... SELECT` statements isn't supported.\n- Datastream doesn't support tagged GTIDs.\n- For MySQL restrictions that apply to GTID-based replication, see [MySQL documentation](https://dev.mysql.com/doc/mysql-replication-excerpt/5.7/en/replication-gtids-restrictions.html).\n\nWhat's next\n-----------\n\n- Learn how to [configure a MySQL source](/datastream/docs/configure-your-source-mysql-database) for use with Datastream."]]
