¿Tiempo de inactividad para aumentar el almacenamiento de AWS RDS?

Estoy buscando aumentar el almacenamiento de dos instancias RDS (solo el espacio de almacenamiento asignado, no el tipo de instancia u otros parámetros). La documentación en https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting sugiere:

Puede cambiar de almacenamiento estándar a almacenamiento de IOPS aprovisionado, o de IOPS aprovisionado a almacenamiento estándar, así como aumentar el almacenamiento, con poco o ningún tiempo de inactividad.

Definitivamente programaría una ventana de mantenimiento antes de realizar el cambio. Pero la documentación parece un poco vaga en esta área. Para alguien que podría haber hecho esto antes, ¿qué es "poco o ningún tiempo de inactividad"? ¿Puedo esperar 5 segundos o son más como 5 minutos?

Actualización de julio de 2019:

He actualizado el enlace a la documentación correcta y actualizada de AWS (que estaba rota). La documentación más reciente tiene una propaganda que también ayuda a responder la pregunta original:

En la mayoría de los casos, escalar el almacenamiento no requiere ninguna interrupción y no degrada el rendimiento del servidor. Después de modificar el tamaño de almacenamiento para una instancia de DB, el estado de la instancia de DB es Optimización de almacenamiento. La instancia de DB está completamente operativa después de una modificación de almacenamiento. Sin embargo, no puede realizar más modificaciones de almacenamiento durante seis horas o mientras el estado de la instancia de base de datos es optimización de almacenamiento, lo que sea más largo.

Sin embargo, un caso especial es si tiene una instancia de DB de SQL Server y no ha modificado la configuración de almacenamiento desde noviembre de 2017. En este caso, puede experimentar una breve interrupción de unos minutos cuando modifica su instancia de DB para aumentar la asignación asignada almacenamiento. Después de la interrupción, la instancia de DB está en línea pero en el estado de optimización de almacenamiento. El rendimiento puede verse degradado durante la optimización del almacenamiento.

Primero, tenga en cuenta que puede estar observando la operación incorrecta: describe que desea cambiar el tamaño de almacenamiento , pero ha citado documentación que describe el tipo de almacenamiento . Esta es una cuestión importante: RDS informa que no experimentará una interrupción por cambiar el tamaño de almacenamiento, sino que experimentará una interrupción por cambiar el tipo de almacenamiento.

Espere un rendimiento degradado para cambiar el tamaño del almacenamiento, cuya duración e impacto dependerán de varios factores:

• Su tipo de instancia de RDS
• Configuración
  • ¿Ocurrirá esto durante el mantenimiento?
  • ¿Ocurrirán estos cambios primero en su esclavo Multi-AZ y luego en la conmutación por error?
• Tamaño actual de la base de datos
• Tamaño de la base de datos del candidato
• Capacidad de AWS para manejar esta solicitud a la hora del día solicitada, en la zona de disponibilidad solicitada, en la región solicitada
• Tipo de motor (para usuarios de Amazon Aurora , RDS gestiona las adiciones de almacenamiento según sea necesario en incrementos de 10 GB, por lo que esta discusión es discutible)

Con esto en mente, sería mejor que lo probara usted mismo, en su entorno y en sus términos. Intenta experimentar con lo siguiente:

• Restaurar una nueva instancia de RDS a partir de una instantánea de su instancia existente y realizar esta operación en el nuevo clon.
• Con este clon:
  • Aumente el tamaño en diferentes momentos del día, cuando esperaría una carga diferente en AWS.
  • Aumentar a diferentes tamaños.
  • Pruébalo con multi-AZ. Vea si su tiempo de inactividad real cambia en comparación con no habilitar multi-AZ.
  • Pruébelo durante una ventana de mantenimiento y compárelo con la aplicación del cambio de inmediato.

Esto costará un poco más (no tiene que ... podría hacer la mayor parte de eso en 1-3 horas-instancia), pero obtendrá una respuesta mucho más limpia que vender nuestras experiencias en una miríada de diferentes RDS ambientes.

Si todavía está buscando una respuesta "aproximada", le aconsejaría que planifique al menos la degradación del rendimiento en cuestión de minutos, no segundos, una vez más, dependiendo mucho de su entorno y configuración.

Como referencia, recientemente apliqué esta operación exacta para agregar 10 GB a una instancia de tipo db.m1.small de 40 GB un sábado por la tarde (en EST). La instancia permaneció en un estado de "modificación" durante aproximadamente 17 minutos. Tenga en cuenta que el estado de modificación no describe el tiempo de inactividad real, sino la duración de la aplicación de la operación . No podrá aplicar cambios adicionales a la instancia real (aunque aún puede acceder al DB en sí) y esta es también la duración que puede esperar que ocurra cualquier degradación del rendimiento.

Si solo planea cambiar el tamaño de almacenamiento, una interrupción es inesperada, pero tenga en cuenta que puede ocurrir si este cambio se realiza junto con otras operaciones, como cambiar el identificador / clase de instancia o el tipo de almacenamiento.

Como solo está aumentando el tamaño de almacenamiento y no está cambiando el tipo de instancia ni nada más, no debería haber ningún tiempo de inactividad, pero podría haber un 'rendimiento degradado' mientras se lleva a cabo la operación.

La referencia que citó es ambigua porque se trata de cambiar el tipo de almacenamiento al mismo tiempo que se trata de cambiar el tamaño de almacenamiento. Si, en cambio, mira 'Almacenamiento asignado' en la tabla aquí:

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

verá que solo dice "El rendimiento puede verse degradado" y nada sobre una interrupción (lo que dice que ocurre en algunos casos al cambiar el tipo de almacenamiento).

Como referencia, al cambiar una base de datos MySQL db.m3.medium de 15 GB a 20 GB en eu-west-1 durante el día laboral, la conectividad de mi aplicación a la base de datos no se vio interrumpida. Sin embargo, los IOPS de lectura / escritura aumentaron a entre 400-700 / s durante poco menos de 20 minutos, de ahí las referencias al rendimiento degradado, supongo. Esto se informó tanto para instancias de bases de datos de AZ único como de AZ múltiple. (Se informó que la instancia se 'modificó' durante un poco más de tiempo, unos 25 minutos).

Naturalmente, puede probarlo en una instancia de base de datos idéntica a su base de datos de producción antes de hacerlo en su instancia de base de datos de producción para que pueda ver con seguridad cómo se comporta en su situación antes de hacerlo de verdad.