Qual é o impacto de converter minha instância mono-AZ do Amazon RDS em uma instância multi-AZ e vice-versa?

Data da última atualização: 30/9/2021

Quero saber o impacto da conversão da minha instância de banco de dados mono-AZ do Amazon Relational Database Service (Amazon RDS) em uma instância multi-AZ.

-ou-

Quero saber o impacto da conversão da minha instância de banco de dados multi-AZ do Amazon RDS em uma instância mono-AZ.

Breve descrição

Em uma configuração mono-AZ, uma instância de banco de dados e um ou mais volumes de armazenamento do Amazon Elastic Block Store (Amazon EBS) são implantados em uma zona de disponibilidade em datacenters. Em uma configuração multi-AZ, as instâncias de banco de dados do Amazon RDS e os volumes de armazenamento do EBS são implantados em várias zonas de disponibilidade.

Quando você habilita o multi-AZ em sua instância, o Amazon RDS mantém uma cópia em espera redundante e consistente de seus dados usando replicação de armazenamento síncrona. 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. Para obter mais informações, consulte Alta disponibilidade (multi-AZ) para o Amazon RDS.

Para converter uma instância de banco de dados da implantação mono-AZ em uma implantação multi-AZ e vice-versa, consulte Modificação de uma instância do Amazon RDS.

Ao converter sua instância mono-AZ em uma instância multi-AZ, você pode ver o seguinte evento na seção Logs e eventos no console do Amazon RDS:

September 21, 2021, 8:45:04 PM UTC            Aplicando modificação para converter em uma instância de banco de dados multi-AZ

Resolução

Impacto da modificação de uma instância mono-AZ para uma instância multi-AZ

Quando você modifica sua instância mono-AZ para uma instância multi-AZ, você não experimenta nenhum tempo de inatividade na instância. Durante a conversão, o Amazon RDS cria um snapshot da instância e usa esse snapshot para restaurar dados nos novos volumes criados em outra zona de disponibilidade. Embora esses novos volumes estejam imediatamente disponíveis para uso, você pode ter alguns problemas de performance. Isso ocorre porque a instância do banco de dados continua carregando dados em segundo plano. Esse processo, chamado de carregamento lento, pode levar a uma latência de gravação elevada e a um impacto na performance durante e após a conversão. O impacto na performance é uma função do tipo de volume, da workload, da instância e do tamanho do volume. O impacto pode ser significativo para grandes instâncias de banco de dados com gravação intensiva durante os horários de pico das operações.

Para reduzir a latência depois de modificar a instância, é prática recomendada fazer o seguinte:

  1. Inicie um failover para sua instância após a conversão para multi-AZ.
  2. Execute um despejo completo dos dados na instância para buscar todos os dados do snapshot.

Quando você converte uma instância de mono-AZ para multi-AZ, uma nova instância é criada com a mesma configuração em outra zona de disponibilidade. Isso leva a custos adicionais. Além disso, como a implantação multi-AZ usa replicação síncrona, as gravações são mais lentas do que as do mono-AZ.

Impacto da modificação de uma instância multi-AZ para uma instância mono-AZ

Quando você modifica sua instância de uma instância multi-AZ para uma instância mono-AZ, você não experimenta nenhum tempo de inatividade na instância. Durante a conversão, o Amazon RDS exclui apenas a instância e os volumes secundários, e a instância primária não é afetada durante esse período.

Aqui estão alguns aspectos a serem considerados antes de modificar sua instância da implantação multi-AZ para mono-AZ:

  • Com a implantação multi-AZ, o Amazon RDS muda automaticamente para uma réplica em espera em outra zona de disponibilidade durante uma interrupção planejada ou não planejada da sua instância de banco de dados. No entanto, em uma instância mono-AZ, talvez seja necessário iniciar uma operação de restauração em um ponto anterior no tempo. Essa operação pode levar várias horas para ser concluída, e as atualizações de dados ocorridas após o último tempo restaurável não estão disponíveis. Portanto, você pode ter um tempo de inatividade adicional em uma instância mono-AZ em caso de falha.
  • Em uma instância multi-AZ, backups automatizados são criados a partir da instância secundária durante a janela de backup automático. Para o Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for Oracle e Amazon RDS for PostgreSQL, a atividade de E/S não é suspensa em sua instância principal durante o backup para implantações multi-AZ, porque o backup é retirado do secundário. Para o Amazon RDS for SQL Server, a atividade de E/S é suspensa brevemente durante o backup para implantações multi-AZ. O processo de backup em uma instância de banco de dados mono-AZ resulta em uma breve suspensão de E/S que pode durar de alguns segundos a alguns minutos, dependendo do tamanho e da classe da instância de banco de dados.
  • Em implantações multi-AZ, a manutenção do sistema operacional é aplicada à instância secundária. A segunda instância é promovida a primária e, em seguida, a manutenção é executada no antigo primário, que se torna o novo modo de espera. Portanto, o tempo de inatividade durante determinados patches do sistema operacional em uma instância multi-AZ é mínimo.
  • Se você estiver escalando sua instância multi-AZ, o tempo de inatividade será mínimo. Isso ocorre porque a instância secundária é atualizada primeiro. A instância secundária é promovida para primária, após o qual a instância primária é atualizada. Uma instância mono-AZ fica indisponível durante a operação de escalabilidade.

Este artigo ajudou?


Precisa de ajuda com faturamento ou suporte técnico?