Multi-AZ de Amazon RDS con una instancia en espera

Conmute por error de manera automática Proteja el rendimiento de la base de datos Mejore la durabilidad Aumente la disponibilidad
Brinde soporte de alta disponibilidad para su aplicación con conmutación por error de base de datos automática con una duración de tan solo 60 segundos, cero pérdida de datos y sin necesidad de intervención manual.
Evite suspender la actividad de E/S en su instancia principal durante la copia de seguridad al realizar la copia de seguridad desde su instancia en espera.
Utilice las tecnologías de replicación síncronas de Multi-AZ de Amazon RDS para mantener los datos de su instancia de base de datos en espera tan actualizados como lo esté la principal. Mejore la disponibilidad al implementar una instancia en espera en una segunda AZ, y consiga tolerancia a errores en caso de error de una AZ o de una instancia de base de datos.

Funcionamiento

En una implementación Multi-AZ de Amazon RDS, Amazon RDS crea de manera automática una instancia de base de datos (DB) principal y replica de manera síncrona los datos en una instancia de una AZ diferente. Cuando detecta un error, Amazon RDS conmuta por error automáticamente a una instancia en espera sin necesidad de intervención manual.
Diagrama de cómo funcionan las implementaciones Multi-AZ de Amazon RDS

Multi-AZ de Amazon RDS con dos instancias en espera legibles

Conmute por error en un tiempo promedio inferior a 35 segundos Utilice puntos de conexión individuales para lecturas y escrituras Consiga una latencia de confirmación de transacción hasta dos veces superior Las actualizaciones de versión menores suelen tardar menos de 1 segundo
Conmutación por error automática en un período promedio inferior a los 35 segundos, con cero pérdida de datos y sin intervención manual. Dirija consultas a los servidores de escritura e instancias en espera de réplica de lectura apropiados para aumentar el rendimiento y la escalabilidad.  Logre una latencia de escritura hasta dos veces superior en comparación con Multi-AZ con una solo instancia en espera. Reduzca el tiempo de inactividad de las actualizaciones de versiones menores a, por lo general, menos de 35 segundos. Reduzca aún más el tiempo de inactividad, que suele ser inferior a 1 segundo, añadiendo un proxy RDS o de código abierto a su despliegue.

Funcionamiento

Implemente bases de datos MySQL o PostgreSQL de alta disponibilidad y duraderas en tres AZ con Amazon RDS Multi-AZ con dos instancias en espera legibles. Realice conmutaciones por error automáticas en un tiempo promedio inferior a 35 segundos y disfrute de una latencia de confirmación de transacción hasta dos veces más rápida en comparación con Amazon RDS Multi-AZ con una instancia en espera, además de capacidad de lectura adicional y una selección de instancias basadas en AWS Graviton2 o en Intel para computación.

Amazon Aurora

Conmute por error de manera automática en tan solo 5 segundos Optimice el rendimiento con hasta 15 réplicas de lectura Aumente la durabilidad

Logre una disponibilidad del 99,99 % 

Conmute por error de manera automática en tan solo 5 segundos en caso de error de una instancia y evite periodos de inactividad Garantice el rendimiento máximo y optimice la capacidad de lectura mediante la replicación de datos a una de las hasta 15 réplicas de lectura de baja latencia Proteja los datos en caso de errores o pérdida de una AZ con una capa de almacenamiento virtualizada respaldada por SSD que replica los datos de seis maneras en tres AZ  Proteja la disponibilidad de su base de datos con un tiempo de actividad de hasta el 99,99 % cada ciclo de facturación mensual

Funcionamiento

Amazon Aurora utiliza una capa de almacenamiento virtualizada respaldada por SSD que replica automáticamente su almacenamiento de seis maneras en tres zonas de disponibilidad, gestionando la pérdida de hasta dos copias de datos sin afectar a la disponibilidad de escritura y hasta tres copias sin repercutir en la disponibilidad de lectura.
Introducción a Amazon RDS Multi-AZ (1:20)

Introducción a Amazon RDS Multi-AZ

