¿Qué ocurre cuando cambio mi instancia de base de datos de RDS de un despliegue single-AZ a multi-AZ o de un despliegue single-AZ a multi-AZ?

Resolución

Elección del tipo de despliegue para tu caso de uso

Antes de cambiar el tipo de despliegue, revisa las siguientes diferencias entre los despliegues multi-AZ y single-AZ:

• Una configuración single-AZ despliega una instancia de base de datos de RDS y volúmenes de almacenamiento de Amazon Elastic Block Store (Amazon EBS) en una zona de disponibilidad.
• Una configuración multi-AZ despliega una instancia y volúmenes de almacenamiento de EBS en dos zonas de disponibilidad.
• Cuando utilizas el despliegue multi-AZ, Amazon RDS mantiene una copia en espera de tus datos. Amazon RDS detecta los errores de infraestructura y, a continuación, se recupera automáticamente de ellos para que puedas reanudar rápidamente las operaciones de la base de datos.
• Cuando utilizas el despliegue single-AZ, es posible que tengas que iniciar una operación de recuperación a un momento dado (PITR) durante una interrupción planificada o no planificada. Una operación PITR puede tardar varias horas en completarse. Las actualizaciones de datos que se producen después del último tiempo de restauración no están disponibles, por lo que es posible que experimentes un tiempo de inactividad adicional.
• Para un despliegue multi-AZ, Amazon RDS crea instantáneas de bases de datos y copias de seguridad automatizadas desde la instancia secundaria durante el periodo de copia de seguridad automática. El proceso de copia de seguridad no suspende la actividad de E/S en la instancia principal porque Amazon RDS toma la copia de seguridad de la instancia secundaria para los motores de bases de datos de Amazon RDS para MariaDB, Amazon RDS para MySQL, Amazon RDS para Oracle y Amazon RDS para PostgreSQL. En el caso de Amazon RDS para SQL Server, el proceso de copia de seguridad suspende brevemente la actividad de E/S.
• En un despliegue single-AZ, el proceso de copia de seguridad 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.
• Para los despliegues multi-AZ, Amazon RDS aplica primero las operaciones de mantenimiento del sistema operativo (SO) y escalamiento a la instancia secundaria. Amazon RDS promueve la instancia secundaria para que pase a ser la instancia principal y, a continuación, realiza tareas de mantenimiento o modificaciones en la instancia principal anterior. La instancia principal anterior se convierte en la nueva instancia en espera. Por lo tanto, el tiempo de inactividad es mínimo durante ciertas operaciones de escalamiento o parches del sistema operativo.
• Una instancia single-AZ no está disponible durante una operación de escalamiento.

Nota: No experimentas tiempos de inactividad en la instancia cuando cambias de un tipo de despliegue a otro.

Modificación del tipo de despliegue de multi-AZ a single-AZ

Modifica el tipo de despliegue.

Cuando cambias la instancia de un despliegue multi-AZ a un despliegue single-AZ, Amazon RDS elimina solo la instancia secundaria y los volúmenes. La modificación no afecta a la instancia principal.

Modificación del tipo de despliegue de single-AZ a multi-AZ

Modifica el tipo de despliegue.

Cuando cambias la instancia de un despliegue single-AZ a un despliegue multi-AZ, Amazon RDS crea una instantánea de los volúmenes de la instancia. Amazon RDS usa la instantánea para crear nuevos volúmenes en otra zona de disponibilidad. Los nuevos volúmenes están disponibles de inmediato para su uso.

Sin embargo, es posible que experimentes un aumento de la latencia de escritura durante y después del proceso de modificación debido a la carga lenta. Esto ocurre porque la instancia carga los datos del nuevo volumen desde Amazon Simple Storage Service (Amazon S3) en segundo plano. Para obtener más información, consulta Restauración a una instancia de base de datos.

La cantidad de latencia que experimentes depende del tipo de volumen, la carga de trabajo, la instancia y el tamaño del volumen. Por lo tanto, se recomienda modificar una instancia de prueba antes de modificar la instancia de producción. También se recomienda modificar la instancia en un periodo de mantenimiento o de bajo rendimiento.

Para reducir la duración de la carga y la latencia de escritura, sigue estos pasos:

1. Cambia el tipo de almacenamiento de la instancia a Operaciones de entrada/salida aprovisionadas por segundo (IOPS). Aprovisiona una cantidad de IOPS que sea mucho mayor de lo que requiere tu carga de trabajo.
   Nota: Si la instancia usa un grupo de parámetros personalizado, puede producirse un tiempo de inactividad al cambiar el tipo de almacenamiento.
2. Si no has cambiado el tipo de despliegue, modifica la instancia para que sea un despliegue multi-AZ.
3. Inicia una conmutación por error en la instancia para asegurarte de que la nueva zona de disponibilidad sea la zona de disponibilidad principal.
4. Realiza un volcado completo de los datos de tu instancia. O bien, ejecuta consultas de análisis de tablas completas en las tablas más activas para cargar rápidamente los datos en los volúmenes.
5. Revisa la métrica WriteLatency en Amazon CloudWatch para confirmar que la latencia de escritura vuelve a los niveles normales.
6. Vuelve a cambiar el tipo de almacenamiento de la instancia o las IOPS a tu configuración anterior.
   Nota: El tiempo de inactividad no se produce cuando vuelves a cambiar el tipo de almacenamiento.

Cuando cambias una instancia de un despliegue single-AZ a un despliegue multi-AZ, Amazon RDS crea una instancia en espera con la misma configuración en otra zona de disponibilidad. La instancia en espera puede generar costes adicionales. Además, dado que un despliegue multi-AZ usa replicación sincrónica, las escrituras son un poco más lentas que en un despliegue single-AZ.

Información relacionada

Amazon RDS Multi-AZ