Oracle Cloud Infrastructure-Dokumentation

Einschränkungen

Die eingehende Replikation in MySQL HeatWave Service unterstützt einige der Konfigurationen nicht, die für die MySQL-Replikation möglich sind.

  • Nur zeilenbasierte Replikation wird unterstützt. Dieses Binärlogformat ist das Standardformat in MySQL Version 5.7 und höher. Anweisungsbasierte Replikation und gemischte Replikation werden nicht unterstützt.
    Hinweis

    MySQL 5.7 weist einen bekannten Bug auf, bei dem die DROP TEMPORARY TABLE-Anweisung falsch im zeilenbasierten Binärlog protokolliert wird und die zeilenbasierte Replikation fehlschlägt. MySQL 5.7 ist seit Oktober 2023 im Sustaining Support enthalten, und es werden keine weiteren Bugfixes gemäß der Oracle Lifetime Support Policy bereitgestellt.
  • Es wird nur die asynchrone Replikation unterstützt. Semisynchrone Replikation wird nicht unterstützt.
  • Ein Ziel-DB-System unterstützt bis zu 18 eingehende Replikationskanäle. Das Limit von 18 Kanälen umfasst alle Kanäle im DB-System, unabhängig von ihrem Servicestatus.
  • DB-Systemvorgänge, die sich auf die Replikation auswirken, werden über alle konfigurierten Kanäle im Ziel-DB-System angewendet. Die für diese Vorgänge erforderliche Zeit kann mit zunehmender Anzahl von Kanälen steigen.
  • Ein Kanal kann maximal 30 Kanalfilter unterstützen.
  • Änderungen am Schema mysql werden nicht repliziert und bewirken, dass die Replikation gestoppt wird.
  • Wenn ein High Availability-DB-System upgegradet wird, werden die eingehenden Replikationskanäle unterbrochen. Die Kanäle werden wiederaufgenommen, wenn der Upgradeprozess abgeschlossen ist.
  • Nur Anweisungen, die der Applier-Benutzername ausführen darf, können repliziert werden. Die Replikation ist nicht erfolgreich, wenn der Applier-Benutzername nicht über die erforderlichen Berechtigungen verfügt, um Anweisungen auszuführen, die aus den Binärlogs des Quellservers gelesen wurden. Die Liste der Berechtigungen ist auf die Berechtigungen beschränkt, die dem Administrator des DB-Systems erteilt wurden. Siehe MySQL-Standardberechtigungen.
  • Vor MySQL 8.2 muss der Benutzername in der DEFINER-Klausel der Anweisungen CREATE VIEW, CREATE PROCEDURE und CREATE FUNCTION mit dem Applier-Benutzernamen identisch sein, um diese Anweisungen erfolgreich zu replizieren. In MySQL 8.2 oder höher muss der Applier-Benutzer über die Berechtigung SET_ANY_DEFINER verfügen, um die Anweisungen CREATE VIEW, CREATE PROCEDURE und CREATE FUNCTION mit der Klausel DEFINER zu replizieren, die einen anderen Benutzernamen enthält.
  • DB-Systeme (MySQL 8.3.0 oder höher), die vor Mai 2024 erstellt wurden und nicht die Berechtigung TRANSACTION_GTID_TAG besitzen, müssen upgegradet werden, um Transaktionen mit GTID-Tags zu replizieren.
  • Bei der asynchronen Replikation können sowohl Quell- als auch Ziel-DB-Systeme Read-Write-DB-Systeme sein, und das zugehörige HeatWave-Cluster kann unabhängig verwaltet werden. Da jedoch ein Replikationskanal dazwischen ist, können Aktionen, die an der Quelle ausgeführt werden, die Funktionalität des Ziel-DB-Systems beeinträchtigen.
  • Wenn die Anweisungen ALTER TABLE <table_name> SECONDARY_LOAD und ALTER TABLE <table_name> SECONDARY_UNLOAD in einem Ziel-DB-System repliziert werden, laden oder entladen sie keine Daten im HeatWave-Cluster, das an das Ziel-DB-System angehängt ist, sofern vorhanden.

    Auf diese Weise können Sie die Replikation zwischen DB-Systemen einrichten, bei denen die Quelle über ein HeatWave-Cluster verfügt, das Ziel jedoch kein HeatWave-Cluster aufweist, und auch in High-Availability-DB-Systemen, bei denen nur das primäre DB-System über ein HeatWave-Cluster verfügt. Wenn die ALTER TABLE <table_name> SECONDARY_LOAD-Anweisung jedoch repliziert wird, werden die Metadaten zum sekundären Laden im MySQL-Data Dictionary aktualisiert. Da die sekundären Lademetadaten zum Zeitpunkt des Recoverys abgerufen werden, werden beim Neustart des Ziel-DB-Systems auch die neuen Tabellen berücksichtigt, deren sekundäre Lade-DDL-Anweisungen repliziert werden. Dies gilt auch für das erneute Laden im HeatWave-Cluster im Ziel-DB-System.

  • Sie können Tabellen im HeatWave-Cluster unabhängig voneinander sowohl auf Quell- als auch auf Ziel-DB-Systemen laden oder entladen. Wenn Sie jedoch in MySQL 9.5.1 und älteren Versionen zuerst eine Tabelle im HeatWave-Cluster im Ziel-DB-System laden und dann versuchen, dieselbe Tabelle im HeatWave-Cluster im Quell-DB-System zu laden, kann dies dazu führen, dass der Replikationskanal unterbrochen wird, und in solchen Fällen wird ein Fehler wie der Folgende generiert: 
    Replica SQL for channel 'replication_channel': Worker 1 failed executing transaction 
