Não é possível conectar-se à instância de banco de dados do Problemas de segurança Solução de problemas de estado de rede incompatível Redefinir a senha de proprietário da instância de banco de dados Interrupção ou reinicialização da instância de banco de dados Alterações de parâmetros que não entram em vigor Instância de banco de dados sem espaço de armazenamento Capacidade insuficiente da instância de banco de dados Problemas de memória liberável do RDS Problemas com o MySQL e o MariaDB Não é possível definir o período de retenção de backup como 0

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.

Tópicos

Não é possível conectar-se à instância de banco de dados do Amazon RDS
Problemas de segurança do Amazon RDS
Solução de problemas de estado de rede incompatível
Redefinir a senha de proprietário da instância de banco de dados
Interrupção ou reinicialização da 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
Instância de banco de dados do Amazon RDS ficando sem espaço de armazenamento
Capacidade insuficiente da instância de banco de dados do Amazon RDS
Problemas de memória liberável no Amazon RDS
Problemas no MySQL e MariaDB
Não é possível definir o período de retenção de backup como 0

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:

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 à instância 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 uma instância 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 uma instância de banco de dados em uma VPC.

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.

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.

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 e a senha mestre da AWS para uma conta de usuário. A prática recomendada é usar sua Conta da AWS principal para criar usuários e atribuí-los a contas de usuário de banco de dados. Você também pode usar sua conta principal 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:

Modificar a classe da instância de banco de dados.
Modificar a instância de banco de dados para usar a implantação do cluster de banco de dados multi-AZ.
Substituir um anfitrião devido a um evento de manutenção.
Iniciar uma instância de banco de dados substituta.
Restaurar por meio de um backup de snapshot.
Iniciar uma instância de banco de dados que foi interrompida.

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:

Abra ohttps://console.aws.amazon.com/rds/ e escolhaBancos de dados no painel de navegação.
Escolha a instância de banco de dados que está no estado de rede incompatível e anote o identificador da respectiva instância, o ID da VPC e os IDs de sub-rede da guia Segurança e conexão.
Use a AWS CLI para executar o comando start-db-instance. Especifique o valor --db-instance-identifier.

nota
A execução desse comando quando o banco de dados está no modo incompatível pode causar algum tempo de inatividade.
O comando start-db-instance não resolve esse problema para instâncias de banco de dados do RDS para SQL Server.

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:

VERIFICAÇÃO INTERNA DE RECURSOS: pode haver problemas com os recursos internos.
VERIFICAÇÃO DE DNS: verifique a resolução de DNS e os nomes de host da VPC no console da VPC.
VERIFICAÇÃO DE ENI: a interface de rede elástica (ENI) para o banco de dados talvez não exista.
VERIFICAÇÃO DE GATEWAY: o gateway da Internet para seu banco de dados disponível ao público não está conectado à VPC.
VERIFICAÇÃO DE IP: não há endereços IP gratuitos nas sub-redes.
VERIFICAÇÃO DE GRUPO DE SEGURANÇA: não há grupos de segurança associados ao banco de dados ou os grupos de segurança são inválidos.
VERIFICAÇÃO DE SUB-REDE: não há sub-redes válidas no grupo de sub-redes de banco de dados ou há problemas na sub-rede.
VERIFICAÇÃO DE VPC: a VPC associada ao banco de dados é inválida.

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.

nota

Depois que uma instância entra no estado de rede incompatível, a instância de banco de dados pode não estar acessível para realizar um backup lógico.

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:

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.
Você altera o tipo de armazenamento de Magnetic (Standard) (Magnético (padrão)) para General Purpose (SSD) (Finalidade geral (SSD)) ou Provisioned IOPS (SSD) (IOPS provisionadas (SSD)) ou de Provisioned IOPS (SSD) (IOPS provisionadas (SSD)) ou General Purpose (SSD) (Finalidade geral (SSD)) para Magnetic (Standard) (Magnético (padrão)).

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.

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.

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

Capacidade insuficiente da instância de banco de dados do Amazon RDS

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:

Repita a solicitação com uma classe de instância de banco de dados diferente.
Repita a solicitação com uma zona de disponibilidade diferente.
Repita a solicitação sem especificar uma zona de disponibilidade explícita.

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 Visão geral do monitoramento de métricas no 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 .

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.

Tópicos

Máximo de conexões MySQL e MariaDB
Diagnosticar e resolver o status de parâmetros incompatíveis para um limite de memória
Diagnosticar e resolver atrasos entre réplicas de leitura
Diagnosticar e resolver uma falha de replicação de leitura do MySQL ou MariaDB
Criar triggers com o registro de logs binários habilitado requer o privilégio SUPER
Diagnosticar e resolver falhas de restauração pontual
Erro de replicação interrompida
Falha na criação da réplica de leitura ou interrupção da replicação com o erro fatal 1236

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 .

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 Trabalhar com grupos de parâmetros.

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

A instância de banco de dados foi reiniciada pelo menos três vezes em uma hora ou pelo menos cinco vezes em um dia quando o status da instância de banco de dados era Disponível.
Uma tentativa de reiniciar a instância de banco de dados falha porque uma ação de manutenção ou processo de monitoramento não conseguiu reiniciar a instância de banco de dados.
O uso de memória potencial da instância de banco de dados excedeu 1,2 vez a memória alocada para a respectiva classe de instância de banco de dados.

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:

Valor 1 – a soma dos seguintes parâmetros:
- innodb_additional_mem_pool_size
- innodb_buffer_pool_size
  
  É possível modificar o valor de innodb_buffer_pool_size. No entanto, o valor nem sempre corresponderá ao que você inseriu. Essa incompatibilidade ocorre por vários motivos. Primeiro, se a instância de banco de dados for uma microinstância de banco de dados, substituiremos o valor padrão e o definiremos como 256 MB. Para ter mais informações, consulte Substituir innodb_buffer_pool_size.
  
  Em segundo lugar, garantimos que 500 MB de memória sejam reservados na instância de banco de dados para o gerenciador de host, o mecanismo, o sistema operacional e o kernel.
  
  Por fim, otimizamos innodb_buffer_pool_size dividindo-o em unidades. O gerenciador de host arredonda para baixo para o múltiplo mais próximo dessas unidades. As unidades são calculadas multiplicando-se innodb_buffer_pool_chunk_size por innodb_buffer_pool_instances. Para ter mais informações, consulte Configuring InnoDB Buffer Pool Size, na documentação do MySQL.
  
  O padrão para innodb_buffer_pool_instances é 8, a menos que innodb_buffer_pool_size seja menor que 1 GB. Se innodb_buffer_pool_size for menor que 1 GB, o padrão para innodb_buffer_pool_instances será 1. O padrão para innodb_buffer_pool_chunk_size é 128 MB.
- innodb_log_buffer_size
- key_buffer_size
- query_cache_size (MySQL versão 5.7 somente)
- tmp_table_size
Valor 2 – o max_connections parâmetro multiplicado pela soma dos seguintes parâmetros:
- binlog_cache_size
- join_buffer_size
- read_buffer_size
- read_rnd_buffer_size
- sort_buffer_size
- thread_stack
Valor 3 – se o parâmetro performance_schema estiver habilitado, multiplique o parâmetro max_connections por 429498.

Se o parâmetro performance_schema estiver desabilitado, esse valor será zero.

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:

Ajuste os parâmetros de memória no grupo de parâmetros de banco de dados associado à instância de banco de dados. Faça isso para que o uso potencial de memória seja menor que 1,2 vezes a memória alocada para a respectiva classe de instância de banco de dados.

Para obter informações sobre como configurar parâmetros, consulte Modificar parâmetros em um grupo de parâmetros de banco de dados.
Reinicie a instância de banco de dados.

Para obter informações sobre como configurar parâmetros, consulte Iniciar uma instância de banco de dados do Amazon RDS que foi anteriormente interrompida.

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.

nota

As versões anteriores do MariaDB e MySQL usavam SHOW SLAVE STATUS em vez de SHOW REPLICA STATUS. Se você estiver usando uma versão do MariaDB anterior à 10.5 ou uma versão do MySQL anterior à 8.0.23, use SHOW SLAVE STATUS.

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:

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 ou MariaDB. 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 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:

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 MySQL ou MariaDB 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ários, você poderá alterar a posição de reprodução da réplica com o comando mysql_rds_next_master_log. Sua instância de banco de dados MySQL ou MariaDB deve estar executando uma versão que ofereça suporte ao comando mysql_rds_next_master_log para alterar a posição de reprodução da réplica. Para obter informações sobre versões, consulte mysql.rds_next_master_log.
Você pode encontrar um problema temporário de performance devido à alta carga de DML. Se sim, você pode definir o parâmetro innodb_flush_log_at_trx_commit como 2 no grupo de parâmetros de 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. Se você fizer isso, 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 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.

Para criar um novo grupo de parâmetros de forma a permitir triggers com o registro em logs binários habilitado usando a CLI

Crie um novo grupo de parâmetros.

Para Linux, macOS ou Unix:


aws rds create-db-parameter-group \
    --db-parameter-group-name allow-triggers \
    --db-parameter-group-family mysql8.0 \
    --description "parameter group allowing triggers"

Para Windows:


aws rds create-db-parameter-group ^
    --db-parameter-group-name allow-triggers ^
    --db-parameter-group-family mysql8.0 ^
    --description "parameter group allowing triggers"

Modifique o grupo de parâmetros de banco de dados para permitir triggers.

Para Linux, macOS ou Unix:


aws rds modify-db-parameter-group \
    --db-parameter-group-name allow-triggers \
    --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

Para Windows:


aws rds modify-db-parameter-group ^
    --db-parameter-group-name allow-triggers ^
    --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

Modifique sua instância de banco de dados para usar o novo grupo de parâmetros de banco de dados.

Para Linux, macOS ou Unix:


aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --db-parameter-group-name allow-triggers \
    --apply-immediately

Para Windows:


aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --db-parameter-group-name allow-triggers ^
    --apply-immediately

Para que as alterações entrem em vigor, reinicialize manualmente a instância de banco de dados.
```
aws rds reboot-db-instance --db-instance-identifier mydbinstance
```

Diagnosticar e resolver falhas de restauração pontual

Restauração de uma instância de banco de dados que inclui 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 em sua instância de banco de dados do MySQL ou do MariaDB, poderá minimizar a possibilidade de uma falha de PITR. Para fazer isso, realize 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.

Restauração de uma instância de banco de dados que inclui 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 Restauração de uma instância de banco de dados para um tempo especificado.

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:

É possível criar uma réplica de leitura para a instância de banco de dados.
A replicação falha com fatal error 1236.

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:

sync_binlog = 1
innodb_support_xa = 1
innodb_flush_log_at_trx_commit = 1

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.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Cotas e restrições

Referência da API do Amazon RDS

Solução de problemas para o Amazon RDS

Tópicos

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

nota

nota

Como configurar um gateway da Internet para uma sub-rede

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

nota

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

Problemas de segurança do Amazon RDS

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

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

Causas

Resolução

Usar o comando start-db-instance

nota

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

nota

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

Interrupção ou reinicialização da 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

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

Capacidade insuficiente da instância de banco de dados do Amazon RDS

Problemas de memória liberável no Amazon RDS

Problemas no MySQL e MariaDB

Tópicos

Máximo de conexões MySQL e MariaDB

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

Diagnosticar e resolver atrasos entre réplicas de leitura

nota

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

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

Para criar um novo grupo de parâmetros de forma a permitir triggers com o registro em logs binários habilitado usando a CLI

Diagnosticar e resolver falhas de restauração pontual

Erro de replicação interrompida

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

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