Organízate con las colecciones
Guarda y clasifica el contenido según tus preferencias.
Esta sección contiene información sobre lo siguiente:
El comportamiento de Datastream al gestionar los datos que se extraen de una base de datos MySQL de origen
Versiones de la base de datos MySQL compatibles con Datastream
Limitaciones conocidas al usar una base de datos MySQL como fuente
Resumen de cómo configurar una base de datos MySQL de origen para que los datos se puedan transmitir desde ella a un destino
Comportamiento
En esta sección se describe el comportamiento de las fuentes de MySQL cuando se replican datos con Datastream. Cuando ingieres datos de bases de datos MySQL, puedes usar la replicación basada en binlog o la replicación basada en el identificador de transacción global (GTID). Selecciona el método de CDC al crear un flujo.
Replicación basada en binlogs
Datastream puede usar archivos de registro binario para mantener un registro de los cambios de datos en las bases de datos MySQL. La información contenida en estos archivos de registro se replica en el destino para reproducir los cambios realizados en el origen.
Estas son las características principales de la replicación basada en binlog en Datastream:
Se pueden seleccionar todas las bases de datos o bases de datos específicas de un origen de MySQL determinado, así como todas las tablas de las bases de datos o tablas específicas.
Todos los datos históricos se replican.
Se replican todos los cambios del lenguaje de manipulación de datos (DML), como las inserciones, las actualizaciones y las eliminaciones de las bases de datos y las tablas especificadas.
Solo se replican los cambios confirmados.
Replicación basada en el identificador de transacción global (GTID)
Datastream también admite la replicación basada en el identificador global (GTID).
El identificador de transacción global (GTID) es un identificador único que se crea y se asocia a cada transacción confirmada en una fuente de MySQL. Este identificador es único no solo para la fuente en la que se originó, sino también para todos los servidores de una topología de replicación determinada, a diferencia de la replicación basada en registros binarios, en la que cada nodo del clúster de bases de datos mantiene sus propios archivos de registro binario, con su propia numeración. Mantener archivos binlog independientes y una numeración
puede suponer un problema en caso de fallo o de inactividad programada, ya que se
interrumpe la continuidad de binlog y se produce un error en la replicación basada en binlog.
La replicación basada en GTID admite conmutaciones por error y clústeres de bases de datos autogestionados, y sigue funcionando independientemente de los cambios que se produzcan en el clúster de bases de datos.
Estas son las características principales de la replicación basada en GTID en Datastream:
Se pueden seleccionar todas las bases de datos o bases de datos específicas de un origen de MySQL determinado, así como todas las tablas de las bases de datos o tablas específicas.
Todos los datos históricos se replican.
Se replican todos los cambios del lenguaje de manipulación de datos (DML), como las inserciones, las actualizaciones y las eliminaciones de las bases de datos y las tablas especificadas.
Solo se replican los cambios confirmados.
Compatibilidad con conmutaciones por error sin interrupciones.
Cambiar de la replicación basada en binlog a la basada en GTID
Si quieres actualizar tu flujo y cambiar de la replicación basada en binlog a la basada en GTID sin tener que hacer un relleno, sigue estos pasos:
Asegúrate de que se cumplen todos los requisitos para la replicación basada en GTID. Para obtener más información, consulta el artículo sobre cómo configurar una base de datos MySQL de origen.
Opcionalmente, crea y ejecuta un flujo de prueba basado en GTID. Para obtener más información, consulta Crear un flujo.
Crea un flujo basado en GTID. No lo inicies todavía.
Detener el tráfico de aplicaciones a la base de datos de origen.
Pausa la réplica basada en binlogs. Para obtener más información, consulta Pausar la emisión.
Espera unos minutos para asegurarte de que Datastream se ha puesto al día con la base de datos. Para comprobarlo, consulta las métricas de la pestaña Monitorización de la página Detalles del flujo. Los valores de Actualización de datos y Rendimiento deben ser 0.
Inicia la réplica basada en GTID. Para obtener más información, consulta Iniciar la emisión.
Reanuda el tráfico a la base de datos de origen.
Si no hay ningún problema en realizar un relleno, puedes truncar tus tablas en BigQuery, eliminar el flujo antiguo e iniciar uno nuevo con relleno. Para obtener más información sobre cómo gestionar el backfill, consulta el artículo Gestionar backfill para objetos de un flujo.
Versiones
Datastream admite las siguientes versiones de la base de datos MySQL:
MySQL 5.6
MySQL 5.7
MySQL 8.0
MySQL 8.4 (solo se admite la replicación basada en GTID)
Datastream admite los siguientes tipos de bases de datos MySQL:
Todas las columnas del índice se incluyen en el flujo.
Datastream obtiene periódicamente el esquema más reciente de la fuente a medida que se procesan los eventos. Si cambia un esquema, Datastream lo detecta y activa una obtención del esquema. Sin embargo, es posible que algunos eventos se procesen de forma incorrecta o se pierdan entre las solicitudes de esquema, lo que puede provocar discrepancias en los datos.
No todos los cambios en el esquema de origen se pueden detectar automáticamente, por lo que puede que los datos se dañen. Los siguientes cambios en el esquema pueden provocar que los datos se dañen o que no se puedan procesar los eventos posteriores:
Eliminar columnas
Añadir columnas en medio de una tabla
Cambiar el tipo de datos de una columna
Reordenar columnas
Eliminar tablas (es relevante si la misma tabla se vuelve a crear con nuevos datos añadidos)
Truncar tablas
Datastream no admite la replicación de vistas.
Datastream no admite columnas de tipos de datos espaciales. Los valores de estas columnas se sustituyen por valores NULL.
Datastream no admite el valor cero (0000-00-00 00:00:00) en las columnas de los tipos de datos DATETIME, DATE o TIMESTAMP. El valor cero se sustituye por el valor NULL.
Datastream no admite la replicación de filas que incluyan los siguientes valores en las columnas JSON: DECIMAL, NEWDECIMAL, TIME, TIME2, DATETIME, DATETIME2, DATE, TIMESTAMP o TIMESTAMP2. Los eventos que contengan estos valores se descartarán.
Datastream no admite cadenas de certificados SSL en los perfiles de conexión de MySQL de origen. Solo se admiten certificados únicos x509 codificados en PEM.
Datastream no admite eliminaciones en cascada. Estos eventos no se escriben en el registro binario y, por lo tanto, no se propagan al destino.
Datastream no admite operaciones DROP PARTITION. Estas operaciones son solo de metadatos y no se replican. Otros eventos no se ven afectados y la emisión se ejecuta correctamente.
Como Datastream no admite conmutaciones por error a réplicas cuando se usa la replicación basada en registros binarios, recomendamos usar la replicación basada en GTID para las fuentes de Cloud SQL para MySQL Enterprise Plus. Las instancias de Cloud SQL Enterprise Plus están sujetas a mantenimiento con un periodo de inactividad casi inexistente y conmutan por error a una réplica durante el mantenimiento.
Limitaciones adicionales de la replicación basada en GTID
La recuperación de las secuencias que usan la replicación basada en GTID solo está disponible cuando se usa la API de Datastream.
No se pueden crear tablas a partir de otras tablas mediante las instrucciones CREATE TABLE ... SELECT.
Datastream no admite GTIDs etiquetados.
Para consultar las restricciones de MySQL que se aplican a la replicación basada en GTID, consulta la documentación de MySQL.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-10 (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."]]