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 replicação do MySQL.

  • Só há suporte para a replicação baseada na linha. Este 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 em que a instrução DROP TEMPORARY TABLE é 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.
  • Um sistema de banco de dados de destino suporta até 18 canais de replicação de entrada. O limite de 18 canais inclui todos os canais no sistema de BD, independentemente do estado do serviço.
  • As operações do sistema de BD que afetam a replicação são aplicadas em todos os canais configurados no sistema de BD de destino, e o tempo necessário para essas operações pode aumentar à medida que o número de canais aumenta.
  • 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, os canais de replicação de entrada são suspensos. Os canais são retomados quando o processo de upgrade é 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 do MySQL 8.2, o nome de usuário na cláusula DEFINER das instruções CREATE VIEW, CREATE PROCEDURE e CREATE FUNCTION deve ser o mesmo que o nome de usuário do aplicador para replicar essas instruções com sucesso. No MySQL 8.2 ou posterior, o usuário aplicador deve ter o privilégio SET_ANY_DEFINER para replicar as 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 mais recente) 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 em um sistema de BD de destino, elas não carregam nem descarregam dados no cluster do 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 somente 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 do MySQL. Como os metadados de carga secundária são consultados no momento da recuperação, se o sistema de banco de dados 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 do HeatWave no sistema de banco de dados de destino.

  • Você pode carregar ou descarregar tabelas de forma independente no cluster do HeatWave nos sistemas de banco de dados de origem e de destino. No entanto, em versões mais antigas e do MySQL 9.5.1, se você carregar uma tabela no cluster do HeatWave no sistema de banco de dados de destino primeiro e, em seguida, tentar carregar a mesma tabela no cluster do HeatWave no sistema de banco de dados de origem, isso poderá interromper o canal de replicação, 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
    No MySQL 9.5.1 e em versões mais antigas, 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 do HeatWave e já tem SECONDARY_ENGINE = RAPID definido.

    No MySQL 9.5.2 e em versões posteriores, você pode carregar e descarregar tabelas de forma independente nos sistemas de banco de dados de origem e de destino sem fazer com que o canal de replicação interrompa ou gere erros.

  • Quando o cluster HeatWave é excluído ou recriado no sistema de banco de dados de origem, todas as tabelas carregadas anteriormente são descarregadas do cluster HeatWave no sistema de banco de dados de origem, e as mesmas tabelas também são descarregadas do cluster HeatWave no sistema de banco de dados 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 quebra ao alterar uma tabela InnoDB com uma chave primária gerada para uma tabela do Lakehouse.
  • Os seguintes nomes não podem ser usados para canais de replicação:
    • group_replication_applier
    • group_replication_recovery
    • oci_upgrade_channel
  • Em versões anteriores à 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.
  • Nas versões anteriores à 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 de mecanismo da tabela externa do Lakehouse.