Las implementaciones Multi-AZ de Amazon RDS ofrecen una mejora de la disponibilidad y la durabilidad de las instancias de base de datos (DB) de RDS, lo que las hace idóneas para las cargas de trabajo de bases de datos de producción. Cuando se aprovisiona una instancia de base de datos Multi-AZ, Amazon RDS crea automáticamente una instancia de base de datos principal y otra instancia de reserva, en la que se replican sincrónicamente los datos, en una zona de disponibilidad (AZ) diferente. Cada zona de disponibilidad se ejecuta en su propia infraestructura, independiente y físicamente distinta, y está diseñada para ofrecer elevados niveles de confianza. En caso de que se produzca un fallo en la infraestructura, Amazon RDS lleva a cabo una conmutación por error automática en el elemento en espera (o en una réplica de lectura en el caso de Amazon Aurora), de modo que puede reanudar las operaciones de la base de datos en cuanto la conmutación por error se completa. Dado que el punto de enlace de la instancia de base de datos seguirá siendo el mismo tras la conmutación por error, su aplicación podrá reanudar las operaciones de la base de datos sin necesidad de realizar una intervención administrativa manual.

Muchos motores de Amazon RDS le permiten agregar réplicas de lectura para mejorar la escalabilidad y mantener la disponibilidad de la base de datos en caso de un fallo de la zona de disponibilidad. Las réplicas de lectura de Amazon RDS se pueden configurar con sus propias instancias en espera en una zona de disponibilidad diferente. En el caso de Aurora, puede elegir situar réplicas de lectura en diferentes zonas de disponibilidad.

Amazon Aurora amplía los beneficios de las zonas de disponibilidad múltiples al emplear una capa de almacenamiento virtualizada respaldada mediante SSD y diseñada específicamente para cargas de trabajo de bases de datos. De este modo, Amazon Aurora replica el almacenamiento automáticamente de seis maneras, en tres zonas de disponibilidad. El almacenamiento de Amazon Aurora es tolerante a errores y administra de manera transparente la pérdida de hasta dos copias de datos sin que ello afecte la disponibilidad de escritura de la base de datos y hasta tres copias sin que incida en la disponibilidad de lectura. Aurora siempre replica sus datos en tres zonas de disponibilidad, sin importar si su base de datos utiliza réplicas de lectura.

Conversión de una instancia de Amazon RDS a Multi-AZ (3:01)

Beneficios

Durabilidad mejorada

Las implementaciones Multi-AZ para los motores MySQL, MariaDB, Oracle y PostgreSQL utilizan la replicación física síncrona para mantener los datos en espera sincronizados con los datos principales. Las implementaciones Multi-AZ para el motor de SQL Server usan la replicación lógica síncrona para conseguir el mismo resultado, con la tecnología de replicación nativa de SQL Server. Amazon Aurora utiliza una capa de almacenamiento virtualizada respaldada mediante SSD y diseñada específicamente para cargas de trabajo de bases de datos. Todos los enfoques protegen los datos por si se produce algún error en la instancia de base de datos o por si se pierde alguna zona de disponibilidad.

Mayor disponibilidad

Puede beneficiarse de una disponibilidad mejorada de la base de datos al ejecutar implementaciones 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, normalmente menos de un minuto para Amazon Aurora (y tan poco como 30 segundos con el conector J de Maria DB) y entre uno y dos minutos para otros motores de base de datos. (Para obtener más detalles, consulte las preguntas frecuentes sobre RDS).

Los beneficios de disponibilidad de las implementaciones Multi-AZ también se trasladan a las backups y a las tareas de mantenimiento planificadas. En caso de que se trate de actualizaciones del sistema, como revisiones del sistema operativo o escalado de la instancia de base de datos, estas operaciones se aplican primero en espera, antes de que se realice la conmutación por error automática. De esta forma, la repercusión en la disponibilidad se verá limitada, una vez más, al tiempo necesario para que se complete la conmutación por error automática.

Protección del rendimiento de su base de datos

A diferencia de las implementaciones Single-AZ, la actividad de E/S no se suspende en la instancia principal durante la realización de backups de implementaciones Multi-AZ para los motores MySQL, MariaDB, Oracle y PostgreSQL, ya que el backup se realiza a partir de la instancia en espera. No obstante, tenga en cuenta que incluso así puede experimentar latencias elevadas durante algunos minutos mientras se realizan las backups para implementaciones Multi-AZ.

Cuando falla una instancia en una implementación de Amazon Aurora, Amazon RDS utiliza la tecnología RDS Multi-AZ para automatizar la conmutación por error a una de las 15 réplicas de Amazon Aurora que ha creado en cualquiera de las tres zonas de disponibilidad. Si no se ha aprovisionado ninguna réplica de Amazon Aurora y se produce un error, Amazon RDS intentará crear automáticamente una nueva instancia de base de datos de Amazon Aurora por usted.

Conmutación por error automática

Si un volumen de almacenamiento o su instancia principal fallan en una implementación Multi-AZ, Amazon RDS inicia automáticamente una conmutación por error en el elemento actualizado (o en una réplica de lectura en el caso de Amazon Aurora). Este método difiere de las implementaciones Single-AZ, en las que, en caso de error de la base de datos, se requerirá que el usuario inicie una operación de restablecimiento a un momento dado. Esta operación puede tardar varias horas en completarse y, además, las actualizaciones posteriores al último punto de restablecimiento (normalmente en los últimos cinco minutos) no se encontrarán disponibles.

