Implantações Multi-AZ do Amazon RDS

O Multi-AZ do Amazon RDS está disponível para RDS para PostgreSQL, RDS para MySQL, RDS para MariaDB, RDS para SQL Server, RDS para Oracle e RDS para Db2. O Multi-AZ do Amazon RDS com duas instâncias de espera legíveis está disponível para o RDS for PostgreSQL e o RDS for MySQL. Para saber como o Amazon Aurora oferece maior disponibilidade ao tornar seus dados duráveis em três zonas de disponibilidade, consulte Implantações Multi-AZ com réplicas do Aurora.

Em implantações Mono-AZ, Multi-AZ com uma instância de espera e Multi-AZ com duas instâncias de espera legíveis, os preços são calculados por instância-hora de banco de dados consumida desde o momento em que a instância de banco de dados é iniciada até que ela seja interrompida ou excluída. As instâncias-hora parciais de banco de dados são cobradas em incrementos de um segundo, com uma cobrança mínima de 10 minutos após uma alteração de status faturável, como criar, iniciar ou modificar a classe da instância de banco de dados.

Para mais informações sobre a definição de preços do Multi-AZ do Amazon RDS, consulte as páginas de definição de preços.

Use os seguintes guias de usuário e tutoriais para começar rapidamente a usar o Multi-AZ do Amazon RDS.

Assista a sessões, webinars e outros vídeos para se aprofundar no Multi-AZ do Amazon RDS.

Leia sobre as melhorias mais recentes do Multi-AZ do Amazon RDS e mergulhe profundamente em como você pode usá-lo em seus casos de uso do Amazon RDS. 

Obtenha um segundo ou menos de tempo de inatividade com o ProxySQL ao atualizar as implantações Multi-AZ do Amazon RDS com dois modos de espera legíveis

Transição rápida com o PgBouncer em implantações Multi-AZ do Amazon RDS com dois modos de espera legíveis para PostgreSQL

Obtenha um segundo ou menos de tempo de inatividade com o Advanced JDBC Wrapper Driver ao atualizar os clusters de banco de dados Multi-AZ do Amazon RDS

Execute atualizações de versão secundárias com um tempo de inatividade de 1 segundo ou menos com as implantações Amazon RDS Proxy e Multi-AZ do Amazon RDS com dois modos de espera legíveis

Consolidação de dados para aplicativos analíticos usando replicação lógica para clusters Multi-AZ do Amazon RDS

Melhores estratégias para alcançar alto desempenho e alta disponibilidade no Amazon RDS para MySQL com clusters de banco de dados Multi-AZ

Melhore o desempenho do aplicativo no Amazon RDS para instâncias MySQL e MariaDB e clusters de banco de dados MySQL Multi-AZ com gravações otimizadas

Escolha a opção certa de implantação do Amazon RDS: instância Single-AZ, instância Multi-AZ ou cluster de banco de dados Multi-AZ

Configure o Multi-AZ com o Amazon RDS Custom para SQL Server

Implante um cluster de banco de dados Multi-AZ Amazon RDS para PostgreSQL e MySQL usando módulos do Terraform

Nova opção de implantação Multi-AZ do Amazon RDS para MySQL e PostgreSQL: melhor desempenho de gravação e failover mais rápido

Ao criar ou modificar a instância de banco de dados para ser executada como uma implantação Multi-AZ, o Amazon RDS automaticamente providencia e mantém uma réplica “em espera” simultânea 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 as 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 com baixa latência.

Ao executar uma instância de banco de dados como uma implantação Multi-AZ, o “principal” atende às gravações e leituras de 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. Você não interage diretamente com o em espera (por exemplo, operações de leitura) em nenhum momento antes da promoção. Se você estiver interessado 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 uma implantação Multi-AZ são a resiliência 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 observar latências elevadas relacionadas a uma implantação padrão de instância de banco de dados em uma única zona de disponibilidade, resultantes da replicação de dados simultânea realizada em seu nome.

Para criar uma implantação de instância de banco de dados Multi-AZ, basta clicar na opção “Sim” da seção “Implantação Multi-AZ” ao iniciar uma instância de banco de dados com o 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 o RDS para PostgreSQL, RDS para MySQL, RDS para MariaDB, RDS para servidor SQL, RDS para Oracle, eRDS para Db2 motores de base de dados quando você for elegível a converter a instância da sua conta Amazon RDS de Mono-AZ para Multi-AZ, o seguinte acontece:

• 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 recupera automaticamente os cenários de falha mais comuns das implantações multi-AZ para que você possa reiniciar as operações de 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 informá-lo que houve um failover. 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 poderá usar as notificações de evento do Amazon RDS para receber notificações quando ocorrerem eventos específicos de banco de dados.

O failover é automaticamente controlado pelo Amazon RDS para que você possa retomar operações de banco de dados o mais rápido possível e 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 automaticamente e sem intervenção do usuário em diversas condiçõ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 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. A espera é automaticamente provisionada em uma zona de disponibilidade diferente da mesma região que a instância de banco de dados principal.

Sim, é possível visualizar o local da principal atual utilizando o Console de Gerenciamento da AWS ou a DescribeDBInstances API.

As zonas de disponibilidade são projetadas para fornecer conectividade de rede de baixa latência para outras zonas de disponibilidade na 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 a funcionalidade de backup automatizado e de DB snapshot é a mesma de uma implantação padrão Single-AZ ou 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.