Amazon RDS Multi-AZ

Cuando cree su instancia de la base de datos para que se ejecute como un despliegue Multi-AZ o la modifique con ese fin, Amazon RDS aprovisionará automáticamente una réplica "en espera" sincrónica dentro de una zona de disponibilidad diferente y la administrará. Las actualizaciones de su instancia de base de datos se replican de forma sincrónica en las zonas de disponibilidad en espera, con el fin de mantener ambas bases de datos sincronizadas y proteger las actualizaciones más recientes de su base de datos de errores de la instancia.

Durante determinados tipos de mantenimiento planificado, o en el improbable caso de que se produzca un error en la instancia de base de datos o la zona de disponibilidad, Amazon RDS conmutará por error automáticamente a la instancia en espera para que pueda reanudar las escrituras y lecturas en la base de datos en cuanto se comience a usar la instancia en espera. Dado que el registro de nombre de su instancia de base de datos no se verá modificado, su aplicación podrá reanudar la operación de la base de datos sin necesidad de intervención administrativa manual. Además, en las implementaciones Multi-AZ, la replicación es transparente. No se interactúa directamente con la instancia en espera, y esta no se puede utilizar para atender tráfico de lectura. Puede obtener más información sobre los despliegues Multi-AZ en la Guía del usuario de Amazon RDS.

Las zonas de disponibilidad son ubicaciones concretas dentro de una región que están diseñadas para estar aisladas de errores que se produzcan en otras zonas de disponibilidad. Cada zona de disponibilidad se ejecuta en su propia infraestructura, independiente y físicamente distinta, y está diseñada para ofrecer un nivel de fiabilidad alto. Los puntos comunes de error, como los generadores y el equipo de enfriamiento, no se comparten entre zonas de disponibilidad. Además, se encuentran en ubicaciones físicas diferentes, de forma que, incluso los desastres extremadamente poco frecuentes, como incendios, tornados o inundaciones, solo afecten a una sola zona de disponibilidad. Las zonas de disponibilidad que se encuentran dentro de la misma región disfrutan de conectividad a red de baja latencia.

Cuando ejecuta una instancia de base de datos como un despliegue Multi-AZ, la instancia "principal" atiende las escrituras y lecturas de la base de datos. Además, Amazon RDS aprovisiona y mantiene una instancia "en espera" en segundo plano, que es una réplica actualizada de la instancia principal. En situaciones de conmutación por error, la instancia en espera se transforma en principal. Tras la conmutación por error, la réplica en espera pasa a ser la principal y acepta las operaciones de base de datos. No interactúa directamente con la instancia en espera (por ejemplo, para operaciones de lectura) en ningún momento antes de que se conviertan en principal. Si le interesa escalar el tráfico de lectura más allá de las limitaciones de capacidad de una sola instancia de base de datos, consulte las preguntas frecuentes sobre las réplicas de lectura.

Los principales beneficios de ejecutar su instancia de base de datos como una implementación multi-AZ son la mejora de la durabilidad y la disponibilidad de la base de datos. El mayor nivel de disponibilidad y tolerancia a errores que ofrecen las implementaciones Multi-AZ las convierten en una opción ideal para los entornos de producción.

La ejecución de su instancia de base de datos como una implementación Multi-AZ protege sus datos en el improbable caso de que se produzca un error en un componente de la instancia de base de datos o una pérdida de disponibilidad en una zona de disponibilidad. Por ejemplo, si uno de los volúmenes de almacenamiento de su instancia principal falla, Amazon RDS inicia automáticamente un proceso de conmutación por error hacia la instancia en espera, en la que todas las actualizaciones de la base de datos están intactas. Esta función proporciona durabilidad de datos adicional respecto a las implementaciones estándar en una única zona de disponibilidad, donde se necesitaría una operación de restauración iniciada por el usuario y no estarían disponibles las actualizaciones producidas tras el tiempo restaurable más reciente (normalmente dentro de los últimos cinco minutos).

También se beneficia de un mayor nivel de disponibilidad de la base de datos cuando ejecuta su instancia de base de datos como una implementación Multi-AZ. Si se produce un error en la zona de disponibilidad o falla una instancia de base de datos, la repercusión en la disponibilidad estará limitada al tiempo que tarda en completarse la conmutación por error automática. Los beneficios de disponibilidad de Multi-AZ también se trasladan a las tareas de mantenimiento planificadas.

