Documentação do Oracle Cloud Infrastructure

Limitações

A replicação de entrada para o MySQL HeatWave Service 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.
  • Um canal pode suportar no máximo 30 filtros de canal.
  • 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.
  • Na replicação assíncrona, os sistemas de banco de dados de origem e de destino podem ser sistemas de banco de dados de Leitura-Gravação e o cluster HeatWave associado pode ser gerenciado de forma independente. No entanto, como há um canal de replicação entre eles, as ações executadas na origem podem afetar a funcionalidade do sistema de banco de dados de destino.
  • 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, elas não carregam nem descarregam dados no cluster HeatWave anexado ao sistema de BD de destino, se houver.

    Isso ajuda a configurar a replicação entre sistemas de banco de dados nos quais a origem tem um cluster HeatWave, mas o destino não tem um cluster HeatWave e também em sistemas de banco de dados de alta disponibilidade nos quais apenas o sistema de banco de dados principal tem um cluster HeatWave. No entanto, quando a instrução ALTER TABLE <table_name> SECONDARY_LOAD é replicada, os metadados de carga secundários são atualizados no dicionário de dados MySQL. Como os metadados de carga secundária são consultados no momento da recuperação, se o sistema de BD de destino for reiniciado, as novas tabelas cujas instruções DDL de carga secundária são replicadas também serão consideradas para recarregamento no cluster HeatWave no sistema de BD de destino.

  • Você pode carregar ou descarregar tabelas independentemente no cluster HeatWave nos sistemas de banco de dados de origem e de destino. Mas, se você carregar uma tabela no cluster HeatWave no sistema de banco de dados de destino primeiro e depois tentar carregar a mesma tabela no cluster HeatWave no sistema de banco de dados de origem, isso poderá fazer com que o canal de replicação seja interrompido, e um erro semelhante ao seguinte será gerado nesses casos: 
    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
    Isso acontece porque a instrução DDL ALTER TABLE <table_name> SECONDARY_ENGINE = RAPID gerada pela carga é replicada, mas falha no sistema de banco de dados de destino porque a tabela correspondente já está carregada no cluster HeatWave e já tem SECONDARY_ENGINE = RAPID definido.
  • Quando o cluster HeatWave é excluído ou recriado no sistema de BD de origem, todas as tabelas carregadas anteriormente são descarregadas do cluster HeatWave no sistema de BD de origem e as mesmas tabelas também são descarregadas do cluster HeatWave no sistema de BD de destino. Isso ocorre porque quando o cluster HeatWave no sistema de banco de dados de origem é excluído ou recriado, a definição SECONDARY_ENGINE para todas as tabelas carregadas anteriormente no sistema de banco de dados de origem é redefinida como NULL. Quando a definição SECONDARY_ENGINE de uma tabela é redefinida no sistema de BD de origem, a definição SECONDARY_ENGINE da mesma tabela também é redefinida como NULL no sistema de BD de destino, o que resulta no descarregamento da tabela do cluster HeatWave no sistema de BD de destino.
  • 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.
  • 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.
  • Em versões anteriores a 8.4.0-u2, mesmo que o carregamento de dados seja ignorado, o canal de replicação poderá interromper se o MySQL HeatWave Lakehouse estiver ativado no sistema de banco de dados de destino e não tiver acesso de leitura e lista aos arquivos especificados no atributo do mecanismo da tabela externa do Lakehouse.