View a markdown version of this page

Requisitos y limitaciones para Aurora Serverless v2 - Amazon Aurora
Disponibilidad en regiones y versionesLos clústeres que utilizan Aurora Serverless v2 deben tener un rango de capacidad especificadoConfiguración de escalado incompatibleAlgunas características aprovisionadas no se admiten en Aurora Serverless v2

Requisitos y limitaciones para Aurora Serverless v2

Cuando cree un clúster en el que desee utilizar instancias de bases de datos de Aurora Serverless v2, preste atención a los siguientes requisitos y limitaciones:

Disponibilidad en regiones y versiones

La disponibilidad de las características varía según las versiones específicas de cada motor de base de datos de Aurora y entre Regiones de AWS. Para obtener más información acerca de la versión y la disponibilidad de las regiones con Aurora y Aurora Serverless v2, consulte Regiones y motores de base de datos Aurora admitidos para Aurora Serverless v2.

En el siguiente ejemplo se muestran los comandos de AWS CLI para confirmar los valores exactos del motor de base de datos que puede utilizar con Aurora Serverless v2 para una Región de AWS determinada. El parámetro --db-instance-class para Aurora Serverless v2 es siempre db.serverless. El parámetro --engine puede ser aurora-mysql o aurora-postgresql. Sustituya los valores --region y --engine correspondientes para confirmar los valores de --engine-version que puede usar. Si el comando no produce ningún resultado, significa que Aurora Serverless v2 no está disponible para esa combinación de Región de AWS y motor de base de datos.

aws rds describe-orderable-db-instance-options --engine aurora-mysql --db-instance-class db.serverless \
  --region my_region --query 'OrderableDBInstanceOptions[].[EngineVersion]' --output text

aws rds describe-orderable-db-instance-options --engine aurora-postgresql --db-instance-class db.serverless \
  --region my_region --query 'OrderableDBInstanceOptions[].[EngineVersion]' --output text

Los clústeres que utilizan Aurora Serverless v2 deben tener un rango de capacidad especificado

Un clúster de Aurora debe tener un atributo ServerlessV2ScalingConfiguration para poder añadir cualquier instancia de base de datos que utilice la clase de instancia de base de datos db.serverless. Este atributo especifica el rango de capacidad. La capacidad de Aurora Serverless v2 oscila entre un mínimo de 0 unidades de capacidad de Aurora (ACU) hasta un máximo de 256 ACU, en incrementos de 0,5 ACU. El valor mínimo permitido depende de la versión de Aurora. Cada ACU proporciona el equivalente a aproximadamente 2 gibibytes (GiB) de RAM y la CPU y las redes asociadas. Para obtener más información sobre cómo utiliza Aurora Serverless v2 la configuración del rango de capacidad, consulte Cómo funciona Aurora Serverless v2.

Para obtener información sobre los rangos de capacidad permitidos de las distintas versiones de motores de base de datos y versiones de plataformas, consulte Aurora Serverless v2Capacidad de. El rango de escalado disponible para un clúster determinado se ve influido tanto por la versión del motor como por el hardware (versión de la plataforma).

Puede especificar los valores de ACU mínimos y máximos en Consola de administración de AWS cuando cree un clúster y la instancia de base de datos de Aurora Serverless v2 asociada. También puede especificar la opción --serverless-v2-scaling-configuration en la AWS CLI. O, si lo desea, puede especificar el parámetro ServerlessV2ScalingConfiguration con la API de Amazon RDS. Puede especificar este atributo cuando cree un clúster o modifique un clúster existente. Para conocer los procedimientos para establecer el rango de capacidad, consulte Configuración del rango de capacidad de Aurora Serverless v2 para un clúster. Para obtener un análisis detallado sobre cómo elegir valores de capacidad mínima y máxima y cómo estos ajustes afectan a algunos parámetros de base de datos, consulte Elegir el rango de capacidad de Aurora Serverless v2 para un clúster de Aurora.

Configuración de escalado incompatible

Cuando modifique su clúster de PostgreSQL en Aurora reduciendo verticalmente la capacidad máxima, cada instancia se reducirá para adaptarse a la nueva configuración. Si Aurora detecta que alguna de sus instancias tiene problemas para reducirse verticalmente, puede cancelar y revertir la actualización de la configuración de escalado. Como resultado, las instancias volverán a escalarse hasta alcanzar su configuración anterior. Este problema puede producirse si la nueva capacidad máxima es insuficiente para gestionar la carga de trabajo actual o si los parámetros personalizados aplicados al grupo de parámetros de la DB del clúster o de las instancias están configurados con valores demasiado altos.

Cuando comience la reversión, se le notificará mediante un evento de Amazon RDS que contiene información sobre las instancias en las que no se ha podido aplicar la configuración de escalado deseada. Una vez completada la reversión, la capacidad máxima de la configuración de escalado volverá a su valor original, que es más alto. Debido a la reversión, es posible que observe que la capacidad de la DB de Aurora Serverless en todas las instancias de su clúster también aumente, lo que podría generar un incremento de los costes.