Por ejemplo, con las copias de seguridad automáticas, la actividad de E/S ya no se suspende en su instancia principal durante el periodo de respaldo preferido, dado que las copias de seguridad se recuperan a partir de la instancia en espera. En el caso de la realización de revisiones o del escalado de la clase de instancia de base de datos, estas operaciones tienen lugar primero en la instancia en espera, antes de realizar la conmutación por error automática. De esta forma, el impacto en la disponibilidad se ve limitado al tiempo necesario para que se complete la conmutación por error.

Otro de los beneficios implícitos de la ejecución de su instancia de base de datos como una implementación Multi-AZ es que la conmutación por error de la instancia de base de datos es automática y no necesita ningún tipo de administración. En el contexto de Amazon RDS, esto significa que no se requiere que supervise los eventos de la instancia de base de datos ni que inicie una recuperación manual de la instancia (mediante las API RestoreDBInstanceToPointInTime o RestoreDBInstanceFromSnapshot) en caso de una falla de la zona de disponibilidad o de la instancia de base de datos.

Es posible que observe latencias más altas en comparación con un despliegue estándar de instancia de base de datos en una sola zona de disponibilidad, como resultado de la replicación síncrona de datos que se realiza en su nombre.

Para crear un despliegue de instancia de base de datos multi-AZ, solo tiene que hacer clic en la opción “Yes” (Sí) de “Multi-AZ Deployment” (Despliegue multi-AZ) al lanzar una instancia de base de datos con la Consola de administración de AWS.

Si utiliza las API de Amazon RDS, también puede realizar una llamada a la API CreateDBInstance y configurar el parámetro “Multi-AZ” con el valor “true”. Para convertir una instancia de base de datos estándar existente (de una sola zona de disponibilidad) en Multi-AZ, modifique la instancia en la Consola de administración de AWS o utilice la operación ModifyDBInstance y establezca el parámetro MultiAZ en verdadero.

En el caso de los motores de bases de datos RDS para PostgreSQL, RDS para MySQL, RDS para MariaDB, RDS para SQL Server, RDS para Oracle y RDS para Db2, cuando decide convertir su instancia de Amazon RDS de Single-AZ a Multi-AZ, ocurre lo siguiente:

• Se genera una instantánea de la instancia principal.
• Se crea una nueva instancia en espera en una zona de disponibilidad distinta a la de la instantánea.
• Se configura la reproducción sincrónica entre las instancias principal y en espera.

No debería haber tiempo de inactividad cuando se convierte una instancia de Single-AZ a Multi-AZ. Sin embargo, es posible que observe un aumento en la latencia mientras los datos de la instancia en espera se sincronizan para igualarse con la principal.

Los despliegues de Amazon RDS Multi-AZ detectan las situaciones de error más comunes y se recuperan automáticamente, por lo que puede restablecer las operaciones de base de datos de la manera más rápida posible sin necesidad de intervención administrativa alguna. Amazon RDS realiza automáticamente una conmutación por error en los siguientes casos:

• Pérdida de disponibilidad en la zona de disponibilidad principal
• Pérdida de conectividad de red con la instancia principal
• Error de unidad informática en la instancia
• Error de almacenamiento en la instancia primaria

Nota: Cuando se inician operaciones, como el escalado de instancias de bases de datos o las actualizaciones del sistema (por ejemplo, la realización de revisiones en el sistema operativo), para las implementaciones Multi-AZ a fin de mejorar la disponibilidad, se aplican primero en la instancia en espera antes de que se realice la conmutación por error automática. De esta forma, el impacto en la disponibilidad se ve limitada solo al tiempo necesario para que se complete la conmutación por error automática. Tenga en cuenta que las implementaciones Multi-AZ de Amazon RDS no realizan conmutación por error de manera automática en respuesta a operaciones de base de datos, como consultas de larga duración, bloqueos o errores de corrupción de la base de datos.

Sí. Amazon RDS emitirá un evento de instancia de base de datos para informarle que se produjo una conmutación por error automática. Puede hacer clic en la sección “Eventos” de la consola de Amazon RDS o usar la API DescribeEvents para obtener información sobre eventos relacionados con la instancia de base de datos. También puede usar las notificaciones de eventos de Amazon RDS para que se le notifique cuando se produzcan determinados eventos en la base de datos.

