MySQL-Quelldatenbank

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 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 binlogbasierte Replikation oder die auf der globalen Transaktions-ID (GTID) basierende Replikation (Vorabversion) 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 zu erfassen. Die Informationen in diesen Protokolldateien werden dann an das Ziel repliziert, um die an der Quelle vorgenommenen Änderungen zu reproduzieren.

Die wichtigsten Merkmale der binlogbasierten 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 GTID-basierte Replikation (Global Transaction Identifier).

Eine globale Transaktions-ID (GTID) ist eine eindeutige Kennung, die für jede Transaktion erstellt und mit einer MySQL-Quelle verknüpft wird. Diese Kennung ist nicht nur für die Quelle, von der sie stammt, sondern auch für alle Server in einer bestimmten Replikationstopologie eindeutig. Im Gegensatz dazu verwaltet jeder Knoten im Datenbankcluster bei der binärprotokollbasierten Replikation seine eigenen Binärprotokolldateien mit eigener Nummerierung. Die Verwaltung separater Binlog-Dateien und -Nummern kann bei einem Fehler oder einer geplanten Ausfallzeit zu Problemen führen, da die Binlog-Kontinuität unterbrochen wird und die binlogbasierte Replikation fehlschlägt.

Die GTID-basierte Replikation unterstützt Failover, selbstverwaltete Datenbankcluster und funktioniert unabhängig von Änderungen am 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.
  • Unterstützung für Failover

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:

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 Tabellen mit mehr als 500 Millionen Zeilen ist kein Backfill möglich, es sei denn, die folgenden Bedingungen sind erfüllt:
    1. Die Tabelle hat einen eindeutigen Index.
    2. Keine der Spalten des Index darf Nullwerte enthalten.
    3. Die Sortierung ist nicht absteigend.
    4. Alle Spalten des Index sind im Stream enthalten.
  • Datastream ruft bei der Verarbeitung von Ereignissen regelmäßig das aktuelle Schema aus der Quelle ab. 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 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 raumbezogenen Datentypen. Die Werte in diesen Spalten werden durch NULL-Werte ersetzt.
  • In Datastream wird der Nullwert (0000-00-00 00:00:00) in Spalten der Datentypen DATETIME, DATE oder TIMESTAMP nicht unterstützt. Der Nullwert wird durch den Wert NULL ersetzt.
  • Datastream unterstützt nicht das Replizieren von Zeilen, 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 Komprimierung von Binärlog-Transaktionen 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ärprotokoll geschrieben und daher nicht an das Ziel übertragen.
  • Bei der Verwendung der binär-logbasierten Replikation unterstützt Datastream keine Failover zu Replikaten. Aus diesem Grund empfehlen wir nicht, Datastream für die Replikation von Cloud SQL for MySQL Enterprise Plus-Quellen zu verwenden. Bei Instanzen der Cloud SQL Enterprise Plus-Version werden Wartungen ohne Ausfallzeiten durchgeführt und während der Wartung wird ein Failover auf ein Replikat ausgeführt. Dadurch wird die Binlog-Kontinuität unterbrochen und die betroffenen Streams schlagen dauerhaft fehl.

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

  • Die Streamwiederherstellung wird nicht unterstützt, wenn Sie die GTID-basierte Replikation verwenden.
  • Das Erstellen von Tabellen aus anderen Tabellen mithilfe der CREATE TABLE ... SELECT-Anweisungen wird nicht unterstützt.
  • Informationen zu MySQL-Einschränkungen für die GTID-basierte Replikation finden Sie in der MySQL-Dokumentation.

Nächste Schritte