Alta disponibilidad (Multi-AZ) para Amazon RDS - Amazon Relational Database Service

Alta disponibilidad (Multi-AZ) para Amazon RDS

Amazon RDS proporciona alta disponibilidad y compatibilidad con la conmutación por error para las instancias de base de datos con despliegues Multi-AZ. Amazon RDS usa varias tecnologías diferentes para proporcionar compatibilidad con la conmutación por error. Las implementaciones Multi-AZ de instancias de base de datos de MariaDB, MySQL, Oracle y PostgreSQL DB usan la tecnología de conmutación por error de Amazon. Las instancias de base de datos de SQL Server utilizan creación de reflejos de base de datos (DBM) o grupos de disponibilidad (AG) Always On de SQL Server.

En un despliegue Multi-AZ, Amazon RDS aprovisiona y mantiene automáticamente una réplica en espera sincrónica dentro de una zona de disponibilidad diferente. La instancia de base de datos principal se replica de forma síncrona en distintas zonas de disponibilidad en una réplica en espera para proporcionar redundancia de datos, eliminar las congelaciones de E/S y minimizar 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 de las instancias de base de datos y las interrupciones de las zonas de disponibilidad. Para obtener más información acerca de las zonas de disponibilidad, consulte Regiones, zonas de disponibilidad y zonas locales .

nota

La característica de alta disponibilidad no es una solución de escalado para situaciones de solo lectura; no puede usar una réplica en espera para servir tráfico de lectura. Para servir tráfico de solo lectura debe usar una réplica de lectura. Para obtener más información, consulte Trabajo con réplicas de lectura.


			Situación de alta disponibilidad

Con la consola de RDS, puede crear un despliegue Multi-AZ especificando Multi-AZ al crear una instancia de base de datos. Puede usar la consola para convertir las instancias de base de datos existentes en implementaciones Multi-AZ mediante la modificación de la instancia de base de datos y la especificación de la opción Multi-AZ. También puede especificar una implementación Multi-AZ con la AWS CLI o la API de Amazon RDS. Utilice el comando de la CLI create-db-instance o modify-db-instance, o la operación de la API CreateDBInstance o ModifyDBInstance.

La consola de RDS muestra la zona de disponibilidad de la réplica en espera (denominada zona de disponibilidad secundaria). También puede utilizar el comando de la CLI describe-db-instances o la operación de la API DescribeDBInstances para buscar la AZ secundaria.

Las instancias de base de datos que usan implementaciones Multi-AZ pueden tener una latencia de escritura y confirmación superior a la de una implementación Single-AZ, a causa de la replicación de datos síncrona que se produce. Puede detectar un cambio en la latencia si la implementación conmuta a la réplica en espera, aunque AWS se ha diseñado con una conectividad de red de baja latencia entre zonas de disponibilidad. Para las cargas de trabajo de producción, es recomendable usar IOPS provisionadas y clases de instancia de base de datos que estén optimizadas para las IOPS provisionadas para obtener un rendimiento elevado y coherente. Para obtener más información acerca de las clases de instancias de bases de datos, consulte Clases de instancia de base de datos.

Modificación de una instancia de base de datos para convertirla en una implementación Multi-AZ

Si tiene una instancia de base de datos en una implementación Single-AZ y la modifica para convertirla en una implementación Multi-AZ (para motores diferentes a Amazon Aurora) Amazon RDS da varios pasos. En primer lugar, Amazon RDS crea una instantánea de la instancia de base de datos principal a partir de la implementación y, a continuación, restaura la instantánea en otra zona de disponibilidad. Después, Amazon RDS configura la replicación síncrona entre la instancia de base de datos principal y la nueva instancia.

Para obtener más información acerca de la modificación de una instancia de base de datos , consulte Modificación de una instancia de base de datos de Amazon RDS.

importante

Esta acción evita el tiempo de inactividad al convertir de Single-AZ a Multi-AZ, pero puede experimentar un impacto en el rendimiento durante y después de la conversión a Multi-AZ. Este impacto puede ser significativo para grandes instancias de base de datos con uso intensivo de escritura.

Para habilitar Multi-AZ para una instancia de base de datos, RDS toma una instantánea del volumen de EBS de la instancia de base de datos principal, lo restaura en la réplica en espera recién creada y, a continuación, sincroniza ambos volúmenes. Los nuevos volúmenes creados a partir de instantáneas de EBS existentes se cargan lentamente en segundo plano. Esta capacidad permite restaurar rápidamente volúmenes grandes a partir de una instantánea, pero existe la posibilidad de que haya más latencia durante la modificación y después de que se complete la modificación. Para obtener más información, consulte Restauración de un volumen de Amazon EBS a partir de una instantánea en la documentación de Amazon EC2.

Una vez que la modificación se ha completado, Amazon RDS desencadena un evento (RDS-EVENT-0025) que indica que el proceso se ha completado. Puede monitorizar los eventos de Amazon RDS. Para obtener más información acerca de los eventos, consulte Uso de las notificaciones de eventos de Amazon RDS.

