# Uso de Aurora Serverless v2
Aurora Serverless v2 es una configuración de escalado automático bajo demanda para Amazon Aurora.Aurora Serverless v2 ayuda a automatizar los procesos de supervisión de la carga de trabajo y ajustar la capacidad de las bases de datos. La capacidad se ajusta automáticamente en función de la demanda de la aplicación. Solo se le cobrará por los recursos que consuman los clústeres de base de datos. Por lo tanto, Aurora Serverless v2 puede ayudarle a mantenerse dentro del presupuesto y evitar pagar los recursos de computación que no utiliza.
Este tipo de automatización es especialmente valioso para bases de datos de multitenencia, bases de datos distribuidas, sistemas de desarrollo y pruebas y otros entornos con cargas de trabajo muy variables e impredecibles.
**Topics**
+ [Casos de uso de Aurora Serverless v2](#aurora-serverless-v2.use-cases)
+ [Ventajas de Aurora Serverless v2](#aurora-serverless-v2.advantages)
+ [Cómo funciona Aurora Serverless v2](aurora-serverless-v2.how-it-works.md)
+ [Requisitos y limitaciones para Aurora Serverless v2](aurora-serverless-v2.requirements.md)
+ [Creación de un clúster de base de datos que utiliza Aurora Serverless v2](aurora-serverless-v2.create.md)
+ [Administración de clústeres de bases de datos de Aurora Serverless v2](aurora-serverless-v2-administration.md)
+ [Rendimiento y escalado para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md)
+ [Escalado a cero ACU con pausa y reanudación automáticas para Aurora Serverless v2](aurora-serverless-v2-auto-pause.md)
+ [Migración a Aurora Serverless v2](aurora-serverless-v2.upgrade.md)
## Casos de uso de Aurora Serverless v2
Aurora Serverless v2 admite muchos tipos de cargas de trabajo de bases de datos Estos comprenden, entre otros, entornos de desarrollo y pruebas, sitios web y aplicaciones que tienen cargas de trabajo impredecibles y las aplicaciones más exigentes y esenciales para la empresa que requieren una gran escala y disponibilidad.
Aurora Serverless v2 es especialmente útil para los siguientes casos de uso:
+ **Cargas de trabajo impredecibles**: cuando ejecuta cargas de trabajo diarias que tienen un aumento de actividad repentino e impredecible. Un ejemplo de ello sería un sitio dedicado al tráfico, que experimenta un aumento repentino de la actividad cuando comienza a llover. Otro caso sería un sitio de comercio electrónico en el que aumenta el tráfico cuando se ofrecen ventas o promociones especiales. Con Aurora Serverless v2, la capacidad de la base de datos se escala automáticamente para satisfacer las necesidades de los picos de carga de la aplicación y vuelve a disminuir cuando termina el aumento de actividad. Con Aurora Serverless v2, ya no tiene que aprovisionar la capacidad para los picos ni para la carga promedio. Puede especificar un límite de capacidad superior para gestionar la peor situación. Esa capacidad no se utilizaría a menos que fuera necesario.
La granularidad de la reducción horizontal de Aurora Serverless v2 le ayuda a adaptar la capacidad a las necesidades de su base de datos. En un clúster aprovisionado, para el escalado vertical hay que añadir una nueva instancia de base de datos. En un clúster de Aurora Serverless v1, para el escalado vertical hay que duplicar el número de unidades de capacidad (ACU) de Aurora para el clúster (por ejemplo, de 16 a 32 o de 32 a 64). En cambio, Aurora Serverless v2 puede añadir media ACU cuando solo se necesite un poco más de capacidad. Puede añadir 0,5, 1, 1,5, 2 o media ACU adicional en función de la capacidad adicional necesaria para gestionar un aumento de la carga de trabajo. Además, puede eliminar 0,5, 1, 1,5, 2 o media ACU adicional cuando la carga de trabajo disminuya y esa capacidad ya no se necesite.
+ **Aplicaciones de varios inquilinos**: con Aurora Serverless v2, no es preciso administrar individualmente la capacidad de la base de datos para cada aplicación de la flota. Aurora Serverless v2 administra la capacidad de la base de datos individual por usted.
Puede crear un clúster para cada inquilino. De esta forma, puede utilizar funciones como la clonación, la restauración de instantáneas y las bases de datos globales de Aurora para mejorar la alta disponibilidad y la recuperación de desastres según corresponda para cada inquilino.
Cada inquilino puede tener períodos específicos de actividad e inactividad según la hora del día, la época del año, los eventos promocionales, etc. Cada clúster puede tener un amplio rango de capacidad. De esta forma, los clústeres con poca actividad incurren en los cargos mínimos de instancias de base de datos. Cualquier clúster puede escalarse de forma vertical rápidamente para gestionar períodos de actividad elevada.
+ **Aplicaciones nuevas**: implementa una nueva aplicación y no está seguro del tamaño de instancia de base de datos que necesita. Con Aurora Serverless v2, puede configurar un clúster con una o varias instancias de base de datos y hacer que esta última se escale automáticamente de acuerdo con los requisitos de capacidad de la aplicación.
+ **Aplicaciones de uso mixto**: supongamos que tiene una aplicación de procesamiento de transacciones en línea (OLTP), pero periódicamente experimenta picos en el tráfico de consultas. Si especifica niveles de promoción para las instancias de base de datos de Aurora Serverless v2 en un clúster, puede configurar el clúster para que las instancias de base de datos del lector se puedan escalar independientemente de la instancia de base de datos de escritor para gestionar la carga adicional. Cuando el pico de uso disminuye, las instancias de base de datos del lector se escalan de nuevo para adaptarlas a la capacidad de la instancia de base de datos del escritor.
+ **Planificación de capacidad**: supongamos que normalmente ajusta la capacidad de la base de datos o verifica la capacidad de la base de datos óptima para la carga de trabajo modificando las clases de instancias de base de datos de todas las instancias de base de datos de un clúster. Con Aurora Serverless v2, puede evitar esta sobrecarga administrativa. Para determinar la capacidad mínima y máxima apropiadas, puede ejecutar la carga de trabajo y comprobar cuánto se escalan realmente las instancias de base de datos.
Puede modificar las instancias de base de datos existentes de aprovisionadas a Aurora Serverless v2 o de Aurora Serverless v2 a aprovisionadas. En estos casos, no es necesario crear un clúster nuevo o una instancia de base de datos nueva.
Con una base de datos global de Aurora, puede que no necesite tanta capacidad para los clústeres secundarios como en el clúster principal. Puede usar instancias de base de datos de Aurora Serverless v2 en los clústeres secundarios. De esta forma, la capacidad del clúster se puede escalar verticalmente si se promueve una región secundaria que se hace cargo de la carga de trabajo de la aplicación.
+ **Desarrollo y pruebas**: además de ejecutar las aplicaciones más exigentes, también puede utilizarlas en entornosAurora Serverless v2 de desarrollo y pruebas. Con Aurora Serverless v2, puede crear instancias de base de datos de con una capacidad mínima en lugar de utilizar clases de instancias ampliables de base de datos db.t\$1. Puede establecer la capacidad máxima lo suficientemente alta como para que esas instancias de base de datos puedan seguir ejecutando cargas de trabajo sustanciales sin quedarse sin memoria. Cuando la base de datos no está en uso, todas las instancias de base de datos se escalan verticalmente para evitar cargos innecesarios.
**sugerencia**
Para que sea cómodo usar Aurora Serverless v2 en entornos de desarrollo y pruebas, Consola de administración de AWS proporciona el acceso directo **Easy create** (Creación sencilla) para crear un nuevo clúster. Si elige la opción **Dev/Test** (Desarrollo/pruebas), Aurora crea un clúster con una instancia de base de datos de Aurora Serverless v2 y un rango de capacidad típico de un sistema de desarrollo y prueba.
### Uso de Aurora Serverless v2 para cargas de trabajo aprovisionadas existentes
Supongamos que ya tiene una aplicación Aurora en ejecución en un clúster aprovisionado. Puede comprobar cómo funcionaría la aplicación con Aurora Serverless v2 añadiendo una o varias instancias de base de datos de Aurora Serverless v2 al clúster existente como instancias de base de datos del lector. Puede comprobar con qué frecuencia se escalan vertical y horizontalmente las instancias de base de datos del lector. Puede utilizar el mecanismo de conmutación por error de Aurora para promover una instancia de base de datos de Aurora Serverless v2 para que sea el escritor y comprobar cómo gestiona la carga de trabajo de lectura y escritura. De esta forma, puede realizar el cambio con un tiempo de inactividad mínimo y sin cambiar el punto de conexión que utilizan las aplicaciones cliente. Para obtener más información sobre el procedimiento para convertir los clústeres existentes a Aurora Serverless v2, consulte [Migración a Aurora Serverless v2](aurora-serverless-v2.upgrade.md).
## Ventajas de Aurora Serverless v2
Aurora Serverless v2 está destinado a cargas de trabajo variables o “con picos”. Con cargas de trabajo tan impredecibles, podría tener dificultades para planificar cuándo cambiar la capacidad de la base de datos. También podría tener problemas para realizar cambios de capacidad con la suficiente rapidez mediante los mecanismos conocidos, como añadir instancias de base de datos o cambiar clases de instancias de base de datos. Aurora Serverless v2 proporciona las siguientes ventajas para ayudar con estos casos de uso:
+ **Administración de la capacidad más sencilla que con la aprovisionada**: Aurora Serverless v2 reduce el esfuerzo de planificar los tamaños de las instancias de base de datos y cambiar el tamaño de las instancias de base de datos a medida que cambia la carga de trabajo. También reduce el esfuerzo para mantener una capacidad uniforme para todas las instancias de base de datos en un clúster.
+ **Escalado más rápido y sencillo durante períodos de alta actividad**: Aurora Serverless v2 escala la capacidad de memoria y de computación en función de las necesidades, sin interrumpir las transacciones del cliente ni de la carga de trabajo general. La capacidad de utilizar instancias de base de datos de lectores con Aurora Serverless v2 le ayuda a aprovechar el escalado horizontal además del escalado vertical. La capacidad de utilizar las bases de datos globales de Aurora le permite repartir la carga de trabajo de lectura de Aurora Serverless v2 entre varias Regiones de AWS. Esta capacidad es más práctica que los mecanismos de escalado de los clústeres aprovisionados. También es un método más rápido y granular que las capacidades de escalado de Aurora Serverless v1.
+ **Rentable durante períodos de baja actividad**: Aurora Serverless v2 le ayuda a evitar el sobreaprovisionamiento de las instancias de base de datos.Aurora Serverless v2 añade recursos en incrementos granulares cuando se escalan verticalmente las instancias de base de datos. Solo paga por los recursos de bases de datos que consume. El uso de los recursos de Aurora Serverless v2 se mide por segundo. De esta forma, cuando una instancia de base de datos se reduce, la reducción del uso de recursos se registra de inmediato.
+ **Mayor paridad de características con aprovisionamiento**: puede utilizar muchas características de Aurora con Aurora Serverless v2 que no están disponibles para Aurora Serverless v1. Por ejemplo, con Aurora Serverless v2 puede utilizar instancias de base de datos de lectores, bases de datos globales, autenticación de base de datos de AWS Identity and Access Management (IAM) y Performance Insights. También puede utilizar muchos más parámetros de configuración que con Aurora Serverless v1.
En particular, con Aurora Serverless v2 puede aprovechar las siguientes características de los clústeres aprovisionados:
+ **Instancias de base de datos**:Aurora Serverless v2 puede aprovechar las instancias de base de datos de lector para escalar horizontalmente. Cuando un clúster contiene una o más instancias de base de datos de lectores, el clúster puede conmutar por error inmediatamente en caso de que haya problemas con la instancia de base de datos del escritor. Esta es una capacidad que no está disponible con Aurora Serverless v1.
+ **Clústeres multi-AZ**: puede distribuir las instancias de base de datos de Aurora Serverless v2 de un clúster entre varias zonas de disponibilidad (AZ). La configuración de un clúster Multi-AZ ayuda a garantizar la continuidad del negocio incluso en los raros casos en los que hay problemas que afectan a una AZ completa. Esta es una capacidad que no está disponible con Aurora Serverless v1.
+ **Bases de datos globales**: puede usar Aurora Serverless v2 en combinación con las bases de datos globales de Aurora para crear copias de solo lectura adicionales del clúster en otras Regiones de AWS para fines de recuperación de desastres.
+ **Proxy RDS**: puede usar el proxy de Amazon RDS para permitir a las aplicaciones agrupar y compartir conexiones de base de datos para mejorar su capacidad de escala.
+ **Escalado más rápido, más granular y menos disruptivo que con Aurora Serverless v1**: Aurora Serverless v2 puede escalarse más rápido. El escalado puede cambiar la capacidad en tan solo 0,5 ACU, en lugar de duplicar o reducir a la mitad el número de ACU. El escalado suele producirse sin interrumpir el procesamiento. El escalado no implica un evento que deba tener en cuenta, como ocurre con Aurora Serverless v1. El escalado puede realizarse mientras se ejecutan las instrucciones SQL y las transacciones están abiertas, sin necesidad de esperar a que haya un punto de silencio.
# Cómo funciona Aurora Serverless v2
La siguiente información general describe cómo funciona Aurora Serverless v2.
**Topics**
+ [Descripción general](#aurora-serverless-v2.architecture)
+ [Configuraciones de clúster](#aurora-serverless-v2.how-it-works.cluster_topology)
+ [Capacidad](#aurora-serverless-v2.how-it-works.capacity)
+ [Escalado](#aurora-serverless-v2.how-it-works.scaling)
+ [Alta disponibilidad](#aurora-serverless.ha)
+ [Almacenamiento](#aurora-serverless.storage)
+ [Parámetros de configuración](#aurora-serverless-v2.parameters)
## Aurora Serverless v2Información general de
*Amazon Aurora Serverless v2* va bien para las cargas de trabajo más exigentes y muy variables. Por ejemplo, el uso de la base de datos puede ser intensivo durante un corto periodo de tiempo, seguido de largos periodos de poca actividad o de ninguna actividad en absoluto. Ejemplos de ello son sitios web de venta minorista, juegos o deportes con eventos promocionales periódicos y bases de datos que generan informes cuando se necesitan. Otros son entornos de desarrollo y pruebas y nuevas aplicaciones en las que el uso podría aumentar rápidamente. Para casos como estos y muchos otros, la configuración correcta de la capacidad por anticipado no siempre es posible con el modelo aprovisionado. También puede resultar en costos más elevados si se aprovisiona en exceso y tiene capacidad que no utiliza.
En cambio, los *clústeres aprovisionados de Aurora* van bien para cargas de trabajo estables. Los clústeres aprovisionados le permiten elegir una clase de instancia de base de datos que tenga una cantidad predefinida de memoria, capacidad de CPU, ancho de banda de E/S, etc. Si la carga de trabajo cambia, modificará manualmente la clase del escritor y los lectores. El modelo aprovisionado funciona bien cuando se puede ajustar con anticipación la capacidad de los patrones de consumo esperados y se aceptan interrupciones breves mientras cambia la clase del escritor y los lectores del clúster.
Aurora Serverless v2 se ha diseñado desde cero para admitir clústeres de base de datos sin servidor escalables al instante. Aurora Serverless v2 se ha diseñado para proporcionar el mismo grado de seguridad y aislamiento que con escritores y lectores aprovisionados. Estos aspectos son cruciales en entornos de nube sin servidor multitenant. El mecanismo de escalado dinámico tiene muy poca sobrecarga para que pueda responder rápidamente a los cambios en la carga de trabajo de la base de datos. También es lo suficientemente potente como para satisfacer los incrementos drásticos en la demanda de procesamiento.
Con Aurora Serverless v2 podrá crear un clúster de bases de datos Aurora sin quedar sujeto a una capacidad de base de datos específica para escritor y lector. El usuario especifica el rango mínimo y máximo de capacidad. Aurora escala cada instancia Aurora Serverless v2 de escritura o lectura en el clúster dentro de ese rango de capacidad. Usar un clúster Multi-AZ en el que cada escritor o lector puede escalar dinámicamente permite aprovechar el escalado dinámico y de una alta disponibilidad.
Aurora Serverless v2 escala los recursos de base de datos de forma automática en función de las especificaciones de capacidad mínima y máxima. El escalado es rápido, ya que la mayoría de las operaciones de eventos de escalado mantienen al escritor o al lector en el mismo host. En los raros casos en que una instancia Aurora Serverless v2 de escritura o lectura se mueve de un host a otro, Aurora Serverless v2 administra las conexiones automáticamente. No es necesario cambiar el código de la aplicación cliente de base de datos o las cadenas de conexión de base de datos.
Con Aurora Serverless v2, al igual que ocurre con los clústeres aprovisionados, la capacidad de almacenamiento y la capacidad informática son independientes. Cuando hablamos de capacidad y escalado de Aurora Serverless v2, lo hacemos siempre de la capacidad de computación que aumenta o disminuye. Por lo tanto, el clúster puede contener muchos terabytes de datos incluso cuando la capacidad de la CPU y la memoria se reducen a niveles bajos.
En lugar de aprovisionar y administrar los servidores de bases de datos, hay que especificar la capacidad de la base de datos. Para más detalles acerca de la capacidad en Aurora Serverless v2, consulte [Aurora Serverless v2Capacidad de](#aurora-serverless-v2.how-it-works.capacity). La capacidad real de cada instancia Aurora Serverless v2 de escritor o de lector varía con el tiempo, según la carga de trabajo. Para obtener más información sobre este mecanismo, consulte [Aurora Serverless v2Escalado en](#aurora-serverless-v2.how-it-works.scaling).
**importante**
Con Aurora Serverless v1, el clúster tiene una única medida de capacidad informática que puede escalar entre los valores de capacidad mínima y máxima. Con Aurora Serverless v2, el clúster puede contener lectores además del escritor. Cada escritor y lector Aurora Serverless v2 pueden escalar entre los valores de capacidad mínima y máxima. Por lo tanto, la capacidad total del clúster de Aurora Serverless v2 depende tanto del rango de capacidad que defina para el clúster de bases de datos como del número de escritores y lectores del clúster. En cualquier momento dado, solo se le cobrará por la capacidad de Aurora Serverless v2 que se estén utilizando activamente en el clúster de bases de datos de Aurora.
## Configuraciones para clústeres de base de datos de Aurora
Para cada uno de sus clústeres de base de datos Aurora, puede elegir cualquier combinación de capacidad de Aurora Serverless v2, capacidad aprovisionada o ambas.
Puede configurar un clúster que contenga ambas, capacidad Aurora Serverless v2 y capacidad aprovisionada, llamado un *clúster de configuración mixta*. Por ejemplo, supongamos que necesita más capacidad de lectura/escritura de la disponible para un escritor Aurora Serverless v2. En este caso, puede configurar el clúster con un escritor aprovisionado muy grande. En ese caso, puede seguir utilizando Aurora Serverless v2 para los lectores. O, supongamos que la carga de trabajo de escritura del clúster varía pero la carga de trabajo de lectura es estable. En este caso, puede configurar el clúster con un escritor Aurora Serverless v2 y uno o más lectores aprovisionados.
También puede configurar un clúster de bases de datos en el que administre toda la capacidad Aurora Serverless v2. Para ello, puede crear un nuevo clúster y utilizar Aurora Serverless v2 desde el principio. O bien, puede reemplazar toda la capacidad aprovisionada de un clúster existente por Aurora Serverless v2. Por ejemplo, algunas de las rutas de actualización de versiones anteriores del motor requieren comenzar con un escritor aprovisionado y reemplazarlo por un escritor Aurora Serverless v2. Para los procedimientos para crear un nuevo clúster de bases de datos con Aurora Serverless v2, o para cambiar un clúster de bases de datos existente a Aurora Serverless v2, consulte [Creación de un clúster de bases de datos de Aurora Serverless v2](aurora-serverless-v2.create.md#aurora-serverless-v2.create-cluster) y [Cambiar de un clúster aprovisionado a Aurora Serverless v2](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.switch-from-provisioned).
Si no utiliza Aurora Serverless v2 en absoluto en un clúster de bases de datos, todos los escritores y lectores del clúster de bases de datos serán *aprovisionados*. Este es el tipo de clúster de bases de datos más antiguo y común con el que la mayoría de los usuarios están familiarizados. De hecho, antes de Aurora Serverless, no había un nombre especial para este tipo de clúster de bases de datos de Aurora. La capacidad aprovisionada es constante. Los cargos son relativamente fáciles de pronosticar. No obstante, debe predecir de antemano cuánta capacidad necesita. En algunos casos, las predicciones pueden ser inexactas o las necesidades de capacidad pueden cambiar. En estos casos, el clúster de bases de datos puede estar infraprovisionado (más lento de lo que se desea) o sobreaprovisionado (más caro de lo que se desea).
## Aurora Serverless v2Capacidad de
La unidad de medida de Aurora Serverless v2 es la *unidad de capacidad Aurora (ACU)*. La capacidad de Aurora Serverless v2 no va vinculada a las clases de instancias de base de datos que se utilizan para los clústeres aprovisionados.
Cada ACU es una combinación de aproximadamente 2 gigabytes (GiB) de memoria, la CPU correspondiente y las redes. El rango de capacidad de la base de datos se especifica mediante esta unidad de medida. Las métricas `ServerlessDatabaseCapacity` y `ACUUtilization` le ayudan a determinar cuánta capacidad está utilizando realmente su base de datos y dónde se encuentra dentro del rango especificado.
En cualquier momento, cada instancia de base de datos de escritura o lectura Aurora Serverless v2 datos tiene una *capacidad*. La capacidad se representa como un número de coma flotante que representa la ACU. La capacidad aumenta o disminuye cada vez que el escritor o el lector se escalan. Este valor se mide cada segundo. Para cada clúster de bases de datos en el que se pretenda utilizar Aurora Serverless v2, se defines un *rango de capacidad*: los valores de capacidad mínima y máxima entre los que puede escalar cada escritor o lector Aurora Serverless v2. El rango de capacidad es el mismo para cada escritor o lector Aurora Serverless v2 en un clúster de bases de datos. Cada escritor o lector Aurora Serverless v2 tiene su propia capacidad, la cual corresponderá a algún punto en ese rango.
En la tabla siguiente se muestran los rangos de capacidad de Aurora Serverless v2 y la versión del motor compatibles con Aurora MySQL y Aurora PostgreSQL.
| Rango de capacidad (ACU) | Versiones compatibles de Aurora MySQL | Versiones compatibles de Aurora PostgreSQL |
| --- | --- | --- |
| 0,5–128 | 3.02.0 y versiones posteriores | 13.6 y versiones posteriores, 14.3 y versiones posteriores, 15.2 y versiones posteriores, 16.1 y versiones posteriores |
| 0,5–256 | 3.06.0 y versiones posteriores | 13.13 y versiones posteriores, 14.10 y versiones posteriores, 15.5 y versiones posteriores, 16.1 y versiones posteriores |
| 0–256 | 3.08.0 y versiones posteriores | 13.15 y versiones posteriores, 14.12 y versiones posteriores, 15.7 y versiones posteriores, 16.3 y versiones posteriores |
En la siguiente tabla, se muestran las versiones de la plataforma Aurora Serverless v2 con sus rangos de ACU y características de rendimiento.
| Aurora Serverless v2Versión de la plataforma de | Gama de ACU | Rendimiento |
| --- | --- | --- |
| 1 | 0-128 | Rendimiento de referencia |
| 2 | 0–256 | Rendimiento de referencia |
| 3 | 0–256 | Rendimiento mejorado hasta un 30 % en comparación con la versión 2 de la plataforma |
**nota**
El rango de escalado disponible para un clúster determinado viene determinado tanto por la versión del motor como por la versión de la plataforma. Es posible tener una versión de motor con mayor capacidad que se ejecute en una versión de la plataforma con menor capacidad y viceversa. El rango de escalado viene determinado por la versión de motor o versión de la plataforma con menor capacidad.
Puede determinar la versión de la plataforma en la que se ejecuta el clúster en la sección de configuración de instancias de la Consola de administración de AWS o a través de la API consultando la `ServerlessV2PlatformVersion` correspondiente para un [DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DBCluster.html).
La capacidad de Aurora Serverless v2 mínima que puede definir es de 0 ACU, para las versiones de Aurora Serverless v2 que admiten la característica de pausa automática. Puede especificar un número mayor si es menor o igual que el valor de capacidad máxima. Si se establece la capacidad mínima en un número pequeño, los clústeres de base de datos cargados ligeramente consumen recursos informáticos mínimos. Al mismo tiempo, permanecen listos para aceptar conexiones de inmediato y ampliarse cuando están ocupados.
Recomendamos establecer el mínimo en un valor que permita a cada instancia de base de datos de escritura o lectura mantener el conjunto de trabajo de la aplicación en el grupo del búfer. De esta forma, el contenido del grupo del búfer no se desecha durante los períodos de inactividad. Para saber todo lo que debe tener en cuenta a la hora de elegir el valor de capacidad mínima, consulte [Elegir la configuración de capacidad de Aurora Serverless v2 mínima para un clúster](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.min_capacity_considerations). Para saber todo lo que debe tener en cuenta a la hora de elegir el valor de capacidad máxima, consulte [Elegir la configuración de capacidad de Aurora Serverless v2 máxima para un clúster](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max_capacity_considerations).
En función de cómo configure los lectores en una implementación multi-AZ, sus capacidades se pueden vincular a la capacidad del escritor o de forma independiente. Para obtener información detallada sobre cómo hacerlo, consulte [Aurora Serverless v2Escalado en](#aurora-serverless-v2.how-it-works.scaling).
Supervisar Aurora Serverless v2 implica medir los valores de capacidad del escritor y los lectores del clúster de bases de datos a lo largo del tiempo. Si la base de datos no se reduce a la capacidad mínima, puede realizar acciones como ajustar el mínimo y optimizar la aplicación de base de datos. Si la base de datos alcanza su capacidad máxima de forma coherente, puede realizar acciones como aumentar el máximo. También puede optimizar la aplicación de base de datos y distribuir la carga de consultas entre más lectores.
Los cargos correspondientes a la capacidad de Aurora Serverless v2 se mide en términos de horas de ACU. Para obtener información acerca de cómo se calculan los cargos para Aurora Serverless v2, consulte la [página de precios de Aurora](https://aws.amazon.com/rds/aurora/pricing/).
Supongamos que el número total de escritores y lectores del clúster es *n*. En ese caso, el clúster consume aproximadamente `n x minimum ACUs` cuando no se está ejecutando ninguna operación de base de datos. Aurora puede ejecutar operaciones de supervisión o mantenimiento que provocan una pequeña cantidad de carga. Ese clúster no consume más de `n x maximum ACUs` cuando la base de datos se ejecuta a plena capacidad.
Para obtener más información sobre cómo elegir los valores de ACU mínimos y máximos adecuados, consulte [Elegir el rango de capacidad de Aurora Serverless v2 para un clúster de Aurora](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster). Los valores de ACU mínimo y máximo especificados también afectan a la forma en que funcionan algunos de los parámetros de configuración de Aurora para Aurora Serverless v2. Para obtener más información sobre la interacción entre el rango de capacidad y los parámetros de configuración, consulte [Trabajo con los grupos de parámetros para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.parameter-groups).
## Aurora Serverless v2Escalado en
Para cada escritor o lector Aurora Serverless v2, Aurora realiza un seguimiento continuo del uso de recursos como la CPU, la memoria y la red. Estas mediciones se denominan colectivamente *carga*. La carga incluye las operaciones de base de datos realizadas por la aplicación. También incluye procesamiento en segundo plano para el servidor de base de datos y tareas administrativas de Aurora. Cuando la capacidad queda limitada por cualquiera de ellos, Aurora Serverless v2 aumenta. Aurora Serverless v2 también se amplía cuando detecta problemas de rendimiento que se pueden resolver de esta manera. Puede supervisar la utilización de los recursos y cómo afecta al escalado en Aurora Serverless v2 mediante los procedimientos en [Métricas importantes de Amazon CloudWatch para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring) y [Supervisión del rendimiento de Aurora Serverless v2 con la información de rendimiento](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.performance-insights).
La carga puede variar según el escritor o los lectores del clúster de bases de datos. El escritor se encarga de todas las instrucciones de lenguaje de definición de datos (DDL), tales como `CREATE TABLE`, `ALTER TABLE` y `DROP TABLE`. El escritor también se encarga de todas las instrucciones de lenguaje de manipulación de datos (DML), como `INSERT` y `UPDATE`. Los lectores pueden procesar declaraciones de solo lectura, como consultas `SELECT`.
El *escalado* es la operación que aumenta o disminuye la capacidad de Aurora Serverless v2 para la base de datos. Con Aurora Serverless v2, escritor y lector tiene su propio valor de capacidad en uso, medida en ACU. Aurora Serverless v2 escala un escritor o lector a una mayor capacidad cuando su capacidad en uso es demasiado baja para manejar la carga. Escala el escritor o el lector a una capacidad inferior cuando su capacidad en uso es superior a la necesaria.
A diferencia de Aurora Serverless v1, que escala duplicando las ACU cada vez que el clúster de bases de datos alcanza un límite, Aurora Serverless v2 puede aumentar la capacidad incrementalmente. Cuando la demanda de carga de trabajo comienza a alcanzar la capacidad de base de datos en uso de un escritor o un lector, Aurora Serverless v2 aumenta el número de ACU de ese escritor y lector. Aurora Serverless v2 escala la capacidad en función de los incrementos necesarios para proporcionar el mejor rendimiento de los recursos consumidos. El escalado se produce en incrementos tan pequeños como 0,5 ACU. Cuanto mayor sea la capacidad en uso, mayor será el incremento de escalado y, por lo tanto, más rápido puede producirse el escalado.
Ya que el escalado en Aurora Serverless v2 es tan frecuente, granular y no disruptivo, no genera eventos discretos en la Consola de administración de AWS igual que lo hace Aurora Serverless v1. En su lugar, puede medir las métricas de Amazon CloudWatch, como `ServerlessDatabaseCapacity` y `ACUUtilization` y hacer un seguimiento de sus valores mínimo, máximo y medio a lo largo del tiempo. Para obtener más información sobre las métricas de Aurora, consulte [Supervisión de métricas en un clúster de Amazon Aurora](MonitoringAurora.md). Para ver sobre cómo supervisar Aurora Serverless v2, consulte [Métricas importantes de Amazon CloudWatch para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring).
Puede elegir escalar el lector al mismo tiempo que el escritor asociado o independientemente del escritor. Para ello, especifique el nivel de promoción de ese lector.
+ Los lectores en niveles de promoción 0 y 1 se escalan al mismo tiempo que el escritor. Este comportamiento de escalado hace que los lectores de los niveles prioritarios 0 y 1 sean ideales para disponibilidad. Esto se debe a que siempre tienen el tamaño adecuado para asumir la carga de trabajo de escritura en caso de conmutación por error.
+ Los lectores de los niveles de promoción 2 a 15 escalan independientemente del escritor. Cada lector se mantiene dentro de los valores de ACU mínimo y máximo especificados para el clúster. Cuando un lector escala independientemente de la base de datos de escritura asociada, puede pasar a quedar inactiva y reducirse mientras el escritor continúa procesando un gran volumen de transacciones. Sigue disponible como objetivo de conmutación por error si no hay otros lectores disponibles en niveles de promoción más bajos. No obstante, si se promueve para ser el escritor, es posible que tenga que escalar para manejar toda la carga de trabajo del escritor.
Para obtener información detallada sobre los niveles de promoción, consulte [Elegir el nivel de promoción para un lector Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier).
Las nociones de los puntos de escala y los periodos de tiempo de espera asociados desde Aurora Serverless v1 no son aplicables en Aurora Serverless v2. El escalado en Aurora Serverless v2 puede ocurrir mientras hay conexiones de base de datos abiertas, mientras hay transacciones SQL en proceso, mientras hay tablas bloqueadas y mientras se utilizan tablas temporales. Aurora Serverless v2 no espera a que un llegue punto de dewscanso para comenzar a escalar. El escalado no interrumpe ninguna operación de base de datos en curso.
Si la carga de trabajo requiere más capacidad de lectura de la disponible con un solo escritor y un solo lector, puede agregar varios lectores Aurora Serverless v2 al clúster. Cada lector Aurora Serverless v2 puede escalar dentro de los valores de capacidad mínimo y máximo especificados para el clúster de bases de datos. Puede utilizar el punto de conexión del lector del clúster para dirigir las sesiones de solo lectura a los lectores y reducir la carga en el escritor.
Que Aurora Serverless v2 realice un escalado y lo rápido que se produzca el escalado una vez que se inicie, también dependerá de la configuración de ACU mínima y máxima para el clúster. Además, depende de si un lector está configurado para escalar junto con el escritor o independientemente de él. Para obtener información acerca de los factores que afectan al escalado de Aurora Serverless v2, consulte [Rendimiento y escalado para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md).
### Escalado hasta cero
En las versiones de Aurora MySQL y Aurora PostgreSQL recientes, los escritores y los lectores de Aurora Serverless v2 pueden escalarse hasta cero ACU. Nos referimos a esta capacidad como pausa y reanudación automáticas o pausa automática. Puede elegir si desea permitir este comportamiento al especificar un valor cero o distinto de cero para la capacidad mínima. También puede elegir cuánto tiempo esperar antes de que una instancia de Aurora Serverless v2 se detenga. Para obtener información sobre las versiones que tienen esta capacidad, consulte [Aurora Serverless v2Capacidad de](#aurora-serverless-v2.how-it-works.capacity). Para obtener información acerca de cómo utilizarlo de manera eficaz, consulte [Escalado a cero ACU con pausa y reanudación automáticas para Aurora Serverless v2](aurora-serverless-v2-auto-pause.md).
En las versiones de Aurora MySQL y Aurora PostgreSQL anteriores, los escritores y los lectores de Aurora Serverless v2 inactivos pueden reducir verticalmente hasta el valor de ACU mínimo especificado para el clúster, pero no hasta cero ACU. En ese caso, la opción de cero ACU no está disponible al establecer el rango de capacidad. Ese comportamiento es diferente de Aurora Serverless v1, que puede detenerse después de un período de inactividad, pero luego tarda algún tiempo en reanudarse al abrir una nueva conexión.
Cuando el clúster de bases de datos con capacidad de Aurora Serverless v2 no se necesita durante algún tiempo, puede también detener e iniciar todo el clúster, lo mismo con los clústeres de bases de datos aprovisionados. Esta técnica es la más adecuada para los sistemas de desarrollo y prueba, en los que es posible que no se necesiten durante muchas horas seguidas y la velocidad de reanudación del clúster no es crucial. La característica de detener o iniciar el clúster está disponible para todas las versiones de Aurora Serverless v2. Para obtener más información acerca de esa característica, consulte [Detención e inicio de un clúster de bases de datos de Amazon Aurora](aurora-cluster-stop-start.md).
## Aurora Serverless v2 y alta disponibilidad
La forma de establecer una alta disponibilidad para un clúster de bases de datos Aurora es convertirlo en un clúster de bases de datos Multi-AZ. Un *clúster de bases de datos Aurora Multi-AZ* tiene capacidad informática disponible en todo momento en más de una zona de disponibilidad (AZ). Esta configuración mantiene la base de datos en funcionamiento incluso en caso de una interrupción significativa. Aurora realiza una conmutación por error automática en caso de que se produzca un problema que afecte al escritor o incluso a toda la zona de disponibilidad. Con Aurora Serverless v2 puede elegir que la capacidad de computación en espera se amplíe y disminuya junto con la capacidad de escritura. De esta forma, la capacidad de computación en la segunda zona de disponibilidad queda lista para asumir la carga de trabajo actual en cualquier momento. Al mismo tiempo, la capacidad de computación de todas las zonas de disponibilidad puede reducirse cuando la base de datos está inactiva. Para obtener más información sobre cómo funciona Aurora con Regiones de AWS y las zonas de disponibilidad, consulte [Alta disponibilidad para instancias de bases de datos de Aurora](Concepts.AuroraHighAvailability.md#Concepts.AuroraHighAvailability.Instances).
La capacidad Multi-AZ de Aurora Serverless v2 utiliza *lectores* además del escritor. La compatibilidad para lectores es nueva para Aurora Serverless v2 en comparación con Aurora Serverless v1. Puede añadir hasta 15 lectores de Aurora Serverless v2 distribuidos en tres zonas de disponibilidad en un clúster de bases de datos de Aurora.
Para aplicaciones críticas para el negocio que deben permanecer disponibles incluso en caso de que se produzca un problema que afecte a todo el clúster o a toda la región de AWS, puede configurar una base de datos global de Aurora. Puede usar la capacidad de Aurora Serverless v2 en los clústeres secundarios para que estén listos para asumir el control durante la recuperación ante desastres. También se pueden reducir cuando la base de datos no está ocupada. Para obtener información detallada sobre bases de datos globales de Aurora, consulte [Uso de una base de datos global de Amazon Aurora](aurora-global-database.md).
Aurora Serverless v2 funciona como aprovisionado para conmutación por error y otras funciones de alta disponibilidad. Para obtener más información, consulte [Alta disponibilidad para Amazon Aurora](Concepts.AuroraHighAvailability.md).
Supongamos que desea garantizar la máxima disponibilidad de su clúster de Aurora Serverless v2. Puede crear un lector además del escritor. Si asigna al lector al nivel de promoción 0 o 1, cualquier escalado que ocurra para el escritor también se producirá en el lector. De esta forma, un lector con capacidad idéntica siempre estará listo para sustituir al escritor en caso de conmutación por error.
Supongamos que desea ejecutar informes trimestrales para su empresa al mismo tiempo que el clúster continúa procesando transacciones. Si añade un lector Aurora Serverless v2 al clúster y lo asigna a un nivel de promoción del 2 al 15, puede conectarse directamente a ese lector para ejecutar los informes. Dependiendo del uso intensivo de memoria y de la CPU que hagan las consultas de informes, ese lector puede escalar para adaptarse a la carga de trabajo. A continuación, puede reducirse de nuevo cuando los informes hayan finalizado.
## Aurora Serverless v2 y almacenamiento
El almacenamiento de cada clúster de bases de datos Aurora consta de seis copias de todos sus datos, repartidas en tres zonas de disponibilidad. Esta replicación de datos integrada se aplica independientemente de si el clúster de bases de datos incluye lectores además del escritor. De esta forma, sus datos están seguros, incluso ante problemas que afecten a la capacidad de computación del clúster.
Aurora Serverless v2 El almacenamiento de tiene las mismas características de fiabilidad y durabilidad que se describen en [Almacenamiento de Amazon Aurora](Aurora.Overview.StorageReliability.md). Esto se debe a que el almacenamiento de los clústeres de bases de datos Aurora funciona igual tanto si la capacidad de computación utiliza Aurora Serverless v2 como si es aprovisionada.
## Parámetros de configuración de los clústeres de Aurora
Puede ajustar los mismos parámetros de configuración de clúster y base de datos para clústeres con capacidad de Aurora Serverless v2 como para clústeres de base de datos aprovisionados. Sin embargo, algunos parámetros relacionados con la capacidad se manejan de forma diferente para Aurora Serverless v2. En un clúster de configuración mixta, los valores de los parámetros especificados para esos parámetros relacionados con la capacidad se siguen aplicando a los escritores y los lectores aprovisionados.
Casi todos los parámetros funcionan de la misma manera para los escritores y los lectores Aurora Serverless v2 que para los aprovisionados. Las excepciones son algunos parámetros que Aurora ajusta automáticamente durante el escalado y algunos parámetros que Aurora mantiene en valores fijos que dependen de la configuración de capacidad máxima.
Por ejemplo, la cantidad de memoria reservada para la memoria caché del búfer aumenta a medida que un escritor o un lector aumenta y disminuye cuando se reduce la escala. De esta forma, la memoria se puede liberar cuando la base de datos no está ocupada. Por el contrario, Aurora establece automáticamente el número máximo de conexiones en un valor adecuado según la configuración de capacidad máxima. De esta forma, las conexiones activas no se pierden si la carga cae y Aurora Serverless v2escala a menos. Para obtener información acerca de cómo Aurora Serverless v2 gestiona parámetros específicos, consulte [Trabajo con los grupos de parámetros para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.parameter-groups).
# 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:
**Topics**
+ [Disponibilidad en regiones y versiones](#aurora-serverless-v2-Availability)
+ [Los clústeres que utilizan Aurora Serverless v2 deben tener un rango de capacidad especificado](#aurora-serverless-v2.requirements.capacity-range)
+ [Algunas características aprovisionadas no se admiten en Aurora Serverless v2](#aurora-serverless-v2.limitations)
+ [Algunos aspectos de Aurora Serverless v2 son diferentes en Aurora Serverless v1](#aurora-serverless-v2.requirements.v1-v2-differences)
## 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](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md).
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](aurora-serverless-v2.how-it-works.md).
Para obtener información sobre los rangos de capacidad permitidos de las distintas versiones de motores de base de datos, consulte [Aurora Serverless v2Capacidad de](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
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](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus). 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](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster).
## 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](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster). 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](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.setting-capacity.incompatible_parameters).
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.
## Algunos aspectos de Aurora Serverless v2 son diferentes en Aurora Serverless v1
Si es usuario de Aurora Serverless v1 y es la primera vez que usa Aurora Serverless v2, consulte las [diferencias entre los requisitos de Aurora Serverless v2 y Aurora Serverless v1](aurora-serverless-v2.upgrade.md#Serverless.v1-v2-requirements) para saber qué requisitos son diferentes en Aurora Serverless v1 y Aurora Serverless v2.
# Creación de un clúster de base de datos que utiliza Aurora Serverless v2
Para crear un clúster de Aurora en el que pueda agregar instancias de bases de datos de Aurora Serverless v2, siga el mismo procedimiento que en [Creación de un clúster de base de datos de Amazon Aurora](Aurora.CreateInstance.md). Con Aurora Serverless v2, los clústeres son intercambiables por clústeres aprovisionados. Puede tener clústeres donde algunas instancias de base de datos utilicen Aurora Serverless v2 y se aprovisionen algunas instancias de base de datos.
**Topics**
+ [Configuración de clústeres de bases de datos de Aurora Serverless v2](#aurora-serverless-v2.create-settings)
+ [Creación de un clúster de bases de datos de Aurora Serverless v2](#aurora-serverless-v2.create-cluster)
+ [Creación de una instancia de base de datos de escritura de Aurora Serverless v2](#aurora-serverless-v2-adding-writer)
## Configuración de clústeres de bases de datos de Aurora Serverless v2
Asegúrese de que la configuración inicial del clúster cumpla los requisitos que se indican en [Requisitos y limitaciones para Aurora Serverless v2](aurora-serverless-v2.requirements.md). Especifique la siguiente configuración para asegurarse de que puede agregar instancias de base de datos de Aurora Serverless v2 al clúster:
**Región de AWS**
Cree el clúster en una Región de AWS donde haya instancias de base de datos de Aurora Serverless v2 disponibles. Para obtener más información sobre las regiones disponibles, consulte [Regiones y motores de base de datos Aurora admitidos para Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md).
**Versión del motor de base de datos**
Elija una versión de motor compatible con Aurora Serverless v2. Para obtener información sobre los requisitos de versión de Aurora Serverless v2, consulte [Requisitos y limitaciones para Aurora Serverless v2](aurora-serverless-v2.requirements.md).
**Clase de instancia de base de datos**
Si crea un clúster mediante la Consola de administración de AWS, elija la clase de instancia de base de datos de la instancia de base de datos de escritura al mismo tiempo. Elija la clase de instancia de base de datos **Serverless** (Sin servidor). Al elegir esa clase de instancia de base de datos, también especifica el rango de capacidad de la instancia de base de datos de escritura. El mismo rango de capacidad se aplica al resto de instancias de base de datos Aurora Serverless v2 que añada a ese clúster.
Si no ve la opción **Sin servidor** para la clase de instancia de base de datos, elija una versión de motor de base de datos compatible con [Regiones y motores de base de datos Aurora admitidos para Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md).
Cuando utiliza la AWS CLI o la API de Amazon RDS, el parámetro que especifica para la clase de instancia de base de datos es `db.serverless`.
**Capacity range (Rango de capacidad)**
Rellene los valores mínimos y máximos de la unidad de capacidad Aurora (ACU) aplicables a todas las instancias de base de datos del clúster. Esta opción está disponible en ambas páginas de la consola **Create cluster** (Crear el clúster) y **Add reader** (Añadir lector) al elegir **Serverless** (Sin servidor) para la clase de instancia de base de datos.
Para obtener información sobre los rangos de capacidad permitidos de las distintas versiones de motores de base de datos, consulte [Aurora Serverless v2Capacidad de](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
Si no ve los campos de ACU mínima y máxima, asegúrese de elegir la clase de instancia de base de datos **Sin servidor** de la instancia de base de datos de escritura.
En un principio se crea el clúster con una instancia de base de datos aprovisionada, no se especifican las ACU mínimas y máximas. En ese caso puede modificar el clúster posteriormente para agregar esa opción. También puede añadir una instancia de base de datos de lectura Aurora Serverless v2 al clúster. El rango de capacidad se especifica como parte de ese proceso.
Hasta que no especifique el rango de capacidad del clúster, no podrá agregar ninguna instancia de base de datos Aurora Serverless v2 al clúster mediante la AWS CLI o la API de RDS. Si intenta añadir una instancia de base de datos de Aurora Serverless v2, aparecerá un error. En la AWS CLI o en los procedimientos la API de RDS, el rango de capacidad se representa mediante el atributo `ServerlessV2ScalingConfiguration`.
Para los clústeres que contienen más de una instancia de base de datos de lectura, la prioridad de conmutación por error de cada instancia de base de datos de lectura Aurora Serverless v2 desempeña un papel importante en la forma en que esa instancia de base de datos escala (a más o a menos). No puede especificar la prioridad en el momento de crear el clúster. Tenga en cuenta esta propiedad cuando agregue una segunda instancia de base de datos de lectura (o más) al clúster. Para obtener más información, consulte [Elegir el nivel de promoción para un lector Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier).
## Creación de un clúster de bases de datos de Aurora Serverless v2
Puede usar la Consola de administración de AWS, la AWS CLI o la API de RDS para crear un clúster de base de datos de Aurora Serverless v2.
### Consola
**Para crear un clúster con escritor de Aurora Serverless v2**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija **Databases** (Bases de datos).
1. Elija **Create database (Creación de base de datos)**. En la página que aparece, elija las opciones siguientes:
+ En **Tipo de motor**, elija **Aurora (compatible con MySQL)** o **Aurora (compatible con PostgreSQL)**.
+ En **Versión**, elija una de las versiones compatibles para [Regiones y motores de base de datos Aurora admitidos para Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md).
1. En **Clase de instancia de base de datos**, elija **Sin servidor v2**.
1. En **Configuración de capacidad**, puede aceptar el rango predeterminado. O puede elegir otros valores para las unidades de capacidad mínima y máxima. Puede elegir entre un ACU mínimo de 0 y un ACU máximo de 256, en incrementos de ACU de 0,5.
Para obtener más información acerca de las unidades de capacidad de Aurora Serverless v2, consulte [Aurora Serverless v2Capacidad de](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity) y [Rendimiento y escalado para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md).
Según el motor y la versión que elija, el límite superior puede ser de 128 ACU, el límite inferior de 0,5 ACU o ambos. Para obtener más información sobre el límite de cada combinación de motor y versión de Aurora, consulte [Aurora Serverless v2Capacidad de](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
![\[Parámetros de configuración de instancias para Aurora Serverless v2.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_setting_incl_nonzero_minimum.png)
Si se selecciona una capacidad mínima de 0 ACU, se habilita la función de pausa y reanudación automáticas de Aurora Serverless v2. En ese caso, puede elegir además cuánto tiempo deben esperar las instancias de base de datos de Aurora Serverless v2 sin conexión a la base de datos antes de realizar una pausa automática. Para obtener información sobre la capacidad de pausa y reanudación automáticas, consulte [Escalado a cero ACU con pausa y reanudación automáticas para Aurora Serverless v2](aurora-serverless-v2-auto-pause.md).
![\[Configuración de capacidad de Aurora Serverless v2 cuando el límite inferior es de 0 ACU.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_setting_incl_zero_minimum.png)
1. Elija cualquier otra configuración de clúster de base de datos, tal y como se describe en [Configuración de clústeres de bases de datos de Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings).
1. Elija **Crear base de datos** para crear un clúster de base de datos de Aurora con una instancia de base de datos Aurora Serverless v2 como instancia de escritura, también llamada instancia de base de datos principal.
### CLI
Para crear un clúster de bases de datos compatible con instancias de base de datos Aurora Serverless v2 con AWS CLI, siga el procedimiento de CLI [Creación de un clúster de base de datos de Amazon Aurora](Aurora.CreateInstance.md). Incluya los siguientes parámetros en su comando `create-db-cluster`:
+ --region *región\$1de\$1AWS\$1donde\$1las\$1instancias\$1de\$1Aurora Serverless v2\$1están disponibles*
+ --engine-version *versión\$1de\$1motor\$1compatible\$1con\$1serverless\$1v2*
+ --serverless-v2-scaling-configuration MinCapacity=*capacidad\$1mínima*,MaxCapacity=*capacidad\$1máxima*
En el siguiente ejemplo se muestra la creación de un clúster de base de datos de Aurora Serverless v2.
```
aws rds create-db-cluster \
--db-cluster-identifier my-serverless-v2-cluster \
--region eu-central-1 \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.04.1 \
--serverless-v2-scaling-configuration MinCapacity=1,MaxCapacity=4 \
--master-username myuser \
--manage-master-user-password
```
**nota**
Al crear un clúster de base de datos de Aurora Serverless v2 utilizando la AWS CLI, el modo de motor aparece en la salida como `provisioned` en lugar de `serverless`. El modo de motor `serverless` hace referencia a Aurora Serverless v1.
En este ejemplo se especifica la opción `--manage-master-user-password` para generar la contraseña administrativa y administrarla en Secrets Manager. Para obtener más información, consulte [Administración de contraseñas con Amazon Aurora y AWS Secrets Manager](rds-secrets-manager.md). También puede utilizar la opción `--master-password` para especificar y administrar la contraseña usted mismo.
Para obtener información sobre los requisitos de versión de Aurora Serverless v2, consulte [Requisitos y limitaciones para Aurora Serverless v2](aurora-serverless-v2.requirements.md). Para obtener información sobre los números permitidos para el rango de capacidad y qué representan esos números, consulte [Aurora Serverless v2Capacidad de](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity) y [Rendimiento y escalado para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md).
Para comprobar si un clúster existente tiene la configuración de capacidad especificada, compruebe la salida del comando `describe-db-clusters` para el atributo `ServerlessV2ScalingConfiguration`. Este atributo tiene un aspecto similar al siguiente.
```
"ServerlessV2ScalingConfiguration": {
"MinCapacity": 1.5,
"MaxCapacity": 24.0
}
```
**sugerencia**
Si no especifica las ACU mínimas y máximas al crear el clúster, puede utilizar el comando `modify-db-cluster` después para agregar esa configuración. Hasta que lo haga no podrá añadir ninguna instancias de base de datos Aurora Serverless v2 al clúster. Si intenta añadir una instancia de base de datos de `db.serverless`, aparecerá un error.
### API
Para crear un clúster de bases de datos compatible con instancias de base de datos Aurora Serverless v2 que utilicen la API de RDS, siga el procedimiento de API en [Creación de un clúster de base de datos de Amazon Aurora](Aurora.CreateInstance.md). Seleccione los siguientes valores. Asegúrese de que su operación `CreateDBCluster` incluye los siguientes parámetros:
```
EngineVersion serverless_v2_compatible_engine_version
ServerlessV2ScalingConfiguration with MinCapacity=minimum_capacity and MaxCapacity=maximum_capacity
```
Para obtener información sobre los requisitos de versión de Aurora Serverless v2, consulte [Requisitos y limitaciones para Aurora Serverless v2](aurora-serverless-v2.requirements.md). Para obtener información sobre los números permitidos para el rango de capacidad y qué representan esos números, consulte [Aurora Serverless v2Capacidad de](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity) y [Rendimiento y escalado para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md).
Para comprobar si un clúster existente tiene la configuración de capacidad especificada, compruebe la salida de la operación `DescribeDBClusters` para el atributo `ServerlessV2ScalingConfiguration`. Este atributo tiene un aspecto similar al siguiente.
```
"ServerlessV2ScalingConfiguration": {
"MinCapacity": 1.5,
"MaxCapacity": 24.0
}
```
**sugerencia**
Si no especifica las ACU mínimas y máximas al crear el clúster, puede utilizar la operación `ModifyDBCluster` después para agregar esa configuración. Hasta que lo haga no podrá añadir ninguna instancias de base de datos Aurora Serverless v2 al clúster. Si intenta añadir una instancia de base de datos de `db.serverless`, aparecerá un error.
## Creación de una instancia de base de datos de escritura de Aurora Serverless v2
Aunque especifique el rango de capacidad de Aurora Serverless v2 al crear un clúster de Aurora, puede elegir si desea usar Aurora Serverless v2 o aprovisionado para cada instancia de base de datos del clúster. Para empezar a usar Aurora Serverless v2 inmediatamente en el clúster de base de datos, agregue una instancia de base de datos de escritura que utilice la clase de instancia de `db.serverless`. En la consola, normalmente se hace esta elección como parte del flujo de trabajo para crear el clúster de base de datos. Por lo tanto, este procedimiento se aplica principalmente cuando se realiza la configuración a través de la CLI.
### Consola
Cuando se crea un clúster de base de datos con la Consola de administración de AWS, en ese momento se especifican las propiedades de la instancia de base de datos de escritura. Para que la instancia de base de datos de escritura utilice Aurora Serverless v2, elija la clase d instancia de base de datos **Serverless** (Sin servidor).
A continuación deberá establecer el rango de capacidad del clúster especificando los valores mínimos y máximos de la unidad de capacidad Aurora (ACU). Los mismos valores mínimo y máximo se aplican a cada instancia de base de datos Aurora Serverless v2 del clúster. Para ver información sobre ese procedimiento y ver información sobre la importancia de la configuración de capacidad mínima y máxima, consulte [Creación de un clúster de bases de datos de Aurora Serverless v2](#aurora-serverless-v2.create-cluster).
Si no crea una instancia de base de datos Aurora Serverless v2 en el momento de crear el clúster por primera vez, puede agregar una o varias instancias de base de datos Aurora Serverless v2 más adelante. Para ello, siga los procedimientos en [Adición de un lector Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-adding-reader) y en [Conversión de un escritor o un lector aprovisionados a Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned). Especifique el rango de capacidad en el momento en el que añada la primera instancia de base de datos Aurora Serverless v2 al clúster. Puede cambiar el rango de capacidad posteriormente siguiendo el procedimiento en [Configuración del rango de capacidad de Aurora Serverless v2 para un clúster](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus).
### CLI
Cuando crea un clúster de base de datos de Aurora Serverless v2 mediante la AWS CLI, agrega explícitamente la instancia de base de datos del escritor mediante el comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html). Incluya el siguiente parámetro:
+ `--db-instance-class db.serverless`
En el siguiente ejemplo se muestra la creación de una instancia de base de datos del escritor de Aurora Serverless v2.
```
aws rds create-db-instance \
--db-cluster-identifier my-serverless-v2-cluster \
--db-instance-identifier my-serverless-v2-instance \
--db-instance-class db.serverless \
--engine aurora-mysql
```
# Administración de clústeres de bases de datos de Aurora Serverless v2
Con Aurora Serverless v2, los clústeres son intercambiables por clústeres aprovisionados. Las propiedades de Aurora Serverless v2 se aplican a una o varias instancias de base de datos dentro de un clúster de base de datos. Así pues, los procedimientos para crear clústeres, modificar clústeres, crear y restaurar instantáneas, etc., son básicamente los mismos que para otros tipos de clústeres de Aurora. Para obtener información sobre procedimientos generales para administrar clústeres e instancias de base de datos de Aurora, consulte [Administración de un clúster de base de datos de Amazon Aurora](CHAP_Aurora.md).
En los siguientes temas, puede obtener más información sobre elementos importantes a la hora de administrar clústeres que contengan instancias de bases de datos de Aurora Serverless v2.
**Topics**
+ [Configuración del rango de capacidad de Aurora Serverless v2 para un clúster](#aurora-serverless-v2-setting-acus)
+ [Comprobación del rango de capacidad para Aurora Serverless v2](#aurora-serverless-v2-checking-capacity)
+ [Adición de un lector Aurora Serverless v2](#aurora-serverless-v2-adding-reader)
+ [Conversión de un escritor o un lector aprovisionados a Aurora Serverless v2](#aurora-serverless-v2-converting-from-provisioned)
+ [Conversión de un escritor o un lector Aurora Serverless v2 a aprovisionado](#aurora-serverless-v2-converting-to-provisioned)
+ [Pausado de las instancias de base de datos de Aurora Serverless v2](#pause-when-inactive)
+ [Elegir el nivel de promoción para un lector Aurora Serverless v2](#aurora-serverless-v2-choosing-promotion-tier)
+ [Uso de TLS/SSL con Aurora Serverless v2](#aurora-serverless-v2.tls)
+ [Visualización de instancias de Aurora Serverless v2 de escritura y lectura](#aurora-serverless-v2.viewing)
+ [Registros en Aurora Serverless v2](#aurora-serverless-v2.logging)
## Configuración del rango de capacidad de Aurora Serverless v2 para un clúster
Para modificar los parámetros de configuración u otros parámetros de clústeres que contengan instancias de base de datos Aurora Serverless v2, o las propias instancias de base de datos, siga los mismos procedimientos generales que para los clústeres aprovisionados. Para obtener más información, consulte [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md).
La opción más importante exclusiva de Aurora Serverless v2 es el rango de capacidad. Después de establecer los valores mínimos y máximos de la unidad de capacidad Aurora (ACU) para un clúster Aurora, no es necesario ajustar activamente la capacidad de las instancias de base de datos Aurora Serverless v2 del clúster. Aurora lo hace por usted. Esta opción de configuración se administra en el nivel de clúster. Los mismos valores de ACU mínima y máxima se aplican a cada instancia de base de datos Aurora Serverless v2 del clúster.
Puede establecer los valores específicos siguientes:
+ **Minimum ACUs** (UCA mínimas): la instancia de base de datos Aurora Serverless v2 puede reducir la capacidad hasta este número de ACU.
+ **Maximum ACUs (UCA máximas)**: la instancia de base de datos Aurora Serverless v2 puede aumentar la capacidad hasta este número de ACU.
El rango de capacidad disponible para Aurora Serverless v2 es una función tanto de la versión del motor de base de datos como de la versión de la plataforma. Las versiones más recientes del motor de base de datos permiten una capacidad máxima de 256 ACU, una capacidad mínima de 0 ACU, o ambas. Para obtener información sobre los rangos de capacidad de las distintas versiones de motores de base de datos, consulte [Aurora Serverless v2Capacidad de](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
Para obtener información sobre la capacidad de pausa y reanudación automáticas que se habilita al establecer la capacidad mínima en 0 ACU, consulte [Escalado a cero ACU con pausa y reanudación automáticas para Aurora Serverless v2](aurora-serverless-v2-auto-pause.md).
Para obtener más información sobre cómo garantizar que los clústeres de bases de datos de Aurora Serverless v2 puedan escalar verticalmente hasta 256 ACU, consulte [Actualización del clúster de base de datos de Aurora Serverless v2 para permitir el escalado a 256 ACU](#setting-256-acus).
**nota**
Al modificar el rango de capacidad de un clúster de base de datos Aurora Serverless v2, el cambio se produce inmediatamente, independientemente de si decide aplicarlo de inmediato o durante el siguiente período de mantenimiento programado.
En Aurora Serverless v2, no puede configurar directamente la capacidad actual sin modificar el rango de capacidad, ya que la capacidad se ajusta dinámicamente en función de la carga de trabajo dentro del rango especificado. Sin embargo, puede influir en la capacidad indirectamente de las siguientes maneras:
+ **Ajuste de la capacidad mínima**: reduzca temporalmente la capacidad mínima para reducir la capacidad de referencia cuando las cargas de trabajo sean ligeras.
+ **Pausa del escalado temporalmente**: para fijar la capacidad en un valor específico, establezca la capacidad mínima y máxima en el mismo nivel.
+ **Escalado proactivo para un uso intensivo**: si prevé sobrecargar las cargas de trabajo, aumente la capacidad mínima de antemano para mantener una base de referencia más alta durante los periodos de alta actividad.
Para ver más información sobre los efectos del rango de capacidad y cómo supervisarlo y ajustarlo, consulte [Métricas importantes de Amazon CloudWatch para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring) y [Rendimiento y escalado para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md). Su objetivo es asegurarse de que la capacidad máxima del clúster sea lo suficientemente alta como para gestionar los picos de la carga de trabajo y que la mínima sea lo suficientemente baja como para minimizar los costos cuando el clúster no esté ocupado.
Supongamos que determina tras la supervisión que el rango de ACU para el clúster debe ser mayor, menor, o más o menos amplio. Puede establecer la capacidad de un clúster de Aurora en un rango específico mediante la Consola de administración de AWS, la AWS CLI o la API de Amazon RDS. Este rango de capacidad se aplica a cada instancia de base de datos Aurora Serverless v2 del clúster.
Por ejemplo, supongamos que el clúster tiene un rango de capacidad de 1 a 16 ACU y contiene dos instancias de base de datos Aurora Serverless v2. Luego el clúster en su conjunto consume entre 2 ACU (cuando está inactivo) y 32 ACU (cuando está en uso total). Si cambia el rango de capacidad de 8 a 40,5 ACU, ahora el clúster consume 16 ACU cuando está inactivo y hasta 81 ACU cuando se usan por completo.
Aurora establece automáticamente ciertos parámetros para instancias de base de datos Aurora Serverless v2 en valores que dependen del valor máximo de ACU en el rango de capacidad. Para ver la lista completa de estos parámetros, consulte [Número máximo de conexiones para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections). Para los parámetros estáticos que se basan en este tipo de cálculo, el valor se evalúa de nuevo al reiniciar la instancia de base de datos. Por lo tanto, puede actualizar el valor de dichos parámetros reiniciando la instancia de base de datos después de cambiar el rango de capacidad. Para comprobar si necesita reiniciar la instancia de base de datos para detectar estos cambios en los parámetros, consulte el atributo `ParameterApplyStatus` de la instancia de base de datos. Un valor de `pending-reboot` indica que el reinicio aplicará cambios a los valores de algunos parámetros.
### Consola
Puede establecer el rango de capacidad de un clúster que contenga bases de datos Aurora Serverless v2 mediante la Consola de administración de AWS.
Cuando utiliza la consola, establece el rango de capacidad del clúster en el momento en que agrega la primera instancia de base de datos Aurora Serverless v2 en ese clúster. Podría hacerlo al elegir la clase de instancia de base de datos **Serverless v2** (Sin servidor v2) para la instancia de base de datos de escritura al crear el clúster. O podría hacerlo al elegir la clase de instancia de base de datos **Serverless v2 (Sin servidor v2)** cuando se agrega una instancia de base de datos de escritura Aurora Serverless v2 al clúster. También podría hacerlo al convertir una instancia de base de datos aprovisionada existente en el clúster en la clase de instancia de base de datos **Serverless** (Sin servidor). Para ver las versiones completas de estos procedimientos, consulte [Creación de una instancia de base de datos de escritura de Aurora Serverless v2](aurora-serverless-v2.create.md#aurora-serverless-v2-adding-writer), [Adición de un lector Aurora Serverless v2](#aurora-serverless-v2-adding-reader) y [Conversión de un escritor o un lector aprovisionados a Aurora Serverless v2](#aurora-serverless-v2-converting-from-provisioned).
Cualquiera que sea el rango de capacidad que establezca en el nivel de clúster, este se aplicará a todas las instancias de base de datos Aurora Serverless v2 del clúster. La siguiente imagen muestra un clúster con varias instancias de base de datos de lectura Aurora Serverless v2. Cada uno tiene un rango de capacidad idéntico de 2 a 64 ACU.
![\[Clúster con varias instancias de base de datos de lectura Aurora Serverless v2\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_identical_all_instances_in_tree_view.png)
**Para modificar la capacidad de un clúster de Aurora Serverless v2**
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Databases (Bases de datos)**.
1. Elija el clúster que contiene sus instancias de base de datos Aurora Serverless v2 en la lista. El clúster debe contener ya al menos una instancia de base de datos Aurora Serverless v2. De lo contrario, Aurora no muestra la sección **Capacity range** (Rango de capacidad).
1. Para **Actions (Acciones)**, elija **Modify (Modificar)**.
1. En la sección **Capacity range** (Rango de capacidad), elija lo siguiente:
1. Introduzca un valor para **Minimum ACUs** (UCA mínimas). La consola muestra el rango de valores permitidos. Puede elegir una capacidad mínima entre 0 y 256 ACU. Puede elegir una capacidad máxima entre 1 y 256 ACU. Puede ajustar los valores de capacidad en incrementos de 0,5 ACU. El rango de capacidad disponible depende tanto de la versión del motor de base de datos como de la versión de la plataforma.
1. Introduzca un valor para **Maximum ACUs** (UCA máximas). Este valor debe ser igual o superior a **Minimum ACUs (ACU mínimas)**. La consola muestra el rango de valores permitidos. En la siguiente figura se muestra esa opción.
![\[Modificación de la capacidad del clúster de base de datos.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/sv2_capacity_settings_256_acus.png)
1. Elija **Continue (Continuar)**. Aparecerá la página **Summary of modifications (Resumen de modificaciones)**.
1. Seleccione **Apply immediately (Aplicar inmediatamente)**.
La capacidad de cambio se produce inmediatamente, independientemente de si decide aplicarlo de inmediato o durante el siguiente período de mantenimiento programado.
1. Elija **Modify clúster (Modificar clúster)** para aceptar el resumen de las modificaciones. También puede elegir **Back (Atrás)** para modificar los cambios o **Cancel (Cancelar)** para descartar los cambios.
### AWS CLI
Para configurar la capacidad de un clúster en el que se va a utilizar instancias de base de datos Aurora Serverless v2 mediante la AWS CLI, ejecute el comando [modify-db-clúster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) de la AWS CLI. Especifique la opción `--serverless-v2-scaling-configuration`. Es posible que el clúster ya contenga una o varias instancias de base de datos Aurora Serverless v2, o puede agregar las de base de datos más adelante. Las claves y los valores válidos para los campos `MinCapacity` y `MaxCapacity` incluyen los siguientes:
+ `0`, `0.5`, `1`, `1.5`, `2`, etc., en incrementos de 0,5 y hasta un máximo de 256. El valor mínimo de ACU de 0 solo está disponible para las versiones de Aurora que admiten la característica de pausa automática.
La capacidad disponible máxima depende tanto de la versión del motor de base de datos como de la versión de la plataforma.
En este ejemplo se establece el rango de ACU de un clúster de bases de datos Aurora llamado `sample-cluster` hasta un mínimo de `48.5` y un máximo de 64.
```
aws rds modify-db-cluster --db-cluster-identifier sample-cluster \
--serverless-v2-scaling-configuration MinCapacity=48.5,MaxCapacity=64
```
La capacidad de cambio se produce inmediatamente, independientemente de si decide aplicarlo de inmediato o durante el siguiente período de mantenimiento programado.
Después de hacerlo, podrá añadir las instancias de base de datos Aurora Serverless v2 al clúster, y cada nueva instancia de base de datos podrá escalarse entre 48,5 y 64 ACU. El nuevo rango de capacidad también se aplica a cualquier instancia de base de datos Aurora Serverless v2 que ya estuviera en el clúster. Las instancias de base de datos se escalan a más o menos si es necesario para situarse dentro del nuevo rango de capacidad.
Para ver más ejemplos de configuración del rango de capacidad mediante la CLI, consulte [Elegir el rango de capacidad de Aurora Serverless v2 para un clúster de Aurora](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster).
Para modificar la configuración de escalado de un clúster de bases de datos de Aurora Serverless mediante la AWS CLI, ejecute el comando [modify-db-clúster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) de la AWS CLI. Especifique la opción `--serverless-v2-scaling-configuration` para configurar la capacidad mínima y la capacidad máxima. Entre los valores de capacidad válidos se incluyen los siguientes:
+ Aurora MySQL: `0`, `0.5`, `1`, `1.5`, `2`, etc., en incrementos de 0,5 ACU hasta un máximo de `256`.
+ Aurora PostgreSQL: `0`, `0.5`, `1`, `1.5`, `2`, etc., en incrementos de 0,5 ACU hasta un máximo de `256`.
+ El valor mínimo de ACU de 0 solo está disponible para las versiones de Aurora que admiten la característica de pausa automática.
En el siguiente ejemplo se modifica la configuración de escalado de una base de datos Aurora Serverless v2 llamada `sample-instance` que forma parte de un clúster llamado `sample-cluster`.
Para Linux, macOS o Unix:
```
aws rds modify-db-cluster --db-cluster-identifier sample-cluster \
--serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64
```
Para Windows:
```
aws rds modify-db-cluster --db-cluster-identifier sample-cluster ^
--serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64
```
### API de RDS
Puede establecer la capacidad de una instancia de base de datos Aurora mediante la operación de la API [ModifyDBclúster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Especifique el parámetro `ServerlessV2ScalingConfiguration`. Las claves y los valores válidos para los campos `MinCapacity` y `MaxCapacity` incluyen los siguientes:
+ `0`, `0.5`, `1`, `1.5`, `2`, etc., en incrementos de 0,5 y hasta un máximo de 256. El valor mínimo de ACU de 0 solo está disponible para las versiones de Aurora que admiten la característica de pausa automática.
Puede modificar la configuración de escalado de un clúster que contenga instancias de base de datos Aurora Serverless v2 mediante la operación de la API [ModifyDBclúster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Especifique el parámetro `ServerlessV2ScalingConfiguration` para configurar la capacidad mínima y la capacidad máxima. Entre los valores de capacidad válidos se incluyen los siguientes:
+ Aurora MySQL: `0`, `0.5`, `1`, `1.5`, `2`, etc., en incrementos de 0,5 ACU hasta un máximo de `256`.
+ Aurora PostgreSQL: `0`, `0.5`, `1`, `1.5`, `2`, etc., en incrementos de 0,5 ACU hasta un máximo de `256`.
+ El valor mínimo de ACU de 0 solo está disponible para las versiones de Aurora que admiten la característica de pausa automática.
La capacidad disponible máxima depende tanto de la versión del motor de base de datos como de la versión de la plataforma.
La capacidad de cambio se produce inmediatamente, independientemente de si decide aplicarlo de inmediato o durante el siguiente período de mantenimiento programado.
### Actualización del clúster de base de datos de Aurora Serverless v2 para permitir el escalado a 256 ACU
En algunos casos, al intentar escalar el clúster de base de datos de Aurora Serverless v2 a capacidades superiores a 128 ACU, recibirá un mensaje de error. El mensaje de error indica las instancias que son incompatibles con el nuevo rango de escalado. Esto pone de relieve la importante relación entre el rango de capacidad, la versión del motor de base de datos y la versión de la plataforma.
La incapacidad de escalar más de 128 ACU puede suceder por una de estas dos razones:
+ Versión anterior del motor de base de datos: actualice la versión del motor de base de datos a una que admita 256 ACU. Para obtener más información, consulte [Aurora Serverless v2Capacidad de](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
+ Versión de la plataforma anterior: actualice la plataforma del clúster de base de datos de Aurora Serverless v2. Puedes hacerlo de una de las siguientes formas:
+ Detenga y reinicie el clúster de base de datos. Cuando el clúster se reinicie, estará en la última versión de la plataforma compatible, que puede ser capaz de soportar un máximo de ACU superior.
Sin embargo, detener e iniciar un clúster de base de datos conlleva cierto tiempo de inactividad, que normalmente es de unos minutos. Para obtener más información, consulte [Detención e inicio de un clúster de bases de datos de Amazon Aurora](aurora-cluster-stop-start.md).
+ Utilice una implementación azul/verde. Para obtener más información, consulte [Descripción general de las implementaciones azul/verde de Amazon Aurora](blue-green-deployments-overview.md).
1. Creación de una implementación azul/verde Para obtener más información, consulte [Creación de una implementación azul/verde en Amazon Aurora](blue-green-deployments-creating.md).
1. Confirme que puede establecer la capacidad máxima del entorno provisional (verde) en 256 ACU.
1. Cambie al entorno verde. Para obtener más información, consulte [Cambio de una implementación azul/verde en Amazon Aurora](blue-green-deployments-switching.md).
1. Elimine el clúster de base de datos original.
**nota**
Si mantiene las credenciales de la base de datos en AWS Secrets Manager, no podrá utilizar la implementación azul/verde.
La base de datos global de Aurora no admite la implementación azul/verde.
## Comprobación del rango de capacidad para Aurora Serverless v2
El procedimiento para comprobar el rango de capacidad del clúster de Aurora Serverless v2requiere que primero establezca un rango de capacidad. Si aún no lo ha hecho, siga el procedimiento en [Configuración del rango de capacidad de Aurora Serverless v2 para un clúster](#aurora-serverless-v2-setting-acus).
Cualquiera que sea el rango de capacidad que establezca en el nivel de clúster, este se aplicará a todas las instancias de base de datos Aurora Serverless v2 del clúster. La siguiente imagen muestra un clúster con varias instancias de base de datos Aurora Serverless v2. Cada uno tiene un rango de capacidad idéntico.
![\[Detalles de clúster para varias instancias de base de datos de Aurora Serverless v2.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_identical_all_instances_in_tree_view.png)
También puede ver la página de detalles de cualquier instancia de base de datos Aurora Serverless v2 en el clúster. El rango de capacidad de las instancias de base de datos aparece en la pestaña **Configuration** (Configuración).
![\[Sección de tipo de instancia, parte de la interfaz de usuario de configuración de instancias de base de datos\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_shown_for_serverless_instance.png)
También puede ver el rango de capacidad actual del clúster en la página **Modify** (Modificar) del clúster. En ese momento podrá cambiar el rango de capacidad. Para conocer todas las formas en que puede configurar o cambiar el rango de capacidad, consulte [Configuración del rango de capacidad de Aurora Serverless v2 para un clúster](#aurora-serverless-v2-setting-acus).
### Comprobación del rango de capacidad en uso de un clúster Aurora
Puede comprobar el rango de capacidad configurado para instancias de base de datos Aurora Serverless v2 en un clúster examinando el atributo `ServerlessV2ScalingConfiguration` del clúster. Los siguientes ejemplos de AWS CLI muestran un clúster con una capacidad mínima de 0,5 unidades de capacidad Aurora (ACU) y una capacidad máxima de 16 ACU.
```
$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-64-acu-cluster \
--query 'DBClusters[*].[ServerlessV2ScalingConfiguration]'
[
[
{
"MinCapacity": 0.5,
"MaxCapacity": 16.0
}
]
]
```
## Adición de un lector Aurora Serverless v2
Para agregar una instancia de base de datos Aurora Serverless v2 de lectura al clúster, siga el mismo procedimiento general que en [Adición de réplicas de Aurora a un clúster de base de datos](aurora-replicas-adding.md). Elija la clase de instancia **Serverless v2** (V2 sin servidor) para la nueva instancia de base de datos.
Si la instancia de base de datos de lectura es la primera instancia de base de datos Aurora Serverless v2 en el clúster, también se elige el rango de capacidad. Esta configuración se aplica a esta instancia de base de datos de lectura y a cualquier otra instancias de base de datos Aurora Serverless v2 que se añada al clúster. Cada instancia de base de datos Aurora Serverless v2 puede escalarse entre los valores de ACU mínima y máxima.
Si ya existe alguna otra instancia de Aurora Serverless v2 en el clúster, el cuadro de diálogo **Agregar lector** muestra el rango de capacidad actual del clúster. En ese caso, no puede cambiar la capacidad. En la siguiente imagen, se muestra el informe de la capacidad actual del clúster.
![\[Interfaz de usuario de configuración de instancias de Aurora Serverless v2.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_settable_for_add_reader_modify_instance.png)
Si ya ha añadido alguna instancia de base de datos Aurora Serverless v2 al clúster, al agregar otra instancia de base de datos Aurora Serverless v2 de lectura se muestra el rango de capacidad en uso. En la imagen siguiente se muestran los controles de solo lectura.
![\[Los ajustes de capacidad para Aurora Serverless v2 que aparecen en la interfaz de Añadir lector.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_fixed_for_add_reader_modify_instance.png)
Si desea cambiar el rango de capacidad del clúster, siga el procedimiento en [Configuración del rango de capacidad de Aurora Serverless v2 para un clúster](#aurora-serverless-v2-setting-acus).
Para los clústeres que contienen más de una instancia de base de datos de lectura, la prioridad de conmutación por error de cada instancia de base de datos de lectura Aurora Serverless v2 desempeña un papel importante en la forma en que esa instancia de base de datos escala (a más o a menos). No puede especificar la prioridad en el momento de crear el clúster. Tenga en cuenta esta propiedad cuando agregue una segunda instancia de base de datos de lectura (o más) al clúster. Para obtener más información, consulte [Elegir el nivel de promoción para un lector Aurora Serverless v2](#aurora-serverless-v2-choosing-promotion-tier).
Para saber otras formas de ver el rango de capacidad en uso de un clúster, consulte [Comprobación del rango de capacidad para Aurora Serverless v2](#aurora-serverless-v2-checking-capacity).
## Conversión de un escritor o un lector aprovisionados a Aurora Serverless v2
Puede convertir una instancia de base de datos aprovisionada para usar Aurora Serverless v2. Para ello, siga el procedimiento en [Modificación de una instancia de base de datos en un clúster de base de datos](Aurora.Modifying.md#Aurora.Modifying.Instance). El clúster debe cumplir los requisitos de [Requisitos y limitaciones para Aurora Serverless v2](aurora-serverless-v2.requirements.md). Por ejemplo, las instancias de base de datos Aurora Serverless v2 requieren que el clúster ejecute ciertas versiones mínimas del motor.
Supongamos que va a convertir un clúster aprovisionado en ejecución para aprovechar Aurora Serverless v2. En ese caso puede minimizar el tiempo de inactividad convirtiendo una instancia de base de datos a Aurora Serverless v2 como primer paso del proceso de conmutación. Para ver el procedimiento completo, consulte [Cambiar de un clúster aprovisionado a Aurora Serverless v2](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.switch-from-provisioned).
Si la instancia de base de datos que convierte es la primera instancia de base de datos Aurora Serverless v2 en el clúster, elija el rango de capacidad del clúster como parte de la operación **Modify** (Modificar). Este rango de capacidad se aplica a cada instancia de base de datos Aurora Serverless v2 que se agregue al clúster. En la imagen siguiente se ve la página donde se especifican las unidades de capacidad (ACU) mínima y máxima de Aurora.
![\[Interfaz de usuario de configuración de instancias\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_settable_for_add_reader_modify_instance.png)
Para ver más información acerca de la importancia del rango de capacidad, consulte [Aurora Serverless v2Capacidad de](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
Si el clúster ya contiene una o más instancias de base de datos Aurora Serverless v2, verá el rango de capacidad existente durante la operación **Modify** (Modificar). En la siguiente imagen se muestra un ejemplo de ese panel de información.
![\[Panel de información del rango de capacidad\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_fixed_for_add_reader_modify_instance.png)
Si desea cambiar el rango de capacidad del clúster después de agregar más instancias de base de datos Aurora Serverless v2, siga el procedimiento en [Configuración del rango de capacidad de Aurora Serverless v2 para un clúster](#aurora-serverless-v2-setting-acus).
## Conversión de un escritor o un lector Aurora Serverless v2 a aprovisionado
Puede convertir una instancia de base de datos Aurora Serverless v2 a una instancia de base de datos aprovisionada. Para ello, siga el procedimiento en [Modificación de una instancia de base de datos en un clúster de base de datos](Aurora.Modifying.md#Aurora.Modifying.Instance). Elija la clase de instancia de base de datos distinta a **Serverless (Sin servidor)**.
Podría convertir una instancia de base de datos Aurora Serverless v2 a aprovisionada si necesita una capacidad superior a la disponible con las unidades de capacidad máxima de Aurora (ACU) de una instancia de base de datos Aurora Serverless v2. Por ejemplo, las clases de instancia de base de datos db.r5 y db.r6g más grandes tienen una capacidad de memoria mayor que la que puede llegar a alcanzar una instancia de base de datos Aurora Serverless v2 al escalarse.
**sugerencia**
Algunas de las clases de instancias de base de datos anteriores, como db.r3 y db.t2, no están disponibles para las versiones de Aurora que se utilizan con Aurora Serverless v2. Para ver qué clases de instancias de base de datos puede utilizar al convertir una instancia de base de datos Aurora Serverless v2 a una aprovisionada, consulte [Motores de base de datos compatibles para clases de instancia de base de datos](Concepts.DBInstanceClass.SupportAurora.md).
Si va a convertir la instancia de base de datos de escritura del clúster desdeAurora Serverless v2 para aprovisionarla, puede seguir el procedimiento en [Cambiar de un clúster aprovisionado a Aurora Serverless v2](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.switch-from-provisioned), pero en sentido inverso. Cambie una de las instancias de base de datos de lectura del clúster de Aurora Serverless v2a aprovisionada. A continuación, realice una conmutación por error para convertir esa instancia de base de datos aprovisionada en la de escritura.
Los rangos de capacidad que haya especificado anteriormente para el clúster siguen igual, incluso si todas las instancias de base de datos Aurora Serverless v2 se eliminan del clúster. Si desea cambiar el rango de capacidad, puede modificar el clúster, tal y como se explica en [Configuración del rango de capacidad de Aurora Serverless v2 para un clúster](#aurora-serverless-v2-setting-acus).
## Pausado de las instancias de base de datos de Aurora Serverless v2
Puede configurar los clústeres de Aurora para pausar y reanudar automáticamente sus instancias de base de datos de Aurora Serverless v2. Para obtener más información, consulte [Escalado a cero ACU con pausa y reanudación automáticas para Aurora Serverless v2](aurora-serverless-v2-auto-pause.md).
## Elegir el nivel de promoción para un lector Aurora Serverless v2
Para clústeres que contienen varias instancias de base de datos Aurora Serverless v2 o una combinación de instancias de base de datos Aurora Serverless v2 y aprovisionadas, preste atención a la configuración del nivel de promoción para cada instancia de base de datos Aurora Serverless v2. Esta configuración controla más comportamiento para instancias de base de datos Aurora Serverless v2 que para instancias de base de datos aprovisionadas.
En la Consola de administración de AWS, especifique esta configuración mediante la opción **Prioridad de conmutación por error** en **Configuración adicional** para las páginas **Crear base de datos**, **Modificar instancia** y **Agregar lector**. Puede ver esta propiedad para las instancias de base de datos existentes en la columna opcional **Priority tier** (Nivel prioritario) de la página **Databases** (Bases de datos). También puede ver esta propiedad en la página de detalles de un clúster de bases de datos o en una instancia de base de datos.
Para las instancias de base de datos aprovisionadas, la elección de nivel 0 a 15 determina únicamente el orden en que Aurora elige qué instancia de base de datos de lectura debe promocionarse a de escritura durante una operación de conmutación por error. Para instancias de base de datos Aurora Serverless v2 de lectura, el número de nivel también determina si la instancia de base de datos se amplía para que coincida con la capacidad de la instancia de base de datos de escritura o se escala de manera independiente en función de su propia carga de trabajo. Las instancias de base de datos Aurora Serverless v2 de lectura en los niveles 0 o 1 se mantienen en una capacidad mínima, al menos tan alta como la instancia de base de datos de escritura. De esta forma, quedan listas para tomar el relevo de la instancia de base de datos de escritura en caso de conmutación por error. Si la instancia de base de datos de escritura es una instancia de base de datos aprovisionada, Aurora estima la capacidad equivalente de Aurora Serverless v2. Utilice esa estimación como capacidad mínima para la instancia de base de datos Aurora Serverless v2 de lectura.
Aurora Serverless v2Las instancias de base de datos de lectura de los niveles 2 a 15 no tienen la misma restricción en cuanto a capacidad mínima. Cuando están inactivas pueden escalarse hasta el valor mínimo de la unidad de capacidad (ACU) de Aurora especificado en el rango de capacidad del clúster.
El siguiente ejemplo de la AWS CLI de Linux muestra cómo examinar los niveles de promoción de todas las instancias de base de datos del clúster. El campo final incluye un valor de `True` para la instancia de base de datos de escritura y `False` para todas las instancias de base de datos de lectura.
```
$ aws rds describe-db-clusters --db-cluster-identifier promotion-tier-demo \
--query 'DBClusters[*].DBClusterMembers[*].[PromotionTier,DBInstanceIdentifier,IsClusterWriter]' \
--output text
1 instance-192 True
1 tier-01-4840 False
10 tier-10-7425 False
15 tier-15-6694 False
```
El siguiente ejemplo de la AWS CLI de Linux muestra cómo cambiar el nivel de promoción de una instancia de base de datos concreta del clúster. Los comandos modifican primero la instancia de base de datos con un nuevo nivel de promoción. A continuación, esperan a que la instancia de base de datos vuelva a estar disponible y confirman el nuevo nivel de promoción de la instancia de base de datos.
```
$ aws rds modify-db-instance --db-instance-identifier instance-192 --promotion-tier 0
$ aws rds wait db-instance-available --db-instance-identifier instance-192
$ aws rds describe-db-instances --db-instance-identifier instance-192 \
--query '*[].[PromotionTier]' --output text
0
```
Para obtener más información sobre cómo especificar niveles de promoción para diferentes casos de uso, consulte [Aurora Serverless v2Escalado en](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.scaling).
## Uso de TLS/SSL con Aurora Serverless v2
Aurora Serverless v2 utiliza el protocolo de Transport Layer Security/Secure Sockets Layer (TLS/SSL) para cifrar las comunicaciones entre los clientes y el clúster de bases de datos de Aurora Serverless v2. Admite TLS/SSL versiones 1.0, 1.1 y 1.2. Para obtener información general sobre cómo se usa de IAM con RDS y Aurora, consulte [Conexiones TLS a clústeres de base de datos de Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
Para obtener más información acerca de cómo conectarse a la base de datos de Aurora MySQL con el cliente MySQL, consulte [Conexión a una instancia de base de datos que ejecuta el motor de base de datos MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html).
Aurora Serverless v2 admite todos los modos de TLS/SSL disponibles para el cliente MySQL (`mysql`) y el cliente PostgreSQL (`psql`), incluidos los enumerados en la tabla siguiente.
| Descripción del modo TLS/SSL | mysql | psql |
| --- | --- | --- |
| Conéctese sin utilizar TLS/SSL. | DISABLED | disable |
| Intente conectarse usando TLS/SSL primero, pero vuelva a no SSL si es necesario. | PREFERRED | preferir (predeterminado) |
| Aplicar mediante TLS/SSL. | REQUIRED | require |
| Implemente TLS/SSL y verifique la entidad de certificación (CA). | VERIFY\$1CA | verify-ca |
| Aplique TLS/SSL, verifique la CA y compruebe el nombre de alojamiento de la CA. | VERIFY\$1IDENTITY | verify-full |
Aurora Serverless v2 utiliza certificados comodín. Si especifica la opción “verify CA (verificar CA)” o “verify CA and CA hostname (verificar CA y nombre de alojamiento de CA)” al utilizar TLS/SSL, descargue primero el [almacén de confianza Amazon Root CA 1](https://www.amazontrust.com/repository/AmazonRootCA1.pem) de Amazon Trust Services. Después de hacerlo, puede identificar este archivo con formato PEM en el comando del cliente. Para hacerlo utilizando el cliente PostgreSQL, haga lo que sigue.
Para Linux, macOS o Unix:
```
psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'
```
Para obtener más información acerca de cómo trabajar con la base de datos de Aurora PostgreSQL usando el cliente PostgreSQL, consulte [Conexión a una instancia de base de datos que ejecuta el motor de base de datos PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html).
Para obtener más información acerca de cómo conectarse a los clústeres de base de datos de Aurora en general, consulte [Conexión a un clúster de base de datos Amazon Aurora](Aurora.Connecting.md).
### Conjuntos de cifrado compatibles para conexiones a clústeres de base de datos de Aurora Serverless v2
Mediante el uso de conjuntos de cifrado configurables, puede tener más control sobre la seguridad de las conexiones de su base de datos. Puede especificar una lista de conjuntos de cifrado que desea permitir para proteger las conexiones TLS/SSL del cliente a su base de datos. Con conjuntos de cifrado configurables, puede controlar el cifrado de conexión que acepta el servidor de base de datos. Esto evita el uso de cifrados que no son seguros o que ya no se utilizan.
Aurora Serverless v2Los clústeres de base de datos de basados en Aurora MySQL admiten los mismos conjuntos de cifrado que los clústeres de base de datos aprovisionados de Aurora MySQL. Para obtener información sobre estos conjuntos de cifrado, consulte [Configuración de conjuntos de cifrado para conexiones a clústeres de base de datos de Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.ConfiguringCipherSuites).
Aurora Serverless v2Los clústeres de base de datos de basados en Aurora PostgreSQL admiten los mismos conjuntos de cifrado que los clústeres de base de datos aprovisionados de Aurora PostgreSQL. Para obtener información sobre estos conjuntos de cifrado, consulte [Configuración de conjuntos de cifrado para conexiones a clústeres de base de datos de Aurora PostgreSQL](AuroraPostgreSQL.Security.md#AuroraPostgreSQL.Security.SSL.ConfiguringCipherSuites).
## Visualización de instancias de Aurora Serverless v2 de escritura y lectura
Puede ver los detalles de las instancias de base de datos Aurora Serverless v2 del mismo modo que lo hace para las instancias de base de datos aprovisionadas. Para ello, siga el procedimiento general en [Visualización de un clúster de base de datos de Amazon Aurora](accessing-monitoring.md#Aurora.Viewing). Un clúster podría contener todas las instancias de base de datos Aurora Serverless v2, todas las instancias de base de datos aprovisionadas o algunas de ambas.
Después de crear una o varias instancias de base de datos Aurora Serverless v2 puede consultar cuáles de dellas son de tipo **Serverless (Sin servidor)** y cuáles son de tipo **Instance (Instancia)**. También puede ver las unidades de capacidad mínima y máxima de Aurora (ACU) que puede usar la instancia de base de datos Aurora Serverless v2. Cada ACU es una combinación de capacidad de procesamiento (CPU) y de memoria (RAM). Este rango de capacidad se aplica a cada instancia de base de datos Aurora Serverless v2 del clúster. Para que el procedimiento compruebe el rango de capacidad de un clúster o de cualquier instancia de base de datos Aurora Serverless v2 en el clúster, consulte [Comprobación del rango de capacidad para Aurora Serverless v2](#aurora-serverless-v2-checking-capacity).
En la Consola de administración de AWS, las instancias de base de datos Aurora Serverless v2 aparecen marcadas bajo la columna **Size** (Tamaño) de la página **Databases** (Bases de datos). Las instancias de base de datos aprovisionadas muestran el nombre de una clase de instancia de base de datos como r6g.xlarge. Las instancias de base de datosAurora Serverless **Serverless** (Sin servidor) para la clase de instancia de base de datos, junto con la capacidad mínima y máxima de la instancia de base de datos. Por ejemplo, podría ver **Serverless v2 (4–64 ACUs)** o **Serverless v2 (1–40 ACUs)**.
Podrá ver la misma información en la pestaña **Configuration** (Configuración) de cada instancia de base de datos Aurora Serverless v2 en la consola. Por ejemplo, es posible que vea una sección **Instance type** (Tipo de instancia) como la siguiente. Aquí, el valor **Instance type** (Tipo de instancia) es **Serverless v2** (Sin servidor v2), el valor **Minimum capacity** (Capacidad mínima) es **2 ACUs (4 GiB)** y el valor **Maximum capacity** (Capacidad máxima) es **64 ACUs (128 GiB)**.
![\[Sección de tipo de instancia, parte de la interfaz de usuario de configuración de instancias de base de datos\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_shown_for_serverless_instance.png)
Puede supervisar la capacidad de cada instancia de base de datos Aurora Serverless v2 a lo largo del tiempo. De esta forma, puede comprobar las ACU mínima, máxima y media que consume cada instancia de base de datos. También puede comprobar lo cerca que ha llegado la instancia de base de datos a su capacidad mínima o máxima. Para ver estos detalles en la Consola de administración de AWS, examine los gráficos de las métricas de Amazon CloudWatch en la pestaña **Monitoring** (Supervisión) de la instancia de base de datos. Para obtener información acerca de las métricas de supervisión y cómo interpretarlas, consulte [Métricas importantes de Amazon CloudWatch para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring).
## Registros en Aurora Serverless v2
Para activar el registro de bases de datos, especifique qué registros que se van a habilitar mediante parámetros de configuración en el grupo de parámetros personalizado.
Para Aurora MySQL, puede habilitar los siguientes registros.
| Aurora MySQL | Descripción |
| --- | --- |
| `general_log` | Crea el registro general. Se establece en 1 para activarlo. El valor predeterminado es desactivado (0). |
| `log_queries_not_using_indexes` | Registra todas las consultas en el registro de consultas lentas que no utilizan un índice. El valor predeterminado es desactivado (0). Se establece en 1 para activar este registro. |
| `long_query_time` | Evita que las consultas de ejecución rápida se registren en el registro de consultas lentas. Se puede establecer en un número flotante entre 0 y 31536000. El valor predeterminado es 0 (no activo). |
| `server_audit_events` | La lista de eventos que se deben capturar en los registros. Los valores admitidos son `CONNECT`, `QUERY`, `QUERY_DCL`, `QUERY_DDL` y `QUERY_DML` y `TABLE`. |
| `server_audit_logging` | Se establece en 1 para activar el registro de auditoría del servidor. Si activa esta opción, puede especificar los eventos de auditoría que se enviarán a CloudWatch enumerándolos en el parámetro de `server_audit_events`. |
| `slow_query_log` | Crea un registro de consulta lento. Se establece en 1 para activar el registro de consultas lentas. El valor predeterminado es desactivado (0). |
Para obtener más información, consulte [Uso de auditorías avanzadas con un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
Para Aurora PostgreSQL, puede habilitar los siguientes registros en sus instancias de base de datos Aurora Serverless v2.
| Aurora PostgreSQL | Descripción |
| --- | --- |
| `log_connections` | Registra cada conexión realizada correctamente. |
| `log_disconnections` | Registra el final de una sesión, incluida su duración. |
| `log_lock_waits` | El valor predeterminado es 0 (desactivado). Se establece en 1 para registrar las esperas de bloqueo. |
| `log_min_duration_statement` | La duración mínima (en milisegundos) para que una instrucción se ejecute antes de que se registre. |
| `log_min_messages` | Define los niveles de los mensajes que se registran. Los valores admitidos son debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. Para registrar los datos de rendimiento en el registro de postgres, establezca el valor en debug1. |
| `log_temp_files` | Registra el uso de archivos temporales que superan los kilobytes especificados (kB). |
| `log_statement` | Controla las instrucciones SQL específicas que se registran. Los valores admitidos son `none`, `ddl`, `mod` y `all`. El valor predeterminado es `none`. |
**Topics**
+ [Registro con Amazon CloudWatch](#aurora-serverless-v2.how-it-works.logging)
+ [Visualización registros de Aurora Serverless v2 en Amazon CloudWatch](#aurora-serverless-v2.logging.monitoring)
+ [Capacidad de monitoreo con Amazon CloudWatch](#aurora-serverless-v2.how-it-works.logging.monitoring)
+ [Supervisión de la actividad de pausa y reanudación de Aurora Serverless v2](#autopause-logging-instance-log)
### Registro con Amazon CloudWatch
Después de usar el procedimiento en [Registros en Aurora Serverless v2](#aurora-serverless-v2.logging) para elegir qué registros de bases de datos activar, puede elegir qué registros cargar (“publicar”) en Amazon CloudWatch.
Amazon CloudWatch le permite analizar los datos de registro, crear alarmas y ver métricas. De forma predeterminada, los registros de errores para Aurora Serverless v2 están habilitados y se cargan automáticamente en CloudWatch. También puede cargar otros registros desde instancias de base de datos Aurora Serverless v2 a CloudWatch.
A continuación se elige cuál de esos registros desea cargar en CloudWatch con las opciones de **Log exports** (Exportaciones de registros) en la Consola de administración de AWS o en la opción `--enable-cloudwatch-logs-exports` de la AWS CLI.
Puede elegir cuál de sus registros de Aurora Serverless v2 cargar en CloudWatch. Para obtener más información, consulte [Uso de auditorías avanzadas con un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
Igual que con cualquier tipo de clúster de base de datos de Aurora, no se puede modificar el grupo de parámetros de clúster de base de datos predeterminado. En su lugar, puede crear su propio grupo de parámetros de clúster de base de datos basado en un parámetro predeterminado para su clúster de base de datos y tipo de motor. Le recomendamos que cree su grupo de parámetros de clúster de base de datos personalizado antes de crear el clúster de base de datos de Aurora Serverless v2, de modo que esté disponible para elegirlo cuando cree una base de datos en la consola.
**nota**
Para Aurora Serverless v2, puede crear clústeres de base de datos y grupos de parámetros de base de datos. Esto contrasta con Aurora Serverless v1, donde solo puede crear grupos de parámetros de clústeres de bases de datos.
### Visualización registros de Aurora Serverless v2 en Amazon CloudWatch
Tras utilizar el procedimiento en [Registro con Amazon CloudWatch](#aurora-serverless-v2.how-it-works.logging) para elegir qué registros de bases de datos activar, podrá ver el contenido de los registros.
Para obtener más información acerca de cómo usar CloudWatch con registros de Aurora MySQL y Aurora PostgreSQL, consulte [Monitoreo de eventos de registro en Amazon CloudWatch](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor) y [Publicación de registros de Aurora PostgreSQL en Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md).
**Para ver los registros del clúster de bases de datos de Aurora Serverless v2**
1. Abra la consola de CloudWatch en [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Elija su Región de AWS.
1. Elija **Log groups (Grupos de registros)**.
1. Seleccione el registro del clúster de bases de datos de Aurora Serverless v2 de la lista. El patrón de nomenclatura de los registros es el siguiente.
```
/aws/rds/cluster/cluster-name/log_type
```
**nota**
Para los clústeres de bases de datos Aurora Serverless v2 compatibles con Aurora MySQL, el registro de errores incluye los eventos de escalado de grupos de búferes incluso cuando no hay errores.
### Capacidad de monitoreo con Amazon CloudWatch
Aurora Serverless v2 le permite utilizar CloudWatch para supervisar la capacidad y el uso de todos las instancias de base de datos Aurora Serverless v2 del clúster. Puede ver las métricas en el nivel de instancia para comprobar la capacidad de cada instancia de base de datos Aurora Serverless v2 a medida que se amplía o reduce. También puede comparar las métricas relacionadas con la capacidad con otras métricas para ver cómo los cambios en las cargas de trabajo afectan el consumo de recursos. Por ejemplo, puede comparar `ServerlessDatabaseCapacity` con `DatabaseUsedMemory`, `DatabaseConnections` y `DMLThroughput` para evaluar cómo responde su clúster de bases de datos durante las operaciones. Para obtener más información sobre las métricas relacionadas con la capacidad que se aplican a Aurora Serverless v2, consulte [Métricas importantes de Amazon CloudWatch para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring).
**Para monitorear la capacidad del clúster de base de datos de Aurora Serverless v2**
1. Abra la consola de CloudWatch en [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Elija **Metrics (Métricas)**. Todas las métricas disponibles aparecen como tarjetas en la consola, agrupadas por nombre de servicio.
1. Elija **RDS**.
1. (Opcional) Utilice el cuadro de **búsqueda** encontrar las métricas que son especialmente importantes para:Aurora Serverless v2 `ServerlessDatabaseCapacity`, `ACUUtilization`, `CPUUtilization` y `FreeableMemory`.
Se recomienda configurar un panel de CloudWatch para supervisar la capacidad del clúster de bases de datos de Aurora Serverless v2 con métricas relacionadas con la capacidad. Para obtener información acerca de cómo hacerlo, consulte [Creación de paneles con CloudWatch](https://docs.aws.amazon.com/autoscaling/application/userguide/monitoring-cloudwatch.html).
Para obtener más información acerca del uso de Amazon CloudWatch con Amazon Aurora, consulte [Publicación de registros de Amazon Aurora MySQL en Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md).
### Supervisión de la actividad de pausa y reanudación de Aurora Serverless v2
Aurora escribe un archivo de registro independiente para las instancias de base de datos de Aurora Serverless v2 con la pausa automática habilitada. Aurora escribe en el registro por cada intervalo de 10 minutos en el que la instancia no esté pausada. Aurora retiene hasta siete de estos registros, que se rotan a diario. El archivo de registro actual se denomina `instance.log` y los registros más antiguos se designan siguiendo el patrón `instance.YYYY-MM-DD.N.log`.
Este registro está habilitado de forma predeterminada para las instancias de base de datos de Aurora Serverless v2 con la pausa automática habilitada. Puede ver el contenido de este registro en la Consola de administración de AWS o mediante la AWS CLI o la API de RDSP. En la actualidad, no puede cargar este registro en CloudWatch.
Los eventos que se enumeran en [Eventos de instancia de base de datos](USER_Events.Messages.md#USER_Events.Messages.instance) proporcionan una descripción general de alto nivel de la actividad de pausa y reanudación, como la siguiente:
+ Cuándo empieza a pausarse la instancia y cuándo termina de pausarse.
+ Cuándo comienza a reanudarse la instancia y cuándo termina de reanudarse.
+ Casos en los que la instancia ha intentado hacer una pausa, pero alguna condición ha impedido que se detuviera.
`instance.log` proporciona información más detallada sobre los motivos por los que una instancia de Aurora Serverless v2 podría o no pausarse.
El registro puede indicar que una instancia se ha reanudado por diferentes motivos:
+ **actividad del usuario**: solicitud de conexión a una base de datos. Puede provenir de una sesión de cliente interactiva, una llamada a la API de datos de RDS o una solicitud para descargar los registros de la instancia.
+ **actividad en segundo plano**: categoría amplia que incluye todos los motivos por los que Aurora reanuda una instancia. Por ejemplo, cuando una solicitud de conexión a una instancia de lector provoca que la instancia de escritor se reanude, el registro del lector indica la actividad del usuario, mientras que el registro del escritor clasifica la solicitud de reanudación como actividad en segundo plano. Para conocer los motivos por los que Aurora podría reanudar una instancia que no sea una solicitud de conexión de usuario, consulte [Reanudación de una instancia de Aurora Serverless v2 pausada automáticamente](aurora-serverless-v2-auto-pause.md#auto-pause-waking).
Cuando Aurora no conoce ninguna condición que impida que la instancia se pause al expirar el intervalo de pausa automática, escribe periódicamente un mensaje informativo en el registro. En el caso de los clústeres con una sola instancia de base de datos, el registro contiene este mensaje:
```
[INFO] No auto-pause blockers registered since time
```
En el caso de los clústeres con varias instancias de base de datos, el mensaje es ligeramente diferente. Esto se debe a que es posible que un escritor no pueda pausar debido a la actividad de alguna de las instancias de lector. Si la actividad del lector finaliza antes de que finalice el intervalo de pausa automática en el escritor, el escritor podrá pausar a la hora prevista.
```
[INFO] No auto-pause blockers registered since time.
Database might be required to maintain compute capacity for high availability.
```
Si se inicia una operación de pausa, pero llega una nueva solicitud de conexión a la base de datos antes de que la instancia termine de pausarse, el registro tendrá este mensaje:
```
[INFO] Unable to pause database due to a new database activity
```
Si Aurora detecta alguna condición que impida definitivamente que la instancia se pause, el registro tendrá este mensaje en el que se enumeran todas estas condiciones:
```
[INFO] Auto-pause blockers registered since time: list_of_conditions
```
De esta forma, Aurora no le impide activar la replicación, la integración sin ETL, la base de datos global de Aurora, etc., en combinación con la característica de pausa automática. El registro le informa si el uso de estas características podría impedir que la pausa automática surta efecto.
Las siguientes son los motivos por los que una instancia de Aurora Serverless v2 puede superar el intervalo de tiempo de espera de la pausa automática, pero no se puede pausar:
+ **actividad de la base de datos antes del tiempo de espera de la pausa automática**: la instancia de base de datos ha recibido una solicitud de conexión antes de que expirara el tiempo de espera.
+ **miembro de la base de datos global**: si el clúster de base de datos forma parte de una base de datos global de Aurora, las instancias de Aurora Serverless v2 del clúster no se pausan. Un clúster puede cambiar de un clúster independiente a un clúster de base de datos global. Por lo tanto, las instancias que antes se pausaban automáticamente podrían dejar de pausarse e informar de este motivo en el registro. Una vez que un clúster pasa a ser miembro de una base de datos global, no vuelve a ser un clúster independiente hasta que se desasocia de forma explícita. El clúster principal sigue considerándose parte de la base de datos global aunque se desasocien todos los clústeres secundarios.
+ **capacidad de replicación configurada**: la instancia de base de datos de escritor tiene habilitada la replicación específica del motor, ya sea la replicación binlog para MySQL o la replicación lógica para PostgreSQL. Esta condición también podría deberse al uso de otra característica de Aurora que requiera activar la replicación, como las integraciones sin ETL o los flujos de actividad de bases de datos (DAS).
+ **retraso continuo de la copia de seguridad**: si el sistema de almacenamiento de Aurora no ha terminado de aplicar los cambios de almacenamiento hasta el momento actual, la instancia de escritor no se pausa hasta que se actualice. Esta condición solo afecta a la instancia de escritor y se espera que sea relativamente breve.
+ **acción de mantenimiento del servicio o del cliente**: si se inicia una operación de mantenimiento, la instancia de base de datos no volverá a pausarse hasta que finalice la operación. Esta condición incluye una amplia variedad de operaciones que puede iniciar usted o Aurora, como las actualizaciones, la clonación, el cambio de los ajustes de configuración, la descarga de archivos de registro, etc. Este evento también ocurre cuando solicita eliminar una instancia y Aurora reanuda brevemente la instancia como parte del mecanismo de eliminación.
+ **problema de comunicación transitoria**: si Aurora no puede determinar si la configuración de escalado tiene actualmente una configuración de capacidad mínima de cero ACU, no pausa la instancia. Se espera que esto ocurra de forma puntual.
# Rendimiento y escalado para Aurora Serverless v2
Los siguientes procedimientos y ejemplos muestran cómo se puede establecer el rango de capacidad para clústeres de Aurora Serverless v2 y sus instancias de base de datos asociadas. También puede utilizar los siguientes procedimientos para supervisar la ocupación de las instancias de base de datos. A continuación, puede utilizar lo averiguado para determinar si necesita ajustar el rango de capacidad a más o a menos.
Antes de utilizar estos procedimientos, asegúrese de estar familiarizado con cómo funciona el escalado en Aurora Serverless v2. El mecanismo de escalado es diferente al de Aurora Serverless v1. Para obtener más información, consulte [Aurora Serverless v2Escalado en](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.scaling).
**Contents**
+ [Elegir el rango de capacidad de Aurora Serverless v2 para un clúster de Aurora](#aurora-serverless-v2-examples-setting-capacity-range-for-cluster)
+ [Elegir la configuración de capacidad de Aurora Serverless v2 mínima para un clúster](#aurora-serverless-v2.min_capacity_considerations)
+ [Elegir la configuración de capacidad de Aurora Serverless v2 máxima para un clúster](#aurora-serverless-v2.max_capacity_considerations)
+ [Ejemplo: Cambiar el rango de capacidad de Aurora Serverless v2 de un clúster de Aurora MySQL](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-ams)
+ [Ejemplo: Cambiar el rango de capacidad Aurora Serverless v2 de un clúster de Aurora PostgreSQL](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-apg)
+ [Trabajo con los grupos de parámetros para Aurora Serverless v2](#aurora-serverless-v2.parameter-groups)
+ [Valores de parámetros predeterminados](#aurora-serverless-v2.parameter-groups-defaults)
+ [Número máximo de conexiones para Aurora Serverless v2](#aurora-serverless-v2.max-connections)
+ [Parámetros que Aurora ajusta cuando se escala Aurora Serverless v2 a más o a menos](#aurora-serverless-v2.parameters-based-on-scaling)
+ [Parámetros en los que Aurora hace sus cómputos basándose en la capacidad máxima de Aurora Serverless v2](#aurora-serverless-v2.parameters-based-on-max-capacity)
+ [Evitar errores de memoria insuficiente](#aurora-serverless-v2.setting-capacity.incompatible_parameters)
+ [Métricas importantes de Amazon CloudWatch para Aurora Serverless v2](#aurora-serverless-v2.viewing.monitoring)
+ [Cómo se aplican las métricas de Aurora Serverless v2 en la factura de AWS](#aurora-serverless-v2-billing)
+ [Ejemplos de comandos de CloudWatch para métricas de Aurora Serverless v2](#aurora-serverless-v2-cw-examples)
+ [Supervisión del rendimiento de Aurora Serverless v2 con la información de rendimiento](#aurora-serverless-v2.viewing.performance-insights)
+ [Solución de problemas de capacidad de Aurora Serverless v2](#aurora-serverless-v2.troubleshooting)
## Elegir el rango de capacidad de Aurora Serverless v2 para un clúster de Aurora
Con las instancias de base de datos Aurora Serverless v2, usted establece el rango de capacidad que se aplica a todas las instancias de base de datos del clúster de bases de datos al mismo tiempo que agrega la primera instancia de base de datos Aurora Serverless v2 en el clúster de bases de datos. Para ver el procedimiento para hacerlo, consulte [Configuración del rango de capacidad de Aurora Serverless v2 para un clúster](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus).
También puede cambiar el rango de capacidad de un clúster existente. En las siguientes secciones se explica con más detalle cómo elegir los valores mínimos y máximos adecuados y qué ocurre cuando se realiza un cambio en el rango de capacidad. Por ejemplo, cambiar el rango de capacidad puede modificar los valores predeterminados de algunos parámetros de configuración. Aplicar todos los cambios de parámetros puede requerir reiniciar cada instancia de base de datos Aurora Serverless v2.
**Topics**
+ [Elegir la configuración de capacidad de Aurora Serverless v2 mínima para un clúster](#aurora-serverless-v2.min_capacity_considerations)
+ [Elegir la configuración de capacidad de Aurora Serverless v2 máxima para un clúster](#aurora-serverless-v2.max_capacity_considerations)
+ [Ejemplo: Cambiar el rango de capacidad de Aurora Serverless v2 de un clúster de Aurora MySQL](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-ams)
+ [Ejemplo: Cambiar el rango de capacidad Aurora Serverless v2 de un clúster de Aurora PostgreSQL](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-apg)
### Elegir la configuración de capacidad de Aurora Serverless v2 mínima para un clúster
Es tentador elegir siempre 0,5 para la configuración de capacidad mínima de Aurora Serverless v2. Este valor permite que la instancia de base de datos reduzca verticalmente al mínimo la capacidad cuando esté completamente inactiva y, al mismo tiempo, permanezca activa. También puede activar el comportamiento de pausa automática especificando una capacidad mínima de 0 ACU, como se explica en [Escalado a cero ACU con pausa y reanudación automáticas para Aurora Serverless v2](aurora-serverless-v2-auto-pause.md). No obstante, en función de cómo se utilice ese clúster y de los demás ajustes que se configuren, un capacidad mínima diferente podría ser lo más efectivo. Debe tener en cuenta los factores siguientes al elegir la configuración de capacidad mínima:
+ La tasa de escalado de una instancia de base de datos Aurora Serverless v2 depende de su capacidad actual. Cuanto mayor sea la capacidad actual, más rápido podrá ampliarse. Si necesita que la instancia de base de datos se amplíe rápidamente a una capacidad muy alta, piense en establecer la capacidad mínima en un valor en el que la tasa de escalado cumpla con sus requisitos.
+ Si normalmente modifica la clase de instancia de base de datos de sus instancias de base de datos en previsión de una carga de trabajo especialmente alta o baja, puede aprovechar esa experiencia para hacer una estimación aproximada del rango de capacidad de Aurora Serverless v2 equivalente. Para determinar el tamaño de la memoria que se utilizará en momentos de poco tráfico, consulte [Especificaciones de hardware para clases de instancia de base de datos para Aurora](Concepts.DBInstanceClass.Summary.md).
Por ejemplo, supongamos que utiliza la clase de instancia de base de datos db.r6g.xlarge cuando el clúster tiene una carga de trabajo baja. Esta clase de instancia de base de datos tiene 32 GiB de memoria. Por lo tanto, puede especificar una configuración mínima de unidad de capacidad Aurora (ACU) de 16 para configurar una instancia de base de datos Aurora Serverless v2 que puede escalarse hacia menos a aproximadamente a la misma capacidad. Esto se debe a que cada ACU corresponde a aproximadamente 2 GiB de memoria. Puede especificar un valor algo inferior para permitir que la instancia de base de datos se amplíe aún más en caso de que la instancia de base de datos db.r6g.xlarge se haya infrautilizado a veces.
+ Si la aplicación funciona de la manera más eficiente cuando las instancias de base de datos tienen cierta cantidad de datos en la memoria caché del búfer, piense en especificar una configuración mínima de ACU en la que la memoria sea lo suficientemente grande como para contener los datos a los que se accede con frecuencia. De lo contrario, algunos datos se sacan de la memoria caché del búfer cuando las instancias de base de datos Aurora Serverless v2 se escalan a un tamaño de memoria inferior. Luego, cuando las instancias de base de datos se escalan a más, la información se vuelve a leer en la caché del búfer a lo largo del tiempo. Si la cantidad de E/S para devolver los datos a la caché del búfer es importante, podría resultar más eficaz elegir un valor de ACU mínimo más alto.
+ Si las instancias de base de datos Aurora Serverless v2 se ejecutan la mayor parte del tiempo en una capacidad determinada, piense en especificar una configuración de capacidad mínima inferior a esa línea de base, pero no muy inferior. Aurora Serverless v2 Las instancias de base de datos pueden estimar de la manera más eficaz cuánto y con qué rapidez deben ampliarse cuando la capacidad actual no es drásticamente inferior a la capacidad requerida.
+ Si la carga de trabajo aprovisionada tiene requisitos de memoria demasiado altos para clases de instancias de base de datos pequeñas como T3 o T4g, elija una configuración de ACU mínima que proporcione memoria comparable a una instancia de base de datos R5 o R6g.
En particular, recomendamos la siguiente capacidad mínima de uso con las funciones especificadas (estas recomendaciones están sujetas a cambios):
+ Performance Insights (Información sobre rendimiento): 2 ACU
+ Bases de datos globales de Aurora: 8 ACU (se aplica solo a la Región de AWS principal)
+ En Aurora, la replicación se produce en la capa de almacenamiento, por lo que la capacidad del lector no afecta directamente a la replicación. Sin embargo, en el caso de las instancias de bases de datos de lector de Aurora Serverless v2 que se escalan de forma independiente, asegúrese de que la capacidad mínima sea suficiente para gestionar las cargas de trabajo durante los periodos de escritura intensiva a fin de evitar la latencia de las consultas. Si las instancias de base de datos de lector en los niveles de promoción 2 a 15 experimentan problemas de rendimiento, considere aumentar la capacidad mínima del clúster. Para obtener más información sobre cómo elegir si las instancias de base de datos de lectura se escalan junto con el escritor o de manera independiente, consulte [Elegir el nivel de promoción para un lector Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier).
+ Si tiene un clúster de base de datos con instancias de base de datos lectoras de Aurora Serverless v2, los lectores no se escalan junto con la instancia de base de datos escritora cuando el nivel de promoción de los lectores no es 0 o 1. En ese caso, establecer una capacidad mínima baja puede provocar un retraso excesivo de la replicación. Esto se debe a que es posible que los lectores no tengan la capacidad suficiente para aplicar cambios de escritura cuando la base de datos esté ocupada. Se recomienda establecer la capacidad mínima en un valor que represente una cantidad de memoria y CPU comparables con la de la instancia de base de datos escritora.
+ El valor del parámetro `max_connections` para las instancias de base de datos de Aurora Serverless v2 se basa en el tamaño de memoria obtenido del número máximo de ACU. Sin embargo, cuando especifique una capacidad mínima de 0 o 0,5 ACU en instancias de base de datos compatibles con PostgreSQL, el valor máximo de `max_connections` está limitado a 2000.
Si desea utilizar el clúster de Aurora PostgreSQL para una carga de trabajo de alta conexión, piense en utilizar una configuración de ACU mínima de 1 o más. Para obtener más información acerca de cómo Aurora Serverless v2 maneja el parámetro de configuración `max_connections`, consulte [Número máximo de conexiones para Aurora Serverless v2](#aurora-serverless-v2.max-connections).
+ El tiempo que se tarda en una instancia de base de datos Aurora Serverless v2 en escalar desde su capacidad mínima hasta su capacidad máxima depende de la diferencia entre sus valores de ACU mínima y máxima. Cuando la capacidad actual de la instancia de base de datos es grande, Aurora Serverless v2 se amplía en incrementos mayores que cuando la instancia de base de datos comienza desde una pequeña capacidad. Por lo tanto, si especifica una capacidad máxima relativamente grande y la instancia de base de datos está la mayor parte del tiempo cerca de esa capacidad, considere aumentar la configuración mínima de ACU. De esta forma, una instancia de base de datos inactiva podrá escalar de nuevo hasta la máxima capacidad más rápidamente.
### Elegir la configuración de capacidad de Aurora Serverless v2 máxima para un clúster
Es tentador elegir siempre un valor alto para la configuración de capacidad de Aurora Serverless v2 máxima. Una alta capacidad máxima permite que la instancia de base de datos se amplíe al máximo cuando ejecuta una carga de trabajo intensiva. Un valor bajo evita la posibilidad de cobros inesperados. Según cómo utilice ese clúster y los demás ajustes que configure, el valor más efectivo podría ser mayor o menor de lo que pensaba originalmente. Tenga en cuenta los factores siguientes al elegir la configuración de capacidad máxima:
+ La capacidad máxima debe ser al menos tan alta como la capacidad mínima. Usted puede definir la capacidad mínima y máxima para que sean idénticas. Sin embargo, en ese caso, la capacidad nunca aumenta ni baja. Por lo tanto, utilizar valores idénticos para la capacidad mínima y máxima no es apropiado fuera de situaciones de prueba.
+ La capacidad máxima debe ser superior a 0,5 ACU. Puede establecer la capacidad mínima y máxima para que sean iguales en la mayoría de los casos. No obstante, no puede especificar 0,5 tanto para el mínimo como para el máximo. Utilice un valor de 1 o superior para obtener la capacidad máxima.
+ Si normalmente modifica la clase de instancia de base de datos de sus instancias de base de datos en previsión de una carga de trabajo especialmente alta o baja, puede aprovechar esa experiencia para hacer una estimación del rango de capacidad de Aurora Serverless v2 equivalente. Para determinar el tamaño de la memoria que se utilizará en momentos de mucho tráfico, consulte [Especificaciones de hardware para clases de instancia de base de datos para Aurora](Concepts.DBInstanceClass.Summary.md).
Por ejemplo, supongamos que utiliza la clase de instancia de base de datos db.r6g.4xlarge cuando el clúster tiene una carga de trabajo elevada. Esta clase de instancia de base de datos tiene 128 GiB de memoria. Por lo tanto, puede especificar una configuración de ACU máxima de 64 para configurar una instancia de base de datos Aurora Serverless v2 que pueda escalar hasta aproximadamente la misma capacidad. Esto se debe a que cada ACU corresponde a aproximadamente 2 GiB de memoria. Puede especificar un valor algo mayor para permitir que la instancia de base de datos se amplíe más en caso de que la instancia de base de datos db.r6g.4xlarge a veces no tenga la capacidad suficiente para gestionar la carga de trabajo de forma eficaz.
+ Si tiene un límite presupuestario para usar su base de datos, elija un valor que se mantenga dentro de ese límite, incluso si todas las instancias de base de datos de Aurora Serverless v2 se ejecutan a máxima capacidad todo el tiempo. Recuerde eso cuando tenga *n* Aurora Serverless v2instancias de base de datos en el clúster, la máxima capacidad de Aurora Serverless v2 teórica que el clúster puede consumir en cualquier momento es *n* veces la configuración máxima de ACU para el clúster. (La cantidad real consumida podría ser menor, por ejemplo, si algunos lectores escalan independientemente del escritor).
+ Si hace uso de instancias de base de datos Aurora Serverless v2 de lector para descargar parte de la carga de trabajo de solo lectura de la instancia de base de datos de escritor, es posible que pueda elegir una configuración de capacidad máxima inferior. Esto se hace para reflejar que cada instancia de base de datos de lector no necesita escalar tan alto como si el clúster contuviera solo una instancia de base de datos.
+ Supongamos que desea protegerse contra el uso excesivo por parámetros de base de datos mal configurados o consultas ineficientes en la aplicación. En ese caso, puede evitar un uso excesivo por error eligiendo un ajuste de capacidad máxima inferior al más alto absoluto que podría establecer.
+ Si los picos por actividad real del usuario son poco frecuentes, pero sí ocurren, puede tener en cuenta esas ocasiones al elegir la configuración de capacidad máxima. Si la prioridad es que la aplicación siga funcionando con un rendimiento y escalabilidad completos, puede especificar una configuración de capacidad máxima superior a la observada en el uso normal. Si está bien que la aplicación se ejecute con un rendimiento reducido durante picos de actividad muy extremos, puede elegir una configuración de capacidad máxima ligeramente inferior. Asegúrese de elegir una configuración que aún tenga suficiente memoria y recursos de CPU para mantener la aplicación en ejecución.
+ Si habilita opciones de configuración en el clúster que aumenten el uso de memoria para cada instancia de base de datos, tenga en cuenta esa memoria al decidir el valor máximo de ACU. Estas opciones incluyen las de información del rendimiento, consultas paralelas de Aurora MySQL, esquema de rendimiento de Aurora MySQL y replicación de registros binarios de Aurora MySQL. Asegúrese de que el valor máximo de la ACU permite que las instancias de base de datos Aurora Serverless v2 se escalen lo suficiente como para gestionar la carga de trabajo cuando se usen esas funciones. Para obtener información sobre cómo solucionar problemas causados por la combinación de una configuración de ACU máxima baja y características de Aurora que impongan sobrecarga de memoria, consulte [Evitar errores de memoria insuficiente](#aurora-serverless-v2.setting-capacity.incompatible_parameters).
### Ejemplo: Cambiar el rango de capacidad de Aurora Serverless v2 de un clúster de Aurora MySQL
El siguiente ejemplo de AWS CLI muestra cómo actualizar el rango de ACU para instancias de base de datos Aurora Serverless v2 en un clúster de Aurora MySQL existente. En un principio, el rango de capacidad para el clúster es 8-32 ACU.
```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
--query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
"MinCapacity": 8.0,
"MaxCapacity": 32.0
}
```
La instancia de base de datos está inactiva y se escala a 8 ACU. La siguiente es la configuración relacionada con la capacidad en la instancia de base de datos en este momento. Para representar el tamaño del grupo de búferes en unidades fácilmente legibles, lo dividimos por 2 a la potencia de 30, lo que da lugar a una medición en gibibytes (GiB). Esto es así porque las mediciones relacionadas con la memoria de Aurora utilizan unidades basadas en potencias de 2, no de 10.
```
mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
| 3000 |
+-------------------+
1 row in set (0.00 sec)
mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
| 9294577664 |
+---------------------------+
1 row in set (0.00 sec)
mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
| 8.65625 |
+-----------+
1 row in set (0.00 sec)
```
A continuación, cambiamos el rango de capacidad del clúster. Una vez que finalice el comando `modify-db-cluster`, el rango de ACU para el clúster pasa de 12,5 a 80.
```
aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
--serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
--query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
"MinCapacity": 12.5,
"MaxCapacity": 80.0
}
```
El cambio del rango de capacidad provocó cambios en los valores predeterminados de algunos parámetros de configuración. Aurora puede aplicar algunos de esos nuevos valores predeterminados de manera inmediata. No obstante, algunos de los cambios en los parámetros surten efecto solo después de un reinicio. El estado `pending-reboot` indica que es necesario reiniciar para aplicar algunos cambios en los parámetros.
```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
--query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
"DBClusterMembers": [
{
"DBInstanceIdentifier": "serverless-v2-instance-1",
"DBClusterParameterGroupStatus": "pending-reboot"
}
]
}
```
En este punto, el clúster está inactivo y la instancia de base de datos `serverless-v2-instance-1`consume 12,5 ACU. El siguiente ejemplo muestra cómo el parámetro `innodb_buffer_pool_size` ya se ha ajustado en función de la capacidad actual de la instancia de base de datos. El parámetro `max_connections` sigue reflejando el valor del rango de capacidad máxima anterior. Para restablecer ese valor es necesario reiniciar la instancia de base de datos.
**nota**
Si establece el parámetro `max_connections` directamente en un grupo de parámetros de base de datos personalizado, no será necesario reiniciar.
```
mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
| 3000 |
+-------------------+
1 row in set (0.00 sec)
mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
| 15572402176 |
+---------------------------+
1 row in set (0.00 sec)
mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+---------------+
| gibibytes |
+---------------+
| 14.5029296875 |
+---------------+
1 row in set (0.00 sec)
```
Ahora reiniciamos la instancia de base de datos y esperamos a que vuelva a estar disponible.
```
aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
"DBInstanceIdentifier": "serverless-v2-instance-1",
"DBInstanceStatus": "rebooting"
}
aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1
```
El estado `pending-reboot` se borra. El valor `in-sync` confirma que Aurora ha aplicado todos los cambios de parámetros pendientes.
```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
--query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
"DBClusterMembers": [
{
"DBInstanceIdentifier": "serverless-v2-instance-1",
"DBClusterParameterGroupStatus": "in-sync"
}
]
}
```
El parámetro `innodb_buffer_pool_size` ha aumentado a su tamaño final para una instancia de base de datos inactiva. El parámetro `max_connections` ha aumentado para reflejar un valor derivado del valor de ACU máximo. La fórmula que utiliza Aurora para `max_connections` provoca un aumento de 1000 cuando el tamaño de la memoria se duplica.
```
mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
| 16139681792 |
+---------------------------+
1 row in set (0.00 sec)
mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
| 15.03125 |
+-----------+
1 row in set (0.00 sec)
mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
| 4000 |
+-------------------+
1 row in set (0.00 sec)
```
Establecemos el rango de capacidad entre 0,5 y 128 ACU y reiniciamos la instancia de base de datos. Ahora la instancia de base de datos inactiva tiene un tamaño de caché de búfer inferior a 1 GiB, por lo que la medimos en mebibytes (MiB). El valor `max_connections` de 5000 se deriva del tamaño de memoria de la configuración de capacidad máxima.
```
mysql> select @@innodb_buffer_pool_size / pow(2,20) as mebibytes, @@max_connections;
+-----------+-------------------+
| mebibytes | @@max_connections |
+-----------+-------------------+
| 672 | 5000 |
+-----------+-------------------+
1 row in set (0.00 sec)
```
### Ejemplo: Cambiar el rango de capacidad Aurora Serverless v2 de un clúster de Aurora PostgreSQL
Los siguientes ejemplos de la CLI muestran cómo actualizar el rango de ACU para instancias de base de datos de Aurora Serverless v2 en un clúster de Aurora PostgreSQL existente.
1. El rango de capacidad del clúster comienza en 0,5 a 1 ACU.
1. Cambie el rango de capacidad a 8-32 ACU.
1. Cambie el rango de capacidad a 12,5–80 ACU.
1. Cambie el rango de capacidad a 0,5–128 ACU.
1. Devuelva la capacidad a su rango inicial de 0,5-1 ACU.
En el siguiente gráfico, se muestran los cambios de capacidad en Amazon CloudWatch.
![\[Gráfico de CloudWatch de cambios de capacidad de Aurora Serverless v2\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/sv2-apg-scaling-example.png)
La instancia de base de datos está inactiva y se escala a 0,5 ACU. La siguiente es la configuración relacionada con la capacidad en la instancia de base de datos en este momento.
```
postgres=> show max_connections;
max_connections
-----------------
189
(1 row)
postgres=> show shared_buffers;
shared_buffers
----------------
16384
(1 row)
```
A continuación, cambiamos el rango de capacidad del clúster. Una vez que finalice el comando `modify-db-cluster`, el rango de ACU para el clúster es 8,0–32.
```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
--query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
"MinCapacity": 8.0,
"MaxCapacity": 32.0
}
```
El cambio del rango de capacidad provoca cambios en los valores predeterminados de algunos parámetros de configuración. Aurora puede aplicar algunos de esos nuevos valores predeterminados de manera inmediata. No obstante, algunos de los cambios en los parámetros surten efecto solo después de un reinicio. El estado `pending-reboot` indica que es necesario reiniciar para aplicar algunos cambios en los parámetros.
```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
--query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
"DBClusterMembers": [
{
"DBInstanceIdentifier": "serverless-v2-instance-1",
"DBClusterParameterGroupStatus": "pending-reboot"
}
]
}
```
En este punto, el clúster está inactivo y la instancia de base de datos `serverless-v2-instance-1` consume 8,0 ACU. El siguiente ejemplo muestra cómo el parámetro `shared_buffers` ya se ha ajustado en función de la capacidad actual de la instancia de base de datos. El parámetro `max_connections` sigue reflejando el valor del rango de capacidad máxima anterior. Para restablecer ese valor es necesario reiniciar la instancia de base de datos.
**nota**
Si establece el parámetro `max_connections` directamente en un grupo de parámetros de base de datos personalizado, no será necesario reiniciar.
```
postgres=> show max_connections;
max_connections
-----------------
189
(1 row)
postgres=> show shared_buffers;
shared_buffers
----------------
1425408
(1 row)
```
Reiniciamos la instancia de base de datos y esperamos a que vuelva a estar disponible.
```
aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
"DBInstanceIdentifier": "serverless-v2-instance-1",
"DBInstanceStatus": "rebooting"
}
aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1
```
Ahora que la instancia de base de datos se ha reiniciado, el estado `pending-reboot` queda borrado. El valor `in-sync` confirma que Aurora ha aplicado todos los cambios de parámetros pendientes.
```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
--query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
"DBClusterMembers": [
{
"DBInstanceIdentifier": "serverless-v2-instance-1",
"DBClusterParameterGroupStatus": "in-sync"
}
]
}
```
Tras el reinicio, `max_connections` muestra el valor de la nueva capacidad máxima.
```
postgres=> show max_connections;
max_connections
-----------------
5000
(1 row)
postgres=> show shared_buffers;
shared_buffers
----------------
1425408
(1 row)
```
A continuación, cambiamos el rango de capacidad del clúster a 12,5–80 ACU.
```
aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
--serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
--query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
"MinCapacity": 12.5,
"MaxCapacity": 80.0
}
```
En este punto, el clúster está inactivo y la instancia de base de datos `serverless-v2-instance-1`consume 12,5 ACU. El siguiente ejemplo muestra cómo el parámetro `shared_buffers` ya se ha ajustado en función de la capacidad actual de la instancia de base de datos. El valor de `max_connections` sigue siendo 5000.
```
postgres=> show max_connections;
max_connections
-----------------
5000
(1 row)
postgres=> show shared_buffers;
shared_buffers
----------------
2211840
(1 row)
```
Reiniciamos de nuevo, pero los valores de los parámetros siguen siendo los mismos. Esto se debe a que `max_connections` tiene un valor máximo de 5000 para un clúster de base de datos de Aurora Serverless v2 que ejecuta Aurora PostgreSQL.
```
postgres=> show max_connections;
max_connections
-----------------
5000
(1 row)
postgres=> show shared_buffers;
shared_buffers
----------------
2211840
(1 row)
```
Ahora establecemos el rango de capacidad entre 0,5 y 128 ACU. El clúster de base de datos se reduce verticalmente a 10 ACU y, luego, a 2. Reiniciamos la instancia de base de datos.
```
postgres=> show max_connections;
max_connections
-----------------
2000
(1 row)
postgres=> show shared_buffers;
shared_buffers
----------------
16384
(1 row)
```
El valor de `max_connections` de las instancias de base de datos de Aurora Serverless v2 se basa en el tamaño de memoria obtenido del número máximo de ACU. Sin embargo, cuando especifique una capacidad mínima de 0 o 0,5 ACU en instancias de base de datos compatibles con PostgreSQL, el valor máximo de `max_connections` está limitado a 2000.
Ahora devolvemos la capacidad a su rango inicial de 0,5 a 1 ACU y reiniciamos la instancia de base de datos. El parámetro `max_connections` ha recuperado su valor original.
```
postgres=> show max_connections;
max_connections
-----------------
189
(1 row)
postgres=> show shared_buffers;
shared_buffers
----------------
16384
(1 row)
```
## Trabajo con los grupos de parámetros para Aurora Serverless v2
Cuando crea el clúster de bases de datos de Aurora Serverless v2, elige un motor de base de datos de Aurora y un grupo de parámetros de clúster de bases de datos asociado. Si no está familiarizado con cómo Aurora utiliza los grupos de parámetros para aplicar la configuración de forma coherente en clústeres, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). Todos estos procedimientos para crear, modificar, aplicar y otras acciones para grupos de parámetros son aplicables a Aurora Serverless v2.
La característica de grupo de parámetros suele funcionar igual entre clústeres aprovisionados y clústeres que contienen instancias de base de datos Aurora Serverless v2:
+ Los valores de los parámetros predeterminados de todas las instancias de base de datos en el clúster los define el grupo de parámetros del clúster.
+ Puede anular algunos parámetros para instancias de base de datos concretas especificando un grupo de parámetros de base de datos personalizado para esas instancias de base de datos. Puede hacerlo al ajustar las opciones de depuración o de rendimiento de instancias de base de datos específicas. Por ejemplo, suponga que tiene un clúster que contiene algunas instancias de base de datos Aurora Serverless v2 y algunas instancias de base de datos aprovisionadas. En este caso, puede especificar algunos parámetros diferentes para las instancias de base de datos aprovisionadas con un grupo de parámetros de base de datos personalizado.
+ Para Aurora Serverless v2, podría utilizar todos los parámetros que tengan el valor `provisioned` en el atributo `SupportedEngineModes` del grupo de parámetros. En Aurora Serverless v1 solo puede utilizar el subconjunto de parámetros que tienen `serverless` en el atributo `SupportedEngineModes`.
**Topics**
+ [Valores de parámetros predeterminados](#aurora-serverless-v2.parameter-groups-defaults)
+ [Número máximo de conexiones para Aurora Serverless v2](#aurora-serverless-v2.max-connections)
+ [Parámetros que Aurora ajusta cuando se escala Aurora Serverless v2 a más o a menos](#aurora-serverless-v2.parameters-based-on-scaling)
+ [Parámetros en los que Aurora hace sus cómputos basándose en la capacidad máxima de Aurora Serverless v2](#aurora-serverless-v2.parameters-based-on-max-capacity)
### Valores de parámetros predeterminados
Una diferencia crucial entre las instancias de base de datos aprovisionadas y las instancias de base de datos Aurora Serverless v2 es que Aurora anula cualquier valor de parámetro personalizado para determinados parámetros relacionados con la capacidad de las instancias de base de datos. Los valores de los parámetros personalizados se seguirán aplicando a cualquier instancia de base de datos aprovisionada del clúster. Para obtener más información acerca de cómo interpretan las instancias de base de datos Aurora Serverless v2 los parámetros de los grupos de parámetros Aurora, consulte [Parámetros de configuración de los clústeres de Aurora](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.parameters). Para los parámetros específicos que Aurora Serverless v2 anula, consulte [Parámetros que Aurora ajusta cuando se escala Aurora Serverless v2 a más o a menos](#aurora-serverless-v2.parameters-based-on-scaling) y [Parámetros en los que Aurora hace sus cómputos basándose en la capacidad máxima de Aurora Serverless v2](#aurora-serverless-v2.parameters-based-on-max-capacity).
Puede ver la lista de valores predeterminados de los grupos de parámetros predeterminados para los diferentes motores de base de datos de Aurora mediante el comando [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) de la CLI y consultando la Región de AWS. A continuación se indican los valores que puede utilizar para las opciones `--db-parameter-group-family` y `-db-parameter-group-name` para versiones de motor compatibles con Aurora Serverless v2.
| Motor de base de datos y versión | Familia de grupos de parámetros | Nombre del grupo de parámetros predeterminado |
| --- | --- | --- |
| Aurora MySQL versión 3 | `aurora-mysql8.0` | `default.aurora-mysql8.0` |
| Versión 13.x de Aurora PostgreSQL | `aurora-postgresql13` | `default.aurora-postgresql13` |
| Versión 14.x de Aurora PostgreSQL | `aurora-postgresql14` | `default.aurora-postgresql14` |
| Versión 15.x de Aurora PostgreSQL | `aurora-postgresql15` | `default.aurora-postgresql15` |
| Versión 16.x de Aurora PostgreSQL | `aurora-postgresql16` | `default.aurora-postgresql16` |
| Versión 17.x de Aurora PostgreSQL | `aurora-postgresql17` | `default.aurora-postgresql17` |
En el ejemplo siguiente se obtiene una lista de parámetros del grupo de clústeres de base de datos predeterminado para Aurora MySQL versión 3 y Aurora PostgreSQL 13. Estas son las versiones de Aurora MySQL y Aurora PostgreSQL que se usan con Aurora Serverless v2.
Para Linux, macOS o Unix:
```
aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name default.aurora-mysql8.0 \
--query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} |
[?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
--output text
aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name default.aurora-postgresql13 \
--query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} |
[?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
--output text
```
Para Windows:
```
aws rds describe-db-cluster-parameters ^
--db-cluster-parameter-group-name default.aurora-mysql8.0 ^
--query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} |
[?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
--output text
aws rds describe-db-cluster-parameters ^
--db-cluster-parameter-group-name default.aurora-postgresql13 ^
--query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} |
[?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
--output text
```
### Número máximo de conexiones para Aurora Serverless v2
Para Aurora MySQL y Aurora PostgreSQL, las instancias de base de datos Aurora Serverless v2 contienen constante el parámetro `max_connections` para que las conexiones no se pierdan cuando la instancia de base de datos se escala a menos. El valor predeterminado de este parámetro se deriva de una fórmula que se basa en el tamaño de memoria de la instancia de base de datos. Para obtener más información sobre la fórmula y los valores predeterminados de las clases de instancia de base de datos aprovisionadas, consulte [Número máximo de conexiones a una instancia de base de datos Aurora MySQL](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections) y [Número máximo de conexiones a una instancia de base de datos Aurora PostgreSQL](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.MaxConnections).
Cuando Aurora Serverless v2 evalúa la fórmula, utiliza el tamaño de memoria en función de las unidades de capacidad máxima de Aurora (ACU) para la instancia de base de datos, no en el valor ACU actual. Si cambia el valor predeterminado, le recomendamos utilizar una variación de la fórmula en lugar de especificar un valor constante. De esa forma, Aurora Serverless v2 puede utilizar un ajuste del tamaño adecuado basado en la capacidad máxima.
Al cambiar la capacidad máxima de un clúster de base de datos de Aurora Serverless v2, debe reiniciar las instancias de base de datos de Aurora Serverless v2 para actualizar el valor de `max_connections`. Esto se debe a que `max_connections` es un parámetro estático de Aurora Serverless v2.
La siguiente tabla muestra los valores predeterminados de `max_connections` para Aurora Serverless v2 en función del valor máximo de ACU.
| Cantidad máxima de ACU | Conexiones máximas predeterminadas en Aurora MySQL | Conexiones máximas predeterminadas en Aurora PostgreSQL |
| --- | --- | --- |
| 1 | 90 | 189 |
| 4 | 135 | 823 |
| 8 | 1 000 | 1669 |
| 16 | 2,000 | 3360 |
| 32 | 3000 | 5 000 |
| 64 | 4.000 | 5 000 |
| 128 | 5 000 | 5 000 |
| 192 | 6000 | 5 000 |
| 256 | 6000 | 5 000 |
**nota**
El valor de `max_connections` de las instancias de base de datos de Aurora Serverless v2 se basa en el tamaño de memoria obtenido del número máximo de ACU. Sin embargo, cuando especifique una capacidad mínima de 0 o 0,5 ACU en instancias de base de datos compatibles con PostgreSQL, el valor máximo de `max_connections` está limitado a 2000.
Para ver ejemplos específicos que muestran cómo `max_connections` cambia con el valor máximo de ACU, consulte [Ejemplo: Cambiar el rango de capacidad de Aurora Serverless v2 de un clúster de Aurora MySQL](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-ams) y [Ejemplo: Cambiar el rango de capacidad Aurora Serverless v2 de un clúster de Aurora PostgreSQL](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-apg).
### Parámetros que Aurora ajusta cuando se escala Aurora Serverless v2 a más o a menos
Durante el escalado automático, Aurora Serverless v2 necesita poder cambiar los parámetros de cada instancia de base de datos para que funcione mejor para el aumento o la disminución de la capacidad. Por lo tanto, no puede anular algunos parámetros relacionados con la capacidad. En algunos parámetros que sí se pueden anular, evite codificar valores fijos. Tenga en cuenta lo siguiente en cuanto a esta configuración relacionada con la capacidad.
En Aurora MySQL, Aurora Serverless v2 cambia el tamaño de algunos parámetros dinámicamente durante el escalado. En los parámetros siguientes, Aurora Serverless v2 no utiliza ningún valor de parámetro personalizado que especifique el usuario:
+ `innodb_buffer_pool_size`
+ `innodb_purge_threads`
+ `table_definition_cache`
+ `table_open_cache`
En Aurora PostgreSQL, Aurora Serverless v2 cambia el tamaño del siguiente parámetro de forma dinámica durante el escalado. En los parámetros siguientes, Aurora Serverless v2 no utiliza ningún valor de parámetro personalizado que especifique el usuario:
+ `shared_buffers`
Para todos los parámetros distintos de los enumerados aquí, las instancias de base de datos de Aurora Serverless v2 funcionan de la misma manera que las instancias de base de datos aprovisionadas. El valor predeterminado del parámetro se hereda del grupo de parámetros del clúster. Puede modificar el valor predeterminado de todo el clúster mediante un grupo de parámetros de clúster personalizado. O bien, puede modificar el valor predeterminado para determinadas instancias de base de datos mediante un grupo de parámetros de base de datos personalizado. Los parámetros dinámicos se actualizan de inmediato. Los cambios en los parámetros estáticos solo surten efecto después de reiniciar la instancia de base de datos.
### Parámetros en los que Aurora hace sus cómputos basándose en la capacidad máxima de Aurora Serverless v2
Para los siguientes parámetros, Aurora PostgreSQL utiliza valores predeterminados derivados del tamaño de memoria basado en la configuración máxima de ACU, al igual que con `max_connections`:
+ `autovacuum_max_workers`
+ `autovacuum_vacuum_cost_limit`
+ `autovacuum_work_mem`
+ `effective_cache_size`
+ `maintenance_work_mem`
## Evitar errores de memoria insuficiente
Si una de sus instancias de base de datos Aurora Serverless v2 alcanza constantemente el límite de su capacidad máxima, Aurora lo indica estableciendo la instancia de base de datos en un estado de `incompatible-parameters`. Si bien la instancia de base de datos tiene el estado `incompatible-parameters`, algunas operaciones quedan bloqueadas. Por ejemplo, no se puede actualizar la versión del motor.
Normalmente, la instancia de base de datos entra en este estado cuando se reinicia con frecuencia debido a errores de falta de memoria. Aurora graba un evento cuando se produce este tipo de reinicio. Puede ver el evento siguiendo el procedimiento en [Consulta de eventos de Amazon RDS](USER_ListEvents.md). Los casos de uso de memoria inusualmente elevados pueden producirse debido a una sobrecarga en el ajuste de configuraciones como la de la información del rendimiento y la autenticación de IAM. También puede provenir de una carga de trabajo pesada en la instancia de base de datos o de la administración de metadatos asociados a un gran número de objetos de esquema.
Si la presión de memoria disminuye para que la instancia de base de datos no alcance su capacidad máxima muy a menudo, Aurora cambia automáticamente el estado de la instancia de base de datos a `available`.
Para recuperarse de esta situación, puede llevar a cabo algunas o todas las acciones siguientes:
+ Aumentar el límite inferior de capacidad para instancias de base de datos Aurora Serverless v2 cambiando el valor mínimo de la unidad de capacidad Aurora (ACU) para el clúster. Al hacerlo, se evitan problemas en los que la capacidad de una base de datos inactiva se escala a menos memoria de la necesaria para las características activadas en el clúster. Después de cambiar la configuración de ACU del clúster, reinicie la instancia de base de datos Aurora Serverless v2. Al hacerlo, se evalúa si Aurora puede restablecer el estado de nuevo a `available`.
+ Aumentar el límite superior de capacidad para instancias de base de datos Aurora Serverless v2 cambiando el valor máximo de ACU para el clúster. Al hacerlo, se evitan problemas en los que una base de datos ocupada no puede escalar a una capacidad con suficiente memoria para las funciones activadas en el clúster y la carga de trabajo de la base de datos. Después de cambiar la configuración de ACU del clúster, reinicie la instancia de base de datos Aurora Serverless v2. Al hacerlo, se evalúa si Aurora puede restablecer el estado de nuevo a `available`.
+ Desactivar los ajustes de configuración que requieren sobrecarga de memoria. Por ejemplo, suponga que tiene activadas característica como AWS Identity and Access Management (IAM), información sobre el rendimiento o replicación de registros binarios de Aurora MySQL, pero no las usa. Si es así, puede desactivarlas. O bien, puede ajustar los valores de capacidad mínima y máxima del clúster para tener en cuenta la memoria utilizada por esas funciones. Para ver instrucciones sobre cómo elegir la configuración de capacidad mínima y máxima, consulte [Elegir el rango de capacidad de Aurora Serverless v2 para un clúster de Aurora](#aurora-serverless-v2-examples-setting-capacity-range-for-cluster).
+ Reducir la carga de trabajo de la instancia de base de datos. Por ejemplo, puede agregar instancias de base de datos de instancias de lector al clúster para distribuir la carga de las consultas de solo lectura entre más instancias de base de datos.
+ Ajustar el código SQL utilizado por la aplicación para utilizar menos recursos. Por ejemplo, puede ver los planes de consulta, comprobar el registro de consultas lentas o ajustar los índices de las tablas. También puede aplicar otros tipos de ajustes de SQL tradicionales.
## Métricas importantes de Amazon CloudWatch para Aurora Serverless v2
Para empezar a trabajar con Amazon CloudWatch para su instancia de base de datos Aurora Serverless v2, consulte [Visualización registros de Aurora Serverless v2 en Amazon CloudWatch](aurora-serverless-v2-administration.md#aurora-serverless-v2.logging.monitoring). Para obtener más información acerca de cómo monitorear los clústeres de base de datos de Aurora a través de CloudWatch, consulte [Monitoreo de eventos de registro en Amazon CloudWatch](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor).
Puede ver sus instancias de base de datos Aurora Serverless v2 en CloudWatch para supervisar la capacidad consumida por cada instancia de base de datos con la métrica `ServerlessDatabaseCapacity`. También puede supervisar todas las métricas estándar de CloudWatch para Aurora, como `DatabaseConnections` y `Queries`. Para ver la lista completa de métricas de CloudWatch que puede supervisar para Aurora, consulte [Métricas de Amazon CloudWatch para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). Las métricas se dividen en métricas en el nivel de clúster y de instancia, en[Métricas de nivel de clúster para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.clusters) y [Métricas de nivel de instancia para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
Es importante supervisar las siguientes métricas en el nivel de instancia de CloudWatch para comprender cómo se escalan a más o a menos las instancias de base de datos Aurora Serverless v2. Todas estas métricas se calculan cada segundo. De esta forma, puede supervisar el estado en uso de sus instancias de base de datos Aurora Serverless v2. Puede configurar alarmas para notificarle si hay alguna de las instancias de base de datos Aurora Serverless v2 se acerca a un umbral de métricas relacionadas con la capacidad. Puede determinar si los ajustes de capacidad mínima y máxima son apropiados o si necesita ajustarlos. Puede determinar dónde debe centrar sus esfuerzos para optimizar la eficiencia de la base de datos.
+ `ServerlessDatabaseCapacity`. Como métrica en el nivel de instancia, informa del número de ACU representadas por la capacidad de instancia de base de datos actual. Como métrica en el nivel de clúster, representa la media de los valores de `ServerlessDatabaseCapacity` de todas las instancias de base de datos Aurora Serverless v2 del clúster. Esta métrica es solo una métrica de nivel de clúster en Aurora Serverless v1. En Aurora Serverless v2, está disponible en el nivel de instancia de base de datos y en el nivel de clúster.
+ `ACUUtilization`. Esta métrica es nueva en Aurora Serverless v2. Este valor se representa como un porcentaje. Se calcula como el valor de la métrica `ServerlessDatabaseCapacity` dividida por el valor máximo de ACU del clúster de bases de datos. Tenga en cuenta las siguientes pautas para interpretar esta métrica y tomar medidas:
+ Si esta métrica se aproxima a un valor de `100.0`, la instancia de base de datos se ha escalado al punto máximo posible. Considere aumentar la configuración máxima de ACU para el clúster. De este modo, las instancias de base de datos de escritor y lector podrán escalarse a una mayor capacidad.
+ Supongamos que una carga de trabajo de solo lectura hace que una instancia de base de datos de lector se acerque a un valor `ACUUtilization` de `100.0`, mientras que la instancia de base de datos de escritor no está cerca de su capacidad máxima. En ese caso, considere agregar instancias de base de datos de lector adicionales al clúster. De esta forma, puede distribuir la parte de solo lectura de la carga de trabajo distribuida en más instancias de base de datos, reduciendo la carga en cada instancia de base de datos de lector.
+ Supongamos que está ejecutando una aplicación de producción, donde el rendimiento y la escalabilidad son las principales consideraciones. En ese caso, puede establecer el valor máximo de ACU del clúster en un número elevado. Su objetivo es que la métrica `ACUUtilization` quede siempre por debajo de `100.0`. Con un valor de ACU máximo alto, puede estar seguro de tener suficiente espacio en caso de que haya picos inesperados en la actividad de la base de datos. Solo se le cobrará por la capacidad de base de datos que se consuma realmente.
+ `CPUUtilization`. Esta métrica se interpreta de forma diferente en Aurora Serverless v2 que en las instancias de base de datos aprovisionadas. Para Aurora Serverless v2, este valor es un porcentaje que se calcula como la cantidad de CPU que se utiliza actualmente dividida por la capacidad de CPU disponible bajo el valor máximo de ACU del clúster de bases de datos. Aurora supervisa este valor automáticamente y escala hacia arriba su instancia de base de datos Aurora Serverless v2 cuando esta utiliza sistemáticamente una elevada proporción de su capacidad de CPU.
Si esta métrica se aproxima a un valor de `100.0`, la instancia de base de datos ha alcanzado su capacidad máxima de CPU. Considere aumentar la configuración máxima de ACU para el clúster. Si esta métrica se aproxima a un valor de `100.0` en una instancia de base de datos de lector, considere agregar instancias de base de datos de lector adicionales al clúster. De esta forma, puede distribuir la parte de solo lectura de la carga de trabajo distribuida en más instancias de base de datos, reduciendo la carga en cada instancia de base de datos de lector.
+ `FreeableMemory`. Este valor representa la cantidad de memoria sin utilizar que está disponible cuando la instancia de base de datos Aurora Serverless v2 se escala a su capacidad máxima. Por cada ACU en cuya capacidad actual esté por debajo de la capacidad máxima, este valor aumenta aproximadamente 2 GiB. Por lo tanto, esta métrica no se aproxima a cero hasta que la instancia de base de datos se amplía al máximo posible.
Si esta métrica se aproxima a un valor de `0`, la instancia de base de datos se ha ampliado tanto como puede y se acerca al límite de memoria disponible. Considere aumentar la configuración máxima de ACU para el clúster. Si esta métrica se aproxima a un valor de `0` en una instancia de base de datos de lector, considere agregar instancias de base de datos de lector adicionales al clúster. De esta forma, puede distribuir la parte de solo lectura entre más instancias de base de datos, reduciendo el uso de memoria en cada instancia de base de datos de lector.
+ `TempStorageIOPS`. El número de IOPS realizadas en el almacenamiento local adjuntas a la instancia de base de datos. Incluye las IOPS de lecturas y escrituras. Esta métrica representa un recuento y se mide una vez por segundo. Esta es una nueva métrica en Aurora Serverless v2. Para obtener más información, consulte [Métricas de nivel de instancia para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
+ `TempStorageThroughput`. La cantidad de datos transferidos desde y hacia el almacenamiento local asociado a la instancia de base de datos. Esta métrica representa un número de bytes y se mide una vez por segundo. Esta es una nueva métrica en Aurora Serverless v2. Para obtener más información, consulte [Métricas de nivel de instancia para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
Por lo general, la mayoría de los escalados a más para instancias de base de datos Aurora Serverless v2 son por el uso de la memoria y por la actividad. Las métricas `TempStorageIOPS` y `TempStorageThroughput` pueden ayudarle a diagnosticar los raros casos en los que la actividad de red para transferencias entre la instancia de base de datos y los dispositivos de almacenamiento locales es responsable de aumentos de capacidad no esperados. Para supervisar otra actividad de red, puede utilizar estas métricas existentes:
+ `NetworkReceiveThroughput`
+ `NetworkThroughput`
+ `NetworkTransmitThroughput`
+ `StorageNetworkReceiveThroughput`
+ `StorageNetworkThroughput`
+ `StorageNetworkTransmitThroughput`
Puede hacer que Aurora publique algunos registros de base de datos o todos en Registros de Amazon CloudWatch. Para obtener instrucciones, consulte lo siguiente, en función del motor de base de datos:
+ [Publicación de registros de Aurora PostgreSQL en Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md)
+ [Publicación de registros de Amazon Aurora MySQL en Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md)
### Cómo se aplican las métricas de Aurora Serverless v2 en la factura de AWS
Los cargos correspondientes a Aurora Serverless v2 en la factura de AWS se calcula sobre la base de la misma métrica de `ServerlessDatabaseCapacity` que el usuario puede supervisar. El mecanismo de facturación puede diferir de la media computada de CloudWatch para esta métrica en los casos en los que se utilice capacidad de Aurora Serverless v2 durante solo una parte de una hora. También puede variar si los problemas del sistema hacen que la métrica de CloudWatch no esté disponible durante periodos breves. Por lo tanto, es posible que vea un valor ligeramente diferente de las horas de ACU en su factura que si computa el número usted mismo a partir del valor de `ServerlessDatabaseCapacity` promedio.
### Ejemplos de comandos de CloudWatch para métricas de Aurora Serverless v2
Los siguientes ejemplos de AWS CLI muestran cómo se pueden supervisar las métricas de CloudWatch más importantes relacionadas con Aurora Serverless v2. En cada caso, sustituya la cadena `Value=` para el parámetro `--dimensions` con el identificador de su propia instancia de base de datos Aurora Serverless v2.
En el siguiente ejemplo de Linux se muestran los valores de capacidad mínima, máxima y media de una instancia de base de datos, medidos cada 10 minutos durante una hora. El comando de Linux `date` especifica las horas de inicio y finalización en relación con la fecha y la hora en curso. La función `sort_by` en el parámetro `--query` ordena los resultados cronológicamente basándose en el campo `Timestamp`.
```
aws cloudwatch get-metric-statistics --metric-name "ServerlessDatabaseCapacity" \
--start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
--namespace "AWS/RDS" --statistics Minimum Maximum Average \
--dimensions Name=DBInstanceIdentifier,Value=my_instance \
--query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table
```
Los siguientes ejemplos de Linux muestran la supervisión de la capacidad de cada instancia de base de datos de un clúster. Miden el uso de capacidad mínimo, máximo y medio de cada instancia de base de datos. Las mediciones se toman una vez por hora durante un período de tres horas. Estos ejemplos utilizan la métrica `ACUUtilization`, la cual representa un porcentaje del límite superior en las ACU, en lugar de `ServerlessDatabaseCapacity`, que representa un número fijo de ACU. De esta forma, no necesita conocer los números reales de los valores de ACU mínima y máxima en el rango de capacidad. Puede ver porcentajes que oscilan entre 0 y 100.
```
aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
--start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
--namespace "AWS/RDS" --statistics Minimum Maximum Average \
--dimensions Name=DBInstanceIdentifier,Value=my_writer_instance \
--query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table
aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
--start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
--namespace "AWS/RDS" --statistics Minimum Maximum Average \
--dimensions Name=DBInstanceIdentifier,Value=my_reader_instance \
--query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table
```
En el siguiente ejemplo de Linux se hacen mediciones similares a las anteriores. En este caso, las medidas corresponden a la métrica `CPUUtilization`. Las mediciones se toman cada 10 minutos durante un período de 1 hora. Los números representan el porcentaje de CPU disponible utilizada, en función de los recursos de CPU disponibles para la configuración de capacidad máxima de la instancia de base de datos.
```
aws cloudwatch get-metric-statistics --metric-name "CPUUtilization" \
--start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
--namespace "AWS/RDS" --statistics Minimum Maximum Average \
--dimensions Name=DBInstanceIdentifier,Value=my_instance \
--query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table
```
En el siguiente ejemplo de Linux se hacen mediciones similares a las anteriores. En este caso, las medidas corresponden a la métrica `FreeableMemory`. Las mediciones se toman cada 10 minutos durante un período de 1 hora.
```
aws cloudwatch get-metric-statistics --metric-name "FreeableMemory" \
--start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
--namespace "AWS/RDS" --statistics Minimum Maximum Average \
--dimensions Name=DBInstanceIdentifier,Value=my_instance \
--query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table
```
## Supervisión del rendimiento de Aurora Serverless v2 con la información de rendimiento
Puede utilizar Performance Insights (Información de rendimiento) para supervisar el rendimiento de las instancias de base de datos Aurora Serverless v2 Para conocer los procedimientos de información del rendimiento, consulte [Monitoreo de la carga de base de datos con Performance Insights en Amazon Aurora](USER_PerfInsights.md).
Los siguientes son contadores de información del rendimiento nuevos aplicables a instancias de base de datos Aurora Serverless v2
+ `os.general.serverlessDatabaseCapacity`: la capacidad actual de la instancia de base de datos en ACU. El valor corresponde a la métrica de CloudWatch `ServerlessDatabaseCapacity` para la instancia de base de datos.
+ `os.general.acuUtilization`: porcentaje de la capacidad actual fuera de la capacidad máxima configurada. El valor corresponde a la métrica de CloudWatch `ACUUtilization` para la instancia de base de datos.
+ `os.general.maxConfiguredAcu`: la capacidad máxima que ha configurado para esta instancia de base de datos Aurora Serverless v2. Se mide en ACU.
+ `os.general.minConfiguredAcu`: la capacidad máxima que ha configurado para esta instancia de base de datos Aurora Serverless v2. Se mide en ACU.
Para ver la lista completa de contadores de información de rendimiento, consulte [Métricas de contador de Información de rendimiento](USER_PerfInsights_Counters.md).
Cuando se muestran los valores de `vCPU` para una instancia de base de datos Aurora Serverless v2 en la información de rendimiento, estos valores representan estimaciones basadas en el valor de ACU de la instancia de base de datos. En el intervalo predeterminado de un minuto, los valores fraccionarios de vCPU se redondean al número entero más cercano. En intervalos más largos, el valor de vCPU que se muestra es el promedio de los valores de vCPU enteros de cada minuto.
## Solución de problemas de capacidad de Aurora Serverless v2
En algunos casos, Aurora Serverless v2 no se reduce verticalmente a la capacidad mínima, incluso sin carga en la base de datos. Esto puede suceder por una de las siguientes razones:
+ Algunas características pueden aumentar el uso de los recursos e impedir que la base de datos se reduzca verticalmente a su capacidad mínima. Estas son algunas de ellas:
+ Bases de datos globales de Aurora
+ Exportación de registros de CloudWatch
+ Habilitación de `pg_audit` en clústeres de base de datos compatibles con Aurora PostgreSQL
+ Enhanced Monitoring (Monitorización mejorada)
+ Información de rendimiento
Para obtener más información, consulte [Elegir la configuración de capacidad de Aurora Serverless v2 mínima para un clúster](#aurora-serverless-v2.min_capacity_considerations).
+ Si una instancia de lector no se reduce verticalmente al mínimo y permanece en la misma capacidad o más que la instancia de escritor, compruebe el nivel de prioridad de la instancia de lector. Las instancias de base de datos de lector de Aurora Serverless v2 en los niveles 0 o 1 se mantienen a una capacidad mínima al menos tan alta como la instancia de base de datos de escritor. Cambie el nivel de prioridad del lector a 2 o más para que se escale y se reduzca verticalmente independientemente del escritor. Para obtener más información, consulte [Elegir el nivel de promoción para un lector Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier).
+ Defina los parámetros de la base de datos que afecten al tamaño de la memoria compartida en sus valores predeterminados. Si se establece un valor superior al predeterminado, se aumenta el requisito de memoria compartida y se evita que la base de datos se reduzca verticalmente a la capacidad mínima. Algunos ejemplos son `max_connections` y `max_locks_per_transaction`.
**nota**
La actualización de los parámetros de memoria compartida requiere reiniciar la base de datos para que los cambios surtan efecto.
+ Las cargas de trabajo pesadas de las bases de datos pueden aumentar el uso de recursos.
+ Los grandes volúmenes de bases de datos pueden aumentar el uso de recursos.
Amazon Aurora utiliza recursos de memoria y CPU para la administración de clústeres de bases de datos. Aurora requiere más CPU y memoria para administrar los clústeres de bases de datos con volúmenes de bases de datos más grandes. Si la capacidad mínima del clúster es inferior al mínimo requerido para la administración del clúster, el clúster no se reducirá verticalmente a la capacidad mínima.
+ Los procesos en segundo plano, como la purga, también pueden aumentar el uso de los recursos.
+ Las limitaciones de las versiones de la plataforma pueden afectar a las capacidades de escalado. 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). Es posible tener una versión de motor con mayor capacidad que se ejecute en una versión de la plataforma con menor capacidad y viceversa.
Si la base de datos sigue sin reducir verticalmente la capacidad mínima configurada, deténgala y reiníciela para recuperar los fragmentos de memoria que se hayan acumulado con el tiempo. Al detener e iniciar una base de datos, se produce un tiempo de inactividad, por lo que recomendamos hacerlo con moderación.
# 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 [Aurora Serverless v2Capacidad de](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
**Topics**
+ [Descripción general de la pausa automática](#auto-pause-overview)
+ [Requisitos previos y limitaciones](#auto-pause-prereqs)
+ [Activación y desactivación de la pausa automática](#auto-pause-enabling-disabling)
+ [Funcionamiento de la pausa automática](#auto-pause-how-it-works)
+ [Configuraciones de los clústeres de Aurora y de la pausa automática](#auto-pause-topology)
+ [Supervisión de la pausa automática](#auto-pause-monitoring)
+ [Solución de problemas para la característica de pausa automática](#auto-pause-troubleshooting)
+ [Diseño de la aplicación para la pausa automática](#auto-pause-applications)
## 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.
+ Si utiliza Aurora PostgreSQL, el motor de base de datos debe ejecutar al menos las versiones 16.3, 15.7, 14.12 o 13.15.
+ Si utiliza Aurora MySQL, el motor de base de datos debe ejecutar la versión 3.08.0 o superior.
+ Para ver la lista completa de las versiones del motor y las regiones de AWS en las que está disponible esta característica, consulte [Regiones y motores de base de datos Aurora admitidos para Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md).
+ Cuando se reanuda una instancia de Aurora Serverless v2, es posible que su capacidad sea inferior a la que tenía cuando la instancia estaba en pausa. Para obtener más información, consulte [Diferencias en el comportamiento de pausa automática entre Aurora Serverless v2 y Aurora Serverless v1](#auto-pause-differences).
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](#auto-pause-whynot).
## 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.
**Topics**
+ [Activación de la pausa automática](#auto-pause-enabling)
+ [Intervalo de tiempo de espera de la pausa automática](#auto-pause-timeout)
+ [Reanudación de una instancia](#auto-pause-waking)
+ [Desactivación de la pausa automática](#auto-pause-disabling)
### 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](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus). 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 Consola de administración de AWS 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](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus). 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.
**Topics**
+ [Funcionamiento de la pausa automática](#auto-pause-pausing)
+ [Funcionamiento de la reanudación automática](#auto-pause-resuming)
+ [Facturación de CPU](#auto-pause-billing)
+ [Condiciones que impiden la pausa automática](#auto-pause-whynot)
+ [Comparación con la parada o el inicio del clúster](#auto-pause-stop-start)
+ [Mantenimiento y actualizaciones](#auto-pause-maintenance)
+ [Comparación con Aurora Serverless v1](#auto-pause-differences)
### 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](USER_Events.Messages.md#USER_Events.Messages.instance).
### 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](USER_Events.Messages.md#USER_Events.Messages.instance).
+ 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.
**Topics**
+ [Diseños de los clústeres de Aurora](#auto-pause-recommended-layouts)
+ [Pausa automática para la instancia de escritor](#auto-pause-writer)
+ [Pausa automática para clústeres Multi-AZ e instancias de lector](#auto-pause-multi-az)
+ [Pausa automática en clústeres mixtos](#auto-pause-provisioned)
### Diseños de los clústeres de Aurora recomendados al utilizar la pausa automática
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](monitoring-cloudwatch.md) y las métricas de CloudWatch que se muestran en [Referencia de métricas para Amazon Aurora](metrics-reference.md). 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](#auto-pause-prereqs), [Situaciones en las Aurora Serverless v2 que no se pausa automáticamente](#auto-pause-whynot) y [Solución de problemas para la característica de pausa automática de Aurora Serverless v2](#auto-pause-troubleshooting).
+ 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](aurora-serverless-v2-administration.md#autopause-logging-instance-log).
**Topics**
+ [Comprobación de instancias pausadas](#auto-pause-status)
+ [Eventos de pausa automática y reanudación automática](#auto-pause-events)
+ [Información de rendimiento y Monitorización mejorada](#auto-pause-pi-em)
+ [Métricas de Aurora](#auto-pause-metrics)
### 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](USER_Events.Messages.md#USER_Events.Messages.instance).
### 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 [Aurora Serverless v2Capacidad de](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
+ 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](#auto-pause-prereqs).
+ 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](aurora-serverless-v2-administration.md#autopause-logging-instance-log).
+ 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](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
+ 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](#auto-pause-whynot).
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](USER_Events.Messages.md#USER_Events.Messages.instance).
# Migración a Aurora Serverless v2
Para convertir un clúster de base de datos existente para utilizar Aurora Serverless v2, puede hacer lo siguiente:
+ Actualizar desde un clúster de base de datos de Aurora aprovisionado.
+ Actualizar desde un clúster de Aurora Serverless v1.
+ Migrar una base de datos en las instalaciones a un clúster de Aurora Serverless v2.
Cuando el clúster actualizado ejecuta la versión del motor adecuada, tal como se indica en [Requisitos y limitaciones para Aurora Serverless v2](aurora-serverless-v2.requirements.md), puede empezar a añadirle instancias de base de datos de Aurora Serverless v2. La primera instancia de base de datos que se agrega al clúster actualizado debe ser una instancia de base de datos aprovisionada. A continuación, puede cambiar el procesamiento de la carga de trabajo de escritura, la carga de trabajo de lectura o ambos a las instancias de base de datos de Aurora Serverless v2.
**Contents**
+ [Actualización o cambio de clústeres existentes para utilizar Aurora Serverless v2](#aurora-serverless-v2.getting-started-general-procedure)
+ [Rutas de actualización para clústeres compatibles con MySQL para usar Aurora Serverless v2](#serverless-v2-upgrade-paths-ams)
+ [Rutas de actualización para clústeres compatibles con PostgreSQL para usar Aurora Serverless v2](#serverless-v2-upgrade-paths-apg)
+ [Cambiar de un clúster aprovisionado a Aurora Serverless v2](#aurora-serverless-v2.switch-from-provisioned)
+ [Comparación de Aurora Serverless v2 y Aurora Serverless v1](#aurora-serverless.comparison)
+ [Comparación de los requisitos de Aurora Serverless v2 y Aurora Serverless v1](#aurora-serverless.comparison-requirements)
+ [Comparación del escalado y la disponibilidad de Aurora Serverless v2 y Aurora Serverless v1](#aurora-serverless.comparison-scaling)
+ [Comparación de la compatibilidad de características de Aurora Serverless v2 y Aurora Serverless v1](#aurora-serverless.comparison-features)
+ [Adaptación casos de uso de Aurora Serverless v1 para Aurora Serverless v2](#aurora-serverless.comparison-approaches)
+ [Actualización de un clúster de Aurora Serverless v1 a Aurora Serverless v2](#aurora-serverless-v2.upgrade-from-serverless-v1-procedure)
+ [Clústeres de base de datos compatibles con Aurora MySQL](#sv1-to-sv2-ams)
+ [Clústeres de base de datos compatibles con Aurora PostgreSQL](#sv1-to-sv2-apg)
+ [Migración de una base de datos en las instalaciones a Aurora Serverless v2](#aurora-serverless-v2.migrate-from-on-prem)
**nota**
En estos temas se describe cómo convertir un clúster de base de datos existente. Para obtener más información acerca de la creación de un clúster de bases de datos de Aurora Serverless v2 nuevo, consulte [Creación de un clúster de base de datos que utiliza Aurora Serverless v2](aurora-serverless-v2.create.md).
## Actualización o cambio de clústeres existentes para utilizar Aurora Serverless v2
Si el clúster aprovisionado tiene una versión de motor que admite Aurora Serverless v2, cambiar a Aurora Serverless v2 no requiere actualización. En ese caso, puede añadir instancias de base de datos de Aurora Serverless v2 al clúster original. Puede cambiar el clúster para utilizar todas las instancias de base de datos de Aurora Serverless v2. También puede utilizar una combinación de instancias de base de datos de Aurora Serverless v2 aprovisionadas en el mismo clúster de base de datos. Para las versiones del motor Aurora compatibles con Aurora Serverless v2, consulte [Regiones y motores de base de datos Aurora admitidos para Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md).
Si está ejecutando una versión del motor anterior que no admite Aurora Serverless v2, siga estos pasos generales:
1. Actualice el clúster.
1. Cree una instancia de base de datos de escritor aprovisionada para el clúster actualizado.
1. Modifique el clúster para usar instancias de base de datos de Aurora Serverless v2.
**importante**
Cuando realiza una actualización de la versión principal a un versión compatible con Aurora Serverless v2 mediante la restauración o la clonación de instantáneas, la primera instancia de base de datos que agregue al nuevo clúster debe ser una instancia de base de datos aprovisionada. Esta adición inicia la etapa final del proceso de actualización.
Hasta que se llega a esa etapa final, el clúster no tiene la infraestructura necesaria para admitir Aurora Serverless v2. Por lo tanto, estos clústeres actualizados siempre comienzan con una instancia de base de datos de escritura aprovisionada. A continuación, puede conmutar por error o convertir la instancia de base de datos aprovisionada en una instancia de Aurora Serverless v2.
La actualización de Aurora Serverless v1 en Aurora Serverless v2 implica crear un clúster aprovisionado como paso intermedio. A continuación, debe realizar los mismos pasos de actualización que cuando comienza con un clúster aprovisionado.
### Rutas de actualización para clústeres compatibles con MySQL para usar Aurora Serverless v2
Si el clúster original ejecuta Aurora MySQL, elija el procedimiento adecuado según la versión del motor y el modo de motor de su clúster.
| Si su clúster original de Aurora MySQL es este | Haga esto para pasar a Aurora Serverless v2 |
| --- | --- |
| Clúster aprovisionado que ejecuta Aurora MySQL versión 3 compatible con MySQL 8.0 | Esta es la etapa final de todas las conversiones de los clústeres de Aurora MySQL existentes. Si es necesario, realice una actualización de la versión menor a la versión 3.02.0 o superior. Utilice una instancia de base de datos aprovisionada para la instancia de base de datos de escritor. Añada una instancia de base de datos de lector de Aurora Serverless v2. Realice una conmutación por error para convertirla en la instancia de base de datos de escritor. (Opcional) Convierta otras instancias de base de datos aprovisionadas en el clúster en Aurora Serverless v2. O añada nuevas instancias de base de datos de Aurora Serverless v2 y elimine las instancias de base de datos aprovisionadas. Para ver el procedimiento completo y ejemplos, consulte [Cambiar de un clúster aprovisionado a Aurora Serverless v2](#aurora-serverless-v2.switch-from-provisioned). |
| Clúster aprovisionado que ejecuta Aurora MySQL versión 2 compatible con MySQL 5.7 | Realice una actualización de la versión principal a Aurora MySQL versión 3.02.0 o posterior. A continuación, siga el procedimiento para Aurora MySQL versión 3 para cambiar el clúster para que utilice instancias de base de datos de Aurora Serverless v2. |
| Aurora Serverless v1Clúster de que ejecuta Aurora MySQL versión 2, compatible con MySQL 5.7 | Para ayudar a planificar la conversión de Aurora Serverless v1, consulte [Comparación de Aurora Serverless v2 y Aurora Serverless v1](#aurora-serverless.comparison) primero. A continuación, siga el procedimiento indicado en [Actualización de un clúster de Aurora Serverless v1 a Aurora Serverless v2](#aurora-serverless-v2.upgrade-from-serverless-v1-procedure). |
### Rutas de actualización para clústeres compatibles con PostgreSQL para usar Aurora Serverless v2
Si el clúster original ejecuta Aurora PostgreSQL, elija el procedimiento adecuado según la versión del motor y el modo de motor del clúster.
| Si el clúster original de Aurora PostgreSQL es este | Haga esto para cambiar a Aurora Serverless v2 |
| --- | --- |
| Clúster aprovisionado que ejecuta Aurora PostgreSQL versión 13 | Esta es la etapa final de todas las conversiones de los clústeres existentes de Aurora PostgreSQL. Si es necesario, realice una actualización de la versión secundaria a la versión 13.6 o superior. Agregue una instancia de base de datos aprovisionada para la instancia de base de datos de escritor. Añada una instancia de base de datos de lector de Aurora Serverless v2. Lleve a cabo una conmutación por error para hacer que esa instancia de Aurora Serverless v2 sea la instancia de base de datos de escritor. (Opcional) Convierta otras instancias de base de datos aprovisionadas en el clúster en Aurora Serverless v2. O añada nuevas instancias de base de datos de Aurora Serverless v2 y elimine las instancias de base de datos aprovisionadas. Para ver el procedimiento completo y ejemplos, consulte [Cambiar de un clúster aprovisionado a Aurora Serverless v2](#aurora-serverless-v2.switch-from-provisioned). |
| Clúster aprovisionado que ejecuta la versión 11 o 12 de Aurora PostgreSQL | Realice una actualización de la versión principal a Aurora PostgreSQL versión 13.6 o posterior. A continuación, siga el procedimiento para Aurora PostgreSQL versión 13 para cambiar el clúster para que use instancias de base de datos de Aurora Serverless v2. |
| Clúster de Aurora Serverless v1 que ejecuta Aurora PostgreSQL versión 11 o 13 | Para ayudar a planificar la conversión de Aurora Serverless v1, consulte [Comparación de Aurora Serverless v2 y Aurora Serverless v1](#aurora-serverless.comparison) primero. A continuación, siga el procedimiento indicado en [Actualización de un clúster de Aurora Serverless v1 a Aurora Serverless v2](#aurora-serverless-v2.upgrade-from-serverless-v1-procedure). |
## Cambiar de un clúster aprovisionado a Aurora Serverless v2
Para cambiar un clúster aprovisionado para que utilice Aurora Serverless v2, siga estos pasos:
1. Compruebe si es necesario actualizar el clúster aprovisionado para utilizarlo con instancias de base de datos de Aurora Serverless v2. Para las versiones de Aurora compatibles con Aurora Serverless v2, consulte [Requisitos y limitaciones para Aurora Serverless v2](aurora-serverless-v2.requirements.md).
Si el clúster aprovisionado ejecuta una versión de motor que no está disponible para Aurora Serverless v2, actualice la versión del motor del clúster:
+ Si tiene un clúster aprovisionado compatible con MySQL 5.7, siga las instrucciones de actualización para Aurora MySQL versión 3. Utilice el procedimiento de [Pasos para realizar una actualización local](AuroraMySQL.Upgrading.Procedure.md).
+ Si tiene un clúster aprovisionado compatible con PostgreSQL que ejecuta PostgreSQL versiones 11 o 12, siga las instrucciones de actualización de Aurora PostgreSQL versión 13. Utilice el procedimiento de [Actualización a una versión principal](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
1. Configure cualquier otra propiedad del clúster para que coincida con los requisitos de Aurora Serverless v2 de [Requisitos y limitaciones para Aurora Serverless v2](aurora-serverless-v2.requirements.md).
1. Defina la configuración de escalado del clúster. Siga el procedimiento indicado en [Configuración del rango de capacidad de Aurora Serverless v2 para un clúster](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus).
1. Añada una o varias instancias de bases de datos de Aurora Serverless v2 al clúster. Siga el procedimiento general de [Adición de réplicas de Aurora a un clúster de base de datos](aurora-replicas-adding.md). Para cada nueva instancia de base de datos, especifique el nombre de clase de instancia de base de datos **Sin servidor** en la Consola de administración de AWS, o bien `db.serverless` en la AWS CLI o la API de Amazon RDS.
En algunos casos, es posible que ya tenga una o más instancias de base de datos de lector aprovisionadas en el clúster. De ser así, puede convertir uno de los lectores en una instancia de base de datos de Aurora Serverless v2, en lugar de crear una nueva instancia de base de datos. Para ello, siga el procedimiento en [Conversión de un escritor o un lector aprovisionados a Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned).
1. Realice una operación de conmutación por error para hacer que una de las instancias de base de datos de Aurora Serverless v2 sea la instancia de base de datos de escritor del clúster.
1. (Opcional) Convierta las instancias de base de datos aprovisionadas en Aurora Serverless v2 o elimínelas del clúster. Siga el procedimiento general de [Conversión de un escritor o un lector aprovisionados a Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned) o [Eliminación de una instancia de base de datos de un clúster de base de datos de Aurora](USER_DeleteCluster.md#USER_DeleteInstance).
**sugerencia**
Eliminar las instancias de base de datos aprovisionadas no es obligatorio. Puede configurar un clúster que contenga tanto Aurora Serverless v2 como instancias de base de datos aprovisionadas. Sin embargo, hasta que conozca bien las características de rendimiento y escalado de las instancias de base de datos de Aurora Serverless v2, le recomendamos que configure los clústeres con instancias de base de datos del mismo tipo.
Los siguientes ejemplos de la AWS CLI muestran el proceso de conmutación utilizando un clúster aprovisionado que ejecuta Aurora MySQL versión 3.02.0. El clúster se denomina `mysql-80`. El clúster comienza con dos instancias de base de datos aprovisionadas llamadas `provisioned-instance-1` y `provisioned-instance-2`, escritor y lector. Ambos usan la clase instancia de base de datos de `db.r6g.large`.
```
$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
--query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' --output text
mysql-80
provisioned-instance-2 False
provisioned-instance-1 True
$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-1 \
--output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-1 db.r6g.large
$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-2 \
--output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-2 db.r6g.large
```
Creamos una tabla con algunos datos. De esta forma podemos confirmar que los datos y el funcionamiento del clúster son los mismos antes y después de la conmutación.
```
mysql> create database serverless_v2_demo;
mysql> create table serverless_v2_demo.demo (s varchar(128));
mysql> insert into serverless_v2_demo.demo values ('This cluster started with a provisioned writer.');
Query OK, 1 row affected (0.02 sec)
```
En primer lugar, añadimos un rango de capacidad al clúster. De no hacerlo, se producirá un error al añadir cualquier instancia de base de datos de Aurora Serverless v2 al clúster. Si usamos la Consola de administración de AWS para este procedimiento, ese paso es automático cuando añadimos la primera instancia de base de datos de Aurora Serverless v2.
```
$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 \
--db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
An error occurred (InvalidDBClusterStateFault) when calling the CreateDBInstance operation:
Set the Serverless v2 scaling configuration on the parent DB cluster before creating a Serverless v2 DB instance.
$ # The blank ServerlessV2ScalingConfiguration attribute confirms that the cluster doesn't have a capacity range set yet.
$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 --query 'DBClusters[*].ServerlessV2ScalingConfiguration'
[]
$ aws rds modify-db-cluster --db-cluster-identifier mysql-80 \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16
{
"DBClusterIdentifier": "mysql-80",
"ServerlessV2ScalingConfiguration": {
"MinCapacity": 0.5,
"MaxCapacity": 16
}
}
```
Creamos dos lectores de Aurora Serverless v2 que sustituyen a las instancias de base de datos originales. Para ello, especificamos la clase de instancia de base de datos `db.serverless` para las nuevas instancias de base de datos.
```
$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
"DBInstanceIdentifier": "serverless-v2-instance-1",
"DBClusterIdentifier": "mysql-80",
"DBInstanceClass": "db.serverless",
"DBInstanceStatus": "creating"
}
$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-2 \
--db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
"DBInstanceIdentifier": "serverless-v2-instance-2",
"DBClusterIdentifier": "mysql-80",
"DBInstanceClass": "db.serverless",
"DBInstanceStatus": "creating"
}
$ # Wait for both DB instances to finish being created before proceeding.
$ aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1 && \
aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-2
```
Realizamos una conmutación por error para que una de las instancias de base de datos de Aurora Serverless v2 sea el nuevo escritor del clúster.
```
$ aws rds failover-db-cluster --db-cluster-identifier mysql-80 \
--target-db-instance-identifier serverless-v2-instance-1
{
"DBClusterIdentifier": "mysql-80",
"DBClusterMembers": [
{
"DBInstanceIdentifier": "serverless-v2-instance-1",
"IsClusterWriter": false,
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1
},
{
"DBInstanceIdentifier": "serverless-v2-instance-2",
"IsClusterWriter": false,
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1
},
{
"DBInstanceIdentifier": "provisioned-instance-2",
"IsClusterWriter": false,
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1
},
{
"DBInstanceIdentifier": "provisioned-instance-1",
"IsClusterWriter": true,
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1
}
],
"Status": "available"
}
```
Se necesitan unos segundos para que ese cambio surta efecto. En ese momento, tenemos un escritor de Aurora Serverless v2 y lector de Aurora Serverless v2. Por lo tanto, no necesitamos ninguna de las instancias de base de datos aprovisionadas originales.
```
$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
--query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
--output text
mysql-80
serverless-v2-instance-1 True
serverless-v2-instance-2 False
provisioned-instance-2 False
provisioned-instance-1 False
```
El último paso del procedimiento de conmutación es eliminar ambas instancias de base de datos aprovisionadas.
```
$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-2 --skip-final-snapshot
{
"DBInstanceIdentifier": "provisioned-instance-2",
"DBInstanceStatus": "deleting",
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.3.02.0",
"DBInstanceClass": "db.r6g.large"
}
$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-1 --skip-final-snapshot
{
"DBInstanceIdentifier": "provisioned-instance-1",
"DBInstanceStatus": "deleting",
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.3.02.0",
"DBInstanceClass": "db.r6g.large"
}
```
Como comprobación final, confirmamos que la tabla original es accesible y se puede escribir desde la instancia de base de datos de escritor de Aurora Serverless v2.
```
mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s |
+---------------------------------------------------+
| This cluster started with a provisioned writer. |
+---------------------------------------------------+
1 row in set (0.00 sec)
mysql> insert into serverless_v2_demo.demo values ('And it finished with a Serverless v2 writer.');
Query OK, 1 row affected (0.01 sec)
mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s |
+---------------------------------------------------+
| This cluster started with a provisioned writer. |
| And it finished with a Serverless v2 writer. |
+---------------------------------------------------+
2 rows in set (0.01 sec)
```
También nos conectamos a la instancia de base de datos de lector de Aurora Serverless v2 y confirmamos que los datos recién escritos también están disponibles ahí.
```
mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s |
+---------------------------------------------------+
| This cluster started with a provisioned writer. |
| And it finished with a Serverless v2 writer. |
+---------------------------------------------------+
2 rows in set (0.01 sec)
```
## Comparación de Aurora Serverless v2 y Aurora Serverless v1
Si ya está utilizando Aurora Serverless v1, puede conocer las principales diferencias entre Aurora Serverless v1 y Aurora Serverless v2. Las diferencias de arquitectura, como la compatibilidad con instancias de base de datos de lector, abren nuevos tipos de casos de uso.
Puede utilizar las siguientes tablas para comprender las diferencias más importantes que existen entre Aurora Serverless v2 y Aurora Serverless v1.
**Topics**
+ [Comparación de los requisitos de Aurora Serverless v2 y Aurora Serverless v1](#aurora-serverless.comparison-requirements)
+ [Comparación del escalado y la disponibilidad de Aurora Serverless v2 y Aurora Serverless v1](#aurora-serverless.comparison-scaling)
+ [Comparación de la compatibilidad de características de Aurora Serverless v2 y Aurora Serverless v1](#aurora-serverless.comparison-features)
+ [Adaptación casos de uso de Aurora Serverless v1 para Aurora Serverless v2](#aurora-serverless.comparison-approaches)
### Comparación de los requisitos de Aurora Serverless v2 y Aurora Serverless v1
En la siguiente tabla se resumen los diferentes requisitos para ejecutar la base de datos utilizando Aurora Serverless v2 o Aurora Serverless v1. Aurora Serverless v2 ofrece versiones posteriores de los motores de base de datos Aurora MySQL y Aurora PostgreSQL que Aurora Serverless v1.
| Característica | Aurora Serverless v2Requisito de | Aurora Serverless v1Requisito de |
| --- | --- | --- |
| Motores de base de datos | Aurora MySQL, Aurora PostgreSQL | Aurora MySQL, Aurora PostgreSQL |
| Versiones de Aurora MySQL compatibles | Consulte [Aurora Serverless v2 con Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.amy). | Consulte [Aurora Serverless v1 con Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.amy). |
| Versiones compatibles de Aurora PostgreSQL | Consulte [Aurora Serverless v2 con Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.apg). | Consulte [Aurora Serverless v1 con Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.apg). |
| Actualización de un clúster de base de datos | De manera similar a los clústeres de base de datos aprovisionados, puede realizar las actualizaciones manualmente sin esperar a que Aurora actualice el clúster de base de datos automáticamente. Para obtener más información, consulte [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md). Para realizar una actualización de una versión principal de 13.x a 14.x o 15.x de un clúster de base de datos compatible con Aurora PostgreSQL, la capacidad máxima del clúster debe ser de al menos 2 ACU. | Las actualizaciones de versiones secundarias se aplican automáticamente a medida que están disponibles. Para obtener más información, consulte [Aurora Serverless v1 y versiones del motor de base de datos de Aurora](aurora-serverless.relnotes.md). Puede realizar las actualizaciones de la versión principal manualmente. Para obtener más información, consulte [Modificación de un clúster de bases de datos de Aurora Serverless v1](aurora-serverless.modifying.md). |
| Conversión desde un clúster de base de datos aprovisionado | Puede usar uno de los métodos siguientes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.upgrade.html) | Restaure las instantáneas del clúster aprovisionado para crear un nuevo clúster de Aurora Serverless v1. |
| Conversión desde un clúster de Aurora Serverless v1 | Siga el procedimiento indicado en [Actualización de un clúster de Aurora Serverless v1 a Aurora Serverless v2](#aurora-serverless-v2.upgrade-from-serverless-v1-procedure). | No aplicable |
| Clases de instancias de base de datos disponibles | La clase de instancia de base de datos especial db.serverless. En la Consola de administración de AWS, está etiquetada como Sin servidor. | No aplicable. Aurora Serverless v1 usa el modo del motor serverless. |
| Puerto | Cualquier puerto compatible con MySQL o PostgreSQL | Solo el puerto MySQL o PostgreSQL predeterminado |
| ¿Se permite una dirección IP pública? | Sí | No |
| ¿Se requiere una VPC (Nube virtual privada)? | Sí | Sí. Cada clúster de Aurora Serverless v1 consume dos puntos de conexión de interfaz y balanceador de carga de puerta de enlace asignados a la VPC. |
### Comparación del escalado y la disponibilidad de Aurora Serverless v2 y Aurora Serverless v1
En la siguiente tabla se indican las diferencias de escalabilidad y disponibilidad de Aurora Serverless v2 y Aurora Serverless v1.
El escalado de Aurora Serverless v2 es más receptivo, más granular y menos disruptivo que el escalado de Aurora Serverless v1. Aurora Serverless v2 se puede escalar cambiando el tamaño de la instancia de base de datos y añadiendo más instancias de base de datos al clúster de base de datos. También se puede escalar añadiendo clústeres de otras Regiones de AWS a una base de datos global de Aurora. En cambio, Aurora Serverless v1 solo se escala aumentando o disminuyendo la capacidad del escritor. Todo la computación de un clúster de Aurora Serverless v1 se ejecuta en una única zona de disponibilidad y en una única Región de AWS.
| Característica de escalado y alta disponibilidad | Comportamiento de Aurora Serverless v2 | Comportamiento de Aurora Serverless v1 |
| --- | --- | --- |
| Unidades de capacidad mínima de Aurora (ACU) (Aurora MySQL) | 0,5 cuando el clúster se está ejecutando, 0 cuando el clúster está en pausa. | 1 cuando el clúster se está ejecutando, 0 cuando el clúster está en pausa. |
| ACU mínimas (Aurora PostgreSQL) | 0,5 cuando el clúster se está ejecutando, 0 cuando el clúster está en pausa. | 2 cuando el clúster se está ejecutando, 0 cuando el clúster está en pausa. |
| ACU máximas (Aurora MySQL) | 256 | 256 |
| ACU máximas (Aurora PostgreSQL) | 256 | 384 |
| Detención de un clúster | Puede detener e iniciar manualmente el clúster mediante [la misma característica de parada e inicio de clúster](aurora-cluster-stop-start.md) como clústeres aprovisionados. | El clúster se detiene automáticamente tras un tiempo de espera. Lleva algún tiempo hasta que está disponible cuando se reanuda la actividad. |
| Escalado de las instancias de base de datos | Escalado horizontal y vertical con un incremento mínimo de 0,5 ACU. | Escalado horizontal y vertical duplicando o reduciendo a la mitad las AUC. |
| Número de instancias de base de datos | Igual que un clúster aprovisionado: 1 instancia de base de datos de escritor, hasta 15 instancias de base de datos de lector. | 1 instancia de base de datos que gestiona lecturas y escrituras. |
| ¿El escalado puede ocurrir mientras se ejecutan las instrucciones SQL? | Sí. Aurora Serverless v2 no requiere esperar un punto de silencio. | No. Por ejemplo, el escalado espera a que se completen las transacciones de larga duración, las tablas temporales y los bloqueos de tablas. |
| Las instancias de base de datos de lector escalan junto con el escritor | Opcional | No aplicable |
| Almacenamiento máximo | 128 TiB | 128 TiB |
| Se conserva la caché de búfer al escalar | Sí. La memoria caché del búfer cambia de tamaño dinámicamente. | No. La caché de búfer se recalienta después de escalar. |
| Conmutación por error | Sí, igual que con los clústeres aprovisionados. | Solo el mejor esfuerzo, sujeto a la disponibilidad de capacidad. Más lento que en Aurora Serverless v2. |
| Capacidad Multi-AZ | Sí, igual que para los aprovisionados. Un clúster Multi-AZ requiere una instancia de base de datos de lector en una segunda zona de disponibilidad (AZ). Para un clúster Multi-AZ, Aurora realiza una conmutación por error Multi-AZ en caso de fallo de AZ. | Aurora Serverless v1Los clústeres de ejecutan toda su computación en una única zona de disponibilidad. La recuperación en caso de error de AZ es solo un esfuerzo óptimo y está sujeta a la disponibilidad de capacidad. |
| Bases de datos globales de Aurora | Sí | No |
| Escalado basado en la presión de memoria | Sí | No |
| Escalado basado en la carga de la CPU | Sí | Sí |
| Escalado basado en el tráfico de red | Sí, según la sobrecarga de memoria y CPU del tráfico de red. El parámetro max\$1connections se mantiene constante para evitar que se caigan las conexiones al reducir la escala. | Sí, según el número de conexiones. |
| Acción de tiempo de espera para escalar eventos | No | Sí |
| Agregar nuevas instancias de base de datos al clúster mediante AWS Auto Scaling | No se usa. Puede crear instancias de base de datos de lector de Aurora Serverless v2 en los niveles de promoción 2 a 15 y dejarlas reducidas a una capacidad baja. | No. No hay instancias de base de datos de lector disponibles. |
### Comparación de la compatibilidad de características de Aurora Serverless v2 y Aurora Serverless v1
Se resumen en la tabla siguiente:
+ Características que están disponibles en Aurora Serverless v2 pero no en Aurora Serverless v1
+ Características que funcionan de forma diferente en Aurora Serverless v1 y en Aurora Serverless v2
+ Características que no están disponibles actualmente en Aurora Serverless v2
Aurora Serverless v2 incluye muchas características de clústeres aprovisionados que no están disponibles en Aurora Serverless v1.
| Característica | Aurora Serverless v2Compatibilidad con | Aurora Serverless v1Compatibilidad con |
| --- | --- | --- |
| Topología de clúster | Aurora Serverless v2 es una propiedad de instancias de base de datos individuales. Un clúster puede contener varias instancias de base de datos de Aurora Serverless v2 o una combinación de Aurora Serverless v2 y de instancias de base de datos aprovisionadas. | Aurora Serverless v1Los clústeres de no utilizan la noción de instancias de base de datos. Una vez creado el clúster, no se puede cambiar la propiedad de Aurora Serverless v1. |
| Parámetros de configuración | Prácticamente se pueden modificar los mismos parámetros que en los clústeres aprovisionados. Para obtener más información, consulte [Trabajo con los grupos de parámetros para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.parameter-groups). | Solo se puede modificar un subconjunto de parámetros. |
| Grupos de parámetros | Grupo de parámetros de clúster y grupos de parámetros de base de datos. Están disponibles los parámetros con valor provisioned en el atributo SupportedEngineModes. Son muchos más parámetros que en Aurora Serverless v1. | Solo grupo de parámetros del clúster. Están disponibles los parámetros con el valor serverless en el atributo SupportedEngineModes. |
| Cifrado para volumen del clúster | Opcional | Obligatorio. Las limitaciones de [Limitaciones de los clústeres de base de datos cifrados de Amazon Aurora](Overview.Encryption.md#Overview.Encryption.Limitations) se aplican a todos los clústeres de Aurora Serverless v1. |
| Instantáneas entre regiones | Sí | La instantánea debe cifrarse con su propia clave AWS Key Management Service (AWS KMS). |
| Copias de seguridad automatizadas conservadas tras la eliminación del clúster de base de datos | Sí | No |
| TLS/SSL | Sí. La compatibilidad es la mismo que para los clústeres aprovisionados. Para obtener más información, consulte [Uso de TLS/SSL con Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2.tls). | Sí. Existen algunas diferencias con respecto a la compatibilidad TLS para clústeres aprovisionados. Para obtener más información, consulte [Uso de TLS/SSL con Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls). |
| Clonación | Solo desde y hacia las versiones del motor de base de datos compatibles con Aurora Serverless v2. No puede usar la clonación para actualizar de Aurora Serverless v1 o de una versión anterior de un clúster aprovisionado. | Solo desde y hacia las versiones del motor de base de datos compatibles con Aurora Serverless v1. |
| Integración con Amazon S3 | Sí | Sí |
| Integración con AWS Secrets Manager | Sí | No |
| Exportación de instantáneas del clúster de bases de datos a S3 | Sí | No |
| Asociación de un rol de IAM | Sí | No |
| Carga de registros de Amazon CloudWatch | Opcional. Usted elige qué registros activar y qué registros cargar en CloudWatch. | Todos los registros activados se cargan automáticamente en CloudWatch. |
| API de datos disponible | Sí | Sí |
| Publicador de consultas disponible | Sí | Sí |
| Información de rendimiento | Sí | No |
| Proxy de Amazon RDS disponible | Sí | No |
| Babelfish for Aurora PostgreSQL disponible | Sí. Compatible con las versiones de Aurora PostgreSQL que son compatibles con Babelfish y Aurora Serverless v2. | No |
### Adaptación casos de uso de Aurora Serverless v1 para Aurora Serverless v2
En función de su caso de uso para Aurora Serverless v1, podrá adaptar ese enfoque para aprovechar las características de Aurora Serverless v2 de la siguiente manera.
Supongamos que tiene un clúster de Aurora Serverless v1 que está ligeramente cargado y su prioridad es mantener la disponibilidad continua y minimizar los costes. Con Aurora Serverless v2, puede configurar una valor de ACU mínimo menor de 0,5, en comparación con un mínimo de 1 ACU para Aurora Serverless v1. Puede aumentar la disponibilidad creando una configuración Multi-AZ, ya que la instancia de base de datos del lector también tiene un mínimo de 0,5 ACU.
Supongamos que tiene un clúster de Aurora Serverless v1 que utiliza en un escenario de desarrollo y prueba. En este caso, el costo también es de alta prioridad, pero el clúster no necesita estar disponible en todo momento. Aurora Serverless v2 puede pausar automáticamente cada instancia cuando esté completamente inactiva. Para ello, especifique una capacidad mínima de 0 ACU para el clúster, como se explica en [Escalado a cero ACU con pausa y reanudación automáticas para Aurora Serverless v2](aurora-serverless-v2-auto-pause.md). Puede detener también manualmente el clúster cuando no sea necesario e iniciarlo cuando llegue el momento del próximo ciclo de prueba o desarrollo.
Supongamos que tiene un clúster de Aurora Serverless v1 con una carga de trabajo pesada. Se puede escalar un clúster equivalente mediante Aurora Serverless v2 con más granularidad. Por ejemplo, Aurora Serverless v1 escala duplicando la capacidad, por ejemplo, de 64 a 128 AUC. Por el contrario, la instancia de base de datos de Aurora Serverless v2 puede reducirse horizontalmente en incrementos de 0,5 ACU.
Supongamos que su carga de trabajo requiere una capacidad total superior a la disponible en Aurora Serverless v1. Puedes usar varias instancias de base de datos de lector de Aurora Serverless v2 para descargar las partes de lectura intensiva de la carga de trabajo de la instancia de base de datos de escritor. También puede dividir la carga de trabajo de lectura intensiva entre varias instancias de base de datos de lector.
Para una carga de trabajo de escritura intensiva, puede configurar el clúster con una instancia de base de datos aprovisionada de gran tamaño como escritor. Puede hacerlo junto con una o más instancias de base de datos de lector de Aurora Serverless v2.
## Actualización de un clúster de Aurora Serverless v1 a Aurora Serverless v2
**importante**
AWS ha [anunciado la fecha de fin de la vida útil de Aurora Serverless v1, que será el 31 de marzo de 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Todos los clústeres de Aurora Serverless v1 que no se migren antes del 31 de marzo de 2025 se migrarán a Aurora Serverless v2 durante el periodo de mantenimiento. Si se produce un error en la actualización, Amazon Aurora convierte el clúster sin servidor v1 en un clúster aprovisionado con la versión de motor equivalente durante el periodo de mantenimiento. Si procede, Amazon Aurora inscribirá el clúster aprovisionado convertido en soporte extendido de Amazon RDS. Para obtener más información, consulte [Soporte extendido de Amazon RDS con Amazon Aurora](extended-support.md).
El proceso de actualización de un clúster de base de datos de Aurora Serverless v1 a Aurora Serverless v2 tiene varios pasos. Esto se debe a que no se puede convertir directamente de Aurora Serverless v1 a Aurora Serverless v2. Siempre hay un paso intermedio que implica convertir el clúster de base de datos de Aurora Serverless v1 en un clúster aprovisionado.
### Clústeres de base de datos compatibles con Aurora MySQL
Puede convertir su clúster de base de datos de Aurora Serverless v1 en un clúster de base de datos aprovisionado y, a continuación, utilizar una implementación azul/verde para actualizarlo y convertirlo en un clúster de base de datos de Aurora Serverless v2. Recomendamos este procedimiento para los entornos de producción. Para obtener más información, consulte [Uso de las implementaciones azul/verde de Amazon Aurora para actualizar las bases de datos](blue-green-deployments.md).
**Para utilizar una implementación azul/verde para actualizar un clúster de Aurora Serverless v1 que ejecuta la versión 2 de Aurora MySQL (compatible con MySQL 5.7)**
1. Convierta el clúster de base de datos de Aurora Serverless v1 en un clúster aprovisionado de Aurora MySQL versión 2. Siga el procedimiento indicado en [Conversión de Aurora Serverless v1 a aprovisionada](aurora-serverless.modifying.md#aurora-serverless.modifying.convert).
1. Creación de una implementación azul/verde Siga el procedimiento indicado en [Creación de una implementación azul/verde en Amazon Aurora](blue-green-deployments-creating.md).
1. Elija una versión de Aurora MySQL para el clúster verde que sea compatible con Aurora Serverless v2, por ejemplo, la 3.04.1.
Para conocer las versiones compatibles, consulte [Aurora Serverless v2 con Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.amy).
1. Modifique la instancia de base de datos del escritor del clúster verde para que utilice la clase de instancia de base de datos de **Serverless v2** (db.serverless).
Para obtener más información, consulte [Conversión de un escritor o un lector aprovisionados a Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned).
1. Cuando su clúster de base de datos de Aurora Serverless v2 actualizado esté disponible, cambie del clúster azul al clúster verde.
### Clústeres de base de datos compatibles con Aurora PostgreSQL
Puede convertir su clúster de base de datos de Aurora Serverless v1 en un clúster de base de datos aprovisionado y, a continuación, utilizar una implementación azul/verde para actualizarlo y convertirlo en un clúster de base de datos de Aurora Serverless v2. Recomendamos este procedimiento para los entornos de producción. Para obtener más información, consulte [Uso de las implementaciones azul/verde de Amazon Aurora para actualizar las bases de datos](blue-green-deployments.md).
**Para utilizar una implementación azul/verde para actualizar un clúster de Aurora Serverless v1 que ejecute la versión 11 de Aurora PostgreSQL**
1. Convierta el clúster de base de datos de Aurora Serverless v1 en un clúster de Aurora PostgreSQL aprovisionado. Siga el procedimiento indicado en [Conversión de Aurora Serverless v1 a aprovisionada](aurora-serverless.modifying.md#aurora-serverless.modifying.convert).
1. Creación de una implementación azul/verde Siga el procedimiento indicado en [Creación de una implementación azul/verde en Amazon Aurora](blue-green-deployments-creating.md).
1. Elija una versión de Aurora PostgreSQL para el clúster verde que sea compatible con Aurora Serverless v2, por ejemplo, la 15.3.
Para conocer las versiones compatibles, consulte [Aurora Serverless v2 con Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.apg).
1. Modifique la instancia de base de datos del escritor del clúster verde para que utilice la clase de instancia de base de datos de **Serverless v2** (db.serverless).
Para obtener más información, consulte [Conversión de un escritor o un lector aprovisionados a Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned).
1. Cuando su clúster de base de datos de Aurora Serverless v2 actualizado esté disponible, cambie del clúster azul al clúster verde.
También puede actualizar el clúster de base de datos de Aurora Serverless v1 directamente desde la versión 11 de Aurora PostgreSQL a la versión 13, convertirlo en un clúster de base de datos aprovisionado y, a continuación, convertir el clúster aprovisionado en un clúster de base de datos de Aurora Serverless v2.
**Para actualizar y luego convertir un clúster de Aurora Serverless v1 que ejecute la versión 11 de Aurora PostgreSQL**
1. Convierta el clúster de base de datos de Aurora Serverless v1 en un clúster de Aurora PostgreSQL aprovisionado. Siga el procedimiento indicado en [Conversión de Aurora Serverless v1 a aprovisionada](aurora-serverless.modifying.md#aurora-serverless.modifying.convert).
1. Actualice el clúster de Aurora Serverless v1 a una versión 13 de Aurora PostgreSQL que sea compatible con Aurora Serverless v2, por ejemplo, la 13.12. Siga el procedimiento indicado en [Actualización de la versión principal](aurora-serverless.modifying.md#aurora-serverless.modifying.upgrade).
Para conocer las versiones compatibles, consulte [Aurora Serverless v2 con Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.apg).
1. Agregue una instancia de base de datos de lectura Aurora Serverless v2 al clúster. Para obtener más información, consulte [Adición de un lector Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-adding-reader).
1. Conmute por error a la instancia de base de datos de Aurora Serverless v2:
1. Seleccione la instancia de base de datos del escritor del clúster de base de datos.
1. En **Actions** (Acciones), elija **Failover** (conmutación por error).
1. En la página de confirmación, seleccione **Conmutación por error**.
Para los clústeres de base de datos de Aurora Serverless v1 que ejecuten Aurora PostgreSQL versión 13, debe convertir el clúster de Aurora Serverless v1 en un clúster de base de datos aprovisionado y, a continuación, convertir el clúster aprovisionado en un clúster de base de datos de Aurora Serverless v2.
**Para actualizar un clúster de Aurora Serverless v1 que ejecute la versión 13 de Aurora PostgreSQL**
1. Convierta el clúster de base de datos de Aurora Serverless v1 en un clúster de Aurora PostgreSQL aprovisionado. Siga el procedimiento indicado en [Conversión de Aurora Serverless v1 a aprovisionada](aurora-serverless.modifying.md#aurora-serverless.modifying.convert).
1. Agregue una instancia de base de datos de lectura Aurora Serverless v2 al clúster. Para obtener más información, consulte [Adición de un lector Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-adding-reader).
1. Conmute por error a la instancia de base de datos de Aurora Serverless v2:
1. Seleccione la instancia de base de datos del escritor del clúster de base de datos.
1. En **Actions** (Acciones), elija **Failover** (conmutación por error).
1. En la página de confirmación, seleccione **Conmutación por error**.
1. Elimine la instancia de lector.
## Migración de una base de datos en las instalaciones a Aurora Serverless v2
Puede migrar sus bases de datos en las instalaciones a Aurora Serverless v2, de igual modo que con Aurora MySQL y Aurora PostgreSQL.
+ Para las bases de datos MySQL, puede usar el comando `mysqldump`. Para obtener más información, consulte [Importación de datos a una base de datos de Amazon RDS para MySQL con tiempo de inactividad reducido](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html) en la *Guía del usuario de Amazon Relational Database Service*.
+ Para las bases de datos PostgreSQL, puede usar los comandos `pg_dump` y `pg_restore`. Para obtener más información, consulte la publicación del blog [Best practices for migrating PostgreSQL databases to Amazon RDS and Amazon Aurora](https://aws.amazon.com/blogs/database/best-practices-for-migrating-postgresql-databases-to-amazon-rds-and-amazon-aurora/) (Prácticas recomendadas para migrar bases de datos de PostgreSQL a Amazon RDS y Amazon Aurora).