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, PostgreSQL e RDS Custom para SQL Server usam 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. Para ter informações sobre como trabalhar com o RDS Custom para multi-AZ, consulte Gerenciar uma implantação multi-AZ para o RDS Custom para 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 ter 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 ter mais informações sobre clusters de banco de dados multi-AZ, consulte Implantações de clusters de banco de dados multi-AZ. Para ter mais informações sobre réplicas de leitura, consulte Trabalhar com réplicas de leitura de instância de banco de dados.
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 ter mais informações sobre classes de instância de banco de dados, consulte Classes de instância de banco de dados do .
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:
-
Gera um snapshot dos volumes do Amazon Elastic Block Store (EBS) da instância de banco de dados primária.
-
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.
-
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 ter mais informações, consulteTrabalhar com réplicas de leitura de instância de banco de dados
Há duas formas de modificar uma instância de banco de dados para ser uma implantação de instância de banco de dados multi-AZ:
Tópicos
Converter para uma implantação de instância de banco de dados multi-AZ com o console do RDS
É possível usar o console do RDS para converter uma instância de banco de dados para uma implantação de instância de banco de dados multi-AZ.
É possível usar o console somente para concluir a conversão. Para usar o AWS CLI ou a API do RDS, siga as instruções em Modificar uma instância de banco de dados para ser uma implantação de instância de banco de dados multi-AZ.
Como converter para uma implantação de instância de banco de dados multi-AZ com o console do RDS
Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/
. -
No painel de navegação, escolha Databases (Bancos de dados) e a instância de banco de dados que você deseja modificar.
-
Em Actions (Ações), selecione Convert to Multi-AZ deployment (Converter para implantação multi-AZ).
-
Na página de confirmação, selecione Apply Immediately (Aplicar imediatamente) para aplicar as alterações imediatamente. A escolha dessa opção não causa tempo de inatividade, mas pode causar um possível impacto na performance. Você também pode optar por aplicar a atualização durante a próxima janela de manutenção. Para ter mais informações, consulte Configuração de agendamento de modificações.
-
Selecione Convert to Multi-AZ (Converter em multi-AZ).
Modificar uma instância de banco de dados para ser uma implantação de instância de banco de dados multi-AZ
Você também pode modificar uma instância de banco de dados para ser uma implantação de instância de banco de dados multiAZ das seguintes formas:
-
Usando o console do RDS, modifique a instância de banco de dados e defina Multi-AZ deployment (Implantação Multi-AZ) como Yes (Sim).
-
Usando o AWS CLI, chame o comando modify-db-instance e defina a opção
--multi-az. -
Usando a API do RDS, chame a operação ModifyDBInstance e defina o parâmetro
MultiAZcomotrue.
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. 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 ter 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 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 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 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
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.ttlno arquivo$JAVA_HOME/jre/lib/security/java.security.networkaddress.cache.ttl=60 -
Para definir a propriedade localmente somente para seu aplicativo, defina
networkaddress.cache.ttlno código de inicialização do aplicativo antes de quaisquer conexões de rede serem estabelecidas.java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
