Solução de problemas para o Amazon RDS

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 Amazon RDS.

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:

Para problemas de conexão específicos do mecanismo, consulte os seguintes tópicos:

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.

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.

Para ter mais informações sobre a modificação de uma instância de banco de dados , consulte Modificar uma instância de banco de dados do Amazon 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.

Solução de problemas de estado de rede incompatível

Estado de rede incompatível significa que, embora o banco de dados ainda possa estar acessível em nível de banco de dados, ele não pode ser modificado nem reinicializado.

Causas

O estado de rede incompatível de sua instância de banco de dados pode resultar de uma das seguintes ações:

Resolução

Usar o comando start-db-instance

Para corrigir um banco de dados em um estado de rede incompatível, siga estas instruções:

O status do banco de dados mudará para Disponível se o comando for executado com êxito.

Se o banco de dados for reiniciado, a instância de banco de dados poderá executar a última operação executada na instância antes de ser movida para um estado de rede incompatível. Isso pode levar a instância de volta ao estado de rede incompatível.

Se o comando start-db-instance não for bem-sucedido ou a instância voltar ao estado de rede incompatível, abra a página Bancos de dados no console do RDS e selecione o banco de dados. Acesse a seção Logs e eventos. A seção Eventos recentes exibe outras etapas de resolução que devem ser seguidas. As mensagens são classificadas da seguinte forma:

Realize a recuperação para um ponto no tempo.

É uma prática recomendada ter um backup (instantâneo ou lógico), caso o banco de dados entre em um estado de rede incompatível. Consulte Introdução aos backups. Ao ativar backups automatizados, interrompa temporariamente qualquer gravação no banco de dados e execute uma recuperação para um ponto no tempo.

Se você não ativou backups automatizados, crie uma instância de banco de dados. Em seguida, migre os dados usando o AWS Database Migration Service(AWS DMS) ou usando uma ferramenta de backup e restauração.

Se isso não resolver o problema, entre em contato com o AWS Supportpara obter maior assistência.

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

Se não conseguir acessar sua instância 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 a modificação de uma instância de banco de dados , consulte Modificar uma instância de banco de dados do Amazon RDS.

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:

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

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.

Para ver uma tabela que mostra as ações das instâncias de bancos de dados e o efeito de configurar o valor Apply Immediately, consulte Modificar uma instância de banco de dados do Amazon RDS.

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 RDS.

Instância de banco de dados do Amazon RDS ficando sem espaço de armazenamento

Se a sua instância de banco de dados ficar sem espaço de armazenamento, talvez ela se torne indisponível. Recomendamos que você monitore constantemente a métrica FreeStorageSpace publicada no CloudWatch para garantir que a sua instância de banco de dados tenha espaço de armazenamento livre suficiente.

Se a instância de banco de dados ficar sem armazenamento, seu status será alterado para storage-full. Por exemplo, uma chamada para a operação de API DescribeDBInstances para uma instância de banco de dados que esgotou seu armazenamento emitirá o seguinte:

aws rds describe-db-instances --db-instance-identifier mydbinstance

DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
storage-full  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

Para solucionar esse cenário, adicione mais espaço de armazenamento à instância usando a operação de API ModifyDBInstance ou o comando da AWS CLI a seguir.

Para Linux, macOS ou Unix:

aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --allocated-storage 60 \
    --apply-immediately

Para Windows:

aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --allocated-storage 60 ^
    --apply-immediately

DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
storage-full  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3  60
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

Agora, quando descrever sua instância de banco de dados, você verá que ela terá o status modifying, o que indica que o armazenamento está sendo dimensionado.

aws rds describe-db-instances --db-instance-identifier mydbinstance 

DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
modifying  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com
3306  us-east-1b  3  60
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

Após a conclusão da escalabilidade do armazenamento, o status da instância de banco de dados mudará para available.

aws rds describe-db-instances --db-instance-identifier mydbinstance 

DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  60  sa
available  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

Ao usar a operação DescribeEvents, é possível que você receba notificações quando seu espaço estiver esgotado. Por exemplo, nesse cenário, se fizer uma chamada DescribeEvents depois dessas operações, você verá a seguinte saída:

aws rds describe-events --source-type db-instance --source-identifier mydbinstance 

2009-12-22T23:44:14.374Z  mydbinstance  Allocated storage has been exhausted db-instance
2009-12-23T00:14:02.737Z  mydbinstance  Applying modification to allocated storage db-instance
2009-12-23T00:31:54.764Z  mydbinstance  Finished applying modification to allocated storage

