La replicación de entrada en el servicio HeatWave no admite algunas de las configuraciones posibles para la replicación de MySQL.

• Solo se admite la replicación basada en filas. Este formato de log binario es el valor por defecto en MySQL versión 5.7 y superior. La replicación basada en sentencias y la replicación mixta no están soportadas.
  Nota
  
  MySQL 5.7 tiene un bug conocido en el que la sentencia DROP TEMPORARY TABLE se ha conectado incorrectamente en el log binario basado en filas y hace que falle la replicación basada en filas. MySQL 5.7 se encuentra en Sustaining Support desde octubre de 2023 y no se ofrecerán más correcciones de fallos según Oracle Lifetime Support Policy.
• Solo se admite la replicación asíncrona. No se admite la replicación semisíncrona.
• Solo se admite la replicación desde un único origen. No está soportada la replicación de varios orígenes.
• Los cambios en el esquema mysql no se replican y hacen que la replicación se pare.
• Cuando se actualiza un sistema de base de datos de alta disponibilidad, el canal de replicación de entrada se suspende. El canal se reanuda cuando se completa el proceso de cambio de versión.
• Solo se pueden replicar las sentencias que el nombre de usuario del aplicador tiene privilegios para ejecutar. La replicación falla si el nombre de usuario del aplicador no tiene suficientes privilegios para ejecutar cualquier sentencia leída de los logs binarios del servidor de origen. La lista de privilegios está restringida a los privilegios otorgados al administrador del sistema de base de datos. Consulte Privilegios por defecto de MySQL.
• Antes de MySQL 8.2, el nombre de usuario de la cláusula DEFINER de las sentencias CREATE VIEW, CREATE PROCEDURE y CREATE FUNCTION debe ser el mismo que el nombre de usuario del aplicador para replicar estas sentencias correctamente. En MySQL 8.2 o superior, el usuario de aplicador debe tener el privilegio SET_ANY_DEFINER para replicar las sentencias CREATE VIEW, CREATE PROCEDURE y CREATE FUNCTION con la cláusula DEFINER que contiene otro nombre de usuario.
• Los sistemas de base de datos (MySQL 8.3.0 o superior) creados antes de mayo de 2024 que no tienen el privilegio TRANSACTION_GTID_TAG deben actualizarse para replicar transacciones con etiquetas GTID.
• Cuando las sentencias ALTER TABLE <table_name> SECONDARY_LOAD y ALTER TABLE <table_name> SECONDARY_UNLOAD se replican en un sistema de base de datos de destino, estas sentencias no cargan ni descargan datos en el cluster HeatWave asociado al sistema de base de datos de destino, si los hay.
  Nota
  
  En las versiones anteriores a 8.4.0-u2, aunque se omite la carga de datos, el canal de replicación se puede interrumpir si HeatWave Lakehouse está activado en el sistema de base de datos de destino y no tiene acceso de lectura ni de lista a los archivos especificados en el atributo de motor de la tabla externa de Lakehouse.
• En las versiones anteriores a 8.4.0-u2, si el sistema de base de datos de destino tiene un cluster HeatWave parado (inactivo), el canal de replicación no puede aplicar ninguna sentencia DDL que cree o modifique una tabla externa de Lakehouse. El canal de replicación se interrumpirá.
• Si desea replicar las tablas externas de Lakehouse, se recomienda no definir el canal en GENERATE_IMPLICIT_PRIMARY_KEY para las tablas sin clave primaria. Se interrumpe la replicación al modificar una tabla InnoDB con una clave primaria generada en una tabla de Lakehouse.