Los despliegues Multi-AZ de Amazon RDS ofrecen una mejora de la disponibilidad y la durabilidad de las instancias de base de datos, 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 diferente. Cada zona de disponibilidad (AZ) 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.

Amazon Aurora utiliza una capa de almacenamiento virtualizada con respaldo SSD diseñada específicamente para cargas de trabajo de bases de datos. 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 a la disponibilidad de escritura de la base de datos y hasta tres copias sin que incida en la disponibilidad de lectura. El almacenamiento de Amazon Aurora también ofrece recuperación automática. Los bloques de datos y los discos están sujetos a un análisis constante en busca de errores y se sustituyen automáticamente. Para obtener más información sobre la alta disponibilidad con Amazon Aurora, consulte la documentación online.

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

Comience con AWS de forma gratuita

Cree una cuenta gratuita

La capa gratuita de AWS incluye 750 horas de microinstancias de base de datos cada mes durante un año, 20 GB de almacenamiento y 20 GB de capacidad para backups con Amazon Relational Database Service (RDS).

Consulte los detalles de la capa gratuita de AWS »

Los despliegues 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. Los despliegues Multi-AZ para el motor de SQL Server usan la replicación lógica síncrona para conseguir el mismo resultado empleando la tecnología de reflejo nativo de SQL Server. Ambos 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.

Si un volumen de almacenamiento o su instancia principal fallan en un despliegue 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.

También puede beneficiarse de una disponibilidad mejorada de la base de datos al ejecutar despliegues 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 los despliegues 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.

A diferencia de los despliegues Single-AZ, la actividad de E/S no se suspende en la instancia principal durante la realización de backups de despliegues 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 despliegues 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.

La conmutación por error de instancias de bases de datos es totalmente automática y no precisa de intervención administrativa. Amazon RDS monitoriza 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.

Los despliegues multi-AZ de Amazon RDS detectan las situaciones de fallo más comunes y se recuperan automáticamente, por lo que puede restablecer las operaciones de base de datos lo más rápidamente 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 a principal
  • Error de unidad informática en principal
  • Error de almacenamiento en 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 los despliegues 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 los despliegues 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.

Consulte la página de precios de Amazon RDS para obtener más informació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 despliegues Multi-AZ. Para crear un despliegue Multi-AZ nuevo con la consola de administración de AWS, solo tiene que hacer clic en “Yes” para “Multi-AZ Deployment” al lanzar una instancia de base de datos. Para convertir una instancia de base de datos Single-AZ existente en un despliegue Multi-AZ, utilice la opción “Modify” correspondiente a la instancia de base de datos en la consola de administración de AWS.

Complemento de despliegues Multi-AZ de Amazon RDS Réplicas de lectura para Amazon RDS para MySQL, MariaDB y PostgreSQL. Si bien ambas características mantienen una segunda copia de sus datos, hay diferencias entre ellas:

Despliegues Multi-AZ Réplicas de lectura
Replicación síncrona de larga duración Replicación asíncrona altamente escalable
Solo el motor de base de datos en la instancia principal está activo Todas las réplicas de lectura son accesibles y se pueden usar para la escalabilidad de lectura
Los backups automáticos se realizan a partir de la instancia en espera No hay backups configurados de manera predeterminada
Siempre abarca dos zonas de disponibilidad dentro de una sola región Puede estar dentro de una zona de disponibilidad, entre AZ o entre regiones
Las actualizaciones de la versión del motor de base de datos ocurren en la instancia principal La actualización de la versión del motor de base de datos es independiente de la instancia de origen
Conmutación por error automática al modo de espera cuando se detecta un problema Se puede promocionar manualmente a una instancia de base de datos independiente

Puede utilizar conjuntamente los despliegues Multi-AZ y las réplicas de lectura para disfrutar de los beneficios que aporta cada una de estas características. 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 el escalado de lectura.

Con RDS para MySQL y MariaDB, también puede establecer la réplica de lectura como Multi-AZ, lo que le permite usar la réplica de lectura como un objetivo de DR. Cuando ascienda la réplica de lectura para que sea una base de datos independiente, ya estará habilitada para Multi-AZ. Tenga en cuenta que RDS para PostgreSQL aún no es compatible con esta función.