¿Cuál es el impacto de modificar mi instancia Single-AZ de Amazon RDS a una instancia Multi-AZ y viceversa?

Descripción corta

En una configuración Single-AZ, una instancia de base de datos de Amazon RDS y uno o varios volúmenes de almacenamiento de Amazon Elastic Block Store (Amazon EBS) se implementan en una zona de disponibilidad. En una configuración Multi-AZ, las instancias de base de datos de Amazon RDS y los volúmenes de almacenamiento de EBS se implementan en dos zonas de disponibilidad.

Al habilitar Multi-AZ en la instancia, Amazon RDS mantiene una copia de reserva redundante y coherente de los datos mediante la replicación sincrónica del almacenamiento. Amazon RDS detecta y, a continuación, se recupera automáticamente de los escenarios de error de infraestructura más comunes para las implementaciones Multi-AZ. Esta detección y recuperación se produce para que pueda reanudar las operaciones de la base de datos lo antes posible. Para obtener más información, consulte Alta disponibilidad (Multi-AZ) para Amazon RDS.

Para cambiar una instancia de base de datos de una implementación Single-AZ a una implementación Multi-AZ y viceversa, consulte Modificación de una instancia de Amazon RDS.

Resolución

Impacto del cambio de una instancia Single-AZ a una instancia Multi-AZ

No experimentará ningún tiempo de inactividad en la instancia al cambiar la instancia Single-AZ a Multi-AZ. Durante la modificación, Amazon RDS crea una instantánea de los volúmenes de la instancia. A continuación, esta instantánea se utiliza para crear nuevos volúmenes en otra zona de disponibilidad. Aunque estos nuevos volúmenes están inmediatamente disponibles para su uso, es posible que el rendimiento se vea afectado. Este impacto se produce porque los datos del nuevo volumen se siguen cargando desde Amazon Simple Storage Service (Amazon S3). Mientras tanto, la instancia de base de datos sigue cargando datos en segundo plano. Este proceso, denominado carga lenta, puede provocar una elevada latencia de escritura y un impacto en el rendimiento durante y después del proceso de modificación.

La cantidad de impacto en el rendimiento es una función del tipo de volumen, la carga de trabajo, la instancia y el tamaño del volumen. El impacto podría ser significativo para las instancias de base de datos grandes que hacen un uso intensivo de la escritura durante las horas pico de las operaciones. Por lo tanto, es una práctica recomendada probar el impacto en una instancia de prueba antes de ejecutar esta modificación en producción. También es una práctica recomendada completar esta modificación en una ventana de mantenimiento o de bajo rendimiento.

Reducción de la duración de la carga

Para reducir de forma proactiva la duración y el impacto de la carga, haga lo siguiente:

1. Cambie el tipo de almacenamiento de instancias de base de datos a IOPS provisionadas. Asegúrese de aprovisionar una cantidad de IOPS que sea considerablemente superior a la que requiere la carga de trabajo.
   Nota: Este paso puede provocar un breve período de inactividad si la instancia utiliza un grupo de parámetros personalizado.
2. Cambio de la instancia a Multi-AZ.
3. Inicie una conmutación por error en la instancia para asegurarse de que la nueva AZ es la AZ principal.
4. Ejecute un volcado completo de los datos de la instancia. O bien, ejecute consultas de análisis de tabla completa en las tablas más activas para acelerar la carga de los datos en los volúmenes.
5. Confirme que la latencia de escritura ha vuelto a los niveles normales revisando la métrica WriteLatency en Amazon CloudWatch.
6. Cambie el tipo de almacenamiento de instancias o las IOPS a la configuración anterior.
   Nota: Este paso no requiere tiempo de inactividad.

Reducción de la latencia si la instancia ya es Multi-AZ

Para reducir la latencia si ya ha modificado la instancia a Multi-AZ, haga lo siguiente:

