La replica in entrata nel servizio HeatWave non supporta alcune configurazioni possibili per la replica MySQL.

• È supportata solo la replica basata su righe. Questo formato di log binario è quello predefinito in MySQL versione 5.7 e successive. Replica basata su istruzioni e replica mista non supportate.
  Nota
  
  MySQL 5.7 ha un bug noto in cui l'istruzione DROP TEMPORARY TABLE viene erroneamente registrata nel log binario basato su righe e la replica basata su righe non riesce. MySQL 5.7 è disponibile nella sezione Sustaining Support da ottobre 2023 e non verranno fornite ulteriori correzioni di bug in base alla Oracle Lifetime Support Policy.
• È supportata solo la replica asincrona. Replica semi-sincrona non supportata.
• È supportata solo la replica da una singola origine. Replica multi-origine non supportata.
• Le modifiche allo schema mysql non vengono replicate e causano l'arresto della replica.
• Quando viene eseguito l'upgrade di un sistema DB High Availability, il canale di replica in entrata viene sospeso. Il canale viene ripreso al termine del processo di aggiornamento.
• È possibile replicare solo le istruzioni per le quali il nome utente dell'applier dispone del privilegio per l'esecuzione. La replica non riesce se il nome utente dell'applier non dispone di privilegi sufficienti per eseguire alcuna istruzione letta dai log binari del server di origine. La lista di privilegi è limitata ai privilegi concessi all'amministratore del sistema DB. Vedere Privilegi MySQL predefiniti.
• Prima di MySQL 8.2, il nome utente nella clausola DEFINER delle istruzioni CREATE VIEW, CREATE PROCEDURE e CREATE FUNCTION deve essere uguale al nome utente dell'applier per replicare correttamente queste istruzioni. In MySQL 8.2 o versioni successive, l'utente applier deve disporre del privilegio SET_ANY_DEFINER per replicare le istruzioni CREATE VIEW, CREATE PROCEDURE e CREATE FUNCTION con clausola DEFINER contenente un altro nome utente.
• I sistemi DB (MySQL 8.3.0 o versioni successive) creati prima di maggio 2024 che non dispongono del privilegio TRANSACTION_GTID_TAG devono essere aggiornati per replicare le transazioni con tag GTID.
• Quando le istruzioni ALTER TABLE <table_name> SECONDARY_LOAD e ALTER TABLE <table_name> SECONDARY_UNLOAD vengono replicate in un sistema DB di destinazione, queste istruzioni non caricano né scaricano i dati nel cluster HeatWave collegato al sistema DB di destinazione, se presente.
  Nota
  
  Nelle versioni precedenti a 8.4.0-u2, anche se il caricamento dati viene saltato, il canale di replica può interrompersi se HeatWave Lakehouse è abilitato nel sistema DB di destinazione e non dispone dell'accesso in lettura ed elenco ai file specificati nell'attributo motore della tabella esterna Lakehouse.
• Nelle versioni precedenti a 8.4.0-u2, se il sistema DB di destinazione dispone di un cluster HeatWave arrestato (inattivo), il canale di replica non può applicare alcuna istruzione DDL che crei o modifichi una tabella esterna Lakehouse. Il canale di replica si interromperà.
• Se si desidera replicare le tabelle esterne di Lakehouse, si consiglia di non impostare il canale su GENERATE_IMPLICIT_PRIMARY_KEY per le tabelle senza chiave primaria. La replica si interrompe quando si modifica una tabella InnoDB con una chiave primaria generata in una tabella Lakehouse.