Implementaciones de clústeres de base de datos Multi-AZ

La implementación de un clúster de base de datos multi-AZ es un modo de implementación de alta disponibilidad semisíncrono de Amazon RDS con dos instancias de base de datos de réplica legibles. Un clúster de base de datos Multi-AZ tiene una instancia de base de datos del escritor y dos instancias de base de datos del lector en tres zonas de disponibilidad diferentes en la misma Región de AWS. Los clústeres de base de datos Multi-AZ proporcionan alta disponibilidad, mayor capacidad para cargas de trabajo de lectura y menor latencia de escritura en comparación con las implementaciones de las instancias de base de datos Multi-AZ.

Puede importar datos de una base de datos en las instalaciones a un clúster de base de datos Multi-AZ siguiendo las instrucciones de Importación de datos a una base de datos de Amazon RDS MariaDB o MySQL con un tiempo de inactividad reducido.

Puede comprar instancias de base de datos reservadas para un clúster de base de datos multi-AZ. Para obtener más información, consulte Instancias de base de datos reservadas para un clúster de base de datos multi-AZ.

La disponibilidad de las características varía según las versiones específicas de cada motor de base de datos y entre Regiones de AWS. Para obtener más información sobre la disponibilidad en versiones y regiones de Amazon RDS con clústeres de base de datos Multi-AZ, consulte Regiones y motores de base de datos admitidos para clústeres de bases de datos Multi-AZ en Amazon RDS.

Disponibilidad de clase de instancia para los clústeres de base de datos multi-AZ

Las implementaciones de clústeres de bases de datos multi-AZ son compatibles con las siguientes clases de instancias de base de datos: db.m5d, db.m6gd, db.m6id, db.m6idn, db.r5d, db.r6gd, db.x2iedn, db.r6id, db.r6idn y db.c6gd.

Para obtener más información sobre las clases de instancias de bases de datos, consulte Clases de instancia de base de datos de .

Información general sobre los clústeres de base de datos Multi-AZ

Con un clúster de base de datos Multi-AZ, Amazon RDS replica los datos de la instancia de base de datos del escritor en las dos instancias de base de datos del lector mediante las capacidades de replicación nativa del motor de base de datos. Cuando se realiza un cambio en la instancia de base de datos del escritor, se envía a cada instancia de base de datos del lector.

Las implementaciones de clústeres de base de datos multi-AZ utilizan la replicación semisíncrona, que requiere el reconocimiento de al menos una instancia de base de datos del lector para confirmar un cambio. No es necesario que se reconozca que los eventos se han ejecutado y confirmado en su totalidad en todas las réplicas.

Las instancias de base de datos del lector actúan como destinos de la conmutación por error automática y también proporcionan tráfico de lectura para aumentar el rendimiento de lectura de las aplicaciones. Si se produce una interrupción en la instancia de base de datos de escritor, RDS administra la conmutación por error a una de las instancias de base de datos de lector. RDS hace esto en función de qué instancia de base de datos del lector tiene el registro de cambios más reciente.

El siguiente diagrama muestra un clúster de base de datos Multi-AZ.

Los clústeres de base de datos Multi-AZ suelen tener menor latencia de escritura en comparación con las implementaciones de instancias de base de datos Multi-AZ. También permiten que las cargas de trabajo de solo lectura se ejecuten en instancias de base de datos del lector. La consola de RDS muestra la zona de disponibilidad de la instancia de base de datos del escritor y las zonas de disponibilidad de las instancias de base de datos del lector. También puede utilizar el comando de la CLI describe-db-clusters o la operación de la API DescribeDBClusters para encontrar esta información.

Administración de un clúster de base de datos Multi-AZ con la AWS Management Console

Puede administrar un clúster de base de datos Multi-AZ con la consola.

En la siguiente imagen se muestra un clúster de base de datos Multi-AZ en la consola.

Las acciones disponibles en el menú Actions (Acciones) dependen de si se ha seleccionado el clúster de base de datos Multi-AZ o una instancia de base de datos del clúster.

