Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa sezione contiene informazioni su:
Il comportamento di Datastream nella gestione dei dati estratti da un database MySQL di origine
Le versioni del database MySQL supportate da Datastream
Limitazioni note per l'utilizzo del database MySQL come origine
Una panoramica su come configurare un database MySQL di origine in modo che i dati possano essere trasmessi in streaming a una destinazione
Comportamento
Questa sezione descrive il comportamento delle origini MySQL quando replichi i dati
utilizzando Datastream. Quando importi dati dai database MySQL, puoi utilizzare la replica basata su binlog o sull'ID transazione globale (GTID). Selezioni il metodo CDC quando
crei uno stream.
Replica basata su binlog
Datastream può utilizzare i file di log binario per tenere traccia delle modifiche ai dati nei database MySQL. Le informazioni contenute in questi file di log vengono poi replicate nella destinazione per riprodurre le modifiche apportate all'origine.
Le caratteristiche principali della replica basata su binlog in Datastream sono:
Puoi selezionare tutti i database o database specifici di una determinata origine MySQL, nonché tutte le tabelle dei database o tabelle specifiche.
Tutti i dati storici vengono replicati.
Vengono replicate tutte le modifiche data manipulation language (DML), come inserimenti, aggiornamenti ed eliminazioni dai database e dalle tabelle specificati.
Vengono replicate solo le modifiche di cui è stato eseguito il commit.
Replica basata sull'ID transazione globale (GTID)
Datastream supporta anche la replica basata sull'identificatore globale (GTID).
L'ID transazione globale (GTID) è un identificatore univoco creato e
associato a ogni transazione eseguita su un'origine MySQL. Questo identificatore è
univoco non solo per l'origine in cui è stato creato, ma anche per tutti i server
in una determinata topologia di replica, a differenza della replica basata su log binari
in cui ogni nodo del cluster di database gestisce i propri file binlog
con la propria numerazione. La gestione di file binlog e numerazione separati
potrebbe diventare un problema in caso di errore o tempo di inattività pianificato, perché
la continuità del binlog viene interrotta e la replica basata sul binlog non riesce.
La replica basata su GTID supporta i failover, i cluster di database autogestiti e
continua a funzionare indipendentemente dalle modifiche apportate al cluster di database.
Le caratteristiche principali della replica basata su GTID in Datastream sono:
Puoi selezionare tutti i database o database specifici di una determinata origine MySQL, nonché tutte le tabelle dei database o tabelle specifiche.
Tutti i dati storici vengono replicati.
Vengono replicate tutte le modifiche data manipulation language (DML), come inserimenti, aggiornamenti ed eliminazioni dai database e dalle tabelle specificati.
Vengono replicate solo le modifiche di cui è stato eseguito il commit.
Supporto continuo per i failover.
Passare dalla replica basata su binlog a quella basata su GTID
Se vuoi aggiornare il flusso e passare dalla replica basata su binlog a quella basata su GTID
senza dover eseguire un backfill, segui questi passaggi:
(Facoltativo) Crea ed esegui un flusso basato su GTID di test. Per saperne di più,
vedi Creare uno stream.
Crea uno stream basato su GTID. Non avviarlo ancora.
Interrompi il traffico dell'applicazione verso il database di origine.
Metti in pausa lo stream esistente basato su binlog. Per saperne di più, consulta la sezione
Mettere in pausa lo stream.
Attendi qualche minuto per assicurarti che Datastream abbia recuperato
il database. Puoi verificarlo utilizzando le metriche nella scheda Monitoraggio, nella
pagina Dettagli stream del tuo stream. I valori per Aggiornamento dei dati e
Throughput devono essere 0.
Avvia il flusso basato su GTID. Per saperne di più, consulta
Avvia lo stream.
Riprendi il traffico verso il database di origine.
Se l'esecuzione di un backfill non è un problema, puoi troncare le tabelle in
BigQuery, eliminare il vecchio stream e avviarne uno nuovo con il backfill. Per
maggiori informazioni sulla gestione del backfill, vedi
Gestione del backfill per gli oggetti di un flusso.
Versioni
Datastream supporta le seguenti versioni del database MySQL:
MySQL 5.6
MySQL 5.7
MySQL 8.0
MySQL 8.4 (supportato solo per la replica basata su GTID)
Datastream supporta i seguenti tipi di database MySQL:
Tutte le colonne dell'indice sono incluse nel flusso.
Datastream recupera periodicamente lo schema più recente dall'origine durante l'elaborazione degli eventi. Se uno schema cambia, Datastream rileva la modifica e attiva un recupero dello schema. Tuttavia, alcuni eventi potrebbero essere elaborati in modo errato o eliminati tra i recuperi dello schema, il che può causare discrepanze nei dati.
Non tutte le modifiche allo schema di origine possono essere rilevate automaticamente, nel qual caso potrebbe verificarsi un danneggiamento dei dati. Le seguenti modifiche allo schema potrebbero causare il danneggiamento dei dati o l'impossibilità di elaborare gli eventi a valle:
Eliminare colonne
Aggiungere colonne al centro di una tabella
Modifica del tipo di dati di una colonna
Riordinare le colonne
Eliminazione di tabelle (pertinente se la stessa tabella viene poi ricreata con l'aggiunta di nuovi dati)
Troncare le tabelle
Datastream non supporta la replica delle viste.
Datastream non supporta le colonne di tipi di dati spaziali. I valori in queste colonne vengono sostituiti con valori NULL.
Datastream non supporta il valore zero (0000-00-00 00:00:00) nelle colonne dei tipi di dati DATETIME, DATE o TIMESTAMP. Il valore zero viene sostituito con il valore NULL.
Datastream non supporta la replica delle righe che includono i seguenti valori nelle colonne JSON: DECIMAL, NEWDECIMAL, TIME, TIME2DATETIME, DATETIME2, DATE, TIMESTAMP o TIMESTAMP2. Gli eventi contenenti questi valori vengono eliminati.
Datastream non supporta le catene di certificati SSL nei profili di connessione MySQL di origine. Sono supportati solo i certificati singoli con codifica PEM x509.
Datastream non supporta le eliminazioni a cascata. Questi eventi non vengono scritti nel log binario e, di conseguenza, non vengono propagati alla destinazione.
Datastream non supporta le operazioni DROP PARTITION. Queste operazioni sono solo sui metadati e non vengono replicate. Gli altri eventi non sono interessati e lo stream viene eseguito correttamente.
Poiché Datastream non supporta i failover alle repliche quando si utilizza la replica basata su log binario, ti consigliamo di utilizzare la replica basata su GTID per le origini Cloud SQL per MySQL Enterprise Plus. Le istanze Cloud SQL Enterprise Plus sono soggette a manutenzione con tempi di inattività quasi azzerati ed eseguono il failover su una replica durante la manutenzione.
Limitazioni aggiuntive per la replica basata su GTID
Il recupero dei flussi che utilizzano la replica basata su GTID è disponibile solo quando utilizzi l'API Datastream.
La creazione di tabelle da altre tabelle utilizzando le istruzioni CREATE TABLE ... SELECT
non è supportata.
Datastream non supporta i GTID con tag.
Per le limitazioni di MySQL che si applicano alla replica basata su GTID, consulta la documentazione di MySQL.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
