Alta disponibilidade (Multi-AZ) para Amazon RDS - Amazon Relational Database Service

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Alta disponibilidade (Multi-AZ) para Amazon RDS

O Amazon RDS oferece alta disponibilidade e suporte a failover para instâncias de banco de dados usando implantações Multi-AZ. O Amazon RDS usa várias tecnologias diferentes para fornecer suporte a failover. As implantações Multi-AZ para instâncias de banco de dados MariaDB, MySQL, Oracle e PostgreSQL usam a tecnologia de failover da Amazon. As instâncias de banco de dados do SQL Server usam o SQL Server Database Mirroring (DBM) ou Grupos de disponibilidade (AGs) Always On.

Em uma implantação Multi-AZ, o Amazon RDS automaticamente provisiona e mantém uma réplica em espera síncrona em outra Zona de disponibilidade. A instância de banco de dados principal é replicada simultaneamente através de Zonas de disponibilidade para uma réplica em espera, a fim de proporcionar a redundância de dados, eliminar congelamentos de E/S e minimizar os picos de latência durante os backups do sistema. Executar uma instância de banco de dados com alta disponibilidade pode aumentar a disponibilidade durante a manutenção planejada do sistema além de ajudar a proteger seus bancos de dados contra falhas na instância do banco de dados e interrupção na zona de disponibilidade. Para obter mais informações sobre zonas de disponibilidade, consulte Regiões, zonas de disponibilidade e zonas locais .

nota

O recurso de alta disponibilidade não é uma solução de escalabilidade para cenários somente leitura. Você não pode usar uma réplica em espera para atender ao tráfego de leitura. Para tráfego somente leitura, use uma réplica de leitura. Para obter mais informações, consulte Como trabalhar com réplicas de leitura.


			Cenário de alta disponibilidade

Com o console do RDS, você pode criar uma implantação Multi-AZ. Basta especificar Multi-AZ ao criar uma instância de banco de dados. Você pode usar o console para converter instâncias de banco de dados existentes em implantações Multi-AZ modificando a instância de banco de dados e especificando a opção Multi-AZ. Você também pode especificar uma implantação Multi-AZ com a AWS CLI ou a API do Amazon RDS. Use o comando create-db-instance ou modify-db-instance da CLI, ou a operação CreateDBInstance ou ModifyDBInstance da API.

O console do RDS mostra a zona de disponibilidade da réplica em espera (chamada AZ secundária). Você também pode usar o comando describe-db-instances da CLI ou a operação DescribeDBInstances da API para localizar a AZ secundária.

Instâncias de banco de dados com implantações Multi-AZ podem ter mais gravação e comprometer a latência se comparadas a uma implantação Single-AZ, devido a replicação síncrona de dados. É possível ter uma alteração na latência se sua implantação falhar na réplica em espera, ainda que o AWS seja desenvolvido com conectividade de rede de baixa latência entre zonas de disponibilidade. Para cargas de trabalho de produção, recomendamos o uso de IOPS provisionadas e classes de instância de banco de dados otimizadas para IOPS provisionadas para um desempenho rápido e consistente. Para mais informações sobre classes de instância de banco de dados, consulte Classes da instância de banco de dados.

Modificar uma instância de banco de dados para ser uma implantação Multi-AZ

Se você tiver uma instância de banco de dados em uma implantação Single-AZ e modificá-la para uma implantação Multi-AZ (para mecanismos diferentes do Amazon Aurora), o Amazon RDS passará por várias etapas. Primeiro, o Amazon RDS cria um snapshot da implantação da instância de banco de dados primária e, em seguida, restaura o snapshot em outra zona de disponibilidade. O Amazon RDS configura a replicação síncrona entre sua instância de banco de dados primária e a nova instância.

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

Importante

Essa ação evita tempo de inatividade quando você converte da implantação Single-AZ em Multi-AZ. No entanto, você pode observar um impacto no desempenho durante e após a conversão em Multi-AZ. Esse impacto pode ser significativo para grandes instâncias de banco de dados com uso intensivo de gravação.

Para habilitar o Multi-AZ para uma instância de banco de dados, o RDS tira um snapshot do volume do EBS da instância de banco de dados principal e o restaura na réplica em espera recém-criada e, por fim, sincroniza ambos os volumes. Os novos volumes criados com base em snapshots existentes do EBS são carregados como processo de fundo. Esse recurso permite que grandes volumes sejam restaurados rapidamente a partir de um snapshot, mas há a possibilidade de latência adicional durante e após a conclusão da modificação. Para obter mais informações, consulte Restaurar um volume do Amazon EBS a partir de um snapshot na documentação do Amazon EC2.

Após a conclusão da modificação, o Amazon RDS aciona um evento (RDS-EVENT-0025) que indica o término do processo. Você pode monitorar os eventos do Amazon RDS. Para obter mais informações sobre eventos, consulte Usar a notificação de evento do Amazon RDS.

Processo de failover para Amazon RDS

No caso de uma interrupção de planejada ou não planejada de sua instância de banco de dados, o Amazon RDS comuta automaticamente para uma réplica em espera em outra zona de disponibilidade se você tiver habilitado a implantação Multi-AZ. 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 principal do banco de dados 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. Para obter 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 principal do banco de dados comuta automaticamente para a réplica em espera se ocorrer qualquer uma das condições a seguir:

  • Interrupção na zona de disponibilidade;

  • Falha na instância principal do banco de dados;

  • Alteração no tipo de servidor da instância do banco de dados;

  • Correção de software no sistema operacional da instância do banco de dados;

  • Um failover manual da instância de banco de dados foi iniciado usando a Reboot with failover (Reinicialização com failover).

Há várias maneiras de determinar se houve um failover na sua instância de banco de dados Multi-AZ:

  • As assinaturas de evento de banco de dados podem ser configuradas para notificá-lo por e-mail ou SMS caso um failover tenha sido iniciado. Para obter mais informações sobre eventos, consulte Usar a notificação de evento do Amazon RDS.

  • É possível visualizar seus eventos de banco de dados com o console do Amazon RDS ou com as operações de API.

  • Também é possível visualizar o estado atual da implantação Multi-AZ com o console do Amazon RDS e com as operações da 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 Melhores práticas 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 para um período especificado, conhecido como Time-To-Live (TTL – Tempo de duração).

Como recursos da 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 da AWS mudar enquanto o aplicativo 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.

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 obter mais informações sobre gerenciadores de segurança no Oracle, consulte 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");