Elija el clúster de base de datos Multi-AZ para ver sus detalles y levar a cabo acciones en él.

Elija una instancia de base de datos en un clúster de base de datos Multi-AZ para ver los detalles de la instancia de base de datos y llevar a cabo acciones en ella.

Uso de grupos de parámetros para clústeres de base de datos Multi-AZ

En un clúster de base de datos Multi-AZ, un grupo de parámetros del clúster de base de datos funciona como un contenedor de los valores de configuración del motor que se aplican a cada instancia de base de datos en un clúster de base de datos Multi-AZ.

En un clúster de base de datos Multi-AZ, un grupo de parámetros de base de datos se establece en el grupo de parámetros de base de datos predeterminado para el motor de base de datos y la versión del motor de base de datos. La configuración del grupo de parámetros del clúster de base de datos se utiliza para todas las instancias de base de datos del clúster.

Para obtener información acerca de los grupos de parámetros, consulte Working with parameter groups (Trabajar con grupos de parámetros).

Actualización de la versión del motor de un clúster de base de datos Multi-AZ

Amazon RDS proporciona versiones más recientes de cada motor de base de datos admitido para que pueda mantener actualizado su clúster de base de datos multi-AZ. Cuando Amazon RDS admite una nueva versión de un motor de base de datos, puede elegir cuándo y cómo actualizar su clúster de base de datos Multi-AZ.

Existen dos tipos de actualizaciones que se pueden realizar:

En la actualidad, Amazon RDS solo admite actualizaciones de versiones principales para clústeres de base de datos multi-AZ de RDS para PostgreSQL. Amazon RDS admite actualizaciones de versiones secundarias para todos los motores de base de datos que admiten clústeres de base de datos multi-AZ.

Amazon RDS no actualiza réplicas de lectura de clústeres de base de datos Multi-AZ. En el caso de actualizaciones de versiones secundarias, primero debe actualizar manualmente todas las réplicas de lectura y, a continuación, actualizar el clúster. De lo contrario, la actualización se bloquea. Al actualizar la versión principal de un clúster, el estado de replicación de las réplicas de lectura cambia a terminado. Debe eliminar y volver a crear manualmente las réplicas de lectura una vez finalizada la actualización. Para obtener más información, consulte Monitoreo de la replicación de lectura.

El proceso de actualización de la versión del motor de un clúster de base de datos Multi-AZ es el mismo que el proceso de actualización de una versión del motor de instancia de base de datos. Para obtener instrucciones, consulte Actualización de una versión del motor de una instancia de base de datos. La única diferencia es que cuando se utiliza la AWS Command Line Interface (AWS CLI), se usa el comando modify-db-cluster y se especifica el parámetro --db-cluster-identifier (así como el parámetro --allow-major-version-upgrade).

Para obtener más información acerca de las actualizaciones de las versiones principales y secundarias, consulte la documentación del motor de base de datos que se indica a continuación:

Uso de RDS Proxy con clústeres de bases de datos Multi-AZ

Puede utilizar Amazon RDS Proxy para crear un proxy para sus clústeres de base de datos multi-AZ. Con RDS Proxy, las aplicaciones pueden agrupar y compartir conexiones de base de datos para mejorar su capacidad de escala. Todos los proxy hacen multiplexación de conexión, algo conocido también como reutilización de la conexión. Con la multiplexación, el proxy de RDS realiza todas las operaciones de una transacción mediante una conexión de base de datos subyacente. RDS Proxy también puede reducir el tiempo de inactividad de una actualización de una versión secundaria de un clúster de base de datos multi-AZ a un segundo o menos. Para obtener más información sobre las ventajas de RDS Proxy, consulte Uso de Amazon RDS Proxy .

Para configurar un proxy para un clúster de base de datos Multi-AZ, seleccione Creación de un proxy de RDS al crear el clúster. Para obtener instrucciones sobre cómo crear y administrar los puntos de conexión del proxy de RDS, consulte Trabajo con puntos de enlace del proxy de Amazon RDS.

Retraso de réplica y clústeres de base de datos Multi-AZ

