Implementaciones de instancias de base de datos Multi-AZ

Amazon RDS proporciona alta disponibilidad y compatibilidad con la conmutación por error para las instancias de base de datos mediante implementaciones Multi-AZ con una instancia de base de datos única en espera. Este tipo de implementación se denomina Implementación de instancia de base de datos Multi-AZ. Amazon RDS usa varias tecnologías diferentes para proporcionar esta compatibilidad con la conmutación por error. Las implementaciones multi-AZ de instancias de base de datos de MariaDB, MySQL, Oracle, PostgreSQL y RDS Custom para SQL Server usan la tecnología de conmutación por error de Amazon. Las instancias de base de datos de Microsoft SQL Server utilizan la creación de reflejo de la base de datos (DMB) o grupos de disponibilidad (AG) Always On de SQL Server. Para obtener información sobre la compatibilidad con la versión de SQL Server para multi-AZ, consulte Implementaciones Multi-AZ para Amazon RDS for Microsoft SQL Server. Para obtener información sobre el uso de RDS Custom para SQL Server para multi-AZ, consulte Administración de una implementación multi-AZ de RDS Custom para SQL Server.

En una implementación de instancia de base de datos Multi-AZ, Amazon RDS aprovisiona y mantiene automáticamente una réplica síncrona en espera 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 y minimizar los picos de latencia durante las copias de seguridad del sistema. La ejecución de una instancia de base de datos con alta disponibilidad puede mejorar la disponibilidad durante el mantenimiento de sistema planificado. También 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 Local Zones.

nota

La opción de alta disponibilidad no es una solución de escalado para escenarios de solo lectura. No puede usar una réplica en espera para servir tráfico de lectura. Para servir tráfico de solo lectura, utilice un clúster de base de datos Multi-AZ o una réplica de lectura en su lugar. Para obtener más información acerca de los clústeres de base de datos Multi-AZ, consulte Implementaciones de clústeres de base de datos Multi-AZ. Para obtener más información acerca de las réplicas de lectura, consulte Trabajo con réplicas de lectura de instancias de base de datos.

Con la consola de RDS, puede crear una implementación de instancia de base de datos Multi-AZ si especifica la opción 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 de instancia de base de datos 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 de instancia de base de datos 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 de bases de datos Multi-AZ pueden tener una latencia de escritura y confirmación superior a la de una implementación Single-AZ. Esto puede ocurrir debido a 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 cargas de trabajo de producción, recomendamos que utilice IOPS aprovisionadas (operaciones de entrada/salida por segundo) para un rendimiento rápido y consistente. Para obtener más información sobre las clases de instancias de bases de datos, consulte Clases de instancia de base de datos de .

Modificación de una instancia de base de datos para convertirla en una implementación de base de datos 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 de instancia de base de datos Multi-AZ (para motores diferentes a Amazon Aurora) Amazon RDS realiza varias acciones.

1. Toma una instantánea de los volúmenes de Amazon Elastic Block Store (EBS) de la instancia de base de datos principal.

2. Crea nuevos volúmenes para la réplica en espera a partir de la instantánea. Estos volúmenes se inicializan en segundo plano y se alcanza el máximo rendimiento del volumen cuando los datos se han inicializado por completo.

3. Activa la replicación sincrónica a nivel de bloque entre los volúmenes de las réplicas principal y en espera.

importante

El uso de una instantánea para crear la instancia en espera evita el tiempo de inactividad al pasar 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 las cargas de trabajo sensibles a la latencia de escritura.

Si bien esta capacidad permite restaurar rápidamente grandes volúmenes a partir de instantáneas, puede provocar un aumento considerable de la latencia de las operaciones de E/S debido a la replicación sincrónica. Esta latencia puede afectar al rendimiento de la base de datos. Se recomienda encarecidamente no realizar la conversión Multi-AZ en una instancia de base de datos de producción.

Para evitar el impacto en el rendimiento de la instancia de base de datos que actualmente atiende la carga de trabajo confidencial, cree una réplica de lectura y habilite las copias de seguridad en esa réplica Convierta la réplica de lectura en Multi-AZ y ejecute consultas que carguen los datos en los volúmenes de la réplica de lectura (en ambas AZ). Esto hará que la réplica se convierta en la instancia de base de datos principal. Para obtener más información, consulte Trabajo con réplicas de lectura de instancias de base de datos.

Una instancia de base de datos se puede modificar de dos maneras para convertirla en una implementación de base de datos Multi-AZ:

Convertirla en una implementación de instancia de base de datos Multi-AZ con la consola de RDS

Puede utilizar la consola de RDS para convertir una instancia de base de datos en una implementación de instancia de base de datos multi-AZ.

Solo puede utilizar la consola para utilizar para completar la conversión. Para usar la AWS CLI o la API de RDS, siga las instrucciones que se indican en Modificación de una instancia de base de datos para convertirla en una implementación de base de datos Multi-AZ.

Para convertirla en una implementación de instancia de base de datos Multi-AZ con la consola de RDS

1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

