Actualización a una versión secundaria

Puede utilizar los métodos siguientes para actualizar la versión secundaria de un clúster de bases de datos o para aplicar parches a un clúster de bases de datos:

Antes de realizar una actualización de versión secundaria

Le recomendamos que lleve a cabo las siguientes acciones para reducir el tiempo de inactividad durante una actualización de versión secundaria:

• El mantenimiento del clúster de base de datos Aurora debe realizarse durante un periodo de poco tráfico. Utilice Performance Insights para identificar estos periodos de tiempo y configurar correctamente los plazos de mantenimiento. Para obtener más información sobre Performance Insights, consulte Monitoreo de la carga de base de datos con Performance Insights en Amazon RDS. Para obtener más información sobre los periodos de mantenimiento de clústeres de base de datos, consulte Ajuste de la ventana de mantenimiento preferida para un clúster de base de datos.

• Utilice los SDK de AWS que admitan fluctuaciones y retrocesos exponenciales como procedimiento recomendado. Para obtener más información, consulte Exponential Backoff And Jitter.

Cómo realizar actualizaciones de versión secundarias y aplicar revisiones

Las actualizaciones y revisiones de versión secundarias estarán disponibles en Regiones de AWS solo después de rigurosas pruebas. Antes de lanzar actualizaciones y parches, Aurora PostgreSQL realiza pruebas para asegurarse de que los problemas de seguridad conocidos, los errores y otros problemas que surgen después del lanzamiento de la versión secundaria de la comunidad no perturben la estabilidad general de la flota de Aurora PostgreSQL.

A medida que Aurora PostgreSQL hace que las nuevas versiones secundarias estén disponibles, las instancias que componen su clúster de base de datos de Aurora PostgreSQL se pueden actualizar automáticamente durante su periodo de mantenimiento especificado. Para que esto ocurra, el clúster de base de datos de Aurora PostgreSQL debe tener activada la opción Enable auto minor version upgrade (Habilitar la actualización automática de versiones secundarias). Todas las instancias de base de datos que componen su clúster de base de datos de Aurora PostgreSQL deben tener activada la opción de actualización automática de versiones secundarias (AmVU) para que la actualización de versiones secundarias se aplique en todo el clúster.

sugerencia

Asegúrese de que la opción Enable auto minor version upgrade (Habilitar la actualización automática de versiones secundarias) está activada para todas las instancias de base de datos de PostgreSQL que componen su clúster de base de datos de Aurora PostgreSQL. Esta opción debe estar activada para que funcionen todas las instancias del clúster de base de datos. Para obtener información sobre cómo configurar la actualización automática de versiones secundarias y cómo funciona la configuración cuando se aplica a los niveles de clúster e instancia, consulte Actualizaciones de versiones secundarias automáticas para clústeres de base de datos de Aurora.

Puede consultar el valor de la opción Enable auto minor version upgrade (Activar la actualización automática de versiones secundarias) para todos sus clústeres de base de datos de Aurora PostgreSQL mediante el comando describe-db-instances de la AWS CLI con la siguiente consulta.

aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

Esta consulta devuelve una lista de todos los clústeres de base de datos de Aurora y sus instancias con un valor true o false para el estado de la configuración AutoMinorVersionUpgrade. En el comando que se muestra, se supone que tiene configurada la AWS CLI para dirigirse a Región de AWS predeterminada.

Para obtener más información sobre la opción AmVU y cómo modificar el clúster de base de datos de Aurora para utilizarla, consulte Actualizaciones de versiones secundarias automáticas para clústeres de base de datos de Aurora.

Puede actualizar sus clústeres de base de datos de Aurora PostgreSQL a nuevas versiones secundarias, ya sea mediante la respuesta a las tareas de mantenimiento o la modificación del clúster para utilizar la nueva versión.

Puede identificar cualquier actualización o revisión disponible para sus clústeres de base de datos de Aurora PostgreSQL si utiliza la consola de RDS y abre el menú Recommendations (Recomendaciones). Encontrará una lista de varios problemas de mantenimiento, como Old minor versions (Versiones secundarias anteriores). Según su entorno de producción, puede elegir entre programar la actualización o tomar medidas inmediatas, mediante de la elección de Apply now (Aplicar ahora), como se muestra a continuación.

