Alta disponibilidade do Amazon Aurora - Amazon Aurora

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.

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 obter 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 obter 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

Para um cluster que usa a replicação de mestre único, após criar a instância primária, é possível criar até 15 réplicas somente leitura do Aurora. As réplicas do Aurora também são conhecidas como instâncias de leitor.

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.

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 obter mais informações sobre o endpoint do cluster, consulte Gerenciamento de conexões 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 zonas de disponibilidade para melhorar a disponibilidade desse cluster. Dessa forma, um problema que afeta uma zona de disponibilidade inteira não causa uma interrupção para o cluster.

É possível configurar um cluster Multi-AZ fazendo uma escolha simples ao criar o cluster. A escolha é simples, não importa se você usa o AWS Management Console, a AWS CLI ou a API do Amazon RDS. Também é possível transformar um cluster existente do Aurora em um cluster Multi-AZ adicionando uma nova instância de leitor e especificando uma zona de disponibilidade 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 de interrupções em uma região da AWS. O Aurora lida automaticamente com a replicação de todos os dados e atualizações da região primária da AWS para cada uma das regiões secundárias. Para obter mais informações, consulte Usar bancos de dados globais do Amazon Aurora.

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 usando a replicação de mestre único falhar, o Aurora falhará automaticamente em uma nova instância primária de um dos dois jeitos:

  • 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 120 segundos e muitas vezes em menos de 60 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 2.10 e posteriores, 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 2.10 e posteriores, o Aurora reinicia somente a instância de banco de dados do gravador e o destino de failover durante um failover. Outras instâncias de banco de dados do leitor no cluster permanecem disponíveis para continuar processando consultas por meio de conexões com o endpoint do leitor.

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 primeira prioridade a 15 para a última prioridade. 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.

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 primária on-line depende se o cluster usa uma configuração Multi-AZ. Se o cluster contiver instâncias de leitor em outras AZs, Aurora usará o mecanismo de failover para promover uma dessas instâncias de leitor para ser a nova instância primária. Se o cluster provisionado 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 novas instâncias de banco de dados em outra AZ. Se o cluster usar Aurora Serverless, 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 obter 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).