Multi-AZ do Amazon RDS com uma instância secundária

Failover automático Proteja a performance do banco de dados Aperfeiçoe a durabilidade Aumente a disponibilidade
Alta disponibilidade de suporte para a aplicação, com failover automático do banco de dados e conclusão em até 60 segundos, com zero perda de dados e sem nenhuma intervenção manual.
Evite suspender a atividade de E/S da instância primária durante o backup por meio do backup da instância secundária.
Utilize as tecnologias de replicação síncronas do multi-AZ do Amazon RDS para manter os dados na instância de banco de dados secundário atualizadas com a instância primária. Aprimore a disponibilidade implantando uma instância em espera em uma segunda AZ e obtenha tolerância a falhas no caso de uma AZ ou falha de instância de banco de dados.

Como funciona

Em uma implantação multi-AZ, o Amazon RDS cria automaticamente uma instância de banco de dados (BD) primária e replica de forma síncrona os dados para uma instância em uma AZ diferente. Quando detecta uma falha, o Amazon RDS executa automaticamente o failover para uma instância secundária sem nenhuma intervenção manual.
Diagrama de funcionamento da implantação multi-AZ do Amazon RDS

Multi-AZ do Amazon RDS com duas instâncias de espera legíveis

Executa o failover normalmente em menos de 35 segundos Use endpoints separados para leituras e gravações Obtenha latência de confirmação de transação até 2x mais rápida Versões menores normalmente atualizam em menos de 1 segundo
Failover automático normalmente em menos de 35 segundos, sem perda de dados e sem intervenção manual. Roteie consultas para os servidores de gravação e instâncias de espera de réplica de leitura para maximizar a performance e a escalabilidade.  Obtenha uma latência de gravação até 2x melhorada em comparação com o Multi-AZ com um modo de espera. Reduza o tempo de inatividade do upgrade de versões secundárias normalmente para menos de 35 segundos. Reduza ainda mais o tempo de inatividade para normalmente menos de 1 segundo adicionando um RDS Proxy ou um código aberto à sua implantação.

Como funciona

Implante bancos de dados MySQL ou PostgreSQL altamente disponíveis e duráveis em três AZs usando o Multi-AZ do Amazon RDS com duas instâncias de espera legíveis. Obtenha failovers automáticos tipicamente em menos de 35 segundos, latência de confirmação de transação até 2x mais rápida em comparação com o Multi-AZ do Amazon RDS com uma instância de espera, capacidade de leitura adicional e uma opção de instâncias e armazenamento com suporte de instâncias baseadas no AWS Graviton2 ou em Intel para computação.
Introdução ao Multi-AZ do Amazon RDS (1:20)

Introdução ao Multi-AZ do Amazon RDS

As implantações Multi-AZ do Amazon RDS proporcionam disponibilidade e durabilidade melhores para instâncias de seu banco de dados (DB) do Amazon RDS, o que as torna a solução ideal para workloads de banco de dados de produção. Com duas opções diferentes de implantação, você pode personalizar suas workloads para a disponibilidade de que elas precisam.
Introdução ao Multi-AZ do Amazon RDS
As implantações Multi-AZ do Amazon RDS proporcionam disponibilidade e durabilidade melhores para instâncias de seu banco de dados (DB) do Amazon RDS, o que as torna a solução ideal para workloads de banco de dados de produção. Com duas opções diferentes de implantação, você pode personalizar suas workloads para a disponibilidade de que elas precisam.

Tabela de comparação

Mono-AZ do Amazon RDS ou multi-AZ do Amazon RDS com uma instância de espera ou multi-AZ do Amazon RDS com duas instâncias de espera legíveis

Recurso

Mono-AZ

Multi-AZ com uma instância de espera

Multi-AZ com duas instâncias de espera legíveis

Mecanismos disponíveis

  • Amazon RDS para PostgreSQL
  • Amazon RDS for MySQL
  • Amazon RDS para MariaDB
  • Amazon RDS para SQL Server
  • Amazon RDS para Oracle
  • Amazon RDS para Db2
  • Amazon RDS para PostgreSQL
  • Amazon RDS for MySQL
  • Amazon RDS para MariaDB
  • Amazon RDS para SQL Server
  • Amazon RDS para Oracle
  • Amazon RDS para Db2
  • Amazon RDS para PostgreSQL
  • Amazon RDS for MySQL

Capacidade de
leitura adicional

  • Nenhuma: a capacidade de leitura é limitada à sua capacidade primária
  • Nenhuma: a instância de banco de dados de espera é apenas um destino passivo do failover para alta disponibilidade
  • Duas instâncias de banco de dados em espera atuam como destinos de failover e atendem ao tráfego de leitura
  • A capacidade de leitura é determinada pela sobrecarga de transações de gravação da instância primária

·        

Menor latência (maior taxa de transferência) para confirmações de transação

 

 

  • Confirmações de transações até 2x mais rápidas em comparação com o Multi-AZ do Amazon RDS com uma instância de espera

Duração automática do failover

  • Não disponível: será necessária uma operação de restauração pontual iniciada pelo usuário.
  • Esta operação pode levar várias horas para ser concluída
  • Qualquer atualização de dados que ocorrer depois do tempo de restauração mais recente (normalmente, os últimos cinco minutos) não estarão disponíveis
  • Uma nova instância principal está disponível para atender o novo workload em até 60 segundos
  • O tempo de failover é independente da taxa de transferência de gravação
  • Uma nova instância primária está disponível para atender o novo workload normalmente em menos de 35 segundos
  • O tempo do failover depende da duração do atraso da réplica
