Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Dieser Abschnitt enthält Informationen über:
Das Verhalten von Datastream zur Verarbeitung von Daten, die aus einer MySQL-Quelldatenbank abgerufen werden
Die von Datastream unterstützten Versionen der MySQL-Datenbank
Bekannte Einschränkungen bei Verwendung der MySQL-Datenbank als Quelle
Eine Übersicht über das Einrichten einer MySQL-Quelldatenbank, damit Daten daraus an ein Ziel gestreamt werden können
Verhalten
In diesem Abschnitt wird das Verhalten von MySQL-Quellen beschrieben, wenn Sie Daten mit Datastream replizieren. Wenn Sie Daten aus MySQL-Datenbanken aufnehmen, können Sie die binlog-basierte Replikation oder die auf globalen Transaktions-IDs (GTIDs) basierende Replikation verwenden. Sie wählen die CDC-Methode aus, wenn Sie einen Stream erstellen.
Binlog-basierte Replikation
Datastream kann Binärlogdateien verwenden, um Datenänderungen in MySQL-Datenbanken aufzuzeichnen. Die Informationen in diesen Protokolldateien werden dann in das Ziel repliziert, um die an der Quelle vorgenommenen Änderungen zu reproduzieren.
Die wichtigsten Merkmale der binlog-basierten Replikation in Datastream sind:
Es können alle oder nur bestimmte Datenbanken aus einer bestimmten MySQL-Quelle sowie alle Tabellen oder bestimmte Tabellen aus den Datenbanken ausgewählt werden.
Alle Verlaufsdaten werden repliziert.
Alle DML-Änderungen (Data Manipulation Language, Datenbearbeitungssprache) wie Einfügungen, Aktualisierungen und Löschungen aus den angegebenen Datenbanken und Tabellen werden repliziert.
Es werden nur Änderungen repliziert, für die ein Commit durchgeführt wurde.
Datastream unterstützt auch die auf globalen Transaktions-IDs (GTIDs) basierende Replikation.
Eine globale Transaktions-ID (GTID) ist eine eindeutige Kennung, die für jede Transaktion erstellt und ihr zugewiesen wird, für die auf einer MySQL-Quelle ein Commit durchgeführt wurde. Diese Kennung ist nicht nur für die Quelle, aus der sie stammt, sondern auch für alle Server in einer bestimmten Replikationstopologie eindeutig. Bei der binären Log-basierten Replikation hingegen verwaltet jeder Knoten im Datenbankcluster seine eigenen Binlog-Dateien mit eigener Nummerierung. Die Verwaltung separater Binlog-Dateien und die Nummerierung können bei einem Fehler oder einer geplanten Ausfallzeit zu Problemen führen, da die Binlog-Kontinuität unterbrochen wird und die Binlog-basierte Replikation fehlschlägt.
Die GTID-basierte Replikation unterstützt Failover und selbstverwaltete Datenbankcluster und funktioniert unabhängig von Änderungen im Datenbankcluster.
Die wichtigsten Merkmale der GTID-basierten Replikation in Datastream sind:
Es können alle oder nur bestimmte Datenbanken aus einer bestimmten MySQL-Quelle sowie alle Tabellen oder bestimmte Tabellen aus den Datenbanken ausgewählt werden.
Alle Verlaufsdaten werden repliziert.
Alle DML-Änderungen (Data Manipulation Language, Datenbearbeitungssprache) wie Einfügungen, Aktualisierungen und Löschungen aus den angegebenen Datenbanken und Tabellen werden repliziert.
Es werden nur Änderungen repliziert, für die ein Commit durchgeführt wurde.
Nahtlose Unterstützung für Failover.
Von binlogbasierter zu GTID-basierter Replikation wechseln
Wenn Sie Ihren Stream aktualisieren und von der binlog-basierten zur GTID-basierten Replikation wechseln möchten, ohne einen Backfill durchführen zu müssen, gehen Sie so vor:
Prüfen Sie, ob alle Anforderungen für die GTID-basierte Replikation erfüllt sind. Weitere Informationen finden Sie unter MySQL-Quelldatenbank konfigurieren.
Optional können Sie einen Teststream auf GTID-Basis erstellen und ausführen. Weitere Informationen finden Sie unter Stream erstellen.
GTID-basierten Stream erstellen Starten Sie es noch nicht.
Stoppen Sie den Anwendungs-Traffic zur Quelldatenbank.
Pausieren Sie den vorhandenen Binlog-basierten Stream. Weitere Informationen finden Sie unter Stream pausieren.
Warten Sie einige Minuten, bis Datastream die Datenbank synchronisiert hat. Sie können dies anhand der Messwerte auf dem Tab Monitoring auf der Seite Streamdetails für Ihren Stream prüfen. Die Werte für Datenaktualität und Durchsatz müssen 0 sein.
Starten Sie den GTID-basierten Stream. Weitere Informationen finden Sie unter Stream starten.
Setzen Sie den Traffic zur Quelldatenbank fort.
Wenn das kein Problem ist, können Sie Ihre Tabellen in BigQuery kürzen, den alten Stream löschen und einen neuen mit Backfill starten. Weitere Informationen zum Verwalten von Backfill finden Sie unter Backfill für die Objekte eines Streams verwalten.
Versionen
Datastream unterstützt die folgenden Versionen von MySQL-Datenbanken:
MySQL 5.6
MySQL 5.7
MySQL 8.0
MySQL 8.4 (wird nur für die GTID-basierte Replikation unterstützt)
Datastream unterstützt die folgenden Typen von MySQL-Datenbanken:
Datastream ruft das aktuelle Schema regelmäßig von der Quelle ab, während Ereignisse verarbeitet werden. Wenn sich ein Schema ändert, erkennt Datastream die Schemaänderung und löst einen Schemaabruf aus. Einige Ereignisse werden jedoch möglicherweise falsch verarbeitet oder gehen zwischen den Schemaabrufen verloren, was zu Datenabweichungen führen kann.
Nicht alle Änderungen am Quellschema können automatisch erkannt werden. Dies kann zu Datenbeschädigungen führen. Die folgenden Schemaänderungen können zu Datenbeschädigungen oder Fehlern bei der nachgelagerten Verarbeitung der Ereignisse führen:
Spalten entfernen
Spalten in der Mitte einer Tabelle einfügen
Datentyp einer Spalte ändern
Spalten neu sortieren
Tabellen löschen (relevant, wenn dieselbe Tabelle anschließend mit neuen Daten neu erstellt wird)
Tabellen kürzen
Datastream unterstützt keine Replikation von Ansichten.
Datastream unterstützt keine Spalten mit räumlichen Datentypen. Die Werte in diesen Spalten werden durch NULL-Werte ersetzt.
Der Wert „0“ (0000-00-00 00:00:00) wird in Datastream in Spalten der Datentypen DATETIME, DATE oder TIMESTAMP nicht unterstützt. Der Wert „0“ wird durch den Wert NULL ersetzt.
Datastream unterstützt das Replizieren von Zeilen mit den folgenden Werten in JSON-Spalten nicht: DECIMAL, NEWDECIMAL, TIME, TIME2, DATETIME, DATETIME2, DATE, TIMESTAMP oder TIMESTAMP2. Ereignisse mit solchen Werten werden verworfen.
Datastream unterstützt keine SSL-Zertifikatsketten in den MySQL-Quellverbindungsprofilen. Es werden nur einzelne, x509-PEM-codierte Zertifikate unterstützt.
Datastream unterstützt keine kaskadierenden Löschvorgänge. Solche Ereignisse werden nicht in das Binärlog geschrieben und daher nicht an das Ziel weitergegeben.
Datastream unterstützt keine DROP PARTITION-Vorgänge. Solche Vorgänge sind reine Metadatenvorgänge und werden nicht repliziert. Andere Ereignisse sind nicht betroffen und der Stream wird erfolgreich ausgeführt.
Da Datastream keine Failover zu Replikaten unterstützt, wenn die binäre logbasierte Replikation verwendet wird, empfehlen wir, für Cloud SQL for MySQL Enterprise Plus-Quellen die GTID-basierte Replikation zu verwenden. Cloud SQL Enterprise Plus-Instanzen unterliegen der Wartung ohne Ausfallzeiten und führen während der Wartung ein Failover zu einem Replikat durch.
Zusätzliche Einschränkungen für die GTID-basierte Replikation
Das Wiederherstellen von Streams, die die GTID-basierte Replikation verwenden, ist nur über die Datastream API möglich.
Das Erstellen von Tabellen aus anderen Tabellen mit den CREATE TABLE ... SELECT-Anweisungen wird nicht unterstützt.
Datastream unterstützt keine getaggten GTIDs.
Informationen zu MySQL-Einschränkungen für die GTID-basierte Replikation finden Sie in der MySQL-Dokumentation.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
