Tempo de inatividade para aumentar o armazenamento de RDS?

Question

Estou procurando aumentar o armazenamento de duas instâncias do RDS (apenas o espaço de armazenamento alocado, não o tipo de instância ou outros parâmetros). A documentação no link sugere:

You can change from standard storage to Provisioned IOPS storage, or from Provisioned IOPS to standard storage, as well as increase storage, with little to no downtime.

Eu definitivamente planejaria uma janela de manutenção antes de executar a alteração. Mas a documentação parece um pouco vaga nesta área. Para alguém que poderia ter feito isso antes, o que é "pouco ou nenhum tempo de inatividade"? Posso esperar 5 segundos ou é mais como 5 minutos?

    

Answer 1

Primeiro, note que você pode estar olhando para a operação incorreta - você descreve que deseja alterar o armazenamento tamanho , mas citou documentação descrevendo o armazenamento tipo . Essa é uma distinção importante: o RDS informa que você não experimentará uma interrupção para alterar o tamanho do armazenamento, mas sim uma interrupção para alterar o tipo de armazenamento.

Espere um desempenho degradado para alterar o tamanho do armazenamento, cuja duração e impacto dependerão de vários fatores:

• Seu tipo de instância do RDS
• Configuração
  • Isso ocorrerá durante a manutenção?
  • Essas alterações ocorrerão primeiro no seu escravo Multi-AZ e, em seguida, no failover?
• Tamanho atual do banco de dados
• Tamanho do banco de dados de candidatos
• Capacidade da AWS para lidar com essa solicitação na hora do dia solicitada, na zona de disponibilidade solicitada, na região solicitada
• Tipo de mecanismo (para usuários do Amazon Aurora , adições de armazenamento são gerenciadas pelo RDS conforme necessário em incrementos de 10 GB, portanto, esta discussão é discutível)

Com isso em mente, você seria mais bem atendido se testasse isso sozinho, em seu ambiente e em seus próprios termos. Tente experimentar com o seguinte:

• Restaurando uma nova instância do RDS a partir de um instantâneo de sua instância existente e executando essa operação no novo clone.
• Com este clone:
  • Aumente o tamanho em diferentes momentos do dia, quando você esperaria uma carga diferente na AWS.
  • Aumentar para tamanhos diferentes.
  • Experimente com vários AZ. Veja se o seu tempo de inatividade real muda em comparação com a não ativação de multi-AZ.
  • Experimente durante uma janela de manutenção e compare-a com a aplicação da alteração imediatamente.

Isso vai custar um pouco mais (não é necessário ... você pode fazer a maior parte em 1-3 horas-instância), mas você terá uma resposta muito mais limpa do que revender nossas experiências em uma miríade de de diferentes ambientes RDS.

Se você ainda estiver procurando por uma resposta de "estádio de beisebol", aconselharia planejar pelo menos a degradação do desempenho no escopo de minutos, não em segundos - novamente dependendo muito do seu ambiente e configuração.

Para referência, recentemente apliquei essa operação exata para adicionar 10 GB a uma instância de tipo de 40 GB db.m1.small em uma tarde de sábado (em EST). A instância permaneceu em um estado "modificador" por aproximadamente 17 minutos. Observe que o estado de modificação não descreve o tempo de inatividade real, mas a duração em que a operação está sendo aplicado . Você não poderá aplicar alterações adicionais à instância real (embora ainda possa acessar o próprio banco de dados) e essa também é a duração em que você pode esperar que ocorra qualquer degradação de desempenho.

Se você está planejando apenas alterar o tamanho do armazenamento, uma interrupção é inesperada, mas observe que isso pode ocorrer se essa alteração for feita em conjunto com outras operações como alterar o identificador / classe da instância ou o tipo de armazenamento.

    

Answer 2

Como você está apenas aumentando o tamanho do armazenamento e não está alterando o tipo de instância nem qualquer outra coisa, não deve haver nenhum tempo de inatividade, mas pode haver um desempenho "degradado" durante a operação.

A referência que você citou é ambígua porque está discutindo a alteração do tipo de armazenamento ao mesmo tempo em que discute a alteração do tamanho do armazenamento. Se, em vez disso, você consultar "Armazenamento alocado" na tabela:

link

você verá que ele diz apenas que "O desempenho pode ser degradado" e nada sobre uma interrupção (que, em alguns casos, ocorre ao trocar o tipo de armazenamento).

Para referência, ao alterar um banco de dados MySQL de 15 GB db.m3.medium para 20 GB em eu-oeste-1 durante o dia de trabalho, a conectividade do meu aplicativo com o banco de dados era ininterrupta. No entanto, as IOPS de leitura / gravação aumentaram para entre 400-700 / s por pouco menos de 20 minutos, daí as referências ao desempenho degradado, suponho. Isso foi relatado para instâncias de banco de dados único-AZ e multi-AZ. (A instância foi reportada como "modificando" por um pouco mais que isso - cerca de 25 minutos).

Naturalmente, você pode experimentá-lo em uma instância de db idêntica ao seu banco de dados de produção antes de executá-lo em sua instância db de produção para poder ver com segurança como ele se comporta em sua situação antes de executá-lo.