Proceso de conmutación por error para Amazon RDS

Si se produce una interrupción planeada o no planeada de la instancia de base de datos, Amazon RDS cambia automáticamente a una réplica en espera de otra zona de disponibilidad si se ha habilitado Multi-AZ. El tiempo requerido para completar la conmutación por error dependerá de la actividad de la base de datos y de otras condiciones existentes cuando la instancia de base de datos principal dejó de estar disponible. Los tiempos de conmutación por error suelen estar entre 60–120 segundos. Sin embargo, las transacciones grandes o un proceso de recuperación largo pueden aumentar el tiempo de conmutación por error. Cuando la conmutación por error se haya completado, puede hacer falta más tiempo para que la consola de RDS refleje la nueva zona de disponibilidad.

nota

Puede forzar una conmutación por error manualmente cuando reinicie una instancia de base de datos. Para obtener más información, consulte Reinicio de una instancia de base de datos.

Amazon RDS gestiona las conmutaciones por error automáticamente para que sea posible reanudar las operaciones de la base de datos lo antes posible sin intervención administrativa. La instancia de base de datos principal conmuta automáticamente a la réplica en espera si se da cualquiera de las siguientes condiciones:

  • Una interrupción de una zona de disponibilidad

  • Un error de la instancia principal

  • El tipo del servidor de la instancia de base de datos se ha cambiado

  • Se está aplicando un parche de software en el sistema operativo de la instancia de base de datos

  • Una conmutación por error de la instancia de base de datos se inició usando Reboot with failover

Hay varias formas de determinar si se ha producido una conmutación por error en una instancia de base de datos de Multi-AZ:

  • Se pueden configurar suscripciones de eventos de base de datos para notificar por correo electrónico o por SMS que se ha iniciado una conmutación por error. Para obtener más información acerca de los eventos, consulte Uso de las notificaciones de eventos de Amazon RDS.

  • Puede ver sus eventos de base de datos mediante la consola de Amazon RDS o las operaciones de la API.

  • Puede ver el estado actual de su implementación Multi-AZ mediante la consola de Amazon RDS y las operaciones de la API.

Para obtener información acerca de la forma de responder a las conmutaciones por error, reducir el tiempo de recuperación y otras prácticas recomendadas para Amazon RDS, consulte Prácticas recomendadas para Amazon RDS.

Configuración del TTL de JVM para las búsquedas de nombres DNS

El mecanismo de conmutación por error cambia automáticamente el registro del Sistema de nombres de dominio (DNS) de la instancia de base de datos para que apunte a la instancia de base de datos en espera. Como consecuencia, necesita restablecer las conexiones existentes a la instancia de base de datos. En un entorno de máquina virtual Java (JVM), debido al funcionamiento del mecanismo de almacenamiento en caché de DNS, puede ser necesario reconfigurar los ajustes de JVM.

La JVM almacena en caché las búsquedas de nombres DNS. Cuando la JVM resuelve un nombre de host en una dirección IP, almacena en caché la dirección IP durante un periodo de tiempo especificado, conocido como tiempo de vida (TTL).

Como los recursos de AWS utilizan entradas de nombres de DNS que cambian de vez en cuando, le recomendamos que configure su JVM con un valor de TTL no superior a 60 segundos. Al hacer esto se asegurará de que cuando cambie la dirección IP de un recurso, su aplicación pueda recibir y utilizar la nueva dirección IP del recurso volviendo a consultar el DNS.

En algunas configuraciones de Java, el TTL predeterminado de JVM está establecido de forma que nunca se actualicen las entradas DNS hasta que se reinicie la JVM. Por lo tanto, si la dirección IP de un recurso de AWS cambia mientras la aplicación sigue ejecutándose, no podrá utilizar dicho recurso hasta que reinicie manualmente la JVM y se actualice la información de la dirección IP almacenada en caché. En este caso, es fundamental establecer el TTL de la JVM de forma que actualice periódicamente la información de las direcciones IP almacenada en caché.

nota

El TTL predeterminado puede variar en función de la versión de su JVM y de si está instalado un administrador de seguridad. Muchas JVM proporcionan un TTL predeterminado inferior a 60 segundos. Si utiliza una de estas JVM y no usa un administrador de seguridad, puede omitir el resto de este tema. Para obtener más información sobre los administradores de seguridad en Oracle, consulte The Security Manager en la documentación de Oracle.

Para modificar el TTL de la JVM, establezca el valor de la propiedad networkaddress.cache.ttl. Utilice uno de los siguientes métodos, en función de sus necesidades:

  • Para establecer globalmente el valor de la propiedad para todas las aplicaciones que utilizan la JVM, establezca networkaddress.cache.ttl en el archivo $JAVA_HOME/jre/lib/security/java.security.

    networkaddress.cache.ttl=60
  • Para establecer la propiedad localmente sólo para la aplicación, establezca networkaddress.cache.ttl en el código de inicialización de la aplicación antes de establecer las conexiones de red.

    java.security.Security.setProperty("networkaddress.cache.ttl" , "60");