2. En el panel de navegación, elija Databases (Bases de datos) y, a continuación, seleccione la instancia de base de datos que desee modificar.

3. En Actions (Acciones), elija Convert to Multi-AZ deployment (Convertir en implementación multi-AZ).

4. Para aplicar los cambios de forma inmediata, seleccione la opción Apply Immediately (Aplicar inmediatamente) en la página de confirmación. La elección de esta opción no provoca tiempo de inactividad, pero existe un posible impacto en el rendimiento. De forma alternativa, también puede aplicar la actualización durante la siguiente ventana de mantenimiento. Para obtener más información, consulte Configuración de programación de modificaciones.

5. Elija Convert to Multi-AZ (Convertir a Multi-AZ).

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

Puede modificar una instancia de base de datos para convertirla en una implementación de instancia de base de datos Multi-AZ de las siguientes maneras:

• Mediante la consola de RDS, modifique la instancia de base de datos y defina la Multi-AZ deployment (Implementación multi-AZ) en Yes (Sí).

• Con la AWS CLI, ejecute el comando modify-db-instance y defina la opción --multi-az.

• Con la API de RDS, llame a la operación ModifyDBInstance y establezca el parámetro MultiAZ en true.

Para obtener más información sobre la modificación de una instancia de base de datos, consulte Modificación de una instancia de base de datos de Amazon RDS. 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 monitorear los eventos de Amazon RDS. Para obtener más información sobre los eventos, consulte Uso de 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 a causa de un defecto de la infraestructura, Amazon RDS cambia automáticamente a una réplica en espera de otra zona de disponibilidad si se ha activado 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 condiciones descritas en la siguiente tabla. Puede ver los motivos de la conmutación por error en el registro de eventos.

Motivo de la conmutación por error	Descripción
Se le aplican parches al sistema operativo subyacente a la instancia de base de datos de RDS en una operación sin conexión.	Se ha desencadenado una conmutación por error durante la ventana de mantenimiento para un parche del sistema operativo o una actualización de seguridad. Para obtener más información, consulte Mantenimiento de una instancia de base de datos.
El host principal de la instancia multi-AZ de RDS no está en buen estado.	La implementación de una instancia de base de datos Multi-AZ detectó una instancia de base de datos principal deteriorada y se produjo una conmutación por error.
El host principal de la instancia multi-AZ de RDS es inaccesible debido a la pérdida de conectividad de red.	El monitoreo de RDS detectó un error de accesibilidad de la red a la instancia de base de datos principal y desencadenó una conmutación por error.
El cliente modificó la instancia de RDS.	Una modificación de la instancia de base de datos de RDS desencadenó una conmutación por error. Para obtener más información, consulte Modificación de una instancia de base de datos de Amazon RDS.
La instancia principal multi-AZ de RDS está ocupada y no responde.	La instancia de base de datos principal no responde. Le recomendamos que realice las siguientes acciones: Examine los registros de eventos y de CloudWatch en busca de uso excesivo de CPU, memoria o espacio de intercambio. Para obtener más información, consulte Uso de notificaciones de eventos de Amazon RDS y Creación de una regla que se desencadena en función de un evento Amazon RDS. Evalúe su carga de trabajo para determinar si está utilizando la clase de instancia de base de datos adecuada. Para obtener más información, consulte Clases de instancia de base de datos de . Utilice el monitoreo mejorado para las métricas del sistema operativo en tiempo real. Para obtener más información, consulte Supervisión de las métricas del sistema operativo con Supervisión mejorada. Utilice la información sobre rendimiento para ayudar a analizar cualquier problema que afecte al rendimiento de la instancia de base de datos. Para obtener más información, consulte Monitoreo de la carga de base de datos con Performance Insights en Amazon RDS. Para obtener más información sobre estas recomendaciones, consulte Información general de la supervisión de métricas en Amazon RDS y Prácticas recomendadas para Amazon RDS.
El volumen de almacenamiento subyacente al host principal de la instancia multi-AZ de RDS tuvo un error.	La implementación de una instancia de base de datos Multi-AZ detectó un problema de almacenamiento en la instancia de base de datos principal y se produjo una conmutación por error.
El usuario solicitó una conmutación por error de la instancia de base de datos.	Reinició la instancia de base de datos y eligió Reboot with failover (Reiniciar con conmutación por error). Para obtener más información, consulte Reinicio de una instancia de base de datos.

Para determinar si se produjo una conmutación por error en la instancia de base de datos Multi-AZ, puede hacer lo siguiente:

• Configure 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 sobre los eventos, consulte Uso de notificaciones de eventos de Amazon RDS.

• Visualice sus eventos de base de datos mediante la consola de RDS o las operaciones de la API.

• Puede ver el estado actual de la implementación de una instancia de base de datos Multi-AZ mediante la consola de RDS o 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 periodo de vida (TTL).

Como los recursos de AWS utilizan entradas de nombres de DNS que cambian de vez en cuando, 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 en ejecución, 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é.

Para obtener el TTL predeterminado de JVM, recupere el valor de la propiedad networkaddress.cache.ttl:

String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");

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");