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
  • 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 zum 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.

GTID-basierte Replikation (Globale Transaktions-ID)

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:

  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. Stoppen Sie den Anwendungs-Traffic 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
  8. 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:

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 für Ihre MySQL-Quelle in der Produktion Replikate oder eine andere Hochverfügbarkeitskonfiguration verwendet wird, verwenden Sie die GTID-basierte Replikation.

Die auf Binlog-Dateien und Positionen basierende Replikation kann bei einem Datenbank-Failover unterbrochen werden, 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 in der neuen primären Datenbank protokolliert wurde. Die Binlog-Datei 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.

Größe des Lesereplikats richtig anpassen

Wenn Sie Datastream für die Replikation von einem Lesereplikat konfigurieren, kann es zu einer doppelten Verzögerung kommen, die sich aus der MySQL-Replikationsverzögerung (von primär zu Replikat) und der Datastream-Replikationsverzögerung (von Replikat zu Ziel) zusammensetzt. 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 hoher Schreiblast 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 CDC-Methode für Binärlogs erhöhen

Wenn Sie die auf Binlog basierende Replikation verwenden und eine hohe Latenz auftritt, weil durch große Quellschreibvolumen Binlog-Dateien schneller generiert werden, als eine einzelne Aufgabe verarbeiten kann, erhöhen Sie den Durchsatz, 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 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, können Sie 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 gleichzeitige Wiedergabe von Streams.

Größe des Parameters max_allowed_packet 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 Tabellen, die einen Primärschlüssel haben, der als INVISIBLE definiert ist, kann kein Backfill durchgeführt werden.
  • Für eine Tabelle mit mehr als 500 Millionen Zeilen kann kein Backfill durchgeführt werden, es sei denn, die folgenden Bedingungen sind erfüllt:
    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 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 anordnen
    • 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 Datastreams für Spalten mit den Datentypen DATETIME, DATE oder TIMESTAMP nicht unterstützt. Der Wert „0“ wird durch den Wert NULL ersetzt.
  • Im Datastream werden keine Zeilen repliziert, die in JSON-Spalten die folgenden Werte enthalten: 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 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.
  • 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 Probleme mit Zeitüberschreitungen während des Backfills zu vermeiden.
  • Cloud SQL Enterprise Plus-Instanzen müssen die GTID-basierte Replikation verwenden, da sie der Wartung mit praktisch keinen Ausfallzeiten unterliegen. Die auf Binärprotokollen basierende Replikation wird bei Failovern unterbrochen. Daher empfehlen wir für Hochverfügbarkeitsanwendungsfälle die Verwendung der GTID-basierten Replikation.
  • 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.

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.

Nächste Schritte