Amazon RDS administra automáticamente la conmutación por error para que pueda reanudar las operaciones de la base de datos a la mayor brevedad posible y sin intervención administrativa. Durante la conmutación por error, Amazon RDS simplemente cambia el registro de nombre canónico (CNAME) de su instancia de base de datos para que apunte a la versión en espera, que se convierte en la nueva versión principal. Le sugerimos que siga las prácticas recomendadas e implemente el reintento de conexión de la base de datos en la capa de la aplicación.

Las conmutaciones por error, definidas por el intervalo que transcurre entre la detección del error en la instancia principal y la reanudación de las transacciones en la instancia en espera, suelen tardar entre uno y dos minutos. El tiempo de la conmutación por error también puede verse afectado por el volumen de transacciones que sea necesario recuperar. Para obtener los mejores resultados, se recomienda utilizar tipos de instancia de un tamaño adecuado en las implementaciones Multi-AZ. AWS también recomienda utilizar E/S por segundo aprovisionadas con instancias Multi-AZ, para lograr un rendimiento de E/S rápido, predecible y uniforme.

Amazon RDS realiza conmutaciones por error automáticas sin necesidad de que intervenga el usuario bajo determinadas condiciones de error. Además, Amazon RDS cuenta con una opción que permite iniciar la conmutación por error al momento de reiniciar la instancia. Puede acceder a esta característica desde la Consola de administración de AWS o mediante la llamada a la API RebootDBInstance.

En los despliegues Multi-AZ, únicamente tiene que establecer el parámetro “Multi-AZ” en “true”. La creación de la versión en espera, la replicación sincrónica y la conmutación por error se administran de forma automática. Esto implica que no podrá seleccionar la zona de disponibilidad en la que se encuentra situada su versión en espera, ni tampoco alterar el número de versiones en espera disponibles (Amazon RDS aprovisiona una versión en espera dedicada por cada versión principal de instancia de base de datos). Además, la versión en espera no puede configurarse para que acepte actividad de lectura de base de datos. Más información sobre las configuraciones Multi-AZ.

Sí. La versión en espera se aprovisionará de forma automática en una zona de disponibilidad diferente dentro de la misma región que la instancia de base de datos principal.

Sí, puede ver la ubicación de la instancia principal actual con la Consola de administración de AWS o la API DescribeDBInstances.

Las zonas de disponibilidad están diseñadas para ofrecer conectividad de red de baja latencia con otras zonas de disponibilidad dentro de la misma región. Además, es posible que desee considerar la posibilidad de diseñar su aplicación y otros recursos de AWS con redundancia entre varias zonas de disponibilidad, de forma que su aplicación sea resiliente en caso de producirse un error en una zona de disponibilidad. Las implementaciones Multi-AZ satisfacen esta necesidad para la capa de base de datos sin requerir administración de su parte.

El usuario interactúa con la función de copias de seguridad automáticas y con la funcionalidad de instantáneas de bases de datos de la misma forma tanto si ejecuta un despliegue estándar en una zona de disponibilidad única (Single-AZ) como un despliegue en zonas de disponibilidad múltiples (Multi-AZ). Si ejecuta una implementación Multi-AZ, las copias de seguridad automáticas y las instantáneas de bases de datos simplemente se recuperan a partir de la copia en espera para evitar la suspensión de E/S en la versión principal. Tenga en cuenta que puede experimentar una mayor latencia de E/S (normalmente dura unos minutos) durante los procesos de respaldo tanto para las implementaciones Single-AZ como Multi-AZ.

El inicio de una operación de restablecimiento (restablecimiento en un punto del tiempo o restablecimiento a partir de una instantánea de base de datos) funciona igual en implementaciones multi-AZ que en implementaciones estándar Single-AZ. Las nuevas implementaciones para instancias de base de datos pueden crearse con las API "RestoreDBInstanceFromSnapshot" o "RestoreDBInstanceToPointInTime". Estas nuevas implementaciones de instancias de base de datos pueden ser estándar o Multi-AZ, independientemente de si la copia de seguridad de origen se inició en una implementación estándar o en una implementación Multi-AZ.