Daten aus MySQL-Datenbanken streamen

Mit Datastream können Sie Verlaufsdaten und laufende Änderungen aus einer MySQL-Quelldatenbank in Ihr Ziel replizieren, um Echtzeitanalysen und Datenbanksynchronisierung zu ermöglichen.

Bevor Sie eine MySQL-Quelle konfigurieren, sollten Sie sich das Replikationsverhalten, die unterstützten Versionen und Datenbanktypen, die Best Practices und die bekannten Einschränkungen in Datastream ansehen.

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 GTID-basierte Replikation (Globale Transaktions-ID) verwenden. Sie wählen die CDC-Methode aus, wenn Sie einen Stream erstellen.

Binlog-basierte Replikation

Datastream kann binäre Logdateien verwenden, um Datenänderungen in MySQL-Datenbanken aufzuzeichnen. Die in diesen Logdateien enthaltenen Informationen werden dann am Ziel repliziert, um die an der Quelle vorgenommenen Änderungen zu reproduzieren.

Die wichtigsten Merkmale der Binlog-basierten Replikation in Datastream sind:

  • Sie können alle Datenbanken oder bestimmte Datenbanken aus einer bestimmten MySQL-Quelle sowie alle Tabellen aus den Datenbanken oder bestimmte Tabellen auswählen.
  • Alle Verlaufsdaten werden repliziert.
  • Alle Änderungen der Datenbearbeitungssprache (DML), z. B. 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.

GTID-basierte Replikation (Globale Transaktions-ID)

Datastream unterstützt auch die GTID-basierte Replikation (Global Transaction Identifier).

Die globale Transaktions-ID (GTID) ist eine eindeutige Kennung, die für jede Transaktion erstellt und mit ihr verknüpft wird, die auf einer MySQL-Quelle ausgeführt wird. Diese Kennung ist nicht nur für die Quelle, von der sie stammt, eindeutig, sondern auch für alle Server in einer bestimmten Replikationstopologie. Dies steht im Gegensatz zur binären logbasierten Replikation, bei der jeder Knoten im Datenbankcluster seine eigenen Binlog-Dateien mit eigener Nummerierung verwaltet. Das Verwalten separater Binlog-Dateien und -Nummerierungen kann im Falle eines Fehlers oder einer geplanten Ausfallzeit zu einem Problem werden, 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:

  • Sie können alle Datenbanken oder bestimmte Datenbanken aus einer bestimmten MySQL-Quelle sowie alle Tabellen aus den Datenbanken oder bestimmte Tabellen auswählen.
  • Alle Verlaufsdaten werden repliziert.
  • Alle Änderungen der Datenbearbeitungssprache (DML), z. B. 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 binlog-basierter 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, führen Sie die folgenden Schritte aus:

  1. Prüfen Sie, ob alle Anforderungen für die GTID-basierte Replikation erfüllt sind. Weitere Informationen finden Sie unter MySQL-Quelldatenbank konfigurieren.
  2. Optional können Sie einen GTID-basierten Teststream erstellen und ausführen. Weitere Informationen finden Sie unter Stream erstellen.
  3. Erstellen Sie einen GTID-basierten Stream. Starten Sie sie noch nicht.
  4. Beenden Sie den Anwendungstraffic zur Quelldatenbank.
  5. Pausieren Sie den vorhandenen binlog-basierten Stream. Weitere Informationen finden Sie unter Stream pausieren.
  6. Warten Sie einige Minuten, bis Datastream die Datenbank eingeholt 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.
  7. Starten Sie den GTID-basierten Stream. Weitere Informationen finden Sie unter Stream starten.
  8. Setzen Sie den Traffic zur Quelldatenbank fort.

Wenn das Ausführen eines Backfills kein Problem ist, können Sie Ihre Tabellen in BigQuery kürzen, den alten Stream löschen und einen neuen Stream mit Backfill starten. Weitere Informationen zum Verwalten von Backfills 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 (nur für GTID-basierte Replikation unterstützt)

Datastream unterstützt die folgenden Typen von MySQL-Datenbanken:

Best Practices

In diesem Abschnitt werden empfohlene Best Practices für die Konfiguration Ihrer MySQL-Quelle für die Verwendung mit Datastream beschrieben.

GTID für Hochverfügbarkeitseinrichtungen verwenden

Wenn Ihre MySQL-Produktionsquelle Replikate oder eine andere Hochverfügbarkeitskonfiguration verwendet, verwenden Sie die GTID-basierte Replikation.

