Tempo de inatividade para aumentar o armazenamento do AWS RDS?

Estou procurando aumentar o armazenamento de duas instâncias RDS (apenas o espaço de armazenamento alocado, não o tipo de instância ou outros parâmetros). A documentação em https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting sugere:

Você pode alterar do armazenamento padrão para o IOPS provisionado ou do IOPS provisionado para o armazenamento padrão, além de aumentar o armazenamento, com pouco ou nenhum tempo de inatividade.

Definitivamente agendaria uma janela de manutenção antes de realizar a alteração. Mas a documentação parece um pouco vaga nessa área. Para alguém que pode ter feito isso antes, o que é "pouco ou nenhum tempo de inatividade"? Posso esperar 5 segundos ou são mais 5 minutos?

Atualização em julho de 2019:

Atualizei o link para a documentação correta e atualizada da AWS (que estava quebrada). A documentação mais recente possui um resumo que também ajuda a responder à pergunta original:

Na maioria dos casos, o dimensionamento do armazenamento não exige interrupção e não prejudica o desempenho do servidor. Depois de modificar o tamanho do armazenamento para uma instância de banco de dados, o status da instância de banco de dados é otimização de armazenamento. A instância do banco de dados está totalmente operacional após uma modificação de armazenamento. No entanto, você não pode fazer modificações adicionais no armazenamento por seis horas ou enquanto o status da instância do banco de dados for a otimização do armazenamento, o que for maior.

No entanto, um caso especial é se você possui uma instância de banco de dados do SQL Server e não modificou a configuração de armazenamento desde novembro de 2017. Nesse caso, poderá ocorrer uma curta interrupção de alguns minutos ao modificar sua instância de banco de dados para aumentar a alocação armazenamento. Após a interrupção, a instância do banco de dados está online, mas no estado de otimização de armazenamento. O desempenho pode ser prejudicado durante a otimização do armazenamento.

Primeiro, observe que você pode estar olhando para a operação incorreta - descreve que deseja alterar o tamanho do armazenamento , mas citou a documentação que descreve o tipo de armazenamento . Essa é uma distiction importante: o RDS recomenda que você não sofra uma interrupção por alterar o tamanho do armazenamento, mas que sofra uma interrupção por 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 depois no failover?
• Tamanho atual do banco de dados
• Tamanho do banco de dados candidato
• 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 , as 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ê se sentiria melhor testando isso sozinho, em seu ambiente e nos seus termos. Tente experimentar o seguinte:

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

Isso custará um pouco mais (não é necessário ... você pode fazer a maior parte disso em 1 a 3 horas-instância), mas você receberá uma resposta muito mais limpa do que vender suas experiências em uma infinidade de RDS diferentes ambientes.

Se você ainda estiver procurando por uma resposta "aproximada", aconselho a planejar pelo menos a degradação do desempenho no escopo de minutos, não segundos - novamente novamente dependente do seu ambiente e configuração.

Para referência, eu recentemente apliquei essa operação exata para adicionar 10 GB a uma instância do tipo db.m1.small de 40 GB 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 aplicada . 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 seja a duração em que você pode esperar que ocorra qualquer degradação no desempenho.

Se você planeja alterar apenas 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.

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

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 você olhar para 'Armazenamento alocado' na tabela aqui:

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html

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

Para referência, ao alterar um banco de dados MySQL db.m3.medium de 15 GB para 20 GB na eu-west-1 durante o dia útil, a conectividade do meu aplicativo ao banco de dados foi 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 de um e outro AZ. (A instância foi relatada como 'modificando' por um pouco mais do que isso - cerca de 25 minutos.)

Naturalmente, você pode testá-lo em uma instância db idêntica à sua produção db antes de fazê-lo em sua instância db de produção, para poder ver com segurança como ele se comporta na sua situação antes de realizá-lo.