Daten aus MySQL-Datenbanken streamen

Dieser Abschnitt enthält Informationen zu:

  • Das Verhalten von Datastream zur Verarbeitung von Daten, die aus einer MySQL-Quelldatenbank abgerufen werden
  • Die von Datastream unterstützten Versionen von MySQL-Datenbanken
  • 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 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 zu erfassen. Die in diesen Logdateien enthaltenen Informationen 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 (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 GTID-basierte Replikation.

Die globale Transaktions-ID (GTID) ist eine eindeutige Kennung, die für jede Transaktion erstellt und ihr zugeordnet wird, für die auf einer MySQL-Quelle ein Commit durchgeführt wurde. Diese Kennung ist nicht nur für die Quelle, auf der sie erstellt wurde, eindeutig, sondern auch für alle Server in einer bestimmten Replikationstopologie. Im Gegensatz dazu werden bei der binlog-basierten Replikation für jeden Knoten im Datenbankcluster eigene binlog-Dateien mit eigener Nummerierung verwaltet. Die Verwaltung separater binlog-Dateien und ‑Nummerierungen kann 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 (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 der binlog-basierten zur GTID-basierten 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. Achten Sie darauf, dass alle Anforderungen für die GTID-basierte Replikation erfüllt sind. Weitere Informationen finden Sie unter MySQL-Quelldatenbank konfigurieren.
  2. Optional: Erstellen und führen Sie einen Teststream mit GTID-basierter Replikation aus. Weitere Informationen finden Sie unter Stream erstellen.
  3. Erstellen Sie einen Stream mit GTID-basierter Replikation. Starten Sie ihn noch nicht.
  4. Beenden Sie den Anwendungsverkehr zur Quelldatenbank.
  5. Pausieren Sie den vorhandenen binlog-basierten Stream. Weitere Informationen finden Sie unter Stream pausieren.
  6. Warten Sie einige Minuten, damit Datastream mit der Datenbank synchronisiert werden kann. Sie können dies auf der Seite Streamdetails für Ihren Stream auf dem Tab Monitoring anhand der Messwerte prüfen. Die Werte für Datenaktualität und Durchsatz müssen 0 sein.
  7. Starten Sie den Stream mit GTID-basierter Replikation. 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 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 (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 Ihre MySQL-Produktionsquelle Replikate oder eine andere Hochverfügbarkeitskonfiguration verwendet, sollten Sie die GTID-basierte Replikation verwenden.

Die binlog-Datei- und positionsbasierte Replikation kann bei einem Datenbank-Failover unterbrochen werden, da die neue primäre Instanz nach dem Ausfall der primären Instanz einen anderen binlog-Verlauf hat. In diesem Fall verliert Datastream seine Position und kann nicht fortgesetzt werden.

GTID weist jeder Transaktion in der gesamten Replikationstopologie (primäre Instanz und Replikate) eine eindeutige ID zu. Nach einem Failover kann Datastream ab der letzten GTID fortgesetzt werden, 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.

Größe des Lesereplikats richtig festlegen

Wenn Sie Datastream so konfigurieren, dass Daten aus einem Lesereplikat repliziert werden, kann es zu einer doppelten Verzögerung kommen. Diese setzt sich aus der MySQL-Replikationsverzögerung (von der primären Instanz zum Replikat) und der Datastream-Replikationsverzögerung (vom Replikat zum Ziel) zusammen. 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 hohen Schreibraten 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 Schreibmengen in der Quelle, die binlog-Dateien schneller generieren, als eine einzelne Aufgabe verarbeiten kann, eine hohe Latenz feststellen, können Sie den Durchsatz erhöhen, indem Sie den Parameter maxConcurrentCdcTasks optimieren. Mit diesem Parameter wird die Anzahl der CDC-Aufgaben gesteuert, 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, beobachten Sie die binlog-Generierungsrate Ihres MySQL-Servers während der Zeiten hoher Nachfrage. Sie können dies tun, indem Sie die Rate beobachten, mit der neue binlog-Dateien im MySQL-Datenverzeichnis erstellt und rotiert werden, oder indem Sie MySQL-Monitoringtools verwenden, um das Wachstum der binären Logs zu verfolgen. Wenn Ihre Quelle beispielsweise während der Spitzenzeiten 10 binlog-Dateien pro Minute generiert, können Sie maxConcurrentCdcTasks auf einen Wert wie 10-15 setzen, damit Datastream diese Dateien parallel verarbeiten kann und ein Rückstand vermieden wird.

Sie können maxConcurrentCdcTasks auf den maximal unterstützten Wert von 50 erhöhen, sofern die Last auf der Quelldatenbank unter Kontrolle bleibt. Weitere Informationen finden Sie unter Steuerung der Stream-Parallelität.

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 BLOB, JSON, oder TEXT Typ Feldern 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:Setzen Sie den Parameter max_allowed_packet auf Ihrem MySQL-Server auf den maximal zulässigen Wert von 1 GB. 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 Speicher-Engine InnoDB 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.
  • 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 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 wie GEOMETRY, POINT, LINESTRING und POLYGON. Die Werte in diesen Spalten werden durch NULL-Werte ersetzt.
  • Datastream unterstützt den Wert 0 (0000-00-00 00:00:00) nicht in Spalten der Datentypen DATETIME, DATE oder TIMESTAMP. Der Wert 0 wird durch den Wert NULL ersetzt.
  • Datastream unterstützt die Replikation von Zeilen nicht, 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 Transaktionskomprimierung für binäre Logs 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 Vorgänge: ON UPDATE CASCADE und ON DELETE CASCADE. Solche Ereignisse werden nicht in das binäre Log geschrieben und daher nicht an das Ziel weitergegeben. Als Problemumgehung 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 Probleme mit Zeitüberschreitungen während des Backfills zu vermeiden.
  • Für Cloud SQL Enterprise Plus-Instanzen muss die GTID-basierte Replikation verwendet werden, da sie einer Wartung mit nahezu null Ausfallzeiten unterliegen. Die binlog-basierte Replikation wird bei Failovern unterbrochen. Daher empfehlen wir die Verwendung der GTID-basierten Replikation für Hochverfügbarkeitsanwendungsfälle.
  • Für 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, 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 so konfigurieren, dass sie die binlog-basierte Replikation verwenden.
    • 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.

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

  • Das Wiederherstellen 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 Anweisungen CREATE TABLE ... SELECT 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