Einschränkungen des MySQL-Connectors

Von Bedeutung

Der MySQL-Connector befindet sich in der öffentlichen Vorschau. Wenden Sie sich an Ihr Azure Databricks-Kontoteam, um den Zugriff anzufordern.

Erfahren Sie mehr über Einschränkungen und Überlegungen für den MySQL-Connector.

Allgemeine Einschränkungen des Datenbankkonnektors

Die Einschränkungen in diesem Abschnitt gelten für alle Datenbankkonnektoren in Lakeflow Connect. Lesen Sie weiter, um verbindungsspezifische Einschränkungen zu erfahren.

  • Wenn Sie eine geplante Pipeline ausführen, werden Warnungen nicht sofort ausgelöst. Stattdessen werden sie ausgelöst, wenn das nächste Update ausgeführt wird.
  • Wenn eine Quelltabelle gelöscht wird, wird die Zieltabelle nicht automatisch gelöscht. Sie müssen die Zieltabelle manuell löschen. Dieses Verhalten entspricht nicht dem Verhalten von Lakeflow Spark Declarative Pipelines.
  • Während der Quellwartungszeiträume können Databricks möglicherweise nicht auf Ihre Daten zugreifen.
  • Wenn ein Quelltabellenname mit einem vorhandenen Zieltabellennamen in Konflikt steht, schlägt die Pipelineaktualisierung fehl.
  • Die Unterstützung für Multi-Destination-Pipelines erfolgt ausschließlich über die API.
  • Das Quellsystem geht davon aus, dass die Cursorspalten monoton steigen.
  • Managed Ingestion Pipelines werden für Arbeitsbereiche in Azure GovCloud Regionen nicht unterstützt.

MySQL-Versionen und Variationen

Der Connector unterstützt die folgenden MySQL-Versionen und -Plattformen:

  • Amazon RDS für MySQL: Version 5.7.44 und höher (sowohl eigenständige als auch HA-Bereitstellungen)
  • Amazon Aurora MySQL: Version 5.7.mysql_aurora.2.12.2 und höher (primäre Instanz nur für HA-Setups)
  • Amazon Aurora MySQL Serverless: Unterstützt
  • Azure-Datenbank für MySQL Flexible Server: Version 5.7.44 und höher (sowohl eigenständige als auch HA-Bereitstellungen)
  • Google Cloud SQL für MySQL: Version 5.7.44 und höher, Version 8.0 und höher
  • MySQL auf EC2: Version 5.7.44 und höher

Der Connector unterstützt mariaDB oder andere mySQL-kompatible Datenbanken nicht.

Authentifizierung

  • Der Connector unterstützt die Benutzernamen- und Kennwortauthentifizierung mit den folgenden Authentifizierungs-Plug-Ins:

    • MySQL 5.7.44: Der Replikationsbenutzer muss mit dem sha256_password Authentifizierungs-Plug-In erstellt werden.
    • MySQL 8.0.x und höher: Sowohl sha256_password als auch caching_sha2_password Plugins werden unterstützt.
  • Die Schaltfläche "Verbindung testen" auf der Benutzeroberfläche kann bei Benutzern fehlschlagen, die sha256_password oder caching_sha2_password verwenden, selbst wenn die Anmeldeinformationen korrekt sind. Dies ist ein bekanntes Problem. Sie können die Verbindung weiterhin erstellen und mit der Pipelineeinrichtung fortfahren.

Anforderungen für binäre Protokolle

  • Die binäre Protokollierung muss mit binlog_format=ROW und binlog_row_image=FULLaktiviert sein.
  • Wenn der Binlog gelöscht wird, bevor das Gateway Änderungen verarbeitet, müssen Sie eine vollständige Aktualisierung aller Tabellen in der Pipeline ausführen.
  • Databricks empfiehlt 7 Tage binlog-Aufbewahrung. Das Festlegen eines niedrigeren Werts kann dazu führen, dass Binlogs bereinigt werden, bevor das Aufnahmegateway sie wiedergibt.

Lesen der Replikatunterstützung

  • Unterstützung für Lese-Replikate ist nur für Amazon RDS für MySQL, Azure Database for MySQL und MySQL auf EC2 verfügbar.
  • Der Connector unterstützt die Datenaufnahme von Aurora MySQL-Lesereplikaten nicht. Sie müssen eine Verbindung mit der primären Instanz von Aurora (Writer-Endpunkt) herstellen.
  • Wenn Sie Lesereplikate verwenden, kann sich die Replikationsverzögerung auf die Aktualität der Daten auswirken.