'<transaction_id>' at source log binary-log.<number>, end_log_pos <number>;
Error 'Secondary engine operation failed. Table already has a secondary engine defined.' on query.
Default database: ''. Query: 'ALTER TABLE <table_name> SECONDARY_ENGINE=RAPID', Error_code: MY-003889
    In MySQL 9.5.1 und älteren Versionen geschieht dies, weil die ALTER TABLE <table_name> SECONDARY_ENGINE = RAPID-DDL-Anweisung, die vom Ladevorgang generiert wird, repliziert wird, aber im Ziel-DB-System nicht erfolgreich ist, weil die entsprechende Tabelle bereits in das HeatWave-Cluster geladen ist und SECONDARY_ENGINE = RAPID bereits festgelegt ist.

    In MySQL 9.5.2 und höher können Sie Tabellen unabhängig voneinander sowohl in Quell- als auch in Ziel-DB-Systemen laden und entladen, ohne dass der Replikationskanal Fehler verursacht oder generiert.

  • Wenn das HeatWave-Cluster im Quell-DB-System gelöscht oder neu erstellt wird, werden alle zuvor geladenen Tabellen aus dem HeatWave-Cluster im Quell-DB-System entladen, und dieselben Tabellen werden auch aus dem HeatWave-Cluster im Ziel-DB-System entladen. Wenn das HeatWave-Cluster im Quell-DB-System gelöscht oder neu erstellt wird, wird die Einstellung SECONDARY_ENGINE für alle zuvor geladenen Tabellen im Quell-DB-System auf NULL zurückgesetzt. Wenn die Einstellung SECONDARY_ENGINE für eine Tabelle im Quell-DB-System zurückgesetzt wird, wird die Einstellung SECONDARY_ENGINE für dieselbe Tabelle auch im Ziel-DB-System auf NULL zurückgesetzt. Dadurch wird die Tabelle aus dem HeatWave-Cluster im Ziel-DB-System entladen.
  • Wenn Sie externe Lakehouse-Tabellen replizieren möchten, wird empfohlen, den Kanal für Tabellen ohne Primärschlüssel nicht auf GENERATE_IMPLICIT_PRIMARY_KEY zu setzen. Die Replikation wird unterbrochen, wenn eine InnoDB-Tabelle mit einem generierten Primärschlüssel in eine Lakehouse-Tabelle geändert wird.
  • Die folgenden Namen dürfen nicht für Replikationskanäle verwendet werden:
    • group_replication_applier
    • group_replication_recovery
    • oci_upgrade_channel
  • Wenn das Ziel-DB-System in Versionen vor 8.4.0-u2 ein gestopptes (inaktives) HeatWave-Cluster aufweist, kann der Replikationskanal keine DDL-Anweisung anwenden, die eine externe Lakehouse-Tabelle erstellt oder ändert. Der Replikationskanal wird unterbrochen.
  • In Versionen vor 8.4.0-u2 kann der Replikationskanal unterbrochen werden, obwohl der Dataload übersprungen wird, wenn MySQL HeatWave Lakehouse im Ziel-DB-System aktiviert ist und er keinen Lese- und Listenzugriff auf die Dateien hat, die im Engine-Attribut der externen Lakehouse-Tabelle angegeben sind.