Para obtener más información sobre cómo mantener un clúster de base de datos de Aurora, incluida la forma de aplicar revisiones y actualizaciones de versión secundarias de forma manual, consulte Mantenimiento de un clúster de base de datos de Amazon Aurora.

Actualizaciones de versión secundarias y aplicación de revisiones sin tiempo de inactividad

La actualización de un clúster de base de datos de Aurora PostgreSQL conlleva la posibilidad de una interrupción. Durante el proceso de actualización, la base de datos se cierra mientras se actualiza. Si comienza la actualización cuando la base de datos está ocupada, perderá todas las conexiones y transacciones que el clúster de base de datos tiene en proceso. Si espera hasta que la base de datos esté inactiva para realizar la actualización, es posible que tenga que esperar mucho tiempo.

La característica de aplicación de revisiones sin tiempo de inactividad (ZDP) mejora el proceso de actualización. Con ZDP, tanto las actualizaciones de versión secundarias como las revisiones pueden aplicarse con un impacto mínimo en el clúster de base de datos de Aurora PostgreSQL. Se utiliza la ZDP al aplicar parches o actualizaciones de versiones secundarias más recientes a las versiones de Aurora PostgreSQL y otras versiones posteriores de estas versiones secundarias y versiones principales más recientes. Es decir, la actualización a nuevas versiones secundarias desde cualquiera de estas versiones en adelante utiliza ZDP.

La siguiente tabla muestra las versiones de Aurora PostgreSQL y las clases de instancia de base de datos donde está disponible ZDP:

Versión	Clases de instancia db.r*	Clases de instancia db.t*	Clases de instancia db.r*	Clases de instancia db.serverless
Versión 10.21.0 y versiones posteriores a la 10.21	Sí	Sí	Sí	N/A
Versión 11.16.0 y versiones posteriores a la 11.16	Sí	Sí	Sí	N/A
Versión 11.17 y posteriores	Sí	Sí	Sí	N/A
Versión 12.11.0 y versiones posteriores a la 12.11	Sí	Sí	Sí	N/A
Versión 12.12 y posteriores	Sí	Sí	Sí	N/A
Versión 13.7.0 y versiones posteriores a la 13.7	Sí	Sí	Sí	N/A
Versión 13.8 y posteriores	Sí	Sí	Sí	Sí
Versión 14.3.1 y versiones posteriores a la 14.3	Sí	Sí	Sí	N/A
Versión 14.4.0 y versiones posteriores a la 14.4	Sí	Sí	Sí	N/A
Versión 14.5 y posteriores	Sí	Sí	Sí	Sí
Versión 15.3 y posteriores	Sí	Sí	Sí	Sí

La ZDP funciona preservando las conexiones de cliente actuales a su clúster de base de datos de Aurora PostgreSQL durante todo el proceso de actualización de Aurora PostgreSQL. Sin embargo, en los siguientes casos, las conexiones se interrumpen para que la ZDP se complete:

• Hay en curso consultas o transacciones de ejecución prolongada.

• Hay instrucciones en lenguaje de definición de datos (DDL) en ejecución.

• Se están utilizando tablas temporales o bloqueos de tabla.

• Todas las sesiones escuchan en los canales de notificación.

• Se está utilizando un cursor en estado “WITH HOLD”.

• Las conexiones TLSv1.3 o TLSv1.1 están en uso.

Durante el proceso de actualización con ZDP, el motor de base de datos busca un punto silencioso para pausar todas las transacciones nuevas. Esta acción protege la base de datos durante las revisiones y las actualizaciones. Para garantizar que las aplicaciones se ejecuten sin problemas con las transacciones pausadas, recomendamos integrar la lógica de reintento en el código. Este enfoque garantiza que el sistema pueda gestionar cualquier breve tiempo de inactividad sin errores y pueda volver a intentar las nuevas transacciones después de la actualización.