Pipelines

  • Jede Aufnahmepipeline muss genau einem Aufnahmegateway zugeordnet sein. Gateways können nicht über Pipelines hinweg freigegeben werden.
  • Obwohl die Pipeline zum Einbinden von Daten auf Serverless-Compute ausgeführt wird, muss das Gateway zum Einbinden von Daten auf klassischem Compute ausgeführt werden.
  • Das Ingestion-Gateway wird kontinuierlich ausgeführt, um Änderungen zu erfassen, bevor Binlogs abgeschnitten oder gelöscht werden können.

Schemaentwicklung und DDL-Vorgänge

Der Verbinder behandelt automatisch neue und gelöschte Spalten.

  • Wenn eine neue nicht-räumliche Spalte in der Quelle angezeigt wird, integriert Azure Databricks sie automatisch bei der nächsten Ausführung der Pipeline.
  • Spalten mit räumlichen Datentypen werden nicht unterstützt und können nicht importiert werden.
  • Wenn eine Spalte aus der Quelle gelöscht wird, wird sie von Azure Databricks nicht automatisch gelöscht. Stattdessen verwendet der Verbinder eine Tabelleneigenschaft, um die gelöschte Spalte im Ziel auf inactive zu setzen. Wenn später eine weitere Spalte mit einem konfliktierenden Namen mit der inactive Spalte angezeigt wird, schlägt die Pipeline fehl. In diesem Fall können Sie eine vollständige Aktualisierung der Tabelle ausführen oder die inaktive Spalte manuell ablegen.

Dies gilt für neu erstellte und gelöschte Tabellen in einem Schema, wenn Sie das gesamte Schema verarbeiten.

DDL-Vorgangsverarbeitung

Der Connector kann einige DDL-Vorgänge verarbeiten, viele erfordern jedoch eine vollständige Aktualisierung der Tabelle:

  • TRUNCATE TABLE: Sie müssen die Tabelle aktualisieren.
  • UMBENENNEN TABLE: Die umbenannte Tabelle wird im Eingangsgateway übersprungen, und ein Fehler wird im Ereignisprotokoll notiert. Der Datenfluss für diese Tabelle ist in der Datenaufnahme-Pipeline als fehlgeschlagen markiert.
  • DROP TABLE: Die Tabelle wird aus dem Aufnahmegateway entfernt, wobei im Ereignisprotokoll ein Fehler auftritt. Der Datenfluss für diese Tabelle ist in der Datenaufnahme-Pipeline als fehlgeschlagen markiert.
  • ADD PRIMARY KEY oder UNIQUE-Beschränkung: Sie müssen die Tabelle aktualisieren.
  • DROP PRIMARY KEY constraint: Sie müssen die Tabelle aktualisieren.
  • DROP UNIQUE constraint: Wenn dies die einzige eindeutige Einschränkung auf der Quelltabelle ist, müssen Sie die Tabelle aktualisieren. Wenn nicht, ist keine Aktion erforderlich.
  • DROP COLUMN / MODIFY COLUMN / CHANGE COLUMN: Sie müssen die Tabelle aktualisieren.
  • HINZUFÜGEN COLUMN:
    • Wenn die Spalte einen nicht räumlichen Typ aufweist: Es ist keine Aktion erforderlich. Die Spalte wird automatisch beim nächsten Pipeline-Update aufgenommen.
    • Wenn die Spalte einen räumlichen Typ aufweist: Das Hinzufügen der Spalte unterbricht die weitere Verarbeitung dieser Tabelle. Im Ingestion-Gateway wird die Tabelle übersprungen, und es erscheint ein Fehler im Ereignisprotokoll. Der Datenfluss für diese Tabelle ist in der Datenaufnahme-Pipeline als fehlgeschlagen markiert.
  • HINZUFÜGEN TABLE (beim Aufnehmen des gesamten Schemas):
    • Wenn die Tabelle keine räumlichen Typen aufweist: Es ist keine Aktion erforderlich. Die Tabelle wird beim nächsten Pipeline-Update automatisch eingelesen.
    • Wenn die Tabelle räumliche Typen enthält: Die Tabelle wird im Ingestion Gateway übersprungen, wobei im Ereignisprotokoll ein Fehler auftritt. Der Datenfluss für diese Tabelle ist in der Datenaufnahme-Pipeline als fehlgeschlagen markiert.

