Tiempo de actualización de la instancia de AWS RDS

Question

Tengo algunas preguntas con respecto a la actualización de la instancia de RDS.

1. ¿Cuál es el tiempo de inactividad al actualizar la instancia de digamos de pequeña a grande. ¿Es el tiempo de inactividad relativamente similar cuando va y cambia cualquier tipo de instancia (pequeño, grande, xgrande) o hay factores determinantes como el tamaño de la base de datos que alteran el tiempo?
2. ¿Alguien puede compartir una técnica de cómo actualizar el tipo de instancia evitando el tiempo de inactividad usando RDS? ¿Es eso posible en RDS? No tiene que ser en gran detalle solo algunas notas de acantilado/cosas de grandes imágenes.
3. ¿Hay un tiempo de inactividad cuando asigna más espacio en disco?

Answer 1

no creo que esta es una pregunta en el tema para StackOverflow en absoluto, pero alguna información de todos modos:

1. Es significativo y depende del tamaño de la base de datos. He tenido que tomar una hora o más algunas veces. También he tenido la creación de instantáneas, la restauración de instantáneas y la creación de varias az alrededor de dos horas antes.

2. Depende de cómo haya configurado las cosas ahora. Si tiene Multi-AZ ya habilitado, entonces una actualización de instancia realmente ocurrirá en el esclavo, luego se producirá una conmutación por error y luego se actualizará el nuevo esclavo. Esto da como resultado aproximadamente 1 o 2 minutos de tiempo de inactividad real. La actualización de la instancia en el esclavo generalmente demora alrededor de 10 a 20 minutos, pero no hay tiempo de inactividad en esta configuración. Tenga en cuenta que cuando realiza la conmutación por error, Amazon realiza un intercambio DNS interno para que su punto final RDS apunte a la máquina correcta, por lo que puede tener que reiniciar sus procesos web que apuntan al DB para que se vuelvan a conectar al DB y nueva IP de una nueva búsqueda de DNS.

Answer 2

1, Desde la experiencia personal, toma poco menos de una hora, para ser precisos, 57 minutos para 15 GB de instancias de pequeño a grande. Lo cual no esperaba que fuera tan largo para ser honesto. actualización: acaba de aprender que la copia de seguridad punto de conmutación en el tiempo antes de la actualización acelera significativamente el proceso

2, yo diría que la creación de MULTI AZ antes de hacer la actualización haría el truco, ojalá que no tenga tiempo de inactividad también. La pregunta es ¿Permiten actualizar una sin la otra ...

3, sí, pero no estoy 100% seguro de que

Answer 3

db.t1.micro>db.m1.small: 8m30s

Engine: mysql 
Storage: 6GiB 
Backups: Yes 
Multi A-Z: No 

El tamaño/tipo de la base de datos no parece afectar el tiempo de inactividad de manera significativa.