Escalado a cero ACU con pausa y reanudación automáticas para Aurora Serverless v2 - Amazon Aurora
Descripción general de la pausa automática Requisitos previos y limitaciones Activación y desactivación de la pausa automática Funcionamiento de la pausa automática Configuraciones de los clústeres de Aurora y de la pausa automática Supervisión de la pausa automática Solución de problemas para la característica de pausa automática Diseño de la aplicación para la pausa automática

Escalado a cero ACU con pausa y reanudación automáticas para Aurora Serverless v2

Puede especificar que las instancias de base de datos de Aurora Serverless v2 se reduzcan verticalmente hasta cero ACU y que se pausen automáticamente si no tienen ninguna conexión iniciada por la actividad del usuario en un período de tiempo específico. Para ello, especifique un valor mínimo de ACU igual a cero para su clúster de base de datos. Mientras la instancia esté en pausa, no se le cobrará por la capacidad de las instancias. Habilitar la característica de pausa y reanudación automáticas (pausa automática) para los clústeres de Aurora que se utilizan poco o tienen períodos prolongados de inactividad puede ayudarlo a administrar los costos de su flota de bases de datos.

nota

La característica de pausa automática está disponible para Aurora Serverless v2 tanto con Aurora PostgreSQL como con Aurora MySQL. Es posible que necesite actualizar la versión del motor de base de datos de Aurora para aprovechar esta característica. Para ver las versiones de motor en las que hay disponible una capacidad mínima de 0 ACU, consulte Capacidad de Aurora Serverless v2.

Descripción general de la característica de pausa automática de Aurora Serverless v2

Las instancias de base de datos de Aurora Serverless v2 pueden pausarse automáticamente después de un período sin conexiones de usuario y reanudarse automáticamente cuando llega una solicitud de conexión. La característica de pausa y reanudación automática de Aurora Serverless v2 ayuda a administrar los costos de los sistemas que no tienen un objetivo de nivel de servicio (SLO) estricto. Por ejemplo, puede habilitar esta característica para los clústeres que se utilizan para el desarrollo y las pruebas, o para las aplicaciones internas en las que se admite una breve pausa mientras se reanuda la base de datos. Si su carga de trabajo tiene períodos de inactividad y puede tolerar pequeños retrasos en la conexión mientras se reanuda la instancia, considere la posibilidad de utilizar la pausa automática con las instancias de Aurora Serverless v2 para reducir los costos.

Para controlar este comportamiento, especifique si las instancias de base de datos de Aurora Serverless v2 de un clúster se pueden pausar automáticamente o no, y cuánto tiempo debe permanecer inactiva cada instancia antes de que se detenga. Para habilitar el comportamiento de pausa automática para todas las instancias de base de datos de Aurora Serverless v2 de un clúster de Aurora, establezca el valor de capacidad mínima del clúster en cero ACU.

Si anteriormente utilizaba la característica de Aurora Serverless v1 que escalaba hasta cero ACU tras un período de inactividad, puede actualizar Aurora Serverless v2 y utilizar la característica de pausa automática correspondiente.

Los beneficios de ahorro de costos de la característica de pausa automática son similares a los del uso de la característica de parar o iniciar el clúster. La pausa automática de Aurora Serverless v2 tiene las ventajas adicionales de una reanudación más rápida que iniciar un clúster detenido y de automatizar el proceso de determinar cuándo pausar y reanudar cada instancia de base de datos.

La característica de pausa automática también proporciona mayor grado de detalle a la hora de controlar los costos de los recursos de computación del clúster. Puede activar algunas instancias de lector para que se detengan incluso mientras la instancia de escritor y otros lectores del clúster permanecen activos en todo momento. Para ello, asigne a las instancias de lector que se pueden pausar independientemente de otras instancias una prioridad de conmutación por error del orden de 2 a 15.

Las instancias de escritor y todas las instancias de lector con prioridad de conmutación por error de 0 y 1 siempre se pausan y se reanudan al mismo tiempo. Por lo tanto, las instancias de este grupo se detienen cuando ninguna de ellas tiene conexión durante el intervalo de tiempo especificado.

Los clústeres de base de datos de Aurora pueden contener una combinación de instancias de base de datos de escritor y de lector e instancias de base de datos de Aurora Serverless v2 y aprovisionadas. Por lo tanto, para utilizar esta característica de forma eficaz, es útil comprender los siguientes aspectos del mecanismo de pausa automática:

  • las circunstancias en las que una instancia de base de datos puede pausarse automáticamente,

  • cuándo se puede impedir que una instancia de base de datos se detenga. Por ejemplo, habilitar algunas características de Aurora o realizar ciertos tipos de operaciones en el clúster puede evitar que las instancias se detengan, incluso sin ninguna conexión a esas instancias.

  • las consecuencias para la supervisión y la facturación mientras una instancia está pausada,

  • qué acciones hacen que una instancia de base de datos reanude el procesamiento,

  • cómo cambia la capacidad de una instancia de base de datos en torno al momento de la pausa y la reanudación de los eventos,

  • cómo controlar el intervalo de inactividad antes de que una instancia de base de datos se pause,

  • cómo codificar la lógica de la aplicación para gestionar el período durante el cual una instancia de base de datos reanuda el procesamiento.

Requisitos previos y limitaciones de la característica de pausa automática de Aurora Serverless v2

Antes de utilizar la característica de pausa automática, compruebe qué versiones de motor debe utilizar. Además, debe comprobar si la pausa automática funciona en combinación con las demás características de Aurora que desee utilizar. No puede activar la pausa automática si utiliza una versión del motor que no la admite. En el caso de las características incompatibles, no obtendrá ningún error si las utiliza en combinación con la pausa automática. Si el clúster utiliza características o ajustes incompatibles, las instancias de Aurora Serverless v2 no se pausarán automáticamente.

Determinadas condiciones o ajustes impiden que las instancias de Aurora Serverless v2 se detengan automáticamente. Para obtener más información, consulte Situaciones en las Aurora Serverless v2 que no se pausa automáticamente.

Activación y desactivación de la característica de pausa automática

