Documentación de Oracle Cloud Infrastructure

Limitaciones

La replicación de entrada en MySQL HeatWave Service no soporta 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.
  • Un canal puede soportar un máximo de 30 filtros de canal.
  • 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.
  • En la replicación asíncrona, tanto los sistemas de base de datos de origen como los de destino pueden ser sistemas de base de datos de lectura y escritura, y el cluster HeatWave asociado se puede gestionar de forma independiente. Sin embargo, dado que hay un canal de replicación intermedio, las acciones realizadas en el origen pueden afectar a la funcionalidad del sistema de base de datos de destino.
  • 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, no cargan ni descargan datos en el cluster HeatWave asociado al sistema de base de datos de destino, si los hay.

    Esto ayuda a configurar la replicación entre sistemas de base de datos en los que el origen tiene un cluster HeatWave, pero el destino no tiene un cluster HeatWave, y también en sistemas de base de datos de alta disponibilidad en los que solo el sistema de base de datos principal tiene un cluster HeatWave. Sin embargo, cuando se replica la sentencia ALTER TABLE <table_name> SECONDARY_LOAD, los metadatos de carga secundarios se actualizan en el diccionario de datos MySQL. Puesto que los metadatos de carga secundaria se consultan en el momento de la recuperación, si se reinicia el sistema de base de datos de destino, las nuevas tablas cuyas sentencias DDL de carga secundaria se replican también se tienen en cuenta para volver a cargarlas en el cluster HeatWave del sistema de base de datos de destino.

  • Puede cargar o descargar tablas de forma independiente en el cluster HeatWave tanto en los sistemas de base de datos de origen como de destino. Sin embargo, si carga una tabla en el cluster HeatWave en el sistema de base de datos de destino primero y, a continuación, intenta cargar la misma tabla en el cluster HeatWave en el sistema de base de datos de origen, puede provocar que el canal de replicación se interrumpa y, en estos casos, se genera un error similar al siguiente: 
    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
    Esto sucede porque la sentencia DDL ALTER TABLE <table_name> SECONDARY_ENGINE = RAPID generada por la carga se replica pero falla en el sistema de base de datos de destino porque la tabla correspondiente ya está cargada en el cluster HeatWave y ya tiene SECONDARY_ENGINE = RAPID definido.
  • Cuando se suprime o se vuelve a crear el cluster HeatWave en el sistema de base de datos de origen, todas las tablas cargadas anteriormente se descargan del cluster HeatWave en el sistema de base de datos de origen y las mismas tablas se descargan del cluster HeatWave en el sistema de base de datos de destino también. Esto se debe a que cuando se suprime o se vuelve a crear el cluster HeatWave en el sistema de base de datos de origen, el valor SECONDARY_ENGINE para todas las tablas cargadas anteriormente en el sistema de base de datos de origen se restablece en NULL. Cuando el valor SECONDARY_ENGINE de una tabla se restablece en el sistema de base de datos de origen, el valor SECONDARY_ENGINE de la misma tabla también se restablece en NULL en el sistema de base de datos de destino, lo que provoca que la tabla se descargue del cluster HeatWave en el sistema de base de datos de destino.
  • 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.
  • 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á.
  • En versiones anteriores a 8.4.0-u2, aunque se omite la carga de datos, el canal de replicación se puede interrumpir si MySQL HeatWave Lakehouse está activado en el sistema de base de datos de destino y no tiene acceso de lectura y lista a los archivos especificados en el atributo de motor de la tabla externa de Lakehouse.