Alta disponibilidad para Amazon Aurora

La arquitectura de Amazon Aurora implica la separación del almacenamiento y el cómputo. Aurora incluye algunas características de alta disponibilidad que se aplican a los datos de su clúster de base de datos. Los datos se mantienen seguros incluso si alguno a todas las instancias de base de datos del clúster dejan de estar disponibles. Otras características de alta disponibilidad se aplican a las instancias de base de datos. Estas características ayudan a garantizar que una o varias instancias de base de datos estén preparadas para gestionar las solicitudes de base de datos desde su aplicación.

Alta disponibilidad para datos de Aurora

Aurora almacena copias de los datos en un clúster de base de datos en varias zonas de disponibilidad en una única Región de AWS. Aurora almacena estas copias independientemente de si las instancias de base de datos en el clúster de base de datos abarcan varias zonas de disponibilidad. Para obtener más información sobre Aurora, consulte Administración de un clúster de base de datos de Amazon Aurora.

Cuando los datos se escriben en la instancia de base de datos principal, Aurora replica de forma síncrona los datos en zonas de disponibilidad a seis nodos de almacenamiento asociados con el volumen de clúster. Este enfoque proporciona redundancia de datos, elimina los bloqueos de E/S y minimiza los picos de latencia durante las copias de seguridad del sistema. Ejecutar una instancia de base de datos con alta disponibilidad puede mejorar la disponibilidad durante el mantenimiento de sistema planificado y ayuda a proteger las bases de datos contra los errores y las interrupciones de las zonas de disponibilidad. Para obtener más información acerca de las zonas de disponibilidad, consulte Regiones y zonas de disponibilidad.

Alta disponibilidad para instancias de bases de datos de Aurora

Después de crear la instancia principal (de escritor), puede crear hasta 15 réplicas de Aurora de solo lectura. Las réplicas de Aurora también se conocen como instancias de lector.

Durante las operaciones diarias, puede descargar parte del trabajo para aplicaciones de lectura intensiva utilizando las instancias del lector para procesar consultas SELECT. Cuando un problema afecta a la instancia principal, una de estas instancias de lector toma el relevo como instancia principal. Este mecanismo se conoce como failover. Muchas características de Aurora se aplican al mecanismo de conmutación por error. Por ejemplo, Aurora detecta problemas de base de datos y activa automáticamente el mecanismo de conmutación por error cuando sea necesario. Aurora también tiene características que reducen el tiempo de finalización de la conmutación por error. Al hacerlo, se minimiza el tiempo en que la base de datos no está disponible para escribir durante una conmutación por error.

Aurora se ha diseñado para recuperarse lo más rápido posible y, por lo general, el camino más rápido hacia la recuperación es reiniciar o realizar una conmutación por error a la misma instancia de base de datos. El reinicio es más rápido e implica menos sobrecarga que la conmutación por error.

Para utilizar una cadena de conexión que permanece igual incluso cuando una conmutación por error promueve una nueva instancia principal, se conecta al punto de enlace del clúster. El punto de enlace del clúster siempre representa la instancia principal actual del clúster. Para obtener más información sobre el punto de enlace del clúster, consulte Conexiones de puntos de conexión de Amazon Aurora.

sugerencia

Dentro de cada Región de AWS, las zonas de disponibilidad representan ubicaciones distintas entre sí para proporcionar aislamiento en caso de interrupciones. Es recomendable que distribuya la instancia principal y las instancias de lectura del clúster de base de datos entre varias zonas de disponibilidad para mejorar la disponibilidad del clúster de base de datos. De esta forma, un problema que afecta a una zona de disponibilidad completa no causa una interrupción en el clúster.

Puede configurar un clúster de base de datos multi-AZ haciendo una elección sencilla al crear el clúster. Puede utilizar la AWS Management Console, la AWS CLI o la API de Amazon RDS. También puede convertir un clúster de base de datos de Aurora existente en uno multi-AZ añadiendo una nueva instancia de base de datos de lectura y especificando una zona de disponibilidad distinta.

Alta disponibilidad en todas las regiones de AWS con bases de datos de Aurora globales

Para una alta disponibilidad en varias Regiones de AWS, puede configurar bases de datos de Aurora globales. Cada base de datos global de Aurora abarca varias Regiones de AWS, lo que permite lecturas globales de baja latencia y la recuperación de desastres de interrupciones en una Región de AWS. Aurora maneja automáticamente la reproducción de todos los datos y actualizaciones desde la Región de AWS primaria a cada una de las regiones secundarias. Para obtener más información, consulte Uso de bases de datos globales de Amazon Aurora.

Tolerancia a errores para un clúster de base de datos de Aurora

Un clúster de base de datos de Aurora ofrece tolerancia a errores por diseño. El volumen del clúster abarca varias zonas de disponibilidad en una única Región de AWS y cada zona de disponibilidad contiene una copia de los datos del volumen del clúster. Esta funcionalidad significa que el clúster de base de datos puede tolerar un error de una zona de disponibilidad sin perder datos y con tan solo una interrupción breve del servicio.