Puede activar y desactivar la característica de pausa automática en el nivel de clúster. Para ello, debe utilizar los mismos procedimientos que cuando ajusta la capacidad mínima y máxima del clúster. La característica de pausa automática está representada por una capacidad mínima de 0 ACU.

Activación de la pausa automática para las instancias de Aurora Serverless v2 de un clúster

Siga el procedimiento indicado en Configuración del rango de capacidad de Aurora Serverless v2 para un clúster. Para obtener la capacidad mínima, elija 0 ACU. Si elige una capacidad mínima de 0 ACU, también puede especificar el tiempo que debe permanecer inactiva la instancia antes de que se pause automáticamente.

El siguiente ejemplo de la CLI muestra cómo puede crear un clúster de Aurora con la característica de pausa automática habilitada y el intervalo de pausa automática establecido en diez minutos (600 segundos). 

aws rds create-db-cluster \
    --db-cluster-identifier my-serverless-v2-cluster \
    --region eu-central-1 \
    --engine aurora-mysql \
    --engine-version 8.0 \
    --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 \
    --master-username myuser \
    --manage-master-user-password

El siguiente ejemplo de la CLI muestra cómo puede activar la característica de pausa automática para un clúster de Aurora existente. En este ejemplo, se establece el intervalo de pausa automática en una hora (3600 segundos). 

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=80,SecondsUntilAutoPause=3600

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 0,
    "MaxCapacity": 80.0,
    "SecondsUntilAutoPause": 3600
}

Intervalo de tiempo de espera de la pausa automática de Aurora Serverless v2 configurable

El intervalo de tiempo de espera se representa en el atributo ServerlessV2ScalingConfiguration del clúster de Aurora. Puede especificar este intervalo en la AWS Management Console al crear o modificar un clúster de Aurora, si la capacidad mínima está establecida en cero ACU. Puede especificarlo en la AWS CLI con el parámetro --serverless-v2-scaling-configuration al crear o modificar un clúster de Aurora. Puede especificarlo en la API de RDS con el parámetro ServerlessV2ScalingConfiguration al crear o modificar un clúster de Aurora.

El intervalo mínimo que puede establecer es de 300 segundos (cinco minutos). Es el valor predeterminado si no especifica un intervalo. El intervalo máximo que puede establecer es 86 400 segundos (un día).

Suponga que desactiva la característica de pausa automática de un clúster al cambiar la capacidad mínima del clúster a un valor distinto de cero. En ese caso, la propiedad del intervalo se elimina del atributo ServerlessV2ScalingConfiguration. La ausencia de esa propiedad proporciona una confirmación adicional de que la característica de pausa automática está desactivada para ese clúster. Si más adelante vuelve a activar la pausa automática, podrá volver a especificar cualquier intervalo personalizado en ese momento.

Reanudación de una instancia de Aurora Serverless v2 pausada automáticamente

  • Cuando se conecta a una instancia de Aurora Serverless v2 pausada, se reanuda automáticamente y acepta la conexión.

  • Si se intenta conectar con credenciales no válidas, la instancia de base de datos se reanudará igualmente.

  • Si se conecta a través del punto de conexión del escritor, Aurora reanuda la instancia de base de datos de escritor si se ha pausado automáticamente. Al mismo tiempo, Aurora reanuda cualquier instancia de lector pausada automáticamente que tenga una prioridad de conmutación por error de 0 o 1, lo que significa que su capacidad está vinculada a la capacidad de la instancia de escritor.

  • Si se conecta a través del punto de conexión del lector, Aurora elige una instancia de lector de forma aleatoria. Si la instancia del lector está pausada, Aurora la reanuda. Aurora también reanuda primero la instancia de escritor, pues la instancia de escritor debe estar siempre activa si hay alguna instancia de lector activa. Cuando Aurora reanuda esa instancia de escritor, también se reanudan las instancias de lector de los niveles de promoción cero y uno de conmutación por error.

  • Si envía una solicitud al clúster a través de la API de datos de RDS, Aurora reanuda la instancia de escritor si está pausada. A continuación, Aurora procesa la solicitud de la API de datos.

  • Al cambiar el valor de un parámetro de configuración en un grupo de parámetros de clúster de base de datos, Aurora reanuda automáticamente las instancias de Aurora Serverless v2 pausadas en todos los clústeres que utilizan ese grupo de parámetros de clúster. De igual modo, al cambiar el valor de un parámetro en un grupo de parámetros de base de datos, Aurora reanuda automáticamente las instancias de Aurora Serverless v2 pausadas que utilizan ese grupo de parámetros de base de datos. El mismo comportamiento de reanudación automática se aplica cuando se modifica un clúster para asignar un grupo de parámetros de clúster diferente o cuando se modifica una instancia para asignar un grupo de parámetros de base de datos diferente.

  • Al realizar una solicitud de retroceso, se reanuda automáticamente la instancia de escritor de Aurora Serverless v2 si está pausada. Aurora procesa la solicitud de retroceso después de que se reanude la instancia de escritor. Puede retroceder hasta un momento en el que se pausó una instancia de Aurora Serverless v2.

  • Si se toma una instantánea de un clúster o se elimina una instantánea, no se reanudará ninguna instancia de Aurora Serverless v2.

  • La creación de un clon de Aurora hace que Aurora reanude la instancia de escritor del clúster que se está clonando.

  • Si una instancia pausada recibe una gran cantidad de solicitudes de conexión antes de que termine de reanudarse, es posible que algunas sesiones no puedan conectarse. Recomendamos implementar la lógica de reintento para las conexiones a los clústeres de Aurora que tienen algunas instancias de Aurora Serverless v2 con la pausa automática activada. Por ejemplo, puede volver a intentar cualquier conexión fallida tres veces.

  • Aurora puede realizar algunos tipos de mantenimiento interno menores sin activar una instancia. Sin embargo, algunos tipos de mantenimiento que se realizan durante el período de mantenimiento del clúster requieren que Aurora reanude la instancia. Cuando finaliza el mantenimiento, la instancia se vuelve a pausar automáticamente si no hay más actividad después del intervalo especificado.

    nota

    Aurora no reanuda automáticamente una instancia pausada para tareas programadas específicas del motor, como las de la extensión pg_cron de PostgreSQL o el programador de eventos de MySQL. Para garantizar que dichos trabajos se ejecuten, debe iniciar una conexión manual con la instancia antes de la hora programada. Aurora no pone en cola ningún trabajo en el que se cumpla la hora programada mientras la instancia de base de datos esté pausada. Estos trabajos se omiten cuando la instancia se reanuda más tarde.

  • Si el clúster de Aurora se somete a una conmutación por error mientras una instancia de Aurora Serverless v2 se pausa automáticamente, Aurora podría reanudar una instancia y, a continuación, convertirla en la instancia de escritor. Lo mismo puede ocurrir si se eliminan una o más instancias de base de datos del clúster mientras una instancia está pausada. En este caso, la instancia pasa a ser de escritor inmediatamente después de reanudarse.

  • Las operaciones que cambian las propiedades del clúster también hacen que se reanuden las instancias de Aurora Serverless v2 pausadas automáticamente. Por ejemplo, una instancia pausada automáticamente se reanuda para operaciones como las siguientes:

    • Cambiar el rango de escalado del clúster.

    • Actualizar la versión del motor del clúster.

    • Describir o descargar archivos de registro de una instancia pausada. Para examinar los datos de registro históricos de las instancias pausadas, habilite las cargas de registros en CloudWatch y analice los registros a través de CloudWatch.