La conmutación por error de instancias de bases de datos es totalmente automática y no precisa de intervención administrativa. Amazon RDS monitorea el estado de la instancia principal y de las instancias en espera, además de iniciar una conmutación por error automáticamente como respuesta a distintas condiciones de error.

Condiciones de la conmutación por error

Las implementaciones multi-AZ de Amazon RDS 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 instancia principal

Nota: cuando se inician operaciones como el escalado de las instancias de base de datos o la actualización del sistema (por ejemplo, la aplicación de parches al sistema operativo) para las implementaciones multi-AZ a fin de mejorar la disponibilidad, se aplican primero en el elemento en espera antes de una conmutación por error automática. Consulte la documentación de Aurora para obtener detalles sobre el comportamiento de la actualización. De esta forma, la repercusión en la disponibilidad se verá limitada 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 automáticamente una conmutación por error en respuesta a operaciones de base de datos, como consultas de larga duración, interbloqueos o errores de daños en bases de datos.

Tolerancia a errores en múltiples centros de datos

Configuración

Con la utilización de la consola de administración de AWS, puede crear con facilidad nuevas implementaciones en zonas de disponibilidad múltiples (Multi-AZ) o modificar las instancias Single-AZ existentes para convertirlas en implementaciones Multi-AZ. Para crear una implementación Multi-AZ nueva con la consola de administración de AWS, solo tiene que hacer clic en “Yes” (Sí) para “Multi-AZ Deployment” (Implementación Multi-AZ) al lanzar una instancia de base de datos. Para convertir una instancia de base de datos Single-AZ existente en una implementación Multi-AZ, utilice la opción “Modify” (Modificar) correspondiente a la instancia de base de datos en la consola de administración de AWS.

Implementaciones Multi-AZ, implementaciones en varias regiones y réplicas de lectura

Las implementaciones Multi-AZ de Amazon RDS complementan a las implementaciones en varias regiones y a las réplicas de lectura. Aunque las tres funciones aumentan la disponibilidad y la durabilidad al mantener copias adicionales de sus datos, hay algunas diferencias entre ellas:

Implementaciones Multi-AZ

Implementaciones en varias regiones

Réplicas de lectura

El objetivo principal es una alta disponibilidad

El objetivo principal es la recuperación ante desastres y el rendimiento local

El objetivo principal es la escalabilidad

Sin Aurora: replicación sincrónica; Aurora: replicación asincrónica

Replicación asíncrona

Replicación asíncrona

Sin Aurora: solo la instancia principal está activa; Aurora: todas las instancias están activas

Todas las regiones son accesibles y se pueden usar para lectura

Todas las réplicas de lectura son accesibles y se pueden usar para la escalabilidad de lectura

Sin Aurora; las copias de seguridad automáticas se realizan a partir de la instancia en espera; Aurora: las copias de seguridad automática se realizan a partir de la capa de almacenamiento compartida

Las copias de seguridad automáticas se pueden realizar en cada región

No hay copias de seguridad configuradas de manera predeterminada

Siempre abarca al menos dos zonas de disponibilidad dentro de una sola región

Cada región puede contar con una implementación Multi-AZ

Puede estar dentro de una zona de disponibilidad, entre zonas distintas o entre regiones distintas

Sin Aurora: las actualizaciones de la versión del motor de base de datos ocurren en la instancia principal; Aurora: todas las instancias se actualizan juntas

Sin Aurora: las actualizaciones de la versión del motor de base de datos se ejecutan de forma independiente en cada región; Aurora: todas las instancias se actualizan juntas

Sin Aurora: la actualización de la versión del motor de base de datos es independiente de la instancia de origen; Aurora: todas las instancias se actualizan juntas

Conmutación por error automática al modo de espera (sin Aurora) o réplica de lectura (Aurora) cuando se detecta un problema

Aurora permite ascender una región secundaria a maestra

Se puede promocionar manualmente a una instancia de base de datos independiente (sin Aurora) o a una instancia principal (Aurora)

Puede combinar las implementaciones Multi-AZ con otras características de Amazon RDS para disfrutar de los beneficios de todas. Por ejemplo, puede configurar una base de datos de origen como Multi-AZ para la alta disponibilidad y crear una réplica de lectura (en Single-AZ) para la escalabilidad de lectura. O puede utilizar Aurora Global Database para replicar datos de su implementación Multi-AZ de Aurora en regiones adicionales.

Con RDS for MySQL, MariaDB, PostgreSQL y Oracle también puede establecer la réplica de lectura como Multi-AZ, lo que permite utilizarla como objetivo de recuperación de desastres. Cuando ascienda la réplica de lectura para convertirla en una base de datos independiente, ya estará habilitada para Multi-AZ.

Más información sobre las características de Amazon RDS
Más información sobre las características de RDS

Explore las características clave de Amazon RDS. 

Más información 
Regístrese para obtener una cuenta de AWS
Regístrese para obtener una cuenta gratuita

Obtenga acceso instantáneo a la capa gratuita de AWS. 

Regístrese 
Comience a crear con Amazon RDS en la consola
Comience a crear en la consola

Introducción a la consola de administración de Amazon RDS

Iniciar sesión