Entiendo que al actualizar a un Multi-AZ rds desde un Single-AZ, ocurre un "congelamiento de E/S de breef". ¿Qué significa eso exactamente?Dos preguntas sobre AWS 'RDS Multi AZ
Cuando se realiza una actualización a una implementación Multi-AZ, digamos de pequeña a grande, ¿se verá afectada la base de datos de producción? ¿Podrá usar el databse de copia de seguridad y luego el failover?
Las respuestas a sus preguntas están escritas:
Al elegir para pasar de simple a multi AZ AZ, breve E/S congelación ocurre. Significa que durante algún tiempo la base de datos no será accesible. No se realizarán operaciones de lectura, escritura en la base de datos. En su mayoría, la duración de esto es de alrededor de 3-4 minutos.
Sí, la base de datos de producción se verá afectada al cambiar el tamaño del cálculo (de pequeño a grande). La mejor idea para realizar operaciones de cambio de tamaño es durante la ventana de mantenimiento programado. Si selecciona la opción Aplicar de inmediato, durante algún tiempo no se podrá acceder a la base de datos (tiempo para cambiar el control al servidor de respaldo).
Saludos, Sanket dangi
el tiempo de inactividad al convertir de una sola AZ a la multi-AZ es esencialmente el tiempo que le toma a una nueva instancia para poner en marcha y ser plenamente funcional como sanket dicho, puede tómate unos minutos
la ampliación de una implementación multi-AZ primero amplía la instancia del esclavo y luego realiza una conmutación por error. el tiempo de inactividad es el tiempo que lleva realizar la conmutación por error real, generalmente más cerca de un minuto.
escalar una implementación multi-AZ se realiza mediante la adición de réplicas de lectura adicionales (que se obtienen desde el modo en espera) sin interrupción. tenga en cuenta que agregar réplicas de lectura crea un sistema eventualmente consistente que puede o no ser deseable.
, tampoco vale la pena utilizar los mismos tipos de instancias en todas las instancias multi-AZ, de lo contrario, el desequilibrio puede ocasionar retraso de réplica.
como probablemente se esté dando cuenta, lo mejor es comenzar con una configuración multi-AZ desde el principio. hace que escalar y escalar sea mucho más fácil y con menos tiempo de inactividad.
Dependiendo del motor, el esclavo debería tener una instancia más poderosa que el maestro. En MySQL, el maestro puede realizar escrituras concurrentes. El esclavo no puede realizar escrituras concurrentes al replicar. –
¿De verdad? ¿Cómo es que RDS no puede usar el modo de espera para la operación de cambio de tamaño? (Pregunta n. ° 2) – Nick
@Nick: cuando se realiza la operación de redimensionamiento, primero pasa al modo de espera. Luego, se produce la conmutación por error y el modo en espera toma la carga y se promueve como principal. Y luego, cambiar el tamaño pasa a primario. –