Daten aus MySQL-Datenbanken streamen

Dieser Abschnitt enthält Informationen über:

  • Das Verhalten von Datastream zur Verarbeitung von Daten, die aus einer MySQL-Quelldatenbank abgerufen werden
  • Von Datastream unterstützte MySQL-Datenbankversionen
  • 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 Logdateien werden dann zum 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 (Data Manipulation Language, 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 auf einer globalen Transaktions-ID (GTID) basierende Replikation.

Eine globale Transaktions-ID (GTID) ist eine eindeutige Kennung, die für jede Transaktion erstellt und ihr zugewiesen wird, die für eine MySQL-Quelle übernommen wird. 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 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 (Data Manipulation Language, 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, gehen Sie so vor:

  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 Teststream auf GTID-Basis erstellen und ausführen. Weitere Informationen finden Sie unter Stream erstellen.
  3. GTID-basierten Stream erstellen Starte 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 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.
  7. Starten Sie den GTID-basierten Stream. Weitere Informationen finden Sie unter Stream starten.
  8. Setzen Sie den Traffic zur Quelldatenbank fort.

Wenn ein Backfill kein Problem darstellt, 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:

Best Practices

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

GTID für Hochverfügbarkeitseinrichtungen verwenden

Wenn für Ihre MySQL-Produktionsquelle Replikate oder eine andere Konfiguration mit hoher Verfügbarkeit verwendet werden, verwenden Sie die GTID-basierte Replikation.

Die auf Binlog-Dateien und ‑Positionen basierende Replikation kann bei einem Datenbank-Failover fehlschlagen, da die neue primäre Instanz bei einem Ausfall der primären Instanz einen anderen Binlog-Verlauf hat. In diesem Fall verliert der Datastream seine Position und kann nicht fortgesetzt werden.

Mit GTID wird jeder Transaktion in Ihrer gesamten Replikationstopologie (primär und Replikate) eine eindeutige ID zugewiesen. Nach einem Failover kann Datastream die Replikation mit der letzten GTID fortsetzen, die auf der neuen primären Instanz protokolliert wurde. Die Binärlogdatei oder die Position sind nicht erforderlich.

Empfehlung:Für alle MySQL-Quellen in der Produktion 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 so konfigurieren, dass Daten aus einem Lesereplikat repliziert werden, kann es zu einer doppelten Verzögerung kommen. Diese ist eine Kombination aus der MySQL-Replikationsverzögerung (von primär zu Replikat) und der Datastream-Replikationsverzögerung (von Replikat zu 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 bei vielen Schreibvorgängen hinter der primären Instanz zurückbleiben.

Empfehlung:Wenn Sie ein Lesereplikat als Quelle für Datastream verwenden, stellen Sie ihm Ressourcen zur Verfügung, die mit denen 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 Quellschreibvolumen, die Binlog-Dateien schneller als von einer einzelnen Aufgabe verarbeitet werden können, eine hohe Latenz auftritt, können Sie den Durchsatz erhöhen, indem Sie den Parameter maxConcurrentCdcTasks optimieren. 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 Rate für die Binlog-Generierung Ihres MySQL-Servers während der Zeiten hoher Nachfrage im Blick behalten. 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 in Spitzenzeiten 10 Binlog-Dateien pro Minute generiert, können Datastream mit dem Wert 10-15 für maxConcurrentCdcTasks diese Dateien parallel verarbeiten lassen, um einen Rückstand zu vermeiden.

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

Größe des max_allowed_packet-Parameters richtig festlegen

Die Standardeinstellung für max_allowed_packet in MySQL (z. B. 16 MB bis 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. Der Stream schlägt dann mit Fehlern wie Packet for query is too large oder Got a packet bigger than 'max_allowed_packet' bytes fehl.

Empfehlung:Legen Sie den Parameter max_allowed_packet auf Ihrem MySQL-Server auf den maximal zulässigen Wert von 1 G 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.
  • Für replizierte Tabellen muss die InnoDB-Speicher-Engine verwendet werden. Tabellen, die die Speicher-Engine MyISAM verwenden, werden nicht unterstützt und führen zu einem Fehler bei der Streamvalidierung.
  • 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 Daten aufgefüllt werden, wenn die folgenden Bedingungen erfüllt sind:
    1. Die Tabelle hat einen eindeutigen Index.
    2. Keine der Spalten des Index kann Nullwerte enthalten.
    3. Der Index ist nicht absteigend.
    4. Alle Spalten des Index sind im Stream enthalten.
  • 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 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.
  • In Datastream werden keine Spalten mit räumlichen Datentypen unterstützt, z. B. GEOMETRY, POINT, LINESTRING, POLYGON. Die Werte in diesen Spalten werden durch NULL-Werte ersetzt.
  • Der Wert „0“ (0000-00-00 00:00:00) wird von Datastream in Spalten mit den Datentypen DATETIME, DATE oder TIMESTAMP nicht unterstützt. Der Wert „0“ wird durch den Wert NULL ersetzt.
  • Das Replizieren von Zeilen, die die folgenden Werte in JSON-Spalten enthalten, wird vom Datastream nicht unterstützt: DECIMAL, NEWDECIMAL, TIME, TIME2, DATETIME, DATETIME2, DATE, TIMESTAMP oder TIMESTAMP2. Ereignisse mit solchen Werten werden verworfen.
  • Datastream unterstützt die binlog-Transaktionskomprimierung nicht.
  • Datastream unterstützt keine Binärlog-Dateien, die größer als 4 GiB sind. Da MySQL jede Transaktion in eine einzelne Binärlogdatei schreibt, sollten einzelne Transaktionen unter 4 GiB bleiben, 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 Workaround 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.
  • Beim Replizieren 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.
  • Für Cloud SQL Enterprise Plus-Instanzen muss die GTID-basierte Replikation verwendet werden, da sie der Wartung mit praktisch keinen Ausfallzeiten unterliegen. Die binäre logbasierte Replikation wird bei Failovers unterbrochen. Daher empfehlen wir, für Anwendungsfälle mit Hochverfügbarkeit die GTID-basierte Replikation zu verwenden.
  • Bei MySQL-Versionen 8.0 und höher muss die Variable binlog_row_value_options auf einen leeren Wert gesetzt werden. Dies ist die Standardeinstellung für die meisten Versionen. Bei einigen, 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.
  • MariaDB-Einschränkungen:
    • 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 (eingeführt in MariaDB 10.7) nicht. Sie müssen Spalten des Datentyps UUID aus der Streamkonfiguration ausschließen.

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, die für die GTID-basierte Replikation gelten, finden Sie in der MySQL-Dokumentation.

Nächste Schritte