Instâncias de banco de dados disponíveis do Amazon RDS insuficientes

O erro InsufficientDBInstanceCapacity pode ser retornado ao tentar criar, iniciar ou modificar uma instância de banco de dados. Ele também pode ser retornado ao tentar restaurar uma instância de banco de dados de um snapshot de banco de dados. Quando esse erro é retornado, uma causa comum é que a classe de instância de banco de dados específica não está disponível na zona de disponibilidade solicitada. É possível tentar uma das seguinte opções para resolver o problema:

Para obter informações sobre como solucionar problemas de capacidade de instância para o Amazon EC2, consulte Capacidade da instância insuficiente no Guia do usuário do Amazon EC2.

Para ter mais informações sobre como modificar uma instância de banco de dados , consulte Modificar uma instância de banco de dados do Amazon RDS.

Problemas de memória liberável no Amazon RDS

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 RDS.

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 .

Também é possível alterar as configurações de memória. Por exemplo, no RDS para 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?)

Problemas no MySQL e MariaDB

É possível diagnosticar e corrigir problemas em instâncias de banco de dados MySQL e MariaDB.

Máximo de conexões MySQL e MariaDB

O número máximo de conexões permitidas para uma instância de banco de dados RDS para MySQL ou RDS para MariaDB baseia-se na quantidade de memória disponível para a classe de instância de banco de dados. Uma classe de instância de banco de dados com mais memória disponível resulta em um número maior de conexões disponíveis. Para ter mais informações sobre classes de instância de banco de dados, consulte Classes de instância de banco de dados do .

O limite de conexão para uma instância de banco de dados é definido por padrão como o máximo para a classe de instância de banco de dados. É possível limitar o número de conexões simultâneas a qualquer valor até o número máximo de conexões permitidas. Use o parâmetro max_connections no grupo de parâmetros para a instância de banco de dados. Para ter mais informações, consulte Número máximo de conexões de banco de dados e Grupos de parâmetros para Amazon RDS.

É possível recuperar o número máximo de conexões permitidas para uma instância de banco de dados MySQL ou MariaDB executando a consulta a seguir.

SELECT @@max_connections;

É possível recuperar o número de conexões ativas para uma instância de banco de dados MySQL ou MariaDB executando a consulta a seguir.

SHOW STATUS WHERE `variable_name` = 'Threads_connected';

Diagnosticar e resolver o status de parâmetros incompatíveis para um limite de memória

Uma instância de banco de dados MariaDB ou MySQL pode ser colocada no status parâmetros incompatíveis para limitar a memória quando as seguintes condições forem atendidas:

Quando uma instância de banco de dados é reiniciada pela terceira vez em uma hora ou pela quinta vez em um dia, será executada uma verificação de uso de memória. A verificação faz com que o cálculo do potencial uso de memória da instância de banco de dados. O valor retornado pelo cálculo é a soma dos seguintes valores:

Então, o valor retornado pelo cálculo é o seguinte:

Value 1 + Value 2 + Value 3

Quando esse valor excede 1,2 vezes a memória alocada para a classe da instância de banco de dados, essa instância é colocada no status incompatible-parameters (parâmetros incompatíveis). Para ter mais informações sobre a memória alocada para as classes de instâncias de banco de dados , consulte Especificações de hardware para classes de instância de banco de dados .

O cálculo multiplica o valor do parâmetro max_connections pela soma de vários parâmetros. Se o parâmetro max_connections for definido para um valor grane, é possível que a verificação retorne um valoro elevado para o uso potencial de memória da instância de banco de dados. Nesse caso, avalie a possibilidade de reduzir o valor do parâmetro max_connections.

Para resolver o problema, conclua as seguintes etapas:

Diagnosticar e resolver atrasos entre réplicas de leitura

Depois de criar uma réplica de leitura MySQL ou MariaDB 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 ReplicaLag do Amazon RDS.

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

Quando a métrica ReplicaLag chega a 0, isso mostra que a réplica alcançou a instância do banco de dados de origem. Se a métrica ReplicaLag 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 ou MariaDB. Um ReplicaLag com um valor de -1 também pode significar que o valor de Seconds_Behind_Master não pode ser determinado ou é NULL.

A métrica ReplicaLag 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 ReplicaLag.

A tecnologia de replicação de leitura do MySQL e do MariaDB é 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 ReplicaLag 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. Para ter mais informações sobre réplicas de leitura e o MariaDB, consulte Visão geral sobre a replicação na documentação do MariaDB.