Wann eine vollständige Aktualisierung durchgeführt werden soll

Führen Sie eine vollständige Aktualisierung einer Tabelle in den folgenden Szenarien aus:

  • Nach einer TRUNCATE TABLE-Operation an der Quelle.
  • Nach einer Änderung des Spaltendatentyps (MODIFY COLUMN).
  • Nach einer Spaltenumbenennung (CHANGE COLUMN).
  • Nach einer DROP COLUMN Operation (zum Entfernen inaktiver Spalten).
  • Wenn räumliche Spalten hinzugefügt werden (bevor Sie sie aus der Auswahl entfernen).

Informationen zum Ausführen einer vollständigen Aktualisierung finden Sie unter "Vollständige Aktualisierung von Zieltabellen".

Staging

Bei dem Staging-Katalog kann es sich nicht um einen externen Katalog handeln.

Tabellen und Datentypen

  • Databricks empfiehlt, maximal 250 Tabellen pro Pipeline zu erfassen. Es gibt jedoch keine Beschränkung für die Anzahl von Zeilen oder Spalten, die in diesen Objekten unterstützt werden.
  • MySQL ist ein Namespace mit zwei Ebenen. Die Namen für source_schema und source_table sind groß-/kleinschreibungssensitiv.
  • Obwohl Sie aus mehreren Quellschemas in einer Pipeline aufnehmen können, können Sie nicht zwei Tabellen mit demselben Namen in dasselbe Zielschema aufnehmen. Sie können z. B. nicht sowohl schema1.customers als auch schema2.customers in dasselbe Zielschema aufnehmen. Sie können sie jedoch mithilfe einer Multi-Destination-Pipeline in verschiedene Zielschemas aufnehmen.
  • Räumliche Datentypen (GEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION) werden nicht unterstützt. Wenn räumliche Spalten in ausgewählten Tabellen vorhanden sind, wird die Tabelle im Ingestion-Gateway mit einem Fehler in der Ereignisprotokolldatei übersprungen.

Zeichensätze und Kollation

Der Connector repliziert derzeit nur UTF-8-kompatible Bytesequenzen. Dies bedeutet, dass die Replikation ordnungsgemäß funktioniert, wenn die in MySQL gespeicherte Bytedarstellung mit UTF-8-Codierung übereinstimmt.

Unterstützte Zeichensätze

Die folgenden MySQL-Zeichensätze werden vollständig oder teilweise unterstützt:

  • Vollständig unterstützt (Bytes stimmen immer mit UTF-8 überein):

    • utf8
    • utf8mb4
    • ascii
  • Teilweise unterstützt (nur ASCII-Bereich):

    • latin1 - Die meisten realen Daten werden als latin1 gespeichert, sind ASCII-kompatibel und funktionieren korrekt. MySQL 5.7.44 verwendet latin1 als Standardzeichensatz.
  • Standardzeichensätze nach Version:

    • MySQL 5.7.44: latin1 (Standard)
    • MySQL 8.0 und höher: utf8mb4 (Standard)

Einschränkungen für Zeichensätze

  • Der Verbinder konvertiert nicht zwischen Zeichensätzen. Es überträgt unformatierte Bytes und erwartet, dass sie gültige UTF-8 darstellen.
  • Nicht-UTF-8 kompatible Zeichen in nicht unterstützten Zeichensätzen können möglicherweise verfälscht oder fehlerhaft am Zielort dargestellt werden.
  • Für Nicht-ASCII-Daten in anderen Zeichensätzen als den oben aufgeführten sollten Sie Ihre Tabellen vor der Aufnahme in utf8mb4 konvertieren.

Bekannte Probleme

  • Die Schaltfläche " Verbindung testen " schlägt für MySQL-Benutzer mit sha256_password oder caching_sha2_password Authentifizierung fehl, auch wenn Anmeldeinformationen gültig sind. Dies ist eine bekannte Einschränkung. Sie können weiterhin Verbindungen und Pipelines erstellen.