Las implementaciones Multi-AZ de Amazon RDS proporcionan una mayor disponibilidad y durabilidad para las instancias de bases de datos (DB) de Amazon RDS, lo que las convierte en una opción ideal para las cargas de trabajo de las bases de datos de producción. Con dos opciones de implementaciones diferentes, puede personalizar sus cargas de trabajo para que tengan la disponibilidad que necesitan.
Introducción a Amazon RDS Multi-AZ
Las implementaciones Multi-AZ de Amazon RDS proporcionan una mayor disponibilidad y durabilidad para las instancias de bases de datos (DB) de Amazon RDS, lo que las convierte en una opción ideal para las cargas de trabajo de las bases de datos de producción. Con dos opciones de implementaciones diferentes, puede personalizar sus cargas de trabajo para que tengan la disponibilidad que necesitan.

Tabla comparativa

Single-AZ de Amazon RDS o Multi-AZ de Amazon RDS con una instancia en espera legible o Multi-AZ de Amazon RDS con dos instancias en espera legibles

Característica

Single-AZ

Multi-AZ con una instancia en espera

Multi-AZ con dos instancias en espera legibles

Motores disponibles

  • Amazon RDS para PostgreSQL
  • Amazon RDS for MySQL
  • Amazon RDS para MariaDB
  • Amazon RDS para SQL Server
  • Amazon RDS para Oracle
  • Amazon RDS para Db2
  • Amazon RDS para PostgreSQL
  • Amazon RDS for MySQL
  • Amazon RDS para MariaDB
  • Amazon RDS para SQL Server
  • Amazon RDS para Oracle
  • Amazon RDS para Db2
  • Amazon RDS para PostgreSQL
  • Amazon RDS for MySQL

Capacidad de lectura
adicional

  • Ninguna: la capacidad de lectura se limita a su instancia principal
  • Ninguna: su instancia de base de datos en espera es solo un destino de conmutación por error pasivo para alta disponibilidad
  • Dos instancias de base de datos en espera actúan como destinos de conmutación por error y sirven tráfico de lectura
  • La capacidad de lectura se determina por la sobrecarga de transacciones de escritura desde la instancia principal

·        

Latencia inferior (mayor rendimiento) para confirmaciones de transacción

 

 

  • Confirmaciones de transacción hasta dos veces más rápidas en comparación con Multi-AZ de Amazon RDS con una instancia en espera

Duración de conmutación por error automática

  • No disponible: será necesaria una operación de restauración a un momento dado iniciada por el usuario.
  • Esta operación puede tardar varias horas en completarse
  • Cualquier actualización de datos posterior al último punto de restablecimiento (normalmente en los últimos cinco minutos) no estará disponible
  • Una nueva instancia principal está disponible para dar servicio a tu nueva carga de trabajo en tan solo 60 segundos
  • El tiempo de duración de la conmutación por error es independiente del rendimiento de escritura
  • Una nueva instancia principal está disponible para dar servicio a tu nueva carga de trabajo en un tiempo promedio inferior a 35 segundos
  • El tiempo de duración de la conmutación por error depende de la longitud del retraso de la réplica
Tiempo de inactividad de actualizaciones de versiones menores
  • Cuando se utilizan actualizaciones automáticas de versiones secundarias, el tiempo de inactividad de las actualizaciones de versiones menores se produce durante el período de mantenimiento de 30 minutos de Amazon RDS
  • Cuando se utilizan actualizaciones automáticas de versiones secundarias, el tiempo de inactividad de las actualizaciones de versiones menores se produce durante el período de mantenimiento de 30 minutos de Amazon RDS
  • Normalmente, menos de 1 segundo cuando los clientes añaden un código abierto o Amazon RDS Proxy a su despliegue
  • Por lo general, menos de 35 segundos con Multi-AZ con solo dos modos de espera legibles

Mayor resiliencia a una interrupción de AZ

  • Ninguna: en caso de un error de AZ, se arriesga a perder datos y horas en tiempo de conmutación por error
  • En caso de un error de AZ, su carga de trabajo conmutará por error automáticamente a la instancia en espera actualizada
  • En caso de error, una de las dos instancias en espera restantes tomará el control y servirá a la carga de trabajo (escrituras) desde la instancia principal

Fluctuación inferior para confirmaciones de transacción

  • Sin optimización para fluctuación
  • Acceso a volúmenes de registro dedicados
  • Utiliza almacenamiento local para los registros transaccionales a fin de reducir la fluctuación

Clientes