Si se produce un error en la instancia principal de un clúster de base de datos, Aurora conmuta automáticamente a una nueva instancia principal de una de las dos formas siguientes:

• Promoviendo una réplica de Aurora ya existente a nueva instancia principal

• Creando una nueva instancia principal

Si el clúster de base de datos tiene una o varias réplicas de Aurora, se promueve una réplica de Aurora a instancia principal durante un evento de error. Un evento de error provoca una interrupción breve durante la cual las operaciones de lectura y escritura generan errores con una excepción. Sin embargo, el servicio se suele restaurar en menos de 60 segundos y, en muchos casos, en menos de 30 segundos. Para aumentar la disponibilidad de su clúster de base de datos, es recomendable que cree al menos una o varias réplicas de Aurora en dos o más zonas de disponibilidad diferentes.

sugerencia

En las versiones 2.10 y posteriores de Aurora MySQL, puede mejorar la disponibilidad durante una conmutación por error si tiene más de una instancia de base de datos del lector en un clúster. En las versiones 2.10 y posteriores de Aurora MySQL, Aurora reinicia solo la instancia de base de datos del escritor y la instancia del lector a la que se conmuta por error. Otras instancias del lector en el clúster siguen disponibles durante una conmutación por error para continuar el procesamiento de consultas mediante conexiones con el punto de conexión del lector.

También puede mejorar la disponibilidad durante una conmutación por error mediante el uso de RDS Proxy con el clúster de bases de datos de Aurora. Para obtener más información, consulte Alta disponibilidad con Amazon RDS Proxy.

Puede personalizar el orden en que se promueven las réplicas de Aurora a instancia principal tras un error mediante la asignación de una prioridad a cada réplica. Las prioridades van desde 0 para la prioridad más alta hasta 15 para la más baja. Si la instancia principal falla, Amazon RDS promueve la réplica de Aurora con la prioridad más alta a la nueva instancia principal. Puede modificar la prioridad de una réplica de Aurora en cualquier momento. Al modificar la prioridad, no se activa una conmutación por error.

Puede haber más de una réplica de Aurora con la misma prioridad, lo que genera niveles de promoción. Si dos o más réplicas de Aurora comparten la misma prioridad, Amazon RDS promueve la réplica que tiene un tamaño mayor. Si dos o más réplicas de Aurora tienen la misma prioridad y el mismo tamaño, Amazon RDS promueve una réplica arbitraria del mismo nivel de promoción.

Si el clúster de base de datos no contiene ninguna Réplica de Aurora, la instancia principal se vuelve a crear en la misma AZ durante un evento de error. Un evento de error provoca una interrupción durante la cual las operaciones de lectura y escritura generan errores con una excepción. El servicio se restaura cuando se crea la nueva instancia principal, un proceso que normalmente dura menos de 10 minutos. Promover una réplica de Aurora a instancia principal es mucho más rápido que crear una nueva instancia principal.

Supongamos que la instancia principal del clúster no está disponible debido a una interrupción que afecta a una zona de disponibilidad completa. En este caso, la forma de poner en línea una nueva instancia principal depende de si el clúster utiliza una configuración Multi-AZ:

• Si el clúster aprovisionado o de Aurora Serverless v2 contiene alguna instancia de lector en otras AZ, Aurora utiliza el mecanismo de conmutación por error para promover una de esas instancias de lector como la nueva instancia principal.

• Si el clúster aprovisionado o de Aurora Serverless v2 solo contiene una única instancia de base de datos, o si la instancia principal y todas las instancias de lector están en la misma zona de disponibilidad, asegúrese de crear manualmente una o más instancias de base de datos nuevas en otra zona de disponibilidad.

• Si el clúster utiliza Aurora Serverless v1, Aurora crea automáticamente una nueva instancia de base de datos en otra zona de disponibilidad. Sin embargo, este proceso implica un reemplazo de anfitrión y, por lo tanto, toma más tiempo que una conmutación por error.

nota

Amazon Aurora también admite la replicación con una base de datos de MySQL externa o una instancia de base de datos de RDS MySQL. Para obtener más información, consulte Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de Aurora (replicación de registro binario).

Alta disponibilidad con Amazon RDS Proxy

Con RDS Proxy, puede crear aplicaciones que puedan tolerar de forma transparente los errores de las bases de datos sin necesidad de escribir código complejo de gestión de errores. El proxy dirige automáticamente el tráfico a una nueva instancia de base de datos y conserva las conexiones de la aplicación. También evita las cachés del Sistema de nombres de dominio (DNS) para reducir los tiempos de conmutación por error hasta en un 66 % para las bases de datos Aurora Multi-AZ. Para obtener más información, consulte Uso de Amazon RDS Proxy para Aurora.