Tiempo de inactividad de actualización de instancia de AWS RDS [cerrado]

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

  1. Cuál es el tiempo de inactividad al actualizar la instancia de, digamos, pequeña a grande. Es el tiempo de inactividad relativamente similar cuando va y cambia cualquier tipo de instancia (pequeña, grande, xlarge) o hay factores determinantes como el tamaño de la base de datos que alteran el tiempo.
  2. ¿Puede alguien compartir una técnica de cómo actualizar el tipo de instancia evitando el tiempo de inactividad utilizando RDS? Es eso incluso posible en RDS. No tiene que ser en gran detalle solo algunas notas de acantilado / cosas de gran imagen.
  3. ¿Hay tiempo de inactividad cuando asigna más espacio en disco?
Author: Teun Zengerink, 2011-01-28
Source

3 answers

No creo que esta sea una pregunta sobre el tema para StackOverflow en absoluto, pero algo de 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 multi-az toma alrededor de dos horas antes.

  2. Depende de cómo tengas las cosas configuradas ahora. Si ya tiene Multi-AZ habilitado, entonces se producirá una actualización de instancia en el esclavo, luego se producirá una conmutación por error, luego se actualizará el nuevo esclavo. Esto resulta en aproximadamente 1 o 2 minutos de tiempo de inactividad real. La actualización de la instancia en el esclavo generalmente toma 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 de DNS internamente para que el punto de conexión RDS apunte a la máquina correcta, por lo que es posible que tenga que reiniciar los procesos web que apuntan a la BD para que se reconecten a la BD y extraigan la nueva IP de una nueva búsqueda de DNS.

 38
Author: Dan Grossman,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-05-03 05:01:52

db.t1.micro > db.m1.pequeño : 8m30s

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

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

 14
Author: Alastair,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-09-09 02:50:37

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

2, yo diría que la creación de MULTI AZ antes de hacer la actualización haría el truco, con suerte que no tiene tiempo de inactividad, así. La pregunta es si permiten actualizar uno sin otro...

3, sí, pero no estoy 100% seguro aunque

 8
Author: DAiki,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-02-02 10:08:29