Cuando la ZDP se completa correctamente, las sesiones de la aplicación se conservan, excepto las sesiones de conexiones interrumpidas, y el motor de base de datos se reinicia mientras la actualización está en curso. Aunque el reinicio del motor de base de datos puede provocar una bajada temporal del rendimiento, esta suele durar solo unos segundos o, como mucho, un minuto aproximadamente.

En algunos casos, la aplicación de revisiones sin tiempo de inactividad (ZDP) podría no realizarse correctamente. Por ejemplo, los cambios de parámetros que tienen un estado pending en su clúster de base de datos de Aurora PostgreSQL o en sus instancias también interfieren con la ZDP.

Puede encontrar métricas y eventos para las operaciones de la ZDP en la página Events (Eventos) de la consola. Los eventos incluyen el inicio de la actualización de la ZDP y la finalización de dicha actualización. En este evento puede encontrar el tiempo que duró el proceso y el número de conexiones conservadas e interrumpidas que se produjeron durante el reinicio. Puede encontrar detalles en el registro de errores de la base de datos.

Actualización del motor de Aurora PostgreSQL a una nueva versión secundaria

Puede actualizar el clúster de base de datos de Aurora PostgreSQL a una versión secundaria nueva mediante la consola, la AWS CLI o la API de RDS. Antes de realizar la actualización, recomendamos que siga las mismas prácticas recomendadas que para las actualizaciones de versión. Igual que con las nuevas versiones principales, las nuevas versiones secundarias también pueden incluir mejoras del optimizador, como correcciones, que pueden provocar regresiones en el plan de consultas. Para garantizar la estabilidad del plan, recomendamos que utilice la extensión Query Plan Management (QPM), tal como se detalla en Garantizar la estabilidad del plan después de una actualización a una versión principal.

Consola

Para actualizar la versión del motor del clúster de base de datos de Aurora PostgreSQL

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

2. En el panel de navegación, elija Databases (Bases de datos) y, a continuación, elija el clúster de base de datos que desea actualizar.

3. Elija Modify (Modificar). Aparece la página Modify DB clúster (Modificar clúster de base de datos).

4. En Engine version (Versión del motor), elija la nueva versión.

5. Elija Continue (Continuar) y consulte el resumen de las modificaciones.

6. Para aplicar los cambios inmediatamente, elija Apply immediately. Si se selecciona esta opción, puede producirse una interrupción en algunos casos. Para obtener más información, consulte Modificación de un clúster de base de datos de Amazon Aurora.

7. En la página de confirmación, revise los cambios. Si son correctos, elija Modify clúster (Modificar clúster) para guardarlos.

   O bien, elija Back (Atrás) para editar los cambios o Cancel (Cancelar) para cancelarlos.

AWS CLI

Para actualizar la versión del motor de un clúster de base de datos, utilice el comando modify-db-clúster de la AWS CLI con los siguientes parámetros:

• --db-cluster-identifier: nombre del clúster de base de datos de Aurora PostgreSQL.

• --engine-version: número de versión del motor de base de datos al que se va a actualizar. Para obtener información sobre versiones de motores válidas, utilice el comando describe-db-engine-versions de la AWS CLI.

• --no-apply-immediately: aplicar los cambios en el siguiente periodo de mantenimiento. Para aplicar los cambios inmediatamente, use --apply-immediately en su lugar.

Para Linux, macOS o:Unix

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --engine-version new_version \
    --no-apply-immediately

En:Windows

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --engine-version new_version ^
    --no-apply-immediately

API de RDS

Para actualizar la versión del motor de un clúster de base de datos, utilice la operación ModifyDBclúster. Especifique los siguientes parámetros:

• DBClusterIdentifier: nombre del clúster de base de datos, por ejemplo, mydbcluster.

• EngineVersion: número de versión del motor de base de datos al que se va a actualizar. Para obtener información sobre versiones de motores válidas, utilice la operación DescribeDBEngineVersions.

• ApplyImmediately: indica si se deben aplicar los cambios inmediatamente o en el siguiente periodo de mantenimiento. Para aplicar los cambios inmediatamente, establezca el valor en true. Para aplicar los cambios en el siguiente periodo de mantenimiento, establezca el valor en false.