1. Inicie una conmutación por error en la instancia para asegurarse de que la nueva AZ es la AZ principal.
2. Cambie el tipo de almacenamiento de instancias de base de datos a IOPS provisionadas. Asegúrese de aprovisionar una cantidad de IOPS que sea considerablemente superior a la que requiere la carga de trabajo.
   Nota: Este paso no requiere tiempo de inactividad.
3. Ejecute un volcado completo de los datos de la instancia. O bien, ejecute consultas de análisis de tabla completa en las tablas más activas para acelerar la carga de los datos en los volúmenes.
4. Confirme que la latencia de escritura ha vuelto a los niveles normales revisando la métrica WriteLatency en Amazon CloudWatch.
5. Cambie el tipo de almacenamiento de instancias o las IOPS a la configuración anterior.
   Nota: Este paso no requiere tiempo de inactividad.

Si cambia una instancia de base de datos de Single-AZ a Multi-AZ, se crea una instancia en espera con la misma configuración en otra zona de disponibilidad. Esto conlleva costos adicionales. Además, debido a que Multi-AZ utiliza la replicación sincrónica, las escrituras son ligeramente más lentas que las de Single-AZ.

Impacto de cambiar una instancia Multi-AZ a una instancia Single-AZ

Cuando se cambia la instancia de Multi-AZ a Single-AZ, no se experimenta tiempo de inactividad en la instancia. Durante la modificación, Amazon RDS elimina solo la instancia secundaria y los volúmenes.La instancia principal no se ve afectada.

Estos son algunos aspectos que se deben tener en cuenta antes de cambiar una instancia de implementación de Multi-AZ a Single-AZ:

• Con la implementación Multi-AZ, Amazon RDS cambia automáticamente a la copia en espera en otra zona de disponibilidad durante una interrupción planificada o no planificada de la instancia de base de datos. En cambio, en una instancia Single-AZ, es posible que tenga que iniciar una operación de restauración a un momento dado. Esta operación puede tardar varias horas en completarse. Cualquier actualización de datos posterior al último punto de restablecimiento no esta disponible. Por lo que podría experimentar un tiempo de inactividad adicional en una instancia Single-AZ en caso de que se produzca un error.
• En una instancia Multi-AZ, las copias de seguridad automatizadas se crean a partir de la instancia secundaria durante el periodo de copia de seguridad automática. En el caso de Amazon RDS para MariaDB, Amazon RDS para MySQL, Amazon RDS para Oracle y Amazon RDS para PostgreSQL, la actividad de E/S no se suspende en la instancia principal durante la realización de la copia de seguridad en las implementaciones Multi-AZ, ya que la copia de seguridad se realiza a partir de la instancia secundaria. En el caso de Amazon RDS para SQL Server, la actividad de E/S se suspende brevemente durante la copia de seguridad para las implementaciones Multi-AZ. El proceso de copia de seguridad en una instancia de base de datos Single-AZ provoca una breve suspensión de E/S que puede durar desde unos segundos hasta unos minutos. La cantidad de tiempo depende del tamaño y la clase de la instancia de base de datos.
• En las implementaciones Multi-AZ, el mantenimiento del sistema operativo se aplica primero a la instancia secundaria. La instancia secundaria pasa a ser la principal y, a continuación, se realiza el mantenimiento en la que anteriormente era la principal, que pasa a ser la nueva instancia en espera. De este modo, el tiempo de inactividad durante la aplicación de ciertos parches en el sistema operativo en una instancia Multi-AZ es mínimo.
• Si escala la instancia Multi-AZ, el tiempo de inactividad es mínimo. Esto se debe a que la instancia secundaria se modifica primero. La instancia secundaria pasa a ser la principal. Entonces, la instancia que anteriormente era la principal, ahora la secundaria, se modifica. Una instancia Single-AZ no está disponible durante la operación de escalado.

---

Información relacionada

Implementaciones Multi-AZ de Amazon RDS