Implantações de instâncias de banco de dados multi-AZ - Amazon Relational Database Service

Implantações de instâncias de banco de dados multi-AZ

O Amazon RDS oferece alta disponibilidade e suporte para failover em instâncias de banco de dados utilizando implantações multi-AZ com uma única instâncias de banco de dados em espera. Esse tipo de implantação é chamado de implantação de instância de banco de dados multi-AZ. O Amazon RDS usa várias tecnologias diferentes para fornecer esse suporte para failover. Implantações multi-AZ para instâncias de banco de dados MariaDB, MySQL, Oracle e PostgreSQL utilizam a tecnologia de failover da Amazon. Instâncias de banco de dados do Microsoft SQL Server utilizam o SQL Server Database Mirroring (DBM) ou grupos de disponibilidade (AGs) Always On. Para obter informações sobre o suporte à versão do SQL Server para multi-AZ, consulte Implantações multi-AZ para o Amazon RDS for Microsoft SQL Server.

Em uma implantação de instância de banco de dados multi-AZ, o Amazon RDS provisiona e mantém automaticamente uma réplica em espera síncrona em outra zona de disponibilidade. A instância de banco de dados primária é replicada simultaneamente através de zonas de disponibilidade para uma réplica em espera, a fim de proporcionar a redundância de dados 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. Também pode ajudar a proteger bancos de dados contra falhas na instância de banco de dados e interrupção da zona de disponibilidade. Para obter mais informações sobre zonas de disponibilidade, consulte Regiões, zonas de disponibilidade e Local Zones.

nota

A opção de alta disponibilidade não é uma solução de escalabilidade para cenários somente leitura. Não é possível utilizar uma réplica em espera para servir tráfego de leitura. Para servir tráfego somente leitura, utilize um cluster de banco de dados multi-AZ ou uma réplica de leitura. Para obter mais informações sobre clusters de banco de dados multi-AZ, consulte Implantações de clusters de banco de dados multi-AZ. Para obter mais informações sobre réplicas de leitura, consulte Como trabalhar com réplicas de leitura.


			Cenário de alta disponibilidade

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

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 que usam implantações de instância de banco de dados multi-AZ podem ter maior latência de gravação e confirmação em comparação com uma implantação single-AZ. Isso pode acontecer devido à replicação de dados síncrona que ocorre. É 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 uma aplicação de produção que exija performance de E/S rápida e consistente, recomendamos o armazenamento de IOPS provisionadas (operações de entrada/saída por segundo). Para obter mais informações sobre classes de instância de banco de dados, consulte Classes de instância de banco de dados .

Modificar uma instância de banco de dados para ser uma implantação de instância de banco de dados 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 de instância de banco de dados multi-AZ (para mecanismos diferentes do Amazon Aurora), o Amazon RDS realizará várias ações:

  1. Gera um snapshot dos volumes do Amazon Elastic Block Store (EBS) da instância de banco de dados primária.

  2. Cria volumes para a réplica em espera baseados no snapshot. Esses volumes são inicializados em segundo plano e a performance máxima do volume é alcançada depois que os dados são totalmente inicializados.

  3. Ativa a replicação síncrona no bloco entre os volumes das réplicas primária e em espera.

Importante

O uso de um snapshot para criar a instância em espera evita tempo de inatividade ao converter da implantação single-AZ em multi-AZ. No entanto, você pode observar um impacto na performance durante e após a conversão em multi-AZ. Esse impacto pode ser significativo para workloads sensíveis à latência de gravação.

Embora esse recurso permita que grandes volumes sejam restaurados rapidamente de snapshots, ele pode causar um aumento significativo na latência das operações de E/S devido à replicação síncrona. Essa latência pode afetar a performance do seu banco de dados. Uma prática altamente recomendada é não realizar a conversão multi-AZ em uma instância de banco de dados de produção.

Para evitar o impacto na performance da instância de banco de dados que atualmente atende à workload confidencial, crie uma réplica de leitura e ative os backups nela. Converta a réplica de leitura em multi-AZ e execute consultas que carregam os dados nos volumes da réplica de leitura (em ambas as AZs). Depois, promova a réplica de leitura para que seja a instância de banco de dados primária. Para obter mais informações, consulteComo trabalhar com réplicas de leitura

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. Após a conclusão da modificação, o Amazon RDS aciona um evento (RDS-EVENT-0025) que indica o término do processo. É possível monitorar eventos do Amazon RDS. Para obter mais informações sobre eventos do , consulte Trabalhar com a notificação de eventos do Amazon RDS.

Processo de failover para Amazon RDS

Se uma interrupção planejada ou não planejada da sua instância de banco de dados for o resultado de um defeito de infraestrutura, o Amazon RDS alternará automaticamente para uma réplica em espera em outra zona de disponibilidade se você tiver ativado 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 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. 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 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 obter 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 obter 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 obter mais informações sobre essas recomendações, consulte Visão geral do monitoramento de métricas no 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 obter 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 obter 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.

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 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");