Desactivación de la pausa automática para las instancias de Aurora Serverless v2 de un clúster

Siga el procedimiento indicado en Configuración del rango de capacidad de Aurora Serverless v2 para un clúster. Para la capacidad mínima, elija un valor de 0,5 o superior. Al desactivar la característica de pausa automática, se restablece el intervalo de inactividad de la instancia. Si vuelve a activar la pausa automática, debe especificar un nuevo intervalo de tiempo de espera.

El siguiente ejemplo de la CLI muestra cómo puede desactivar la característica de pausa automática para un clúster de Aurora existente. El resultado describe-db-clusters muestra que el atributo SecondsUntilAutoPause se elimina cuando la capacidad mínima se establece en un valor distinto de cero. 

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 2,
    "MaxCapacity": 80.0
}

Funcionamiento de la característica de pausa automática de Aurora Serverless v2

Puede utilizar la siguiente información para planificar el uso de la característica de pausa automática. Comprender las circunstancias en las que las instancias se detienen, se reanudan o permanecen activas puede ayudarlo a equilibrar las ventajas y desventajas entre disponibilidad, capacidad de respuesta y ahorro de costos.

Qué sucede cuando se pausan las instancias de Aurora Serverless v2

Cuando una instancia de base de datos de Aurora Serverless v2 se detiene tras un período sin conexiones:

  • Aurora comienza a pausar la instancia una vez transcurrido el intervalo especificado sin conexiones a la instancia, independientemente del número de ACU que tenga la instancia en ese momento.

  • El mecanismo de pausa no es instantáneo. Es posible que una instancia de Aurora Serverless v2 que esté a punto de pausarse automáticamente espere un momento para actualizarse con todos los cambios en el almacenamiento de Aurora.

  • Los cargos de la instancia correspondientes a esa instancia se ponen en espera. La métrica ServerlessV2Usage tiene un valor de 0 mientras la instancia está pausada.

  • El valor de estado de la instancia no cambia. El estado sigue apareciendo como disponible.

  • La instancia deja de escribir en los archivos de registro de la base de datos. Deja de enviar métricas a CloudWatch, salvo registrar cero por ciento para CPUUtilization y ACUUtilization, y cero para ServerlessDatabaseCapacity.

  • Aurora emite eventos cuando una instancia de base de datos de Aurora Serverless v2 comienza la pausa, termina la pausa y si el mecanismo de pausa se interrumpe o no funciona. Para obtener más detalles acerca de estos eventos, consulte Eventos de instancia de base de datos.

Qué ocurre cuando se reanudan las instancias de Aurora Serverless v2 pausadas automáticamente

Cuando una instancia de base de datos de Aurora Serverless v2 se reanuda tras haber sido pausada automáticamente, se aplican las siguientes condiciones:

  • Todos los cambios de parámetros que estén incluidos en los cambios de pending-reboot se aplicarán cuando se reanude la instancia.

  • Aurora emite eventos en el nivel de la instancia cuando cada instancia de base de datos de Aurora Serverless v2 comienza a reanudarse, termina de reanudarse y si la instancia no puede reanudarse por algún motivo. Para obtener más detalles acerca de estos eventos, consulte Eventos de instancia de base de datos.

  • Todas las conexiones solicitadas se establecen una vez que la instancia de base de datos termina de reanudarse. Como el tiempo normal de reanudación puede ser de aproximadamente 15 segundos, le recomendamos que ajuste cualquier configuración de tiempo de espera del cliente para que sea superior a 15 segundos. Por ejemplo, en la configuración del controlador JDBC, puede ajustar los valores de la configuración de connectTimeout y de sslResponseTimeout para que sean superiores a 15 segundos.

nota

Si una instancia de Aurora Serverless v2 permanece pausada durante más de 24 horas, Aurora puede hacer que la instancia entre en un sueño más profundo y que tarde más en reanudarse. En ese caso, el tiempo de reanudación puede ser de 30 segundos o más, aproximadamente el equivalente a reiniciar la instancia. Si su base de datos tiene períodos de inactividad que duran más de un día, le recomendamos configurar los tiempos de espera de conexión en 30 segundos o más.

Funcionamiento de la facturación de instancias para clústeres de Aurora Serverless v2 pausados automáticamente

Mientras una instancia de Aurora Serverless v2 se pausa automáticamente, su cargo por instancia es cero. La métrica ServerlessV2Usage es cero durante ese período. AWS sigue cobrando por el almacenamiento de Aurora y otros aspectos del clúster que no están vinculados a esa instancia de base de datos específica.

