A replicação de entrada para o Serviço HeatWave não suporta algumas das configurações possíveis para a replicação MySQL.

• Só há suporte para a replicação baseada na linha. Esse formato de log de binários é o padrão no MySQL versão 5.7 e posterior. A replicação baseada em instruções e a replicação mista não são suportadas.
  Observação
  
  O MySQL 5.7 tem um bug conhecido no qual a instrução DROP TEMPORARY TABLE está registrada incorretamente no log de binários baseado em linha e causa falha na replicação baseada em linha. O MySQL 5.7 está em Suporte Sustentado desde outubro de 2023 e nenhuma outra correção de bugs será fornecida por Oracle Lifetime Support Policy.
• Somente a replicação assíncrona é suportada. A replicação semissíncrona não é suportada.
• Somente a replicação de uma única origem é suportada. A replicação de várias origens não é suportada.
• As alterações no esquema mysql não são replicadas e fazem com que a replicação seja interrompida.
• Quando um sistema de banco de dados de alta disponibilidade é submetido a upgrade, o canal de replicação de entrada é suspenso. O canal é retomado quando o processo de atualização é concluído.
• Somente as instruções que o nome de usuário do aplicador tem privilégio para executar podem ser replicadas. A replicação falhará se o nome de usuário do applier tiver privilégio insuficiente para executar qualquer instrução lida nos logs binários do servidor de origem. A lista de privilégios é restrita aos privilégios concedidos ao administrador do sistema de banco de dados. Consulte Privilégios Padrão do MySQL.
• Antes da versão MySQL 8.2, o nome de usuário na cláusula DEFINER das instruções CREATE VIEW, CREATE PROCEDURE e CREATE FUNCTION deve ser igual ao nome de usuário do aplicador para replicar essas instruções com sucesso. No MySQL 8.2 ou superior, o usuário do aplicador deve ter o privilégio SET_ANY_DEFINER para replicar instruções CREATE VIEW, CREATE PROCEDURE e CREATE FUNCTION com a cláusula DEFINER contendo outro nome de usuário.
• Os sistemas de banco de dados (MySQL 8.3.0 ou superior) criados antes de maio de 2024 que não têm o privilégio TRANSACTION_GTID_TAG precisam ser atualizados para replicar transações com tags GTID.
• Quando as instruções ALTER TABLE <table_name> SECONDARY_LOAD e ALTER TABLE <table_name> SECONDARY_UNLOAD são replicadas para um sistema de BD de destino, essas instruções não carregam nem descarregam dados no cluster HeatWave anexado ao sistema de BD de destino, se houver.
  Observação
  
  Em versões anteriores a 8.4.0-u2, mesmo que o carregamento de dados seja ignorado, o canal de replicação poderá ser interrompido se o Lakehouse HeatWave estiver ativado no sistema de BD de destino e não tiver acesso de leitura e lista aos arquivos especificados no atributo do mecanismo da tabela externa do Lakehouse.
• Em versões anteriores a 8.4.0-u2, se o sistema de banco de dados de destino tiver um cluster HeatWave interrompido (inativo), o canal de replicação não poderá aplicar nenhuma instrução DDL que crie ou altere uma tabela externa do Lakehouse. O canal de replicação será interrompido.
• Se você quiser replicar tabelas externas do Lakehouse, é recomendável não definir o canal como GENERATE_IMPLICIT_PRIMARY_KEY para tabelas sem chave primária. A replicação é interrompida ao alterar uma tabela InnoDB com uma chave primária gerada para uma tabela do Lakehouse.