Fazer failover de uma instância de banco de dados multi-AZ para o Amazon RDS - Amazon Relational Database Service
Definir o JVM TTL para pesquisas de nome DNS

Fazer failover de uma instância de banco de dados multi-AZ para o Amazon RDS

Se uma interrupção planejada ou não planejada da instância de banco de dados multi-AZ decorrer de um defeito de infraestrutura, o Amazon RDS alternará automaticamente para uma réplica em espera em outra zona de disponibilidade.

O tempo de conclusão do failover depende da atividade do banco de dados e de outras condições no momento em que a instância de banco de dados primária se tornou indisponível. Em geral, os tempos de failover variam de 60 a 120 segundos. No entanto, transações grandes ou um processo de recuperação longo podem aumentar o tempo de failover. Quando o failover é concluído, o console do RDS pode levar mais um tempo para refletir a nova zona de disponibilidade.

nota

Você pode forçar um failover manualmente ao reinicializar uma instância de banco de dados multi-AZ. Para ter mais informações, consulte Reinicializar uma instância de banco de dados .

O Amazon RDS processa os failovers automaticamente para que você possa retomar as operações de banco de dados o mais rápido possível e sem intervenção administrativa. A instância de banco de dados principal muda automaticamente para a réplica em espera se alguma das condições descritas na tabela a seguir ocorrer. Os motivos do failover podem ser visualizados no log de eventos.

Motivo do failover Descrição
O sistema operacional subjacente à instância de banco de dados do RDS está sendo corrigido em uma operação offline.

Um failover foi acionado durante a janela de manutenção para um patch de SO ou uma atualização de segurança.

Para ter mais informações, consulte Manutenção de uma instância de banco de dados.
O host principal da instância RDS multi-AZ não está íntegro. A implantação de instância de banco de dados multi-AZ detectou uma instância de banco de dados primária danificada e executou failover.
O host principal da instância RDS multi-AZ está inacessível devido à perda de conectividade de rede.

O monitoramento do RDS detectou uma falha de alcançabilidade de rede na instância de banco de dados principal e acionou um failover.
A instância do RDS foi modificada pelo cliente.

Uma modificação da instância de banco de dados do RDS acionou um failover.

Para ter mais informações, consulte Modificar uma instância de banco de dados do Amazon RDS.
A instância primária do RDS multi-AZ está ocupada e não responde.

A instância de banco de dados principal não responde. Recomendamos fazer o seguinte:

Para ter mais informações sobre essas recomendações, consulte Ferramentas de monitoramento do Amazon RDS e Práticas recomendadas do Amazon RDS.
O volume de armazenamento subjacente ao host principal da instância multi-AZ do RDS sofreu uma falha. A implantação de instância de banco de dados multi-AZ detectou um problema de armazenamento na instância de banco de dados primária e executou o failover.
O usuário solicitou um failover da instância de banco de dados.

Você reinicializou a instância de banco de dados e escolheu Reinicializar com failover.

Para ter mais informações, consulteReinicializar uma instância de banco de dados

Para determinar se ocorreu failover na instância de banco de dados multi-AZ, faça o seguinte:

  • Configure assinaturas de eventos de banco de dados para notificar você por e-mail ou SMS de que um failover foi iniciado. Para ter mais informações sobre eventos do , consulte Trabalhar com a notificação de eventos do Amazon RDS.

  • Visualize seus eventos de banco de dados usando o console do RDS ou operações de API.

  • Visualize o estado atual da implantação de instância de banco de dados multi-AZ utilizando o console RDS ou operações de API.

Para obter informações sobre como você pode responder aos failovers, reduzir o tempo de recuperação e outras melhores práticas para o Amazon RDS, consulte Práticas recomendadas do Amazon RDS.

Definir o JVM TTL para pesquisas de nome DNS

O mecanismo de failover modifica automaticamente o registro de Domain Name System (DNS) da instância de banco de dados para apontar para a instância de banco de dados em espera. Como resultado, você precisará restabelecer todas as conexões existentes para sua instância de banco de dados. Em um ambiente de máquina virtual Java (JVM), devido à forma como o mecanismo de cache DNS do Java funciona, talvez seja necessário reconfigurar as configurações da JVM.

A JVM armazena em cache pesquisas de nome DNS. Ao resolver um nome de host para um endereço IP, a JVM armazena em cache o endereço IP por um período especificado, conhecido como Time-To-Live (TTL – Vida útil).

Como os recursos AWS usam entradas de nome DNS que acabam mudando, recomendamos configurar a JVM com um valor TTL de até 60 segundos. Isso garante que quando o endereço IP de um recurso mudar, seu aplicativo poderá receber e usar o novo endereço IP do recurso, consultando novamente o DNS.

Em algumas configurações do Java, o TTL padrão da JVM é definido de maneira que jamais atualiza entradas DNS até a JVM ser reiniciada. Por isso, se o endereço IP de um recurso AWS mudar enquanto a aplicação ainda estiver em execução, não será possível usar esse recurso até você reiniciar manualmente a JVM e as informações de IP armazenadas em cache serem atualizadas. Nesse caso, é crucial definir o TTL da JVM, de forma que ele atualize periodicamente as informações de IP armazenadas em cache.

Você pode obter o TTL padrão da JVM recuperando o valor da propriedade networkaddress.cache.ttl:

String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
nota

O TTL padrão pode variar de acordo com a versão da JVM e a possibilidade de um gerenciador de segurança estar instalado. Muitas JVMs oferecem um TTL padrão menor que 60 segundos. Se estiver usando uma JVM como essa, e não um gerenciador de segurança, será possível ignorar o restante deste tópico. Para ter mais informações sobre gerenciadores de segurança no Oracle, consulte The security manager (O gerenciador de segurança) na documentação do Oracle.

Para modificar o TTL da JVM, defina o valor da propriedade networkaddress.cache.ttl. Use um dos seguintes métodos, dependendo das necessidades:

  • Para definir o valor da propriedade globalmente para todos os aplicativos que usam a JVM, defina networkaddress.cache.ttl no arquivo $JAVA_HOME/jre/lib/security/java.security.

    networkaddress.cache.ttl=60

  • Para definir a propriedade localmente somente para seu aplicativo, defina networkaddress.cache.ttl no código de inicialização do aplicativo antes de quaisquer conexões de rede serem estabelecidas.

    java.security.Security.setProperty("networkaddress.cache.ttl" , "60");