Situaciones en las Aurora Serverless v2 que no se pausa automáticamente

  • Si el valor de capacidad mínimo del clúster de base de datos es superior a cero ACU, las instancias de Aurora Serverless v2 del clúster no se pausan automáticamente. Si tiene clústeres con instancias de Aurora Serverless v2 de antes de que existiera la característica de pausa automática, la configuración de capacidad mínima más baja es de 0,5 ACU. Para utilizar la característica de pausa automática con dichos clústeres, debe modificar la configuración de capacidad mínima a cero ACU.

  • Si alguna conexión iniciada por el usuario está abierta a una instancia de Aurora Serverless v2, la instancia no se pausará. La instancia tampoco se pausará mientras se realicen actividades como la aplicación de parches y las actualizaciones. Las conexiones administrativas que Aurora usa para las comprobaciones de estado no cuentan como actividad y no impiden que la instancia se pause.

  • En un clúster de Aurora PostgreSQL que tenga habilitada la replicación lógica o en un clúster de Aurora MySQL que tenga habilitada la replicación binlog, la instancia de escritor y cualquier instancia de lector en los niveles cero y uno de promoción de conmutación por error no se pausan de forma automática. Aurora realiza una cantidad mínima constante de actividades para comprobar el estado de la conexión de replicación.

    En el caso de los clústeres con la replicación habilitada, puede seguir teniendo instancias de lector de Aurora en el clúster de origen que se pausa automáticamente. Para ello, establezca su prioridad de conmutación por error en un valor distinto de cero o uno. De esta forma, se pueden pausar independientemente de la instancia de escritor.

  • Si el clúster de Aurora tiene un proxy RDS asociado, el proxy mantiene una conexión abierta con cada instancia de base de datos del clúster. Por lo tanto, las instancias de Aurora Serverless v2 de un clúster de este tipo no se pausarán automáticamente.

  • Si el clúster es el clúster principal de una base de datos global de Aurora, Aurora no pausa automáticamente la instancia de escritor de Aurora Serverless v2. Esto se debe a que se necesita un nivel de actividad constante en la instancia de escritor para administrar los demás clústeres de la base de datos global. Como la instancia de escritor permanece activa, las instancias de lector de Aurora Serverless v2 con prioridad de conmutación por error cero o uno tampoco se pausan automáticamente.

  • Las instancias de Aurora Serverless v2 de los clústeres secundarios de una base de datos global de Aurora no se pausan automáticamente. Si un clúster de base de datos se convierte en un clúster independiente, la característica de pausa automática será efectiva si se cumplen todas las demás condiciones.

  • En un clúster con una integración sin ETL asociada a Redshift, la instancia de escritor y cualquier instancia de lector de los niveles cero y uno de promoción de conmutación por error no se pausan de forma automática.

  • Además de la actividad en el puerto de base de datos principal de la instancia, si una instancia de Aurora PostgreSQL tiene habilitada la característica Babelfish, cualquier conexión y actividad en el puerto T-SQL impedirá que la instancia se pause automáticamente.

Funcionamiento de la pausa automática con la característica de parada o inicio del clúster

Puede detener e iniciar un clúster de Aurora cuando la característica de pausa automática esté habilitada. No importa si algunas instancias están pausadas. Al volver a iniciar el clúster, las instancias de Aurora Serverless v2 pausadas se reanudan automáticamente.

Mientras un clúster de Aurora está detenido, las instancias de Aurora Serverless v2 pausadas no se reanudan automáticamente en función de los intentos de conexión. Cuando se reinicie el clúster, se aplicarán los mecanismos habituales para pausar y reanudar las instancias de Aurora Serverless v2.

Funcionamiento del mantenimiento y las actualizaciones de los clústeres de Aurora Serverless v2 pausados automáticamente

  • Mientras una instancia de Aurora Serverless v2 está pausada automáticamente, si intenta actualizar el clúster de Aurora, Aurora reanuda la instancia y la actualiza.

  • Aurora reanuda periódicamente las instancias de Aurora Serverless v2 pausadas automáticamente para realizar tareas de mantenimiento, como actualizaciones de versiones secundarias y cambios en propiedades, como los grupos de parámetros.

  • Cuando una instancia de Aurora Serverless v2 se activa para realizar una operación administrativa, como una actualización o una tarea de mantenimiento, Aurora espera al menos 20 minutos antes de volver a pausar la instancia. Esto es para permitir que finalicen las operaciones en segundo plano. El período de veinte minutos también evita que se pause y reanude la instancia varias veces si esta se somete a varias operaciones administrativas seguidas.

Diferencias en el comportamiento de pausa automática entre Aurora Serverless v2 y Aurora Serverless v1

  • El tiempo de reanudación ha mejorado en Aurora Serverless v2 en comparación con Aurora Serverless v1. El tiempo de reanudación suele ser de aproximadamente 15 segundos si la instancia se ha pausado durante menos de 24 horas. Si la instancia permanece pausada durante más de 24 horas, es posible que el tiempo de reanudación sea mayor.

  • La forma en que Aurora Serverless v2 afecta a los clústeres Multi-AZ implica que algunas instancias de base de datos del clúster pueden estar pausadas mientras que otras están activas. La instancia de escritor se reanuda siempre que se esté ejecutando un lector, ya que es necesario que el escritor coordine determinadas actividades dentro del clúster. Como Aurora Serverless v1 no utiliza instancias de lector, todo el clúster estará siempre en pausa o activo.

  • Cuando el punto de conexión del lector selecciona aleatoriamente una instancia de lector a la que conectarse, es posible que esa instancia de lector ya esté activa o que esté pausada automáticamente. Por lo tanto, el tiempo de acceso a la instancia de lector puede variar y ser más difícil de predecir. Por lo tanto, los clústeres Multi-AZ que utilizan Aurora Serverless v2 y se pausan automáticamente podrían beneficiarse de la configuración de puntos de conexión personalizados para casos de uso específicos de solo lectura, en lugar de dirigir todas las sesiones de solo lectura al punto de conexión de lector.

  • Las instancias de Aurora Serverless v2 se someten a operaciones de mantenimiento con la misma frecuencia que las instancias aprovisionadas. Como Aurora reanuda automáticamente las instancias cuando se necesita dicho mantenimiento, es posible que las instancias de Aurora Serverless v2 se reanuden con más frecuencia que los clústeres de Aurora Serverless v1.

