Zonas de disponibilidad múltiples (Multi-AZ) de Amazon RDS

Amazon RDS Multi-AZ está disponible para RDS para PostgreSQL, RDS para MySQL, RDS para MariaDB, RDS para SQL Server, RDS para Oracle y RDS para Db2. Amazon RDS Multi-AZ con dos instancias en espera legibles está disponible para RDS para PostgreSQL y RDS para MySQL. Para saber cómo Amazon Aurora proporciona una disponibilidad mejorada al hacer que sus datos sean duraderos en tres zonas de disponibilidad, consulte Implementaciones multi-AZ con réplicas de Aurora.

Para las implementaciones single-AZ, multi-AZ con una instancia en espera y multi-AZ con dos instancias en espera legibles, los precios están fijados por hora de instancia de base de datos consumida desde el momento en que se lanza una instancia de base de datos hasta que se termina. Las horas parciales de la instancia de base de datos se facturan en incrementos de un segundo con un cargo mínimo de 10 minutos después de un cambio de estado que se puede facturar, como la creación, el inicio o la modificación de la clase de instancia de la base de datos.

Para obtener más información sobre los precios de Amazon RDS Multi-AZ, consulte las páginas de precio de Amazon RDS.

Utilice las siguientes guías de usuario y tutoriales para empezar rápidamente a usar Amazon RDS Multi-AZ.

Vea sesiones, seminarios web y otros vídeos para profundizar en Amazon RDS Multi-AZ.

Lea acerca de las últimas mejoras de Amazon RDS Multi-AZ y profundice en cómo puede utilizarla en sus casos de uso de Amazon RDS. 

Logre un segundo o menos de tiempo de inactividad con ProxySQL al actualizar los despliegues Amazon RDS Multi-AZ con dos sistemas de espera legibles

Conmutaciones rápidas con PgBouncer en los despliegues Amazon RDS Multi-AZ con dos modos de espera legibles para PostgreSQL

Logre un segundo o menos de tiempo de inactividad con el controlador JDBC Wrapper avanzado al actualizar los clústeres de bases de datos Amazon RDS Multi-AZ

Realice actualizaciones menores de versión con un tiempo de inactividad de 1 segundo o menos con Amazon RDS Proxy y los despliegues Amazon RDS Multi-AZ con dos modos de espera legibles

Consolidación de datos para aplicaciones analíticas mediante replicación lógica para clústeres Amazon RDS Multi-AZ

Las mejores estrategias para lograr un alto rendimiento y una alta disponibilidad en Amazon RDS para MySQL con clústeres de bases de datos Multi-AZ

Mejore el rendimiento de las aplicaciones en instancias de Amazon RDS para MySQL y MariaDB y clústeres de bases de datos Multi-AZ de MySQL con escrituras optimizadas

Elija la opción de despliegue de Amazon RDS adecuada: instancia Single-AZ, instancia Multi-AZ o clúster de bases de datos Multi-AZ

Configure Multi-AZ con Amazon RDS Custom para SQL Server

Despliegue un clúster de base de datos Multi-AZ de Amazon RDS para PostgreSQL y MySQL mediante módulos de Terraform

Nueva opción de despliegue Multi-AZ de Amazon RDS para MySQL y PostgreSQL: rendimiento de escritura mejorado y conmutación por error más rápida

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 puede utilizarse 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. Usted no interactuará directamente con la instancia en espera (por ejemplo, para operaciones de lectura) antes de que se transforme 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 un despliegue 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 un contexto de Amazon RDS, esto supone que no tendrá que supervisar los eventos de la instancia de base de datos ni iniciar la recuperación manual de la instancia de base de datos (a través de las API «RestoreDBInstanceToPointInTime» o «RestoreDBInstanceFromSnapshot») en caso de que se produzca un error en una zona de disponibilidad o en una instancia de base de datos.
 

Es posible que observe latencias elevadas en relación con los despliegues de instancias de base de datos estándar en una zona de disponibilidad única, como consecuencia de la replicación de datos sincrónica que se realiza por usted.

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 (Single-AZ) a Multi-AZ, modifique la instancia de base de datos desde la Consola de administración de AWS o utilice la API ModifyDBInstance y configure el parámetro “Multi-AZ” con el valor “true”.
 

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 su 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, puede observar un incremento de la latencia mientras los datos de la instancia en espera se actualizan para coincidir con la instancia principal.

Los despliegues 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 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 los despliegues Amazon RDS Multi-AZ no realizan una conmutación por error automática en respuesta a las operaciones de la base de datos, como las consultas de larga duración, los bloqueos o los errores de corrupción de la base de datos.

Sí, Amazon RDS emitirá un evento de instancia de base de datos para informarle que ha tenido lugar la conmutación por error automática. Puede hacer clic en la sección "Events" de la consola de Amazon RDS o utilizar la API "DescribeEvents" para obtener información acerca de 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 recomienda asimismo el uso de IOPS aprovisionadas con las instancias multi-AZ para que el procesamiento sea rápido, predecible y constante.

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 obtener acceso a esta característica a través de la Consola de administración de AWS o al utilizar 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 que se encuentren 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. Los despliegues Multi-AZ afrontan esta necesidad de la capa de la base de datos sin administración por su parte.

Usted interactúa con la copia de seguridad automatizada y la funcionalidad DB Snapshot de la misma manera si está ejecutando un despliegue estándar en un despliegue Single-AZ o 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". Estos nuevos despliegues 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 un despliegue estándar o Multi-AZ.