SysCloud crea copias de seguridad automática para aplicaciones de software como servicio (SaaS) críticas, supervisa archivos maliciosos y brinda información destacada sobre sus datos y el cumplimiento, todo ello en un único panel. SysCloud utiliza Multi-AZ de Amazon RDS con dos instancias en espera legibles para su sistema de supervisión interno: “La nueva opción de implementación Multi-AZ de Amazon RDS nos brinda una forma rentable de lograr un mejor rendimiento, disponibilidad y escalabilidad de lectura”, afirma Vikram Srinivasan, director de Infraestructura en SysCloud. “Con la nueva opción de implementación Multi-AZ de Amazon RDS, esperamos crear una mejor experiencia para nuestros clientes”.

Precios

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 obtener más información acerca de cómo Amazon Aurora proporciona disponibilidad mejorada al replicar automáticamente sus datos de seis maneras en tres zonas de disponibilidad, consulte Amazon Aurora.

Para los despliegues 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.

Recursos

Introducción

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

DOCUMENTACIÓN


Describe los conceptos de Amazon RDS Multi-AZ con un modo de espera y proporciona instrucciones sobre cómo modificar la instancia de base de datos para que sea una despliegue Multi-AZ y el proceso de conmutación por error para Amazon RDS.

DOCUMENTACIÓN


Describe Amazon RDS Multi-AZ con dos conceptos legibles sobre el modo de espera y proporciona instrucciones sobre la modificación, el cambio de nombre, el reinicio y la eliminación de un clúster, el uso de réplicas de lectura y el uso de la replicación lógica de PostgreSQL con clústeres de bases de datos Multi-AZ.

TUTORIAL DE INTRODUCCIÓN


En este tutorial, cree una instancia de base de datos Oracle Standard Edition Two en Amazon RDS con el modelo de licencia incluida y descubra cómo habilitar características, como Multi-AZ y Performance Insights.

Videos

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

PRESENTACIONES TÉCNICAS EN LÍNEA


En esta sesión, obtenga una breve introducción a Multi-AZ, sus opciones de despliegue y los beneficios de cada opción, y profundice en las dos opciones de espera legibles y sus mejoras recientes.

Blogs

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. 

Preguntas frecuentes

¿Qué supone la ejecución de una instancia de base de datos como un despliegue 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 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.

¿Qué es una zona de disponibilidad?

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.

¿Qué significan “primary” (principal) y “standby” (en espera) en el contexto de un despliegue multi-AZ?

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.

¿Cuáles son las ventajas de un despliegue multi-AZ?

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.
 

¿Existen implicaciones de rendimiento con respecto a la ejecución de mi instancia de base de datos como despliegue multi-AZ?

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.

¿Cómo puedo configurar un despliegue multi-AZ para una instancia de base de datos?

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”.
 

¿Qué sucede cuando convierto mi instancia de Amazon RDS de Single-AZ a multi-AZ?

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.

¿Qué eventos provocan que Amazon RDS inicie una conmutación por error a la réplica en espera?

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.

¿Me avisarán cuando se efectúe una conmutación por error automática en Amazon RDS?

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.

¿Qué ocurre durante la conmutación por error multi-AZ y cuánto tarda?

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.

¿Puedo iniciar una “conmutación por error forzada” para mi despliegue de instancia de base de datos multi-AZ?

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.

¿Cómo puedo controlar o configurar la replicación sincrónica multi-AZ?

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.

¿Estará mi réplica en espera en la misma región que la instancia principal?

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.

¿Puedo ver en qué zona de disponibilidad se encuentra actualmente mi instancia principal?

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

Después de la conmutación por error, mi principal se encuentra en una zona de disponibilidad diferente de la zona en la que se encuentra el resto de mis recursos de AWS (p. ej., las instancias EC2). ¿Debería preocuparme por la latencia?

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.

¿Cómo funcionan las instantáneas de base de datos y las copias de seguridad automáticas con mi despliegue multi-AZ?

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.

Más información sobre las características de Amazon RDS
Aprenda con tutoriales de 10 minutos

Explore Amazon RDS con simples tutoriales.

Explore la formación práctica 
Regístrese para obtener una cuenta de AWS
Comience a trabajar con Amazon RDS y Amazon Aurora

Explore la guía del usuario de Amazon RDS para comenzar.

Lea la documentación 
Comience a crear con Amazon RDS en la consola
Análisis en profundidad de Multi-AZ de Amazon RDS

Descubra con detalle cómo funciona Multi-AZ de Amazon RDS y las diferentes opciones de implementación.

Vea la sesión