Por ejemplo, si tiene un clúster de Aurora Serverless de Aurora PostgreSQL con una sola instancia y la configuración de escalado está establecida en minCapacity=0.5, maxCapacity=128 y secondsUntilAutopause=null. Además, el parámetro track_activity_query_size de la DB está establecido en un valor personalizado de 40960. Si a continuación modifica la configuración de escalado del clúster para que tenga una capacidad máxima de 1 ACU, es posible que observe que, tras un par de horas, la modificación aún no se ha completado. El valor alto del parámetro track_activity_query_size requiere más recursos de los que puede proporcionar la nueva capacidad máxima. Por consiguiente, aunque no haya carga de trabajo, la ServerlessDatabaseCapacity de la instancia no puede reducirse verticalmente para ajustarse a la nueva capacidad máxima de 1 ACU. En ese caso, Aurora Serverless v2 anulará la modificación de la configuración de escalado y volverá a aplicar la configuración de escalado anterior de minCapacity=0.5, maxCapacity=128, secondsUntilAutopause=null. A continuación, la instancia se escalará verticalmente para ajustarse a la configuración de escalado anterior, con lo que finalizará la modificación del clúster. Se publica un evento de Amazon RDS para notificarle que se ha detectado una actualización de la configuración de escalado incompatible, que se ha cancelado y que se ha revertido a la configuración anterior.

Problemas y soluciones

La nueva configuración de escalado no es compatible con la carga de trabajo

La capacidad máxima de la nueva configuración de escalado de Aurora Serverless v2 es demasiado baja para gestionar la carga de trabajo actual.

Recomendaciones:

  • Reduzca la carga de trabajo antes de volver a aplicar la capacidad máxima inferior.

  • Si reducir la carga de trabajo no es una opción, vuelva a evaluar la capacidad máxima deseada. Para seleccionar una capacidad máxima adecuada, compruebe el valor máximo de la métrica ServerlessDatabaseCapacity de CloudWatch correspondiente a su clúster de Aurora PostgreSQL antes de que se cancelara y se revirtiera la actualización de la configuración de escalado. A continuación, establezca la capacidad máxima de su nueva configuración de escalado para que sea, como mínimo, igual al valor observado de ServerlessDatabaseCapacity. Para obtener más información sobre cómo elegir una capacidad máxima, consulte Elegir el rango de capacidad de Aurora Serverless v2 para un clúster de Aurora.

La nueva configuración de escalado no es compatible con los parámetros de DB personalizados

Los grupos de parámetros de DB personalizados de su clúster o de sus instancias requieren recursos adicionales que superan la capacidad máxima de la nueva configuración de escalado.

Parámetros de la DB de Aurora PostgreSQL que podrían ser incompatibles:

  • max_connections

  • track_activity_query_size

  • min_dynamic_shared_memory

Recomendaciones:

  • Para seleccionar un valor adecuado para los parámetros de la DB, consulte los valores predeterminados de cada uno de los parámetros enumerados anteriormente. Si el valor que ha configurado supera los valores predeterminados, reduzca los parámetros a sus valores predeterminados antes de modificar la configuración de escalado con la misma capacidad máxima reducida.

  • Si no es posible reducir los parámetros de la DB, siga los mismos pasos para seleccionar una capacidad máxima adecuada, tal y como se describe anteriormente en: La nueva configuración de escalado no es compatible con la carga de trabajo.

Algunas características aprovisionadas no se admiten en Aurora Serverless v2

Las siguientes características de las instancias de base de datos aprovisionadas de Aurora no están disponibles actualmente para Amazon Aurora Serverless v2:

  • Secuencias de actividades de la base de datos (DAS)

  • Administración de cachés de clústeres para Aurora PostgreSQL. El parámetro de configuración apg_ccm_enabled no se aplica a instancias de base de datos de Aurora Serverless v2.

Algunas características de Aurora funcionan con Aurora Serverless v2, pero esto podría causar problemas si el rango de capacidad es inferior al necesario para los requisitos de memoria de esas características con su carga de trabajo específica. En ese caso, es posible que la base de datos no funcione tan bien como de costumbre o que se produzcan errores de falta de memoria. Para obtener recomendaciones sobre cómo configurar el rango de capacidad adecuado, consulte Elegir el rango de capacidad de Aurora Serverless v2 para un clúster de Aurora. Para obtener información sobre la solución de problemas si la base de datos tiene errores de falta de memoria debido a un rango de capacidad mal configurado, consulte Evitar errores de memoria insuficiente.

No se admite Aurora Auto Scaling. Este tipo de escalado añade lectores nuevos para gestionar la carga de trabajo adicional que requiere un uso intensivo de lectura, con base en el uso de la CPU. Sin embargo, el escalado basado en la utilización de la CPU no tiene sentido para Aurora Serverless v2. Como alternativa, puede crear instancias de base de datos del lector de Aurora Serverless v2 de antemano y dejarlas reducidas verticalmente a baja capacidad. Es una forma más rápida y menos disruptiva de escalar la capacidad de lectura de un clúster que añadir nuevas instancias de base de datos dinámicamente.