El retraso de réplica es la diferencia de tiempo entre la última transacción en la instancia de base de datos del escritor y la última transacción aplicada en una instancia de base de datos del lector. La métrica ReplicaLag de Amazon CloudWatch representa esta diferencia de tiempo. Para obtener más información acerca de las métricas de CloudWatch, consulte Supervisión de métricas de Amazon RDS con Amazon CloudWatch.

Aunque los clústeres de bases de datos Multi-AZ permiten un alto rendimiento de escritura, puede producirse un retraso de réplica debido a la naturaleza de la replicación basada en motor. Dado que cualquier conmutación por error debe resolver el retraso de réplica antes de promover una nueva instancia de base de datos de escritor, la supervisión y administración de este retraso de réplica es una consideración.

Para clústeres de base de datos RDS para MySQL Multi-AZ, el tiempo de conmutación por error depende del retraso de réplica de las dos instancias de base de datos de lectores restantes. Ambas instancias de base de datos de lectura deben aplicar transacciones no aplicadas antes de que una de ellas se promueva a la nueva instancia de base de datos de escritor.

Para clústeres de base de datos RDS para PostgreSQL Multi-AZ, el tiempo de conmutación por error depende del retraso de réplica más bajo de las dos instancias de base de datos de lector restantes. La instancia de base de datos del lector con el retraso de réplica más bajo debe aplicar transacciones no aplicadas antes de que se promueva a la nueva instancia de base de datos del escritor.

Para ver un tutorial que le muestra cómo crear una alarma de CloudWatch cuando el retraso de la réplica supera una cantidad de tiempo establecida, consulte Tutorial: Creating an Amazon CloudWatch alarm for Multi-AZ DB cluster replica lag (Creación de una alarma de Amazon CloudWatch para el retraso de replica de un clúster de bases de datos Multi-AZ).

Causas comunes del retraso de réplica

En general, el retraso de réplica se produce cuando la carga de trabajo de escritura es demasiado alta para que las instancias de base de datos del lector apliquen las transacciones de manera eficiente. Varias cargas de trabajo pueden provocar un retraso de réplica temporal o continuo. Ejemplos de causas comunes:

Mitigación del retraso de réplica

En el caso de los clústeres de bases de datos Multi-AZ para RDS para MySQL y RDS para PostgreSQL, puede reducir la carga de la instancia de base de datos del escritor para mitigar el retraso de réplica. También puede usar el control de flujo para reducir el retraso de la réplica. El control de flujo funciona limitando las escrituras en la instancia de base de datos del escritor, lo que garantiza que el retraso de réplica no siga creciendo de forma ilimitada. La limitación de escritura se logra añadiendo un retardo al final de una transacción, lo que reduce el rendimiento de escritura en la instancia de base de datos del escritor. Aunque el control de flujo no garantiza la eliminación del retraso, puede ayudar a reducir el retraso general en muchas cargas de trabajo. Las siguientes secciones brindan información sobre el uso del control de flujo con RDS para MySQL y RDS para PostgreSQL.

Mitigación del retraso de la réplica con control de flujo para RDS para MySQL

Cuando utiliza RDS para clústeres de base de datos MySQL Multi-AZ, el control de flujo se activa de forma predeterminada mediante el parámetro dinámico rpl_semi_sync_master_target_apply_lag. Este parámetro especifica el límite superior que desea para el retraso de la réplica. A medida que el retardo de la réplica se acerca a este límite configurado, el control de flujo acelera las transacciones de escritura en la instancia de la base de datos del escritor para intentar contener el retardo de la réplica por debajo del valor especificado. En algunos casos, el retraso de réplica supera el límite especificado. De forma predeterminada, este parámetro se establece en 120 segundos. Para desactivar el control de flujo, establezca este parámetro en su valor máximo de 86 400 segundos (un día).

Para ver el retraso actual inyectado por el control de flujo, muestre el parámetro Rpl_semi_sync_master_flow_control_current_delay al ejecturar la siguiente consulta.

