Qual é o impacto causado pela modificação da minha instância mono-AZ do Amazon RDS para uma instância multi-AZ e vice-versa?

Breve descrição

Em uma configuração mono-AZ, uma instância de banco de dados do Amazon RDS e um ou mais volumes de armazenamento do Amazon Elastic Block Store (Amazon EBS) são implantados em uma zona de disponibilidade. Em uma configuração multi-AZ, as instâncias de banco de dados e os volumes de armazenamento do EBS são implantados em duas 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 dos cenários de falha de infraestrutura mais comuns para implantações multi-AZ. A detecção e a recuperação ocorrem para que você possa retomar as operações do banco de dados o mais rápido possível. 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.

Resolução

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

Quando você altera sua instância mono-AZ para multi-AZ, você não experimenta nenhum tempo de inatividade na instância. Durante a modificação, o Amazon RDS cria um snapshot dos volumes da instância. Em seguida, esse snapshot é usado para criar novos volumes em outra zona de disponibilidade. Embora esses novos volumes estejam imediatamente disponíveis para uso, talvez você observe algum problema de performance. Isso ocorre porque os dados do novo volume ainda estão sendo carregados do Amazon Simple Storage Service (Amazon S3). Enquanto isso, a instância de 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 o processo de modificação.

O tamanho do 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. Como resultado, é prática recomendada avaliar o impacto em uma instância de teste antes de executar essa modificação na produção. Também é prática recomendada concluir essa modificação em uma janela de manutenção ou de baixa utilização.

Reduzir a duração do carregamento

Para reduzir proativamente a duração e o impacto do carregamento, faça o seguinte:

1. Altere o tipo de armazenamento da instância de banco de dados para IOPS provisionadas. Certifique-se de provisionar uma quantidade de IOPS substancialmente maior do que a exigida pela workload.
   Observação: esta etapa poderá causar um breve período de inatividade se a instância usar um grupo de parâmetros personalizado.
2. Altere a instância para multi-AZ.
3. Inicie um failover em sua instância para ter certeza de que a nova AZ é a AZ principal.
4. Execute um despejo completo dos dados na sua instância. Ou execute consultas de verificação de tabela completa nas tabelas mais ativas para acelerar o carregamento dos dados nos volumes.
5. Confirme se a latência de gravação voltou aos níveis normais revisando a métrica WriteLatency no Amazon CloudWatch.
6. Altere o tipo de armazenamento da instância ou IOPS de volta para sua configuração anterior.
   Observação: esta etapa não requer tempo de inatividade.

Reduza a latência se sua instância já for multi-AZ

Para reduzir a latência se você já modificou a instância para multi-AZ, faça o seguinte:

1. Inicie um failover em sua instância para ter certeza de que a nova AZ é a AZ principal.
2. Altere o tipo de armazenamento da instância de banco de dados para IOPS provisionadas. Certifique-se de provisionar uma quantidade de IOPS substancialmente maior do que a exigida pela workload.
   Observação: esta etapa não requer tempo de inatividade.
3. Execute um despejo completo dos dados na sua instância. Ou execute consultas de verificação de tabela completa nas tabelas mais ativas para acelerar o carregamento dos dados nos volumes.
4. Confirme se a latência de gravação voltou aos níveis normais revisando a métrica WriteLatency no Amazon CloudWatch.
5. Altere o tipo de armazenamento da instância ou IOPS de volta para sua configuração anterior.
   Observação: esta etapa não requer tempo de inatividade.

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

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

Ao alterar sua instância de multi-AZ para mono-AZ, não há tempo de inatividade na instância. Durante a modificação, o Amazon RDS exclui somente a instância secundária e os volumes, a instância primária não é afetada.

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

• Com a implantação multi-AZ, o Amazon RDS alterna automaticamente para a cópia 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. Esta operação pode levar várias horas para ser concluída. Nenhuma atualização de dados que ocorreu após o último momento de restauração está disponível. Por isso, poderá haver 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 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 é obtido da secundária. 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. A quantidade de tempo depende do tamanho e da classe da sua instância de banco de dados.
• Em implantações multi-AZ, a manutenção do sistema operacional é aplicada primeiro à instância secundária. A segunda instância é promovida a primária e, em seguida, a manutenção é executada na antiga primária, que agora passa a ser a nova instância de espera. Assim, 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 é modificada primeiro. A instância secundária é promovida para primária. Em seguida, a antiga instância primária, agora secundária, é modificada. Uma instância mono-AZ permanece indisponível durante a operação de escalabilidade.

---

Informações relacionadas

Implantações multi-AZ do Amazon RDS