Funcionamiento de la pausa automática de Aurora Serverless v2 para diferentes tipos de clústeres de Aurora

Las consideraciones sobre la característica de pausa automática dependen del número de instancias que haya en el clúster de Aurora, de los niveles de promoción de conmutación por error de las instancias de lector y de si todas las instancias son de Aurora Serverless v2 o es una combinación de instancias de Aurora Serverless v2 y aprovisionadas.

Si la característica de pausa automática está habilitada, puede organizar su clúster de Aurora para lograr el equilibrio adecuado entre alta disponibilidad, respuesta rápida y escalabilidad para que se adapte a su caso de uso. Para ello, debe elegir la combinación de instancias de Aurora Serverless v2, instancias aprovisionadas y niveles de promoción de conmutación por error para las instancias de base de datos de su clúster.

Los siguientes tipos de configuraciones muestran diferentes ventajas y desventajas entre la alta disponibilidad y la optimización de costos para su clúster:

  • Para un sistema de desarrollo y prueba, puede configurar un clúster de base de datos Single-AZ con una instancia de base de datos de Aurora Serverless v2. La instancia única atiende todas las solicitudes de lectura y escritura. Cuando el clúster no se utiliza durante intervalos de tiempo significativos, la instancia de base de datos se pausa. En ese momento, los costos de computación de la base de datos del clúster también se pausan.

  • En el caso de un sistema que ejecute una aplicación en el que la alta disponibilidad sea una prioridad, pero el clúster aún tenga períodos en los que esté completamente inactivo, puede configurar un clúster Multi-AZ en el que las instancias de base de datos de escritor y de lector sean Aurora Serverless v2. Establezca una prioridad de conmutación por error de cero o uno para la instancia de lector, de modo que la instancia de escritor y de lector se pausen y se reanuden al mismo tiempo. Ahora podrá disfrutar de una conmutación por error rápida mientras el clúster esté activo. Cuando el clúster permanece inactivo durante más tiempo que el umbral de pausa automática, se pausan los cargos de la instancia de base de datos de ambas instancias. Cuando el clúster reanude el procesamiento, la primera sesión de base de datos tardará unos breves instantes en conectarse.

  • Suponga que su clúster está constantemente activo con una cantidad mínima de actividad y que requiere una respuesta rápida para cualquier conexión. En ese caso, puede crear un clúster con más de una instancia de lector de Aurora Serverless v2 y separar las capacidades de algunas instancias de lector de las de escritor. Especifique la prioridad de conmutación por error cero o uno para la instancia de escritor y una instancia de lector. Especifique una prioridad mayor que uno para las demás instancias de lector. De esta forma, las instancias de lector en los niveles de mayor prioridad pueden pausarse automáticamente, incluso mientras el escritor y uno de los lectores permanecen activos.

    En este caso, puede emplear otras técnicas para garantizar que el clúster permanezca disponible de forma continua y, al mismo tiempo, se reduzca verticalmente hasta alcanzar una capacidad baja durante los períodos de inactividad:

    • Puede usar instancias aprovisionadas para el escritor y el lector con prioridad 0 o 1. De este modo, dos instancias de base de datos nunca se pausan automáticamente y siempre están disponibles para atender el tráfico de la base de datos y realizar conmutaciones por error.

    • Puede configurar un punto de conexión personalizado que incluya las instancias de Aurora Serverless v2 de los niveles de mayor prioridad, pero no el escritor ni los lectores de nivel de promoción 0 o 1. De esta forma, puede dirigir las sesiones de solo lectura que no sean sensibles a la latencia hacia los lectores que podrían pausarse automáticamente. Puede evitar usar el punto de conexión de lector para este tipo de solicitudes, ya que Aurora podría dirigir las conexiones del punto de conexión de lector a la instancia de lector siempre activa o a una de las instancias pausadas automáticamente. El uso del punto de conexión personalizado le permite dirigir las conexiones hacia diferentes grupos de instancias en función de su preferencia para una respuesta rápida o una capacidad de escalado adicional.

Funcionamiento de la pausa automática de Aurora Serverless v2 para la instancia de escritor en un clúster de base de datos

Cuando un clúster de base de datos de Aurora contiene solo una instancia de base de datos, el mecanismo para pausar y reanudar automáticamente la instancia de base de datos es sencillo. Depende únicamente de la actividad de la instancia de escritor. Es posible que tenga una configuración de este tipo para los clústeres que se utilizan para el desarrollo y las pruebas, o para ejecutar aplicaciones en las que la alta disponibilidad no es crucial. Tenga en cuenta que, en un clúster de instancia única, Aurora dirige las conexiones a través del punto de conexión de lector a la instancia de base de datos de escritor. Por lo tanto, en el caso de un clúster de base de datos de instancia única, al intentar conectarse al punto de conexión de lector, se reanudará la instancia de base de datos de escritor pausada automáticamente.

Los siguientes factores adicionales se aplican a los clústeres de Aurora con varias instancias de base de datos:

  • En un clúster de base de datos de Aurora, normalmente se accede con frecuencia a la instancia de base de datos de escritor. Por lo tanto, es posible que la instancia de base de datos de escritor permanezca activa incluso cuando una o más instancias de base de datos de lector se pausen automáticamente.

  • Algunas actividades de las instancias de base de datos de lector requieren que la instancia de base de datos de escritor esté disponible. Por lo tanto, las instancias de base de datos de escritor no se pueden pausar hasta que todas las instancias de lector también estén pausadas. Al reanudar cualquier instancia de lector, se reanuda automáticamente la instancia de escritor, incluso si la aplicación no accede directamente a la instancia de escritor.

  • Las instancias de escritor de Aurora Serverless v2 en los niveles de promoción de conmutación por error cero y uno se escalan para mantener su capacidad sincronizada con la instancia de escritor. Por lo tanto, cuando se reanuda una instancia de escritor de Aurora Serverless v2, también lo hacen las instancias de lector de Aurora Serverless v2 que estén en los niveles de promoción cero o uno.