SHOW GLOBAL STATUS like '%flow_control%';

El resultado debería tener un aspecto similar al siguiente.

+-------------------------------------------------+-------+
| Variable_name                                   | Value |
+-------------------------------------------------+-------+
| Rpl_semi_sync_master_flow_control_current_delay | 2010  |
+-------------------------------------------------+-------+
1 row in set (0.00 sec)

Cuando tiene Información sobre rendimiento activado para un clúster de base de datos RDS para MySQL Multi-AZ, puede supervisar el evento de espera correspondiente a una instrucción SQL que indica que las consultas se retrasaron por un control de flujo. Cuando un control de flujo introdujo un retraso, puede ver el evento de espera /wait/synch/cond/semisync/semi_sync_flow_control_delay_cond correspondiente a la instrucción SQL del panel de Performance Insights (Información sobre rendimiento). Para ver estas métricas, asegúrese de que el esquema de rendimiento esté activado. Para obtener más información acerca de Información sobre rendimiento, consulte Monitoreo de la carga de base de datos con Performance Insights en Amazon RDS.

Mitigación del retraso de la réplica con control de flujo para RDS para PostgreSQL

Cuando utiliza RDS para clústeres de base de datos Multi-AZ de PostgreSQL, el control de flujo se implementa como una extensión. Activa un empleado en segundo plano para todas las instancias de base de datos en el clúster de base de datos. De forma predeterminada, los empleados en segundo plano de las instancias de base de datos del lector comunican el retraso de réplica actual al empleado en segundo plano de la instancia de base de datos del escritor. Si el retardo supera los dos minutos en cualquier instancia de base de datos del lector, el empleado en segundo plano de la instancia de base de datos del escritor agrega un retraso al final de una transacción. Para controlar el umbral de retraso, utilice el parámetro flow_control.target_standby_apply_lag.

Cuando un control de flujo limita un proceso de PostgreSQL, el evento de espera Extension en pg_stat_activity e Información sobre rendimiento lo indican. La función get_flow_control_stats muestra detalles sobre cuánto retardo se está agregando actualmente.

El control de flujo puede beneficiar a la mayoría de las cargas de trabajo de procesamiento de transacciones en línea (OLTP) que tienen transacciones cortas, pero muy simultáneas. Si el retraso se debe a transacciones de larga duración, como operaciones por lotes, el control de flujo no proporciona tanto beneficio.

Para desactivar el control de flujo, elimine la extensión de shared_preload_libraries y reinicie la instancia de base de datos.

Proceso de conmutación por error para clústeres de base de datos Multi-AZ

Si hay una interrupción planificada o no planificada de su instancia de base de datos de escritor en un clúster de base de datos Multi-AZ, Amazon RDS conmuta por error automáticamente a una instancia de base de datos de lector en una zona de disponibilidad diferente. 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 del escritor dejó de estar disponible. Los tiempos de conmutación por error suelen ser inferiores a 35 segundos. La conmutación por error se completa cuando ambas instancias de base de datos del lector han aplicado transacciones pendientes del escritor con errores. 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.

Conmutaciones por error automáticas

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. Para llevar a cabo la conmutación por error, la instancia de base de datos del escritor cambia automáticamente a una instancia de base de datos del lector.

Conmutación por error manual de un clúster de base de datos Multi-AZ

Si lleva a cabo una conmutación por error manual de un clúster de base de datos multi-AZ, RDS primero termina la instancia de base de datos principal. Luego, el sistema de monitorización interna detecta que la instancia de base de datos principal no se encuentra en buen estado y promueve una instancia de base de datos de réplica legible. Los tiempos de conmutación por error suelen ser inferiores a 35 segundos.

Puede llevar a cabo una conmutación por error manual de un clúster de base de datos Multi-AZ mediante la AWS Management Console, la AWS CLI o la API de RDS.

aws rds failover-db-cluster --db-cluster-identifier mymultiazdbcluster

Determinar si se ha llevado a cabo una conmutación por error en un clúster de base de datos Multi-AZ

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

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 del lector. 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 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: