Alta disponibilidade do Amazon Aurora
A arquitetura do Amazon Aurora envolve separação entre armazenamento e computação. O Aurora contém alguns recursos de alta disponibilidade que se aplicam aos dados no cluster de banco de dados. Os dados permanecem seguros, mesmo que algumas ou todas as instâncias de banco de dados no cluster fiquem indisponíveis. Outros recursos de alta disponibilidade se aplicam às instâncias de banco de dados. Esses recursos ajudam a garantir que uma ou mais instâncias de banco de dados estejam prontas para lidar com solicitações de banco de dados do aplicativo.
Tópicos
Alta disponibilidade de dados do Aurora
O Aurora armazena cópias dos dados em um cluster de banco de dados em várias zonas de disponibilidade em uma única Região da AWS. O Aurora armazena essas cópia independentemente de as instâncias no cluster de banco de dados abrangerem várias zonas de disponibilidade. Para ter mais informações sobre o Aurora, consulte Como gerenciar um cluster de banco de dados do Amazon Aurora.
Quando os dados são gravados na instância principal de banco de dados, o Aurora replica os dados de forma síncrona nas zonas de disponibilidade para seis nós de armazenamento associados ao volume do cluster. Isso fornece redundância de dados, elimina congelamentos de E/S e minimiza picos de latência durante 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 e ajudar a proteger os bancos de dados contra falhas e interrupções da zona de disponibilidade. Para ter mais informações sobre zonas de disponibilidade, consulte Regiões e zonas de disponibilidade.
Alta disponibilidade de instâncias de banco de dados do Aurora
Depois de criar a instância primária (gravador), você poderá criar até 15 réplicas somente leitura do Aurora. As réplicas do Aurora também são conhecidas como instâncias de leitor. As réplicas do Aurora usam replicação assíncrona para permitir alta disponibilidade sem afetar o desempenho da instância primária.
Durante as operações diárias, é possível descarregar parte do trabalho para aplicativos com uso intensivo de leitura usando as instâncias de leitor para processar consultas SELECT. Quando um problema afeta a instância primária, uma dessas instâncias de leitor assume como instância primária. Esse mecanismo é conhecido como failover. Muitos recursos do Aurora se aplicam ao mecanismo de failover. Por exemplo, o Aurora detecta problemas de banco de dados e ativa o mecanismo de failover automaticamente, quando necessário. O Aurora também tem recursos que reduzem o tempo de conclusão do failover. Isso minimiza o tempo em que o banco de dados não está disponível para gravação durante um failover.
O Aurora foi projetado para se recuperar o mais rápido possível, e o caminho mais rápido para a recuperação geralmente é reiniciar ou fazer failover para a mesma instância de banco de dados. A reinicialização é mais rápida e envolve menos sobrecarga do que o failover.
Para usar uma string de conexão que permanece a mesma mesmo quando um failover promove uma nova instância primária, conecte-se ao endpoint do cluster. O endpoint do cluster sempre representa a instância primária atual no cluster. Para ter mais informações sobre o endpoint do cluster, consulte Conexões de endpoints do Amazon Aurora.
dica
Em cada Região da AWS, as zonas de disponibilidade representam locais distintos entre si para fornecer isolamento em caso de interrupções. Recomendamos distribuir a instância primária e as instâncias de leitor no cluster de banco de dados em várias AZs para melhorar a disponibilidade do cluster de banco de dados. Dessa forma, um problema que afeta uma AZ inteira não causa uma interrupção para o cluster.
É possível configurar um cluster de banco de dados multi-AZ fazendo uma escolha simples ao criar o cluster. Você pode usar o AWS Management Console, a AWS CLI ou a API do Amazon RDS. Também é possível converter um cluster de banco de dados existente do Aurora em um cluster de banco de dados multi-AZ adicionando uma nova instância de banco de dados de leitor e especificando uma AZ diferente.
Alta disponibilidade entre as regiões da AWS com bancos de dados globais do Aurora
Para obter alta disponibilidade em várias Regiões da AWS, é possível configurar bancos de dados globais do Aurora. Cada banco de dados global do Aurora abrange várias Regiões da AWS, permitindo leituras globais de baixa latência e recuperação de desastres decorrentes de interrupções em uma Região da AWS. O Aurora replica de forma assíncrona todos os dados e atualizações da Região da AWS primária para cada uma das regiões secundárias. Para ter mais informações, consulte Usar o Amazon Aurora Global Database.
Tolerância a falhas para um cluster de banco de dados do Aurora
Um cluster de banco de dados do Aurora é tolerante a falhas por concepção. O volume do cluster abrange várias zonas de disponibilidade em uma única Região da AWS e cada zona de disponibilidade contém uma cópia dos dados de volume do cluster. Esta funcionalidade significa que seu cluster de banco de dados pode tolerar falhas de uma Zona de disponibilidade sem perder dados, apenas uma breve interrupção do serviço.
Se a instância primária em um cluster de banco de dados falhar, o Aurora fará failover automaticamente para uma nova instância primária de uma das duas seguintes maneiras:
-
Ao promover uma réplica do Aurora existente para a nova instância primária
-
Ao criar uma nova instância primária
Se o cluster de banco de dados tiver uma ou mais réplicas do Aurora, uma réplica do Aurora será promovida à instância primária durante um evento de falha. Um evento de falha resulta em uma breve interrupção, durante a qual as operações de leitura e gravação falham com uma exceção. No entanto, o serviço é restaurado normalmente em menos de 60 segundos e muitas vezes em menos de 30 segundos. Para aumentar a disponibilidade do seu cluster de banco de dados, recomendamos que você crie pelo menos uma ou mais réplicas do Aurora em duas ou mais Zonas de disponibilidade diferentes.
dica
No Aurora MySQL, você pode melhorar a disponibilidade durante um failover com mais de uma instância de banco de dados de leitor em um cluster. No Aurora MySQL, o Aurora reinicia somente a instância de banco de dados do gravador e a instância do leitor que é destino de failover. Outras instâncias do leitor no cluster permanecem disponíveis durante um failover para continuar processando consultas por meio de conexões com o endpoint do leitor.
Você também pode melhorar a disponibilidade durante um failover usando o proxy do RDS com o seu cluster de banco de dados do Aurora. Para ter mais informações, consulte Alta disponibilidade com o Amazon RDS Proxy.
Você pode personalizar a ordem em que suas réplicas do Aurora são promovidas à instância primária após uma falha, atribuindo uma prioridade a cada réplica. As prioridades variam de 0, para a prioridade mais alta, a 15, para a prioridade mais baixa. Se a instância primária falhar, o Amazon RDS promoverá a réplica do Aurora com a maior prioridade à nova instância primária. É possível modificar a prioridade de uma réplica do Aurora a qualquer momento. Modificar a prioridade não desencadeia um failover.
A mesma prioridade pode ser compartilhada por mais de uma réplica do Aurora, resultando em níveis de promoção. Se duas ou mais réplicas do Aurora compartilharem a mesma prioridade, o Amazon RDS promoverá a réplica que for maior. Se duas ou mais réplicas do Aurora compartilharem a mesma prioridade e o mesmo tamanho, o Amazon RDS promoverá uma réplica arbitrária no mesmo nível de promoção.
nota
Vários fatores estão envolvidos na identificação de um destino de failover. Após cinco tentativas de failover com falha, os níveis de promoção não são mais considerados.
Se o cluster de banco de dados não contiver quaisquer réplicas do Aurora, a instância primária será recriada na mesma AZ durante um evento de falha. Um evento de falha resulta em uma interrupção durante a qual as operações de leitura e gravação falham com uma exceção. O serviço é reestabelecido quando a nova instância primária é criada, o que normalmente leva menos de 10 minutos. Promover uma réplica do Aurora à instância primária é muito mais rápido do que criar uma nova instância primária.
Suponha que a instância principal no cluster não esteja disponível devido a uma interrupção que afeta toda uma AZ. Nesse caso, a maneira de colocar uma nova instância principal online depende de o cluster usar ou não uma configuração multi-AZ:
-
Se o cluster provisionado ou do Aurora Serverless v2 contiver instâncias de leitor em outras AZs, o Aurora usará o mecanismo de failover para promover uma dessas instâncias de leitor para ser a nova instância principal.
-
Se o cluster provisionado ou do Aurora Serverless v2 contiver apenas uma única instância de banco de dados ou se a instância principal e todas as instâncias de leitor estiverem na mesma AZ, você deverá criar manualmente uma ou mais instâncias de banco de dados em outra AZ.
-
Se o cluster usar Aurora Serverless v1, Aurora criará automaticamente uma nova instância de banco de dados em outra AZ. No entanto, esse processo envolve uma substituição de host e, portanto, leva mais tempo do que um failover.
nota
O Amazon Aurora também oferece suporte a replicação com um banco de dados MySQL externo ou uma instância de banco de dados MySQL do RDS. Para ter mais informações, consulte Replicação entre Aurora e o MySQL ou entre Aurora e outro cluster de banco de dados do Aurora (replicação de log binário).
Alta disponibilidade com o Amazon RDS Proxy
Com o RDS Proxy, você pode criar aplicações que podem tolerar falhas de banco de dados de forma transparente sem precisar escrever códigos complexos de tratamento de falhas. O proxy direciona automaticamente o tráfego para uma nova instância de banco de dados, preservando as conexões da aplicação. Ele também ignora os caches do Sistema de Nomes de Domínio (DNS) para reduzir os tempos de failover em até 66% para bancos de dados multi-AZ do Aurora. Para ter mais informações, consulte Amazon RDS Proxy para o Aurora.
