Por que as conexões de banco de dados caíram na minha instância de banco de dados RDS?

Resolução

As conexões de banco de dados do Amazon RDS podem cair por vários motivos. Para entender a causa da queda em suas conexões de banco de dados, determine se as conexões de banco de dados caíram durante ou fora da janela de manutenção da sua instância de banco de dados do RDS.

Se as conexões de banco de dados caírem durante a janela de manutenção

Durante a janela de manutenção da instância de banco de dados, a AWS realiza atividades de manutenção que podem levar à queda de conexões de banco de dados.

Atualização automática de versão secundária (se habilitada no Amazon RDS)

Quando o Amazon RDS designa uma nova versão secundária preferencial do mecanismo e a instância de banco de dados está executando uma versão anterior, o Amazon RDS executa uma atualização durante a janela de manutenção programada se o recursoAtualização automática de versão secundária estiver habilitado. Isso pode levar à queda de conexões de banco de dados durante a atualização da versão secundária, pois todas as atualizações de versão no nível do mecanismo envolve tempo de inatividade do RDS.

Manutenção de hardware

O Amazon RDS programa a manutenção de hardware quando os hosts subjacentes das instâncias de banco de dados estão sendo executados em hardware degradado. A manutenção de hardware é executada durante a janela de manutenção configurada para as instâncias de banco de dados. Antes da manutenção ser agendada, você recebe uma notificação por e-mail sobre as janelas de manutenção de hardware programadas que inclui o horário da manutenção e as zonas de disponibilidade afetadas.

Manutenção do sistema operacional

O Amazon RDS realiza periodicamente atualizações do sistema operacional subjacente durante a janela de manutenção configurada para a instância de banco de dados. Se a atualização do sistema operacional envolver tempo de inatividade, o Amazon RDS agendará a manutenção para a próxima janela de manutenção. Se a atualização do sistema operacional não exigir manutenção, é possível adiar a janela de manutenção ajustando a janela de manutenção de sua preferência. Se a manutenção for necessária, a atualização do sistema operacional não poderá ser adiada e a atualização será aplicada durante a janela de manutenção subsequente.

Modificações realizadas no Amazon RDS selecionando “Aplicar na próxima janela de manutenção”

Ao realizar qualquer modificação na configuração do RDS, é possível escolher aplicar as modificações imediatamente ou na próxima janela de manutenção. Se as modificações forem realizadas na próxima janela de manutenção, não haverá tempo de inatividade imediato. As modificações seguintes podem causar tempo de inatividade quando aplicadas durante a próxima janela de manutenção:

• Renomeação de identificadores de instância de banco
• Modificação de classes de instância de banco de dados
• Alteração de períodos de retenção de backup
• Modificação de portas de banco de dados
• Alteração da versão do mecanismo de banco de dados
• Anexação de um novo grupo de sub-redes

Consulte as informações de configurações de instâncias de banco de dados para entender as configurações detalhadas disponíveis para modificação, e o impacto e o tempo de inatividade das instâncias de banco de dados.

Se as conexões de banco de dados caírem fora da janela de manutenção

As conexões de banco de dados podem cair se atingirem o tempo limite do cliente/servidor.

Parâmetros de tempo limite do cliente configurados no lado do aplicativo

Os parâmetros de tempo limite do cliente configurados no lado do aplicativo podem levar à queda das conexões de banco de dados. Se o tempo de processamento de uma consulta for muito longo, a sessão poderá ser encerrada incorretamente pelo cliente. Para resolver esse problema, aumente a configuração de tempo limite do cliente.

Parâmetros de tempo limite do servidor configurados no grupo de parâmetros personalizado anexado ao Amazon RDS

TCP keepalives definidos agressivamente levam a tempos limite de conexão do cliente. Os tempos limite ocorrem quando o cliente está ocioso pela quantidade de tempo definida em tcp_keepalives_idle e pelo número de mensagens definidas em tcp_keepalives_count. Um tempo limite também pode ocorrer quando uma conexão está aguardando uma resposta do servidor enquanto consultas de longa execução estão sendo executadas na instância do banco de dados.

Se idle_in_transaction_session_timeout estiver definido com um valor inferior às 24 horas padrão, qualquer sessão que tenha ficado ociosa por mais tempo do que o valor configurado será encerrada. Se você definir esse valor agressivamente, mesmo que as consultas em execução exijam mais tempo para obter uma resposta do servidor, a conexão será encerrada quando a sessão estiver ociosa por mais tempo do que o valor de tempo limite configurado.

Reinicialização/failover do banco de dados não planejada

Um problema transitório com o hardware subjacente pode levar à perda de comunicação com a instância do banco de dados. Um problema de hardware pode iniciar o failover em uma implantação multi-AZ e a recuperação em uma implantação mono-AZ substituindo o host subjacente. Esse problema pode ter deixado a instância do bando de dados não íntegra, porque o sistema de monitoramento do RDS não pôde se comunicar com a instância do RDS para realizar as verificações de integridade.

Um problema de rede transitório afeta o host subjacente da instância do banco de dados. O sistema de monitoramento interno detecta esse problema e inicia proativamente a recuperação para uma implantação mono-AZ e o failover para implantações multi-AZ.

A instância do banco de dados não responde quando uma alta carga de banco de dados leva a uma crise de memória no banco de dados que impede que o sistema de monitoramento do RDS entre em contato com o host subjacente. Para evitar o failover e a reinicialização das instâncias do banco de dados devido à sobrecarga do banco de dados, configure os parâmetros de memória na instância de banco de dados adequadamente.

Um problema transitório com o subsistema de armazenamento subjacente pode levar à latência elevada para um volume do Amazon Elastic Block Store (Amazon EBS), que é identificado por um sistema de monitoramento interno. Como medida proativa, o sistema de monitoramento inicia a recuperação para uma implantação mono-AZ. Em uma implantação multi-AZ, é realizado um failover para secundário.

---

Informações relacionadas

Como minimizo o tempo de inatividade durante a manutenção obrigatória do Amazon RDS?

Trabalhar com atualizações do sistema operacional

Como resolver problemas ao conectar à minha instância de banco de dados do Amazon RDS?

Como fazer análise de causa-raiz para um failover multi-AZ e reinicializar a instância do Amazon RDS?