Tempo de inatividade dos upgrades de versões secundárias
  • Ao usar atualizações automáticas de versões secundárias, o tempo de inatividade da atualização de versão secundária ocorre durante a janela de manutenção de 30 minutos do Amazon RDS
  • Ao usar atualizações automáticas de versões secundárias, o tempo de inatividade da atualização de versão secundária ocorre durante a janela de manutenção de 30 minutos do Amazon RDS
  • Normalmente, em menos de 1 segundo quando os clientes adicionam um código aberto ou Amazon RDS Proxy à sua implantação
  • Normalmente, menos de 35 segundos com Multi-AZ com apenas dois modos de espera legíveis

Maior resiliência à interrupção de AZ

  • Nenhum: no caso de uma falha de AZ, o risco de perda de dados e horas de tempo de failover
  • No caso de uma falha de AZ, o workload executará failover automaticamente para a instância de espera atualizada
  • Em caso de falha, uma das duas instâncias de espera restantes assumirá o controle e atenderá o workload (gravações) da instância primária

Menor jitter para confirmações de transações

  • Não há otimização para jitter
  • Acesso a volumes de Log dedicados
  • Usa armazenamento local para logs transacionais para reduzir o jitter

Clientes

O SysCloud cria backups automáticos para aplicações críticas de software como serviço (SaaS), monitora arquivos maliciosos e fornece insights poderosos sobre seus dados e conformidade (tudo em um painel). O SysCloud utiliza o Multi-AZ do Amazon RDS com duas instâncias de espera legíveis para o monitoramento interno do sistema: “a nova implantação multi-AZ do Amazon RDS oferece uma opção com bom custo-benefício para obter a melhor performance, disponibilidade e escalabilidade de leitura”, afirma Vikram Srinivasan, diretor, Infraestrutura na SysCloud. “Com a nova opção de implantação Multi-AZ do Amazon RDS, esperamos criar uma experiência melhor para os nossos clientes.”

Definição de preços

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.

Recursos

Conceitos básicos

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

DOCUMENTAÇÃO


Descreve o Multi-AZ do Amazon RDS com um conceito de espera e fornece instruções sobre como modificar sua instância de banco de dados para ser uma implantação Multi-AZ e o processo de failover para o Amazon RDS.

DOCUMENTAÇÃO


Descreve o Multi-AZ do Amazon RDS com dois conceitos de espera legíveis e fornece instruções sobre como modificar, renomear, reinicializar e excluir um cluster; usar réplicas de leitura; e usar replicação lógica do PostgreSQL com clusters de banco de dados Multi-AZ.

TUTORIAL DE CONCEITOS BÁSICOS


Neste tutorial, crie uma instância do banco de dados Oracle Standard Edition Two no Amazon RDS usando o modelo de licença incluída e como habilitar atributos, como Multi-AZ e Performance Insights.

Vídeos

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

CONVERSA TÉCNICA ON-LINE


Nesta sessão, faça uma breve introdução ao Multi-AZ, suas opções de implantação, os benefícios de cada opção e mergulhe profundamente nas duas opções de espera legíveis e seus aprimoramentos recentes.

Blogs

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. 

Perguntas frequentes

O que significa executar uma instância de banco de dados como uma implantação multi-AZ?

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.

O que é uma zona de disponibilidade?

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.

O que significam “primária” e “em espera” no contexto de uma implantação multi-AZ?

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.

Quais são os benefícios de uma implantação Multi-AZ?

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.
 

Existem quaisquer implicações de performance em executar minha instância de banco de dados como uma implantação Multi-AZ?

É 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.

Como eu configuro uma implantação de instância de banco de dados Multi-AZ?

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.
 

O que acontece quando converto minha instância do Amazon RDS de Mono-AZ para Multi-AZ?

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.

Quais eventos fazem com que o Amazon RDS inicie um failover para o modo de réplica em espera?

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.

Serei alertado quando um failover automático ocorrer em um Amazon RDS?

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 que acontece durante o failover Multi-AZ e quanto tempo leva?

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.

Posso iniciar um “failover forçado” para minha implantação de instância de banco de dados multi-AZ?

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 .

Como controlo/configuro a replicação síncrona Multi-AZ?

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.

Minha instância em espera ficará na mesma região que minha principal?

Sim. A espera é automaticamente provisionada em uma zona de disponibilidade diferente da mesma região que a instância de banco de dados principal.

É possível ver em qual Zona de disponibilidade a principal está situada atualmente?

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

Após o failover, minha principal agora está localizada em uma zona de disponibilidade diferente do que meus outros recursos AWS (por exemplo, instâncias EC2). Devo preocupar-me com a latência?

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.

Como as Instâncias de banco de dados e os backups automáticos funcionam com minha implantação Multi-AZ?

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.

Saiba mais sobre os atributos do Amazon RDS
Aprenda com tutoriais de 10 minutos

Explore o Amazon RDS com tutoriais simples.

Explore o treinamento prático 
Cadastre-se para obter uma conta da AWS
Comece a construir com o Amazon RDS e o Amazon Aurora

Explore o Guia do usuário do Amazon RDS para iniciar.

Leia a documentação 
Comece a construir com o Amazon RDS no console
Mergulhe profundamento no Multi-AZ do Amazon RDS

Mergulhe profundamente no funcionamento do Multi-AZ do Amazon RDS e nas diferentes opções de implantação.

Assista à sessão