Funcionamiento de la pausa automática de Aurora Serverless v2 en los clústeres Multi-AZ

Dentro de un clúster de base de datos de Aurora que contiene una instancia de base de datos de escritor y una o más instancias de base de datos de lector, es posible que algunas instancias de base de datos de Aurora Serverless v2 estén pausadas mientras otras están activas. La instancia de escritor y cualquier instancia de lector con prioridad de conmutación por error de 0 y 1 siempre se pausan y se reanudan al mismo tiempo. Las instancias de lector con una prioridad distinta de 0 o 1 pueden pausarse y reanudarse independientemente de las demás instancias.

Al utilizar esta característica para clústeres con varias instancias de lector, puede administrar los costos sin sacrificar la alta disponibilidad. La instancia de escritor y una o dos instancias de lector pueden permanecer activas en todo momento, mientras que las instancias de lector adicionales pueden pausarse cuando no son necesarias para administrar un gran volumen de tráfico de lectura.

El hecho de que una instancia de lector pueda pausarse automáticamente depende de si su capacidad se puede escalar de forma independiente o de si la capacidad está vinculada a la de la instancia de base de datos de escritor. Esa propiedad de escalado depende de la prioridad de conmutación por error de la instancia de base de datos de lector. Cuando la prioridad de lector es cero o uno, la capacidad del lector realiza un seguimiento de la capacidad de la instancia de base de datos del escritor. Por lo tanto, para permitir que las instancias de base de datos de lector se pausen automáticamente en la variedad más amplia de situaciones, debe definir la prioridad en un valor mayor que uno.

El tiempo necesario para reanudar una instancia de lector puede ser ligeramente superior al de reanudar una instancia de escritor. Para obtener la respuesta más rápida en caso de que las instancias estén pausadas, conéctese al punto de conexión del clúster.

Funcionamiento de la pausa automática de Aurora Serverless v2 en clústeres con instancias aprovisionadas

Las instancias de base de datos aprovisionadas en su clúster de base de datos de Aurora no se pausan automáticamente. Solo las instancias de base de datos de Aurora Serverless v2 con la clase de instancia db.serverless pueden usar la característica de pausa automática.

Cuando el clúster de Aurora contiene instancias de base de datos aprovisionadas, cualquier instancia de escritor de Aurora Serverless v2 se pausa automáticamente. Esto se debe al requisito de que la instancia de escritor debe permanecer disponible mientras las instancias de lector estén activas. El hecho de que el escritor de Aurora Serverless v2 también permanezca activo significa que las instancias de lector de Aurora Serverless v2 con prioridad de conmutación por error 0 y 1 no se pausarán automáticamente en un clúster híbrido que contenga instancias aprovisionadas.

Supervisión de los clústeres de Aurora que utilizan la pausa automática

Para supervisar Aurora, ya debe estar familiarizado con los procedimientos de supervisión en Supervisión de métricas de Amazon Aurora con Amazon CloudWatch y las métricas de CloudWatch que se muestran en Referencia de métricas para Amazon Aurora. Tenga en cuenta que hay que tener en cuenta algunas consideraciones especiales al supervisar los clústeres de Aurora que utilizan la característica de pausa automática:

  • Puede haber períodos en los que las instancias de Aurora Serverless v2 no registren los datos de registro y la mayoría de las métricas debido a que las instancias están pausadas. Las únicas métricas que se envían a CloudWatch mientras una instancia está pausada son el cero por ciento para CPUUtilization y ACUUtilization, y el cero para ServerlessDatabaseCapacity.

  • Puede comprobar si las instancias de Aurora Serverless v2 se pausan con más o menos frecuencia de lo esperado. Para ello, compruebe la frecuencia con la que la métrica ServerlessDatabaseCapacity cambia de un valor distinto de cero a cero y durante cuánto tiempo permanece en cero. Si las instancias no permanecen pausadas el tiempo esperado, significa que no está ahorrando todo lo que podría. Si las instancias se pausan y reanudan con más frecuencia de la prevista, es posible que el clúster tenga una latencia innecesaria al responder a las solicitudes de conexión. Para obtener información sobre los factores que afectan a la frecuencia con que se pueden pausar las instancias de Aurora Serverless v2 y de qué manera, consulte Requisitos previos y limitaciones de la característica de pausa automática de Aurora Serverless v2, Situaciones en las Aurora Serverless v2 que no se pausa automáticamente y Solución de problemas para la característica de pausa automática de Aurora Serverless v2.

  • También puede examinar un archivo de registro que registre las operaciones de pausa y reanudación automáticas de una instancia de Aurora Serverless v2. Si una instancia no se ha detenido después de que expirara el intervalo de tiempo de espera, este archivo de registro también incluye el motivo por el que no se ha realizado la pausa automática. Para obtener más información, consulte Supervisión de la actividad de pausa y reanudación de Aurora Serverless v2.

Comprobación de si una instancia de Aurora Serverless v2 está pausada

Para determinar si una instancia de Aurora Serverless v2 está pausada, puede observar la métrica ACUUtilization de la instancia. Esta métrica tiene un valor igual a cero mientras la instancia está pausada.

Mientras una instancia de Aurora Serverless v2 está en pausa, su valor de estado sigue apareciendo como Disponible. Lo mismo se aplica cuando una instancia de Aurora Serverless v2 pausada está en proceso de reanudación. Esto se debe a que puede conectarse correctamente a una instancia de este tipo, incluso si la conexión experimenta un ligero retraso.

Cualquier métrica relacionada con la disponibilidad de las instancias de Aurora considera el período durante el cual la instancia está en pausa como el tiempo en que la instancia ha estado disponible.

Eventos para las operaciones de pausa automática y reanudación automática

Aurora emite eventos para las instancias de Aurora Serverless v2 cuando las operaciones de pausa y reanudación automáticas se inician, finalizan o se cancelan. Los eventos relacionados con la característica de pausa automática son de RDS-EVENT-0370 a RDS-EVENT-0374. Para obtener más detalles acerca de estos eventos, consulte Eventos de instancia de base de datos.

