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 nicht erfolgreich verläuft. MySQL 5.7 ist seit Oktober 2023 im Sustaining Support tätig, und laut Oracle Lifetime Support Policy werden keine weiteren Bugfixes bereitgestellt.
  • Es wird nur die asynchrone Replikation unterstützt. Die semisynchrone Replikation wird nicht unterstützt.
  • Es wird nur die Replikation aus einer einzelnen Quelle unterstützt. Die Replikation mit mehreren Quellen wird nicht unterstützt.
  • 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, wird der eingehende Replikationskanal unterbrochen. Der Kanal wird 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 über die Berechtigung TRANSACTION_GTID_TAG verfügen, 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 Cluster HeatWave, 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, sowie 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 Data Dictionary MySQL 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 Cluster HeatWave im Ziel-DB-System.

  • Sie können Tabellen im Cluster HeatWave unabhängig voneinander sowohl in Quell- als auch in Ziel-DB-Systemen laden oder entladen. Wenn Sie jedoch zuerst eine Tabelle im Cluster HeatWave im Ziel-DB-System laden und dann versuchen, dieselbe Tabelle im Cluster HeatWave im Quell-DB-System zu laden, kann dies dazu führen, dass der Replikationskanal unterbrochen wird, und in diesen 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
    Dies liegt daran, dass die vom Ladevorgang generierte ALTER TABLE <table_name> SECONDARY_ENGINE = RAPID-DDL-Anweisung repliziert wird, im Ziel-DB-System jedoch nicht erfolgreich verläuft, weil die entsprechende Tabelle bereits in das Cluster HeatWave geladen wurde und SECONDARY_ENGINE = RAPID bereits festgelegt ist.
  • Wenn das Cluster HeatWave im Quell-DB-System gelöscht oder neu erstellt wird, werden alle zuvor geladenen Tabellen aus dem Cluster HeatWave im Quell-DB-System entladen, und dieselben Tabellen werden auch aus dem Cluster HeatWave im Ziel-DB-System entladen. Wenn das Cluster HeatWave 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 Cluster HeatWave 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.
  • Wenn in Versionen vor 8.4.0-u2 das Ziel-DB-System 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 brechen, 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.