Die eingehende Replikation in 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.
• Ä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.
• 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 diese Anweisungen keine Daten im Cluster HeatWave, das an das Ziel-DB-System angehängt ist, sofern vorhanden.
  Hinweis
  
  In Versionen vor 8.4.0-u2 kann der Replikationskanal unterbrochen werden, obwohl der Dataload übersprungen wird, wenn 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.
• 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.
• 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.