Funcionamiento de la pausa automática con Información de rendimiento y Monitorización mejorada

Mientras una instancia de Aurora Serverless v2 está en pausa, Aurora no recopila información de supervisión para esa instancia a través de Información de rendimiento o Monitorización mejorada. Cuando se reanude la instancia, es posible que se produzca un breve retraso antes de que Aurora reanude la recopilación de dicha información de supervisión.

Cómo interactúa la característica de pausa automática de Aurora Serverless v2 con las métricas de Aurora

Mientras una instancia de Aurora Serverless v2 está pausada, no emite la mayoría de las métricas de CloudWatch ni escribe información en los registros de su base de datos. Las únicas métricas que se envían a CloudWatch mientras una instancia está pausada son el cero por ciento para CPUUtilization y ACUUtilization, y el cero para ServerlessDatabaseCapacity.

Cuando CloudWatch calcula las estadísticas relacionadas con la disponibilidad y el tiempo de actividad de las instancias o los clústeres, se considera que las instancias de Aurora Serverless v2 están disponibles durante el tiempo en que están pausadas.

Si inicia una acción de la AWS CLI o de la API de RDS para describir o descargar los registros de una instancia de Aurora Serverless v2 pausada, la instancia se reanuda automáticamente para que la información del registro esté disponible.

Ejemplo de métricas de CloudWatch

Los siguientes ejemplos de AWS CLI muestran cómo se puede observar de qué manera cambia la capacidad de una instancia con el paso del tiempo. Durante ese período, la instancia se pausa automáticamente y, a continuación, se reanuda. Mientras está pausada, la métrica ServerlessDatabaseCapacity muestra un valor de cero. Para determinar si la instancia se ha pausado en algún momento durante dicho período de tiempo, verificamos si la capacidad mínima durante ese período de tiempo ha sido igual a cero.

El siguiente ejemplo de Linux representa una instancia de Aurora Serverless v2 que ha estado pausada automáticamente durante algún tiempo. Tomamos muestras de ServerlessDatabaseCapacity cada minuto, durante un período de tres minutos. El valor mínimo de la ACU de 0,0 confirma que la instancia se ha pausado en algún momento en cada minuto. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '3 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:11:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:12:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None

A continuación, intentamos establecer una conexión con la instancia de Aurora Serverless v2 pausada. En este ejemplo, utilizamos una contraseña incorrecta expresamente para que el intento de conexión no tenga éxito. A pesar del error, el intento de conexión hace que Aurora reanude la instancia pausada. 


$ mysql -h my_cluster_endpoint.rds.amazonaws.com -u admin -pwrong-password

ERROR 1045 (28000): Access denied for user 'admin'@'ip_address' (using password: YES)

El siguiente ejemplo de Linux demuestra que la instancia pausada se ha reanudado, ha permanecido inactiva durante aproximadamente cinco minutos y, después, ha vuelto a su estado de pausa. La instancia se ha reanudado con una capacidad de 2,0 ACU. Luego se ha escalado verticalmente, por ejemplo, para realizar una limpieza interna. Puesto que no ha recibido ningún intento de conexión por parte del usuario en el periodo de espera de cinco minutos, ha pasado directamente de 4,0 ACU al estado de pausa. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '8 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None
DATAPOINTS	2.0	2024-08-02T22:14:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:15:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:16:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:17:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:18:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:19:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:20:00+00:00	None

Si el informe pretendía mostrar la rapidez con la que la instancia se ha escalado verticalmente para gestionar la carga de trabajo, podríamos especificar Maximum en lugar de Minimum para la estadística. Para planificar la capacidad y estimar los costos, podríamos especificar un período de tiempo más largo y usar la estadística Average. De esta forma, podríamos determinar los valores de capacidad típicos durante los períodos de alta actividad, baja actividad y estado de pausa. Para examinar el comportamiento durante los momentos precisos de pausa y reanudación, podríamos especificar un período de un segundo y examinar un intervalo de tiempo más corto. Los valores de marca temporal de la salida, como 2024-08-02T22:13:00+00:00, muestran el formato para especificar parámetros precisos para las opciones --start-time y --end-time.

Solución de problemas para la característica de pausa automática de Aurora Serverless v2

