Solução de problemas do Amazon Aurora - Amazon Aurora
Não é possível conectar-se à instância de banco de dados do Problemas de segurançaRedefinir a senha de proprietário da instância de banco de dadosInterrupção ou reinicialização da instância de banco de dadosAlterações de parâmetros que não entram em vigorProblemas de memória liberável do AuroraProblemas de replicação do Aurora MySQL

Solução de problemas do Amazon Aurora

Use as seções a seguir para solucionar problemas que possam surgir com instâncias de bancos de dados do Amazon RDS e do Amazon Aurora.

Para obter informações sobre como depurar problemas usando a API do Amazon RDS, consulte Solução de problemas de aplicações no Aurora.

Não é possível conectar-se à instância de banco de dados do Amazon RDS

Quando você não consegue se conectar a uma instância de banco de dados, as causas a seguir são motivos comuns:

  • Regras de entrada – as regras de acesso impostas pelo firewall local e os endereços IP autorizados a acessar a instância de banco de dados podem não corresponder. O problema está provavelmente nas regras de entrada do seu grupo de segurança.

    Por padrão, as instâncias de banco de dados não permitem acesso. O acesso é concedido por meio de um grupo de segurança associado à VPC que permite o tráfego de entrada e saída da instância de banco de dados. Se necessário, adicione regras de entrada e saída para sua situação específica ao grupo de segurança. Você pode especificar um endereço IP, um intervalo de endereços IP ou outro grupo de segurança da VPC.

    nota

    Ao adicionar uma nova regra de entrada, escolha My IP (Meu IP) para a Source (Origem) a fim de permitir o acesso à instância de banco de dados do endereço IP detectado em seu navegador.

    Para ter mais informações sobre como configurar um grupo de segurança, consulte Fornecer acesso ao cluster de banco de dados na VPC criando um grupo de segurança.

    nota

    Conexões de cliente de endereços IP dentro do intervalo 169.254.0.0/16 não são permitidas. Esse é o APIPA (Automatic Private IP Addressing Range, Intervalo de endereçamento IP privado automático), usado para o endereçamento de link local.

  • Acessibilidade pública – para se conectar à sua instância de banco de dados de fora da VPC, como por exemplo, usando uma aplicação cliente, a instância deve ter um endereço IP público atribuído a ela.

    Para tornar a instância acessível publicamente, modifique-a e escolha Yes (Sim) em Public accessibility (Acessibilidade pública). Para ter mais informações, consulte Ocultar um cluster de banco de dados em uma VPC da Internet.

  • Porta – a porta que você especificou quando criou a instância de banco de dados não pode ser usada para enviar ou receber comunicações devido às restrições de firewall locais. Verifique com seu administrador de rede para determinar se a rede permite que a porta especificada seja usada para a comunicação de entrada e saída.

  • Disponibilidade – a instância de banco de dados recém-criada fica com o status creating até que esteja pronta para uso. Quando o estado for alterado para available, será possível se conectar à instância de banco de dados. Dependendo do tamanho da sua instância de banco de dados, pode demorar até 20 minutos para que uma instância esteja disponível.

  • Gateway da Internet – para que uma instância de banco de dados seja acessível publicamente, as sub-redes no grupo de sub-redes de banco de dados devem ter um gateway da Internet.

    Como configurar um gateway da Internet para uma sub-rede

    1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

    2. No painel de navegação, escolha Databases (Bancos de dados) e escolha o nome da instância de banco de dados.

    3. Na guia Connectivity & security (Conectividade e segurança) anote os valores do ID da VPC em VPC e o ID da sub-rede em Subnets (Sub-redes).

    4. Abra o console da Amazon VPC em https://console.aws.amazon.com/vpc/.

    5. No painel de navegação, escolha Gateways da Internet. Verifique se há um gateway de internet associado à sua VPC. Caso contrário, escolha Criar gateway da internet para criar um gateway da Internet. Selecione o gateway de internet e escolha Associar à VPC e siga as instruções para associá-la à sua VPC.

    6. No painel de navegação, escolha Sub-redes e selecione sua sub-rede.

    7. Na guia Tabela de rotas, verifique que há uma rota com 0.0.0.0/0 como o destino e o gateway de Internet para sua VPC como destino.

      Se você estiver se conectando à sua instância usando o endereço IPv6, verifique se há uma rota para todo o tráfego IPv6 (::/0) que aponta para o gateway de Internet. Caso contrário, faça o seguinte:

      1. Escolha o ID da tabela de rotas (rtb-xxxxxxxx) para navegar para a tabela de rotas.

      2. Na guia Routes (Rotas), escolha Edit routes (Editar rotas). Escolha Add route (Adicionar rota), use 0.0.0.0/0 como o destino, e o gateway da Internet como o destino.

        Para IPv6, escolha Add route (Adicionar rota), use ::/0 como o destino, e o gateway da Internet como o destino.

      3. Escolha Save routes (Salvar rotas).

      Além disso, se você estiver tentando se conectar ao endpoint IPv6, verifique se o intervalo de endereços IPv6 do cliente está autorizado a se conectar à instância de banco de dados.

    Para ter mais informações, consulte Trabalhar com um cluster de banco de dados em uma VPC.

Testar uma conexão a uma instância de banco de dados

É possível testar sua conexão a uma instância de banco de dados usando ferramentas comuns do Linux ou do Microsoft Windows.

Em um terminal Linux ou Unix, teste a conexão inserindo o seguinte. Substitua DB-instance-endpoint pelo endpoint e port pela porta de sua instância de banco de dados.

nc -zv DB-instance-endpoint port

Veja a seguir um exemplo de comando e o valor de retorno.

nc -zv postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299

  Connection to postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded!

Os usuários do Windows podem usar o Telnet para testar a conexão com uma instância de banco de dados. As ações do Telnet não têm suporte além do teste da conexão. Se uma conexão for bem-sucedida, a ação não retorna uma mensagem. Se uma conexão não for bem-sucedida, você receberá uma mensagem de erro, como a seguinte:

C:\>telnet sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com 819

  Connecting To sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com...Could not open
  connection to the host, on port 819: Connect failed

Se as ações do Telnet retornarem êxito, seu grupo de segurança está corretamente configurado.

nota

O Amazon RDS não aceita o tráfego pelo protocolo ICMP (protocolo de mensagens de controle da Internet), incluindo ping.

Solução de problemas de autenticação da conexão

Em alguns casos, você pode se conectar à sua instância de banco de dados, mas recebe erros de autenticação. Nesses casos, convém redefinir a senha do usuário principal para a instância de banco de dados. Isso pode ser feito ao modificar a instância do RDS.

Problemas de segurança do Amazon RDS

Para evitar problemas de segurança, nunca use o nome do usuário-raiz e a senha da Conta da AWS para uma conta de usuário. A prática recomendada é usar o usuário-raiz para criar usuários e atribuí-los a contas de usuário de banco de dados. Também é possível usar o usuário-raiz para criar outras contas de usuário, se necessário.

Para obter informações sobre a criação de usuários, consulte Criar um usuário do IAM na sua Conta da AWS. Para obter informações sobre como criar usuários no AWS IAM Identity Center, consulte Manage identities in IAM Identity Center (Gerenciar identidades no IAM Identity Center).

Mensagem de erro "Falha ao recuperar atributos da conta, certas funções do console podem ser prejudicadas."

Esse erro pode ser exibido por vários motivos. Pode ser porque sua conta não tem as permissões ou não tenha sido configurada corretamente. Se a sua conta for nova, talvez você não tenha esperado que ela ficasse pronta. Se for uma conta existente, talvez você não tenha permissões nas suas políticas de acesso para realizar determinadas ações, como criar uma instância de banco de dados. Para corrigir o problema, o administrador precisa fornecer os perfis necessários para a sua conta. Para ter mais informações, consulte a documentação do IAM.

Redefinir a senha de proprietário da instância de banco de dados

Se não conseguir acessar seu cluster de banco de dados, você poderá fazer login como o usuário mestre. Depois, você poderá redefinir as credenciais de outros usuários administrativos ou funções. Se não conseguir fazer login como usuário mestre, o proprietário da conta da AWS poderá redefinir a senha do usuário mestre. Para obter detalhes sobre quais contas administrativas ou funções deverão ser redefinidas, consulte Privilégios da conta de usuário mestre.

É possível alterar a senha da instância de banco de dados usando o console do Amazon RDS, o comando da AWS CLI modify-db-instance ou a operação de API ModifyDBInstance. Para ter mais informações sobre como modificar uma instância de banco de dados em um cluster de banco de dados, consulte Modificar uma instância de banco de dados em um cluster de banco de dados.

Interrupção ou reinicialização da instância de banco de dados do Amazon RDS

Uma interrupção da instância de banco de dados pode ocorrer quando a instância de banco de dados é reinicializada. A interrupção também pode ocorrer quando a instância de banco de dados é colocada em um estado que impede o acesso a ela e quando o banco de dados é reiniciado. Uma reinicialização pode ocorrer ao reinicializar manualmente a instância de banco de dados. Uma reinicialização também pode ocorrer quando você altera uma configuração da instância de banco de dados que exija uma reinicialização para que tenha efeito.

A reinicialização de uma instância de banco de dados só ocorre quando você altera uma configuração que exija uma reinicialização ou quando você faz uma reinicialização manualmente. Uma reinicialização poderá ocorrer imediatamente se você alterar uma configuração e solicitar que ela tenha efeito imediato. Ou isso pode ocorrer durante a janela de manutenção da instância de banco de dados.

Uma reinicialização de instância de banco de dados ocorre imediatamente quando ocorre um dos seguintes eventos:

  • Você altera o período de retenção de backup para uma instância de banco de dados de 0 para um valor diferente de zero ou vice-versa. Depois, defina Apply Immediately (Aplicar imediatamente) como true.

  • Você altera a classe de instância de banco de dados, e Apply Immediately (Aplicar imediatamente) é definido como true.

A reinicialização de uma instância de banco de dados ocorre durante a janela de manutenção quando ocorre um dos seguintes:

  • Você altera o período de retenção de backup para uma instância de banco de dados de 0 para um valor diferente de zero ou vice-versa e define Apply Immediately (Aplicar imediatamente) como false.

  • Você altera a classe de instância de banco de dados, e Apply Immediately (Aplicar imediatamente) é definido como false.

Quando você altera um parâmetro estático em um grupo de parâmetros de banco de dados, a alteração não terá efeito até que a instância de banco de dados associada ao grupo de parâmetros seja reinicializada. A alteração requer uma reinicialização manual. A instância de banco de dados não é reinicializada automaticamente durante a janela de manutenção.

Alterações de parâmetros de banco de dados do Amazon RDS que não entram em vigor

Em alguns casos, talvez você altere um parâmetro em um grupo de parâmetros do banco de dados, mas não veja as alterações entrarem em vigor. Nesse caso, provavelmente será necessário reinicializar a instância de banco de dados associada ao grupo de parâmetros do banco de dados. Quando você altera um parâmetro dinâmico, a alteração entra em vigor imediatamente. Quando você altera um parâmetro estático, a alteração não entrará em vigor até que você reinicie a instância de banco de dados associada ao grupo de parâmetros.

Você pode reinicializar uma instância de banco de dados usando o console do RDS. Ou você pode chamar explicitamente a operação RebootDBInstance da API. Você poderá reinicializar sem failover se a instância de banco de dados estiver em uma implantação multi-AZ. A exigência de reinicializar a instância de banco de dados associada após uma alteração de parâmetro estático ajuda a atenuar o risco de que uma configuração incorreta de parâmetro afete uma chamada de API. Um exemplo disso é chamar ModifyDBInstance para alterar a classe de instância de banco de dados. Para ter mais informações, consulte Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon Aurora.

Problemas de memória liberável no Amazon Aurora

Memória liberávelé a memória total de acesso aleatório (RAM) em uma instância de banco de dados que pode ser disponibilizada para o mecanismo de banco de dados. É a soma da memória livre do sistema operacional (SO) e o buffer e a memória cache de página disponíveis. O mecanismo de banco de dados usa a maior parte da memória no host, mas os processos do sistema operacional também usam RAM. A memória atualmente alocada ao mecanismo de banco de dados ou usada pelos processos do sistema operacional não está incluída na memória liberável. Quando o mecanismo de banco de dados está ficando sem memória, a instância de banco de dados pode usar o espaço temporário normalmente usado para buffer e armazenamento em cache. Como mencionado anteriormente, esse espaço temporário está incluído na memória liberável.

Você usa a métrica FreeableMemory no Amazon CloudWatch para monitorar a memória liberável. Para ter mais informações, consulte Ferramentas de monitoramento do Amazon Aurora.

Se a instância de banco de dados for executada consistentemente com memória liberável ou usar espaço de troca, pense em aumentar a escala verticalmente para uma classe de instância de banco de dados maior. Para ter mais informações, consulte Classes de instância de banco de dados do Amazon Aurora.

Também é possível alterar as configurações de memória. Por exemplo, no Aurora MySQL , você pode ajustar o tamanho do parâmetro innodb_buffer_pool_size. Esse parâmetro é definido por padrão como 75% da memória física. Para obter mais dicas sobre solução de problemas do MySQL, consulte How can I troubleshoot low freeable memory in an Amazon RDS para MySQL database? (Como posso solucionar problemas de pouca memória liberável em um banco de dados do Amazon RDS para MySQL?)

No caso do Aurora Serverless v2, FreeableMemory representa a quantidade de memória não utilizada que está disponível quando a instância de banco de dados do Aurora Serverless v2 é dimensionada para sua capacidade máxima. Você pode reduzir a escala da instância verticalmente para capacidade relativamente baixa, mas ela ainda relata um valor alto para FreeableMemory, porque é possível aumentar a escala da instância verticalmente. Essa memória não está disponível no momento, mas você poderá obtê-la se for necessário.

Para cada unidade de capacidade do Aurora (ACU) em que a capacidade atual está abaixo da capacidade máxima, a FreeableMemory aumenta em cerca de 2 GiB. Assim, essa métrica não se aproxima de zero até que a escala da instância de banco de dados seja aumentada na vertical ao nível mais alto possível.

Se essa métrica se aproximar de um valor de 0, a escala da instância de banco de dados foi aumentada verticalmente o máximo possível. Está se aproximando do limite de sua memória disponível. Considere aumentar a configuração máxima de ACU para o cluster. Se essa métrica se aproximar de um valor de 0 em uma instância de banco de dados do leitor, considere adicionar mais instâncias de banco de dados do leitor ao cluster. Dessa forma, é possível distribuir a parte somente leitura da workload por mais instâncias de banco de dados, reduzindo o uso de memória em cada instância de banco de dados do leitor. Para ter mais informações, consulte Métricas importantes do Amazon CloudWatch para o Aurora Serverless v2.

No caso do Aurora Serverless v1, você pode alterar o intervalo de capacidade para usar mais ACUs. Para ter mais informações, consulte Modificar um cluster de banco de dados do Aurora Serverless v1.

Problemas de replicação no Amazon Aurora MySQL

Alguns problemas de replicação do MySQL também se aplicam ao Aurora MySQL. É possível diagnosticar e corrigir esses problemas.

Diagnosticar e resolver atrasos entre réplicas de leitura

Depois de criar uma réplica de leitura MySQL e quando ela estiver disponível, o Amazon RDS primeiro replicará as alterações feitas na instância de banco de dados de origem a partir do momento em que a operação de criação da réplica de leitura foi iniciada. Durante essa fase, o tempo de atraso da replicação para a réplica de leitura será maior que 0. Você pode monitorar esse tempo de atraso no Amazon CloudWatch visualizando a métrica AuroraBinlogReplicaLag do Amazon RDS.

A métrica AuroraBinlogReplicaLag informa o valor do campo Seconds_Behind_Master do comando SHOW REPLICA STATUS do MySQL. Para ter mais informações, consulte Instrução SHOW REPLICA STATUS na documentação do MySQL.

Quando a métrica AuroraBinlogReplicaLag chega a 0, isso mostra que a réplica alcançou a instância do banco de dados de origem. Se a métrica AuroraBinlogReplicaLag retornar -1, a replicação pode não estar ativa. Para solucionar um erro de replicação, consulte Diagnosticar e resolver uma falha de replicação de leitura do MySQL. Um AuroraBinlogReplicaLag com um valor de -1 também pode significar que o valor de Seconds_Behind_Master não pode ser determinado ou é NULL.

nota

As versões anteriores do Aurora MySQL usavam SHOW SLAVE STATUS em vez de SHOW REPLICA STATUS. Se você estiver utilizando o Aurora MySQL versão 1 ou 2, utilize SHOW SLAVE STATUS. Use SHOW REPLICA STATUS para o Aurora MySQL versão 3 e posteriores.

A métrica AuroraBinlogReplicaLag retorna -1 durante uma interrupção da rede ou quando um patch é aplicado durante a janela de manutenção. Nesse caso, aguarde até que a conectividade de rede seja restaurada ou a janela de manutenção seja finalizada antes de verificar novamente a métrica AuroraBinlogReplicaLag.

