Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Essa seção contém informações sobre:
O comportamento de como o Datastream lida com dados que estão sendo extraídos de um banco de dados MySQL de origem
As versões do banco de dados MySQL compatível com o Datastream
Limitações conhecidas para o uso do banco de dados MySQL como fonte
Uma visão geral de como configurar um banco de dados MySQL de origem para que os dados possam ser transmitidos dele para um destino
Comportamento
Esta seção descreve o comportamento das origens do MySQL ao replicar dados
usando o Datastream. Ao ingerir dados de bancos de dados MySQL, é possível usar a replicação baseada em binlog ou em identificador global de transação (GTID). Você seleciona o método de CDC ao criar um stream.
Replicação baseada em binlog
O Datastream pode usar arquivos de registro binário para manter um registro das mudanças de dados em bancos de dados MySQL. As informações contidas nesses arquivos de registro são replicadas para o destino para reproduzir as mudanças feitas na origem.
As principais características da replicação baseada em binlog no Datastream são:
É possível selecionar todos os bancos de dados ou bancos de dados específicos de uma determinada origem MySQL, bem como todas as tabelas dos bancos de dados ou tabelas específicas.
Todos os dados históricos são replicados.
Todas as alterações na linguagem de manipulação de dados (DML), como inserções, atualizações e exclusões dos bancos de dados e tabelas especificados, são replicadas.
Apenas alterações confirmadas são replicadas.
Replicação baseada em identificador global de transação (GTID, na sigla em inglês)
O Datastream também é compatível com a replicação baseada em identificador global (GTID).
O identificador global de transação (GTID) é um identificador exclusivo criado e associado a cada transação confirmada em uma origem do MySQL. Esse identificador é exclusivo não apenas para a origem em que foi criado, mas também em todos os servidores em uma determinada topologia de replicação, ao contrário da replicação baseada em registros binários, em que cada nó no cluster de banco de dados mantém seus próprios arquivos binários, com numeração própria. Manter arquivos binlog separados e a numeração
pode se tornar um problema em caso de falha ou inatividade planejada, porque a
continuidade do binlog é interrompida e a replicação baseada em binlog falha.
A replicação baseada em GTID oferece suporte a failovers, clusters de banco de dados autogerenciados e
continua funcionando independentemente das mudanças no cluster de banco de dados.
As principais características da replicação baseada em GTID no Datastream são:
É possível selecionar todos os bancos de dados ou bancos de dados específicos de uma determinada origem MySQL, bem como todas as tabelas dos bancos de dados ou tabelas específicas.
Todos os dados históricos são replicados.
Todas as alterações na linguagem de manipulação de dados (DML), como inserções, atualizações e exclusões dos bancos de dados e tabelas especificados, são replicadas.
Apenas alterações confirmadas são replicadas.
Suporte perfeito para failovers.
Mudar da replicação baseada em binlog para a baseada em GTID
Se você quiser atualizar seu fluxo e mudar da replicação baseada em binlog para a baseada em GTID sem precisar fazer um backfill, siga estas etapas:
Opcionalmente, crie e execute um fluxo de teste baseado em GTID. Para mais informações,
consulte Criar um stream.
Crie um stream baseado em GTID. Não inicie ainda.
Interrompa o tráfego de aplicativos para o banco de dados de origem.
Pause o stream atual com base em binlog. Para mais informações, consulte
Pausar o stream.
Aguarde alguns minutos para garantir que o Datastream tenha alcançado o banco de dados. Para verificar isso, use as métricas na guia Monitoring, na página Detalhes do stream. Os valores de Atualização de dados e Taxa de transferência precisam ser 0.
Inicie o stream baseado em GTID. Para mais informações, consulte
Iniciar a transmissão.
Retome o tráfego para o banco de dados de origem.
Se não houver problema em fazer um backfill, você poderá truncar as tabelas no BigQuery, excluir o fluxo antigo e iniciar um novo com backfill. Para mais informações sobre como gerenciar o preenchimento, consulte Gerenciar o preenchimento dos objetos de um stream.
Versões
O Datastream é compatível com as seguintes versões do banco de dados MySQL:
MySQL 5.6
MySQL 5.7
MySQL 8.0
MySQL 8.4 (compatível apenas com replicação baseada em GTID)
O Datastream é compatível com os seguintes tipos de banco de dados do MySQL:
Todas as colunas do índice são incluídas no fluxo.
O Datastream busca periodicamente o esquema mais recente da origem à medida que os eventos são processados. Se um esquema mudar, o Datastream vai detectar a mudança e acionar uma busca de esquema. No entanto, alguns eventos podem ser processados incorretamente ou descartados entre as buscas de esquema, o que pode causar discrepâncias de dados.
Nem todas as alterações no esquema de origem podem ser detectadas automaticamente. Nesse caso, pode ocorrer corrupção de dados. As seguintes alterações de esquema podem causar corrupção de dados ou falha no processamento de eventos downstream:
Como descartar colunas
Como adicionar colunas no meio de uma tabela
Como alterar o tipo de dados de uma coluna
Como reorganizar as colunas
Como descartar tabelas (relevantes se a mesma tabela for recriada com novos dados adicionados)
Truncando tabelas
O Datastream não é compatível com a replicação de visualizações.
O Datastream não é compatível com colunas de tipos de dados espaciais. Os valores nessas colunas são substituídos por NULL.
O Datastream não é compatível com o valor zero (0000-00-00 00:00:00) nas colunas dos tipos de dados DATETIME, DATE ou TIMESTAMP. O valor zero é substituído pelo valor NULL.
O Datastream não é compatível com a replicação de linhas que incluem os seguintes valores nas colunas JSON: DECIMAL, NEWDECIMAL, TIME, TIME2, DATETIME, DATETIME2, DATE, TIMESTAMP ou TIMESTAMP2. Os eventos que contêm esses valores são descartados.
O Datastream não oferece suporte a cadeias de certificados SSL nos perfis de conexão do MySQL de origem. Somente certificados únicos x509 codificados em PEM são aceitos.
O Datastream não é compatível com exclusões em cascata. Esses eventos não são gravados no registro binário e, portanto, não são propagados para o destino.
O Datastream não é compatível com operações DROP PARTITION. Essas operações são apenas de metadados e não são replicadas. Outros eventos não são afetados, e o stream é executado sem problemas.
Como o Datastream não oferece suporte a failovers para réplicas ao usar a replicação com base em registros binários, recomendamos usar a replicação com base em GTID para fontes do Cloud SQL para MySQL Enterprise Plus. As instâncias do Cloud SQL Enterprise Plus estão sujeitas a manutenção com inatividade quase zero e fazem failover para uma réplica durante a manutenção.
Outras limitações da replicação baseada em GTID
A recuperação de streams que usam a replicação baseada em GTID só está disponível ao usar a API Datastream.
Não é possível criar tabelas usando outras tabelas com as instruções CREATE TABLE ... SELECT.
O Datastream não é compatível com GTIDs marcados.
Para restrições do MySQL que se aplicam à replicação baseada em GTID, consulte a documentação do MySQL.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-12 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."]]