Die Binlog-Datei und die positionsbasierte Replikation können während eines Datenbank-Failovers fehlschlagen, da die neue primäre Instanz einen anderen Binlog-Verlauf hat, wenn die primäre Instanz ausfällt. In diesem Fall verliert Datastream seine Position und kann nicht fortgesetzt werden.

Die GTID weist jeder Transaktion in Ihrer gesamten Replikationstopologie (Primärinstanz und Replikate) eine eindeutige ID zu. Nach einem Failover kann Datastream die Replikation ab der letzten GTID fortsetzen, die auf der neuen primären Instanz protokolliert wurde, ohne dass die Binlog-Datei oder die Position bekannt sein muss.

Empfehlung: Für jede MySQL-Produktionsquelle mit einem Replikat oder einer Hochverfügbarkeitskonfiguration ist die Verwendung der GTID-CDC-Methode für eine robuste und zuverlässige Datenreplikation obligatorisch.

Lesereplikat richtig dimensionieren

Wenn Sie Datastream für die Replikation aus einem Lesereplikat konfigurieren, kann es zu einer doppelten Verzögerung kommen. Dies ist eine Kombination aus der MySQL-Replikationsverzögerung (von der primären Instanz zum Replikat) und der Datastream-Replikationsverzögerung (vom Replikat zum Ziel). Lesereplikate werden oft mit weniger Ressourcen (CPU, RAM, IOPS) als primäre Instanzen bereitgestellt, um Kosten zu sparen. Dies kann dazu führen, dass sie in Zeiten mit vielen Schreibvorgängen hinter der primären Instanz zurückbleiben.

Empfehlung: Wenn Sie ein Lesereplikat als Quelle für Datastream verwenden, stellen Sie es mit Ressourcen bereit, die mit der primären Instanz vergleichbar sind, damit das Replikat mit dem Schreibdurchsatz der primären Instanz mithalten kann.

Durchsatz für die Binlog-CDC-Methode erhöhen

Wenn Sie die binlog-basierte Replikation verwenden und aufgrund großer Schreibvolumen in der Quelle, die binlog-Dateien schneller generieren, als eine einzelne Aufgabe verarbeiten kann, eine hohe Latenz auftritt, können Sie den Durchsatz erhöhen, indem Sie den Parameter maxConcurrentCdcTasks anpassen. Dieser Parameter steuert die Anzahl der CDC-Aufgaben, die ein Stream parallel ausführt. Wenn Sie den Wert für diesen Parameter erhöhen, kann Datastream mehr Binlog-Dateien gleichzeitig verarbeiten.

Empfehlung: Um den geeigneten Wert für die Datenaktualität zu ermitteln, sollten Sie die Binlog-Generierungsrate Ihres MySQL-Servers während der Spitzenzeiten beobachten. Dazu können Sie die Rate beobachten, mit der neue Binlog-Dateien im MySQL-Datenverzeichnis erstellt und rotiert werden, oder MySQL-Monitoring-Tools verwenden, um das Wachstum von Binärlogs zu verfolgen. Wenn Ihre Quelle beispielsweise zu Spitzenzeiten 10 Binlog-Dateien pro Minute generiert, kann Datastream diese Dateien parallel verarbeiten, wenn Sie maxConcurrentCdcTasks auf einen Wert wie 10-15 festlegen. So wird ein Rückstand verhindert.

Sie können maxConcurrentCdcTasks bis zum maximal unterstützten Wert von 50 erhöhen, sofern die Last auf der Quelldatenbank unter Kontrolle bleibt. Weitere Informationen findest du unter Steuerelemente für die Nebenläufigkeit von Streams.

Parameter max_allowed_packet richtig dimensionieren

Die Standardeinstellung für max_allowed_packet in MySQL (z. B. 16 MB–64 MB) ist möglicherweise zu klein. Wenn eine einzelne Zeile mit großen Feldern vom Typ BLOB, JSON oder TEXT oder eine einzelne große Transaktion diese Größe überschreitet, beendet MySQL die Datastream-Verbindung. Dies führt dazu, dass der Stream mit Fehlern wie Packet for query is too large oder Got a packet bigger than 'max_allowed_packet' bytes fehlschlägt.

Empfehlung: Legen Sie den Parameter max_allowed_packet auf Ihrem MySQL-Server auf den maximal zulässigen Wert von 1 GB fest. So wird sichergestellt, dass der Server alle großen Zeilen oder Transaktionen verarbeiten kann, die Datastream aus dem Binlog lesen muss.

Bekannte Einschränkungen