Si detecta que las instancias de Aurora Serverless v2 no se detienen con la frecuencia esperada, compruebe las siguientes causas posibles:

  • Confirme que la versión de Aurora que está ejecutando admite una capacidad mínima de cero ACU. Para conocer los rangos de capacidad de las diferentes versiones de Aurora, consulte Capacidad de Aurora Serverless v2.

  • Confirme que el valor de capacidad mínima del clúster esté establecido en cero ACU.

  • Confirme que la instancia en cuestión utiliza realmente la clase de instancia db.serverless de Aurora Serverless v2, no una de las clases de instancias aprovisionadas.

  • Confirme que el clúster no utilice ninguna de las características o configuraciones incompatibles de Requisitos previos y limitaciones de la característica de pausa automática de Aurora Serverless v2.

  • Examine el archivo de registro que muestra cuándo se pausaron o se reanudaron las instancias de Aurora Serverless v2 o si Aurora no pudo pausar ni reanudar una instancia por algún motivo. Para obtener más información, consulte Supervisión de la actividad de pausa y reanudación de Aurora Serverless v2.

  • Compruebe si algún cliente o aplicación mantiene las conexiones abiertas durante largos periodos de tiempo. Por el contrario, compruebe si alguna aplicación que utilice la API de datos de RDS o las funciones de Lambda envía solicitudes frecuentes para que la instancia nunca esté inactiva el tiempo suficiente como para pausarla. Puede examinar las métricas de CloudWatch, como ConnectionAttempts y DatabaseConnections. Para obtener más información, consulte Métricas de nivel de instancia para Amazon Aurora.

  • Si una instancia de lector se pausa muy pocas veces, o nunca, compruebe su prioridad de conmutación por error. Si el lector se utiliza para escalar el lector y no como dispositivo de reserva en caso de conmutación por error, configúrelo en una prioridad entre 2 y 15.

  • Si la instancia de escritor se detiene muy pocas veces, o nunca, compruebe el uso que hace de las instancias de lector. El escritor solo puede pausar si todo el clúster está inactivo. Esto se debe a que una conexión a cualquier instancia de lector provoca que el escritor se reanude.

  • Si su aplicación recibe tiempos de espera durante las solicitudes de conexión mientras se reanudan las instancias de Aurora Serverless v2, considere la posibilidad de alargar el intervalo de tiempo de espera utilizado por el código de la aplicación o el marco de base de datos subyacente. Los tiempos de espera de conexión más prolongados reducen la posibilidad de que se produzcan errores en las conexiones mientras se reanudan las instancias de Aurora Serverless v2. Sin embargo, los tiempos de espera más largos también pueden hacer que la aplicación detecte más lentamente los problemas de disponibilidad en el clúster.

    Por el contrario, considere la posibilidad de alargar el intervalo de pausa automática para que las aplicaciones no encuentren instancias pausadas con tanta frecuencia.

    Si no existe un equilibrio lógico entre el comportamiento de pausa automática y la capacidad de respuesta del clúster para su aplicación, es posible que ese clúster no sea un buen candidato para usar la característica de pausa automática.

  • Si calcula cuánto tiempo permanecerán en pausa las instancias de Aurora Serverless v2, tenga en cuenta que hay factores que hacen que no sea práctico realizar predicciones precisas.

    • Es posible que las instancias se reanuden periódicamente para realizar tareas de mantenimiento, actualizaciones a versiones secundarias o aplicar cambios a los grupos de parámetros.

    • En el caso de los clústeres Multi-AZ, hay situaciones en las que la reanudación de una instancia provoca que también se reanuden otras instancias. Reanudar un lector siempre provoca que también se reanude el escritor. Al reanudar el escritor, siempre se reanudará la sesión de los lectores con prioridad de conmutación por error 0 y 1.

    Recomendamos medir el tiempo de pausa real durante un período de varios días, con una carga de trabajo realista. A continuación, use esas medidas para establecer una referencia para la proporción de tiempo que cabe esperar que esté pausada una instancia.

  • Es posible que las operaciones internas, como la purga de MySQL, el programador de eventos de MySQL, el autovacuum de PostgreSQL o los trabajos de PostgreSQL programados a través de la extensión pg_cron no se estén ejecutando o no se estén completando. La instancia no se reanuda automáticamente para realizar operaciones que no impliquen una conexión de usuario a la base de datos. Si dichas operaciones internas están en marcha cuando se agote el tiempo de espera de la pausa automática, se cancelarán las tareas de mantenimiento, como la purga de MySQL y el autovacuum de PostgreSQL. Los trabajos programados desde el programador de eventos de MySQL o la extensión pg_cron de PostgreSQL también se cancelan si están en curso cuando Aurora inicia la operación de pausa.

    Si necesita asegurarse de que la instancia esté activa periódicamente para realizar las operaciones programadas, puede iniciar una conexión para reanudar la instancia antes de la hora de inicio del trabajo. También puede aumentar el intervalo de tiempo de espera de la pausa automática para que operaciones como el autovacuum puedan ejecutarse durante más tiempo una vez finalizada la actividad del usuario. También puede usar mecanismos como las funciones de Lambda para realizar las operaciones de la base de datos según una programación, de forma que se reanude automáticamente la instancia si es necesario.

Consideraciones sobre el diseño de la aplicación para la característica de pausa automática de Aurora Serverless v2

Cuando una instancia de base de datos de Aurora Serverless v2 se reanuda tras haber sido pausada automáticamente, comienza con una capacidad relativamente pequeña y, a partir de ahí, se escala verticalmente. Esta capacidad inicial se aplica incluso si la instancia de base de datos tenía una capacidad superior inmediatamente antes de que se detuviera automáticamente.

Utilice esta característica con aplicaciones que puedan tolerar un intervalo de aproximadamente 15 segundos al establecer una conexión. Esto explica el caso típico en el que una instancia de Aurora Serverless v2 se reanuda debido a una o a un número reducido de conexiones entrantes. Si la instancia está pausada durante más de 24 horas, es posible que el tiempo de reanudación sea mayor.

Si la aplicación ya utilizaba Aurora Serverless v1 y la característica de pausa automática, es posible que ya disponga de esos intervalos de tiempo de espera para los intentos de conexión. Si ya utiliza Aurora Serverless v2 en combinación con la característica de parada e inicio en un clúster de Aurora, el tiempo de reanudación de las instancias de Aurora Serverless v2 pausadas automáticamente suele ser mucho más corto que el tiempo de inicio de un clúster detenido.

Al codificar la lógica de conexión en su aplicación, vuelva a intentar la conexión si el primer intento arroja un error de causa transitoria. (Si el error se debe a un error de autenticación, corrija las credenciales antes de volver a intentarlo). Un error que se produce inmediatamente después de la reanudación puede ser un tiempo de espera o algún error relacionado con los límites de la base de datos. Reintentarlo puede solucionar problemas en los casos más raros en los que una instancia de Aurora Serverless v2 se reanuda debido a un gran número de solicitudes de conexión simultáneas. En ese caso, es posible que algunas conexiones tarden más de lo habitual en procesarse o que superen el límite de conexiones simultáneas en el primer intento.

Durante el desarrollo y la depuración de aplicaciones, no deje abiertas a la base de datos las sesiones del cliente o las herramientas de programación con conexiones. Aurora no pausará una instancia si hay alguna conexión iniciada por el usuario abierta, independientemente de si las conexiones no ejecutan ninguna instrucción o transacción de SQL. Cuando una instancia de Aurora Serverless v2 de un clúster de Aurora no se puede pausar, es posible que también se impida que se detengan otras instancias del clúster. Para obtener más información, consulte Situaciones en las Aurora Serverless v2 que no se pausa automáticamente.

Aurora emite eventos cuando una instancia de base de datos de Aurora Serverless v2 comienza a reanudarse, termina de reanudarse y si la instancia no puede reanudarse por algún motivo. Para obtener más detalles acerca de estos eventos, consulte Eventos de instancia de base de datos.