A tecnologia de replicação de leitura do MySQL é assíncrona. Portanto, você pode esperar aumentos ocasionais da métrica BinLogDiskUsage na instância de banco de dados de origem e da métrica AuroraBinlogReplicaLag na réplica de leitura. Por exemplo, considere uma situação em que um alto volume de operações de gravação para a instância de banco de dados de origem ocorra em paralelo. Ao mesmo tempo, as operações de gravação na réplica de leitura são serializadas usando um único thread de E/S. Tal situação pode levar a um atraso entre a instância de origem e a réplica de leitura.

Para ter mais informações sobre réplicas de leitura e o MySQL, consulte Detalhes da implementação da replicação na documentação do MySQL. .

É possível reduzir o atraso entre as atualizações em uma instância de banco de dados de origem e as atualizações subsequentes da réplica de leitura fazendo o seguinte:

  • Defina a classe da instância de banco de dados da réplica de leitura para que ela tenha um tamanho de armazenamento comparável ao da instância de banco de dados de origem.

  • Certifique-se de que as configurações de parâmetros nos grupos de parâmetros do banco de dados utilizados pela instância de banco de dados de origem e pela réplica de leitura sejam compatíveis. Para ter mais informações e um exemplo, consulte a discussão sobre o parâmetro max_allowed_packet na próxima seção.

  • Desabilite o cache de consulta. Para tabelas que são modificadas com frequência, o uso do cache de consulta pode aumentar o atraso das réplicas, pois o cache é bloqueado e atualizado com frequência. Se esse for o caso, talvez você veja um atraso menor de réplicas se desabilitar o cache de consulta. É possível desabilitar o cache de consultas definindo query_cache_type parameter como 0 no grupo de parâmetros de banco de dados da instância de banco de dados. Para ter mais informações sobre o cache de consulta, consulte Configuração do cache de consulta.

  • Aqueça o grupo de buffers na réplica de leitura do InnoDB para MySQL. Por exemplo, suponha que você tenha um pequeno conjunto de tabelas sendo atualizadas com frequência e esteja usando o esquema de tabela InnoDB ou XtraDB. Nesse caso, despeje essas tabelas na réplica de leitura. Isso faz com que o mecanismo de banco de dados explore as linhas dessas tabelas no disco e armazene-as em cache no grupo de buffers, o que pode reduzir o atraso das réplicas. Essa abordagem pode reduzir o atraso da réplica. Por exemplo:

    Para Linux, macOS ou Unix:

    PROMPT> mysqldump \
    -h <endpoint> \
    --port=<port> \
    -u=<username> \
    -p <password> \
    database_name table1 table2 > /dev/null

    Para Windows:

    PROMPT> mysqldump ^
    -h <endpoint> ^
    --port=<port> ^
    -u=<username> ^
    -p <password> ^
    database_name table1 table2 > /dev/null

Diagnosticar e resolver uma falha de replicação de leitura do MySQL

O Amazon RDS monitora o status de replicação de suas réplicas de leitura. O RDS atualiza o campo Replication State (Estado de replicação) da instância da réplica de leitura para Error caso a replicação seja interrompida por qualquer motivo. É possível analisar os detalhes do erro associado lançado pelos mecanismos do MySQL visualizando o campo Replication Error (Erro de replicação). Os eventos que indicam o status da réplica de leitura também são gerados, incluindo RDS-EVENT-0045, RDS-EVENT-0046 e RDS-EVENT-0057. Para ter mais informações sobre eventos e como se inscrever neles, consulte Trabalhar com a notificação de eventos do Amazon RDS. Se for retornada uma mensagem de erro do MySQL, verifique o erro na documentação de mensagens de erro do MySQL. .

Situações comuns que podem causar erros de replicação incluem o seguinte:

  • O valor do parâmetro max_allowed_packet para uma réplica de leitura é menor que o parâmetro max_allowed_packet para a instância do banco de dados de origem.

    O parâmetro max_allowed_packet é um parâmetro personalizado que você pode definir em um grupo de parâmetros de banco de dados. O parâmetro max_allowed_packet é usado para especificar o tamanho máximo de linguagem de manipulação de dados (DML) que pode ser executado no banco de dados. Em alguns casos, o valor max_allowed_packet para a instância de banco de dados de origem pode ser maior do que o valor max_allowed_packet para a réplica de leitura. Se sim, o processo de replicação poderá lançar um erro e interromper a replicação. O erro mais comum é packet bigger than 'max_allowed_packet' bytes. É possível corrigir o erro fazendo com que a origem e a réplica de leitura usem grupos de parâmetros de banco de dados com os mesmos valores do parâmetro max_allowed_packet.

  • A gravação em tabelas em uma réplica de leitura. Se você estiver criando índices em uma réplica de leitura, será necessário que o parâmetro read_only seja definido como 0 para criar os índices. Se você estiver gravando em tabelas na réplica de leitura, isso poderá interromper a replicação.

  • Uso de um mecanismo de armazenamento não transacional, como o MyISAM. As réplicas de leitura exigem um mecanismo de armazenamento transacional. A replicação só é compatível com os seguintes mecanismos de armazenamento: InnoDB para MySQL ou MariaDB.

    Você pode converter uma tabela MyISAM para o InnoDB com o seguinte comando:

    alter table <schema>.<table_name> engine=innodb;

  • Usando consultas não deterministas inseguras, como SYSDATE(). Para ter mais informações, consulte Determinar instruções seguras e não seguras em registros em logs binários na documentação do MySQL.

As seguintes etapas podem ajudar a resolver seu erro de replicação:

  • Se você encontrar um erro lógico e puder ignorar o erro com segurança, siga as etapas descritas em Ignorar o erro de replicação atual. Sua instância de banco de dados do Aurora MySQL deve estar executando uma versão que inclua o procedimento mysql_rds_skip_repl_error. Para ter mais informações, consulte mysql_rds_skip_repl_error.

  • Se encontrar um problema de posição de log binário, você poderá alterar a posição de reprodução da réplica. Você faz isso com o comando mysql.rds_next_master_log do Aurora MySQL versões 1 e 2. Você faz isso com o comando mysql.rds_next_source_log do Aurora MySQL versões 3 e posteriores. Sua instância de banco de dados do Aurora MySQL deve estar executando uma versão com suporte a esse comando para alterar a posição de reprodução da réplica. Para obter informações sobre a versão, consulte mysql_rds_next_master_log.

  • Se encontrar um problema de performance temporário devido à alta carga DML, você poderá definir o parâmetro innodb_flush_log_at_trx_commit como 2 no grupo de parâmetros do banco de dados da réplica de leitura. Fazer isso pode ajudar na recuperação da réplica de leitura, embora isso reduza temporariamente a atomicidade, a consistência, o isolamento e a durabilidade (ACID).

  • É possível excluir a réplica de leitura e criar uma instância usando o mesmo identificador de instância de banco de dados. Dessa forma, o endpoint permanecerá igual ao da réplica de leitura antiga.

Se um erro de replicação for corrigido, o valor de Replication State (Estado de replicação) mudará para replicating (replicando). Para ter mais informações, consulte Solução de problemas da réplica de leitura do MySQL.

Erro de replicação interrompida

Quando você chama o comando mysql.rds_skip_repl_error, você pode receber uma mensagem de erro informando que a replicação está inativa ou desabilitada.

Esta mensagem de erro é exibida porque a replicação parou e não foi possível reiniciá-la.

Se você precisar ignorar um grande número de erros, o atraso de replicação pode aumentar além do período de retenção padrão para arquivos de log binário. Nesse caso, você poderá encontrar um erro fatal devido a arquivos de log binário sendo removidos antes de terem sido reproduzidos na réplica. Essa remoção faz com que a replicação pare, e você não consegue chamar o comando mysql.rds_skip_repl_error para ignorar erros de replicação.

Você pode mitigar esse problema aumentando o número de horas em que os arquivos de log binário são retidos na origem da replicação. Após aumentar o período de retenção de log binário, você pode reiniciar a replicação e chamar o comando mysql.rds_skip_repl_error conforme necessário.

Para definir o tempo de retenção do log binário, use o procedimento mysql_rds_set_configuration . Especifique um parâmetro de configuração de "horas de retenção do log binário" juntamente com o número de horas para reter arquivos de log binário no cluster de banco de dados, até 2160 (90 dias). O padrão para Aurora MySQL é 24 (1 dia). O exemplo a seguir define o período de retenção para arquivos de log binário em 48 horas.

CALL mysql.rds_set_configuration('binlog retention hours', 48);