Bekannte Einschränkungen bei Verwendung der MySQL-Datenbank als Quelle

  • Streams sind auf 10.000 Tabellen beschränkt.
  • Replizierte Tabellen müssen die Speicher-Engine InnoDB verwenden. Tabellen, die die Speicher-Engine MyISAM verwenden, werden nicht unterstützt und bestehen die Streamvalidierung nicht.
  • Für Tabellen, die einen Primärschlüssel haben, der als INVISIBLE definiert ist, kann kein Backfill durchgeführt werden.
  • Eine Tabelle mit mehr als 500 Millionen Zeilen kann nur dann mit Backfill-Daten gefüllt werden, wenn die folgenden Bedingungen erfüllt sind:
    1. Die Tabelle hat einen eindeutigen Index.
    2. Keine der Spalten des Index darf Nullwerte enthalten.
    3. Der Index ist nicht absteigend.
    4. Alle Spalten des Index sind im Stream enthalten.
  • Datastream ruft regelmäßig das neueste Schema aus 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 zwischen den Schemaabrufen verworfen, 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, z. B. GEOMETRY, POINT, LINESTRING, POLYGON. Die Werte in diesen Spalten werden durch NULL-Werte ersetzt.
  • Datastream unterstützt den Nullwert (0000-00-00 00:00:00) in Spalten der Datentypen DATETIME, DATE oder TIMESTAMP nicht. Der Wert „0“ wird durch den Wert NULL ersetzt.
  • Datastream unterstützt nicht die Replikation von Zeilen, die die folgenden Werte in JSON-Spalten enthalten: DECIMAL, NEWDECIMAL, TIME, TIME2, DATETIME, DATETIME2, DATE, TIMESTAMP oder TIMESTAMP2. Ereignisse, die solche Werte enthalten, werden verworfen.
  • Datastream unterstützt die Komprimierung von Binärlog-Transaktionen nicht.
  • Datastream unterstützt keine Binärlogdateien, die größer als 4 GiB sind. Da MySQL jede Transaktion in eine einzelne Binärlogdatei schreibt, sollten einzelne Transaktionen unter 4 GiB liegen, damit Binärlogdateien dieses Limit nicht überschreiten.
  • 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 Vorgänge: ON UPDATE CASCADE und ON DELETE CASCADE. Solche Ereignisse werden nicht in das Binärlog geschrieben und daher nicht an das Ziel weitergegeben. Als Behelfslösung können Sie kaskadierende Vorgänge durch Datenbanktrigger ersetzen.
  • 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.
  • Bei der Replikation von FEDERATED-Tabellen können Verbindungsprobleme auftreten. Entfernen Sie in diesem Fall alle FEDERATED-Tabellen aus der Konfiguration der Quelldatenbank und erhöhen Sie die Werte für die Parameter connect_timeout, net_read_timeout und max_allowed_packet, um Zeitüberschreitungsprobleme während des Backfills zu vermeiden.
  • Cloud SQL Enterprise Plus-Instanzen müssen die GTID-basierte Replikation verwenden, da sie Wartungen mit praktisch keinen Ausfallzeiten unterliegen. Die binäre logbasierte Replikation wird bei Failovern unterbrochen. Daher empfehlen wir die Verwendung der GTID-basierten Replikation für Hochverfügbarkeitsanwendungsfälle.
  • Bei MySQL-Versionen ab 8.0 muss die Variable binlog_row_value_options auf einen leeren Wert gesetzt werden. Dies ist die Standardeinstellung für die meisten Versionen. Bei einigen Versionen, z. B. MySQL-Quellen in Oracle Cloud Infrastructure (OCI), müssen Sie sie jedoch explizit festlegen. Weitere Informationen finden Sie unter Selbstverwaltete MySQL-Datenbank konfigurieren.
  • Einschränkungen für MariaDB:
    • Die GTID-basierte Replikation wird für MariaDB nicht unterstützt. Sie müssen MariaDB-Streams für die Verwendung der binlog-basierten Replikation konfigurieren.
    • Für MariaDB-Versionen 11.4 bis 12.2 müssen Sie die Systemvariable binlog_legacy_event_pos in der Quelldatenbank aktivieren, um die Kompatibilität mit Datastream zu gewährleisten.
    • Datastream unterstützt den Datentyp UUID nicht (eingeführt in MariaDB 10.7). Sie müssen Spalten des Datentyps UUID aus der Streamkonfiguration ausschließen.

Zusätzliche Einschränkungen für die GTID-basierte Replikation

  • Die Wiederherstellung von Streams, die die GTID-basierte Replikation verwenden, ist nur mit der 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, die für die GTID-basierte Replikation gelten, finden Sie in der MySQL-Dokumentation.

Nächste Schritte