É 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:

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

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 ou MariaDB 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. Se for retornada uma mensagem de erro do MariaDB, verifique o erro na documentação de mensagens de erro do MariaDB.

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

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

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 Solucionar problemas de uma réplica de leitura do MySQL.

Criar triggers com o registro de logs binários habilitado requer o privilégio SUPER

Ao tentar criar triggers em uma instância de banco de dados RDS para MySQL ou RDS para MariaDB, você pode receber o seguinte erro:

"You do not have the SUPER privilege and binary logging is enabled" 

Para usar triggers quando o registro em logs binários está habilitado, é necessário ter o privilégio SUPER, que é restrito para as instâncias de bancos de dados RDS para MySQL e RDS para MariaDB. Você pode criar triggers quando o registro em logs binários está habilitado sem o privilégio SUPER, definindo o parâmetro log_bin_trust_function_creators DevOps Guru para RDS Para definir log_bin_trust_function_creators como true, crie um novo grupo de parâmetros de banco de dados ou modifique um grupo de parâmetros de banco de dados existente.

É possível criar um grupo de parâmetros de banco de dados que permita criar triggers em sua instância de banco de dados do RDS para MySQL ou do RDS para MariaDB com o registro em log binário habilitado. Para fazer isso, use os comandos da CLI a seguir. Para modificar um grupo de parâmetros existente, comece com a etapa 2.

Diagnosticar e resolver falhas de restauração pontual

Restaurar uma instância de banco de dados que inclua tabelas temporárias

Ao tentar uma restauração para um ponto específico (PITR) da sua instância de banco de dados MySQL ou MariaDB, você pode encontrar o seguinte erro:

Database instance could not be restored because there has been incompatible database activity for restore
functionality. Common examples of incompatible activity include using temporary tables, in-memory tables,
or using MyISAM tables. In this case, use of Temporary table was detected.	

A PITR depende do snapshot do backup e dos logs binários (binlogs) do MySQL ou do MariaDB para restaurar sua instância de banco de dados para um momento específico. As informações de tabelas temporárias podem ser pouco confiáveis nos logs binários e podem causar uma falha na PITR. Se você usar tabelas temporárias na sua instância de banco de dados do MySQL ou do MariaDB, poderá reduzir a possibilidade de uma falha de PITR realizando backups mais frequentes. Uma falha de PITR é mais provável no momento entre a criação de uma tabela temporária e o próximo snapshot de backup.

Restaurar uma instância de banco de dados que inclua tabelas na memória

Você pode encontrar um problema ao restaurar um banco de dados que possua tabelas na memória. As tabelas na memória são limpas durante uma reinicialização. Como resultado, suas tabelas na memória podem ficar vazias após uma reinicialização. Recomendamos que, ao usar tabelas na memória, você arquitete sua solução para lidar com tabelas vazias em caso de uma reinicialização. Se você estiver usando tabelas na memória com instâncias de banco de dados replicadas, talvez seja necessário recriar as réplicas de leitura após uma reinicialização. Isso pode ser necessário se uma réplica de leitura for reinicializada e não conseguir restaurar dados de uma tabela vazia na memória.

Para ter mais informações sobre backups e PITR, consulte Introdução aos backups e Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS.

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é 720 (30 dias). 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);

Falha na criação da réplica de leitura ou interrupção da replicação com o erro fatal 1236

Depois de alterar os valores de parâmetro padrão para uma instância de banco de dados MySQL ou MariaDB, você pode encontrar um dos seguintes problemas:

Alguns valores de parâmetro padrão para instâncias de banco de dados do MySQL e MariaDB ajudam a garantir que o banco de dados seja compatível com ACID e que as réplicas de leitura estejam protegidas contra falhas. Eles fazem isso garantindo que cada confirmação seja totalmente sincronizada gravando a transação no log binário antes de ser confirmada. Alterar esses parâmetros de seus valores padrão para melhorar a performance pode fazer com que haja falha na replicação quando uma transação não for gravada no log binário.

Para resolver esse problema, defina os seguintes valores de parâmetros:

Não é possível definir o período de retenção de backup como 0

Há várias razões pelas quais pode ser necessário definir o período de retenção de backup como 0. Por exemplo, você pode desativar os backups automáticos imediatamente ao configurar o período de retenção como 0.

Em alguns casos, é possível definir o valor como 0 e receber uma mensagem dizendo que o período de retenção deve estar entre 1 e 35. Nesses casos, verifique se você não configurou uma réplica de leitura para a instância. As réplicas de leitura exigem backups para o gerenciamento dos logs de réplica de leitura, portanto, não será possível definir o período de retenção como 0.