Multi-AZ do Amazon RDS

Ao criar ou modificar sua instância de banco de dados para ser executada como uma implantação multi-AZ, o Amazon RDS provisiona e mantém automaticamente uma réplica no modo “em espera” síncrona em uma zona de disponibilidade diferente. As atualizações de instância de banco de dados são replicadas simultaneamente por meio de zonas de disponibilidade para a espera, a fim de manter ambos em sincronia e proteger as últimas atualizações de banco de dados contra falhas de instância de banco de dados.

Durante alguns tipos de manutenção programada, ou no caso de falha de instância de banco de dados ou falha de zona de disponibilidade, o Amazon RDS automaticamente fará o failover para a espera, para que você possa retomar gravações e leituras de banco de dados assim que a espera for promovida. Como o registro de nome para a instância de banco de dados permanece o mesmo, a aplicação pode retomar as operações de banco de dados sem precisar de intervenção administrativa manual. Com implantações Multi-AZ, a replicação é transparente. Você não interagirá diretamente com o modo standby e ele não poderá ser usado para ler tráfego. Mais informações sobre implantações multi-AZ podem ser encontradas no Guia do usuário do Amazon RDS.

As zonas de disponibilidade são locais distintos em uma região que são projetados para serem isolados de falhas acarretadas por outras zonas de disponibilidade. Cada zona de disponibilidade opera em sua própria infraestrutura fisicamente distinta e independente e é projetada para ser altamente confiável. Pontos comuns de falhas, como geradores e equipamentos de refrigeração, não são compartilhados pelas zonas de disponibilidade. Além disso, eles são fisicamente separados, de tal forma que mesmo desastres extremamente incomuns, como incêndios, tornados ou enchentes, afetariam somente uma única zona de disponibilidade. As zonas de disponibilidade dentro da mesma região beneficiam-se de conectividade de rede de baixa latência.

Quando você executa uma instância de banco de dados em uma implantação multi-AZ, a instância “primária” é responsável pelas gravações e leituras do banco de dados. Além disso, o Amazon RDS providencia e mantém um “em espera” em segundo plano, que é uma réplica atualizada da principal. O em espera é “promovido” em situações de failover. Após um failover, o em espera se torna o principal e aceita suas operações de banco de dados. Não há interação direta com o modo de espera, por exemplo, para operações de leitura, em nenhum momento anterior à promoção. Se você tiver interesse em escalar o tráfego de leitura além das restrições de capacidade de uma única instância de banco de dados, consulte as perguntas frequentes sobre réplicas de leitura.

Os principais benefícios de executar a instância de banco de dados como implantação multi-AZ são a durabilidade e a disponibilidade aprimoradas do banco de dados. A disponibilidade e tolerância a falhas mais abrangentes oferecidas por implantações Multi-AZ as tornam a melhor opção para ambientes de produção.

A execução da instância de banco de dados como uma implantação Multi-AZ protege os dados caso ocorra, inesperadamente, uma falha de componentes de instância de banco de dados ou uma perda de disponibilidade em uma zona de disponibilidade. Por exemplo, se um volume de armazenamento de seu principal falhar, o Amazon RDS automaticamente inicia um failover para o em espera, onde todas as atualizações de seu banco de dados estão intactas. Isso fornece uma resiliência de dados adicional relativa às implantações padrão em um único AZ, em que uma operação de restauração feita por usuário seria necessária e atualizações feitas após o último momento restaurável (geralmente dentro dos últimos cinco minutos) não estariam disponíveis.

Você também se beneficiará da disponibilidade aprimorada do banco de dados ao executar sua instância de banco de dados como uma implantação Multi-AZ. Se ocorrer uma falha de zona de disponibilidade ou de instância de banco de dados, o impacto em sua disponibilidade estará limitado ao tempo que o failover automático leva para ser concluído. Os benefícios de disponibilidade do Multi-AZ também se estendem à manutenção planejada.

Com backups automatizados, por exemplo, a atividade de E/S não é mais suspensa no seu principal durante sua janela de manutenção preferencial, pois os backups são retirados da espera. No caso de aplicação de patches ou escalabilidade de classe de instância de banco de dados, essas operações ocorrem primeiro na espera, antes do failover automático. Como resultado, o impacto de disponibilidade é limitado ao tempo necessário para o failover automático ser concluído.

Outro benefício decorrente da execução da instância de banco de dados como uma implantação Multi-AZ é o failover de instância de banco de dados automático que não exige nenhuma administração. No contexto do Amazon RDS, isso significa que você não precisa monitorar eventos de instância de banco de dados e iniciar a recuperação manual da instância de banco de dados (por meio das APIs RestoreDBInstanceToPointInTime ou RestoreDBInstanceFromSnapshot) caso haja uma falha de zona de disponibilidade ou falha de instância de banco de dados.

É possível que ocorram latências elevadas em relação a uma implantação de instância de banco de dados padrão em uma única zona de disponibilidade como resultado da replicação de dados síncrona realizada em seu nome.

Para criar uma implantação de instância de banco de dados multi-AZ, basta clicar na opção “Sim” em “Implantação multi-AZ” ao iniciar uma instância de banco de dados no Console de Gerenciamento da AWS.

Como alternativa, se você estiver utilizando as APIs do Amazon RDS, poderá chamar a CreateDBInstance API e configurar o parâmetro “Multi-AZ” com o valor “true”. Para converter uma instância de banco de dados padrão (AZ único) para Multi-AZ, modifique a instância de banco de dados no Console de Gerenciamento da AWS ou utilize a API ModifyDBInstance e configure o parâmetro Multi-AZ como verdadeiro.

Para os mecanismos de banco de dados RDS para PostgreSQL, RDS para MySQL, RDS para MariaDB, RDS para SQL Server, RDS para Oracle e RDS para Db2, ao optar por converter a instância do Amazon RDS de zona de disponibilidade única (single-AZ) para zona de disponibilidade múltipla (multi-AZ), ocorre o seguinte:

• Um snapshot da instância principal é criado.
• Uma nova instância em espera é criada em uma zona de disponibilidade diferente da zona em que o snapshot está.
• A replicação síncrona é configurada entre as instâncias primária e em espera.

Dessa maneira, não deve haver períodos de inatividade quando uma instância é convertida de mono-AZ para multi-AZ. No entanto, você poderá ver um aumento na latência enquanto os dados em espera são alcançados para corresponder à primária.

O Amazon RDS detecta e se recupera automaticamente dos cenários de falha mais comuns em implantações multi-AZ, permitindo que você retome as operações do banco de dados o mais rápido possível, sem intervenção administrativa. O Amazon RDS executa automaticamente um failover em qualquer uma das seguintes ocorrências:

• Perda de disponibilidade na zona de disponibilidade principal
• Perda de conectividade de rede para principal
• Falha de unidade computacional na principal
• Falha de armazenamento na principal

Observação: quando operações como ações de escalabilidade de instâncias de banco de dados ou atualizações de sistema como a aplicação de patches no SO são iniciadas em implantações Multi-AZ, elas são aplicadas primeiro na espera antes de um failover automático para oferecer melhor disponibilidade. Como resultado, o impacto na disponibilidade será limitado ao tempo necessário para a conclusão do failover automático. Note que implantações Multi-AZ do Amazon RDS não executam failover automaticamente em caso de operações de banco de dados como consultas com execução demorada, bloqueios ou erros de corrupção de banco de dados.

Sim, o Amazon RDS emitirá um evento de instância de banco de dados para informar você de que ocorreu um failover automático. Clique na seção “Events” do console do Amazon RDS ou use a API DescribeEvents para retornar informações sobre eventos relacionados à instância de banco de dados. Você também pode usar as notificações de eventos do Amazon RDS para receber notificações quando ocorrerem eventos específicos relacionados ao banco de dados.

O Amazon RDS gerencia automaticamente o failover para que você possa retomar as operações do banco de dados o mais rápido possível, sem intervenção administrativa. Ao ocorrer um failover, o Amazon RDS troca o registro de nome canônico (CNAME) da instância de banco de dados para indicar a espera, que em troca é promovida e se torna o novo principal. Encorajamos você a seguir melhores práticas e implementar novas tentativas de conexão de banco de dados na camada de aplicativo.

Os failovers, definidos como o intervalo entre a detecção da falha no banco de dados principal e a retomada das transações no banco de dados de espera, em geral são concluídos em um a dois minutos. O tempo de failover também pode ser afetado pela necessidade ou não de grandes transações não confirmadas serem recuperadas; o uso de tipos de instância adequadamente grandes é recomendado com o Multi-AZ para a obtenção dos melhores resultados. A AWS também recomenda o uso de IOPS provisionadas com instâncias Multi-AZ para obter performance de throughput alta, previsível e consistente.

O Amazon RDS executará o failover de forma automática, sem necessidade de intervenção do usuário, em uma variedade de situações de falha. Além disso, o Amazon RDS oferece uma opção para iniciar um failover quando reiniciar sua instância. Você pode acessar este atributo por meio do Console de Gerenciamento da AWS ou ao usar a RebootDBInstance para chamada de API .

Com as implantações multi-AZ, basta definir o parâmetro “Multi-AZ” como verdadeiro. A criação da espera, da replicação simultânea e do failover é controlada automaticamente. Isso significa que não é possível selecionar a zona de disponibilidade em que a espera é implantada ou alterar o número de esperas disponíveis (o Amazon RDS provisiona uma espera dedicada por instância de banco de dados principal). A espera também não pode ser configurada para aceitar atividades de leitura do banco de dados. Saiba mais sobre as configurações multi-AZ.

Sim. Sua instância em modo de espera é provisionada de forma automática em uma zona de disponibilidade distinta na mesma região de sua instância de banco de dados primária.

Sim, você pode obter visibilidade sobre a localização da instância primária atual usando o Console de Gerenciamento da AWS ou a API DescribeDBInstances.

As zonas de disponibilidade são desenvolvidas para oferecer uma conectividade de rede com baixa latência para outras zonas de disponibilidade dentro da mesma região. Além disso, você tem a opção de criar seu aplicativo e outros recursos da AWS com redundância por meio de múltiplas zonas de disponibilidade para que seu aplicativo seja resiliente no caso de uma falha de zona de disponibilidade. Implantações Multi-AZ abordam essa necessidade para a camada de banco de dados sem administração de sua parte.

A interação com as funcionalidades de backup automático e snapshot de banco de dados é a mesma, independentemente de você estar usando uma implantação padrão single-AZ ou uma implantação multi-AZ. Se você estiver executando uma implantação Multi-AZ, os backups automatizados e DB snapshots serão simplesmente executados na espera para evitar suspensão de E/S na principal. Note que você poderá experimentar uma maior latência de E/S (normalmente por alguns minutos) durante os backups de implantações Single-AZ e Multi-AZ.

O início de uma operação de restauração (restauração point-in-time ou de um DB snapshot) também funciona da mesma forma para implantações Multi-AZ e Single-AZ padrão. Novas implantações de instância de banco de dados podem ser criadas com as APIs RestoreDBInstanceFromSnapshot ou RestoreDBInstanceToPointInTime. Essas novas implantações de instância de banco de dados podem ser padrão ou Multi-AZ, independentemente de o backup de origem ter sido iniciado em uma implantação padrão ou Multi-AZ.