Actualización a una versión principal

Las actualizaciones de versión principales podrían contener cambios realizados en la base de datos que no son compatibles con las versiones anteriores de la base de datos. La nueva funcionalidad de una nueva versión puede provocar que sus aplicaciones existentes dejen de funcionar correctamente. Para evitar problemas, Amazon Aurora no aplica automáticamente actualizaciones de versión principales. En su lugar, le recomendamos que planifique cuidadosamente la actualización de una versión principal mediante los siguientes pasos:

Puede obtener una lista de las versiones de motor disponibles como destinos de actualización de versiones principales para su clúster de base de datos de Aurora PostgreSQL mediante una consulta de su Región de AWS con el comando describe-db-engine-versions de la AWS CLI, como se indica a continuación.

Para Linux, macOS o:Unix

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version version-number \
  --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \
  --output text

En:Windows

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version version-number ^
  --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}" ^
  --output text

En algunos casos, la versión a la que desea actualizar no es un destino para la versión actual. En estos casos, utilice la información de la versions table para realizar actualizaciones de versión secundarias hasta que el clúster esté en una versión que tenga el destino elegido en su fila de destinos.

Prueba de la actualización del clúster de base de datos de producción a una nueva versión principal

Cada nueva versión principal incluye mejoras en el optimizador de consultas que se han diseñado para mejorar el rendimiento. Sin embargo, la carga de trabajo puede incluir consultas que den lugar a un plan que tiene un peor rendimiento en la nueva versión. Por eso le recomendamos que pruebe y revise el rendimiento antes de actualizar en producción. Puede administrar la estabilidad del plan de consultas en todas las versiones mediante la extensión Query Plan Management (QPM), como se detalla en Garantizar la estabilidad del plan después de una actualización a una versión principal.

Antes de actualizar los clústeres de base de datos de Aurora PostgreSQL de producción a una nueva versión principal, le recomendamos que pruebe la actualización para verificar que todas sus aplicaciones funcionan correctamente:

Recomendaciones posteriores a la actualización

Después de completar una actualización de versión principal, se recomienda lo siguiente:

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

Cuando inicia el proceso de actualización a una nueva versión principal, Aurora PostgreSQL toma una instantánea del clúster de base de datos de Aurora antes de realizar cualquier cambio en el clúster. Esta instantánea se crea solo para las actualizaciones de versión principales, no para las actualizaciones de versión secundarias. Cuando el proceso de actualización se complete, podrá encontrar esta instantánea entre las instantáneas manuales que aparecen en Snapshots (Instantáneas) en la consola de RDS. El nombre de la instantánea incluye preupgrade como prefijo el nombre de su clúster de base de datos de Aurora PostgreSQL, la versión de origen, la versión de destino y la fecha y la marca de tiempo, como se muestra en el siguiente ejemplo.

preupgrade-docs-lab-apg-global-db-12-8-to-13-6-2022-05-19-00-19

Una vez completada la actualización, puede utilizar la instantánea que Aurora creó y almacenó en su lista de instantáneas manuales para restaurar el clúster de base de datos a su versión anterior, si es necesario.

Durante el proceso de actualización de la versión principal, Aurora asigna un volumen y clona el clúster de base de datos de Aurora PostgreSQL de origen. Si se produce un error en la actualización por cualquier motivo, Aurora PostgreSQL utiliza el clon para revertir la actualización. Después de asignar más de 15 clones de un volumen de origen, los clones posteriores se convierten en copias completas y tardan más tiempo. Esto puede provocar que el proceso de actualización también sea más largo. Si Aurora PostgreSQL revierte la actualización, tenga en cuenta lo siguiente:

Para actualizar de forma segura las instancias de base de datos que componen su clúster, Aurora PostgreSQL usa la utilidad pg_upgrade. Una vez completada la actualización del escritor, cada instancia del lector experimenta una breve interrupción mientras se actualiza a la nueva versión principal. Para obtener más información sobre esta utilidad de PostgreSQL, consulte pg_upgrade en la documentación de PostgreSQL.

Puede actualizar el clúster de base de datos de Aurora PostgreSQL a una versión nueva mediante la AWS Management Console, la AWS CLI o la API de RDS.

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

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

Actualizaciones importantes para bases de datos globales

En el caso de un clúster de base de datos global de Aurora, el proceso de actualización se aplica a todos los clústeres de base de datos que componen su base de datos global de Aurora al mismo tiempo. Lo hace para asegurarse de que cada uno ejecuta la misma versión de Aurora PostgreSQL. También garantiza que cualquier cambio en las tablas del sistema, formatos de archivo de datos, etc., se replican automáticamente en todos los clústeres secundarios.

Para actualizar un clúster de base de datos global a una nueva versión principal de Aurora PostgreSQL, le recomendamos que pruebe las aplicaciones en la versión actualizada, como se detalla en Prueba de la actualización del clúster de base de datos de producción a una nueva versión principal. Asegúrese de preparar el grupo de parámetros de su clúster de base de datos y la configuración del grupo de parámetros de base de datos para cada Región de AWS en su base de datos global de Aurora antes de la actualización como se detalla en step 1. de Prueba de la actualización del clúster de base de datos de producción a una nueva versión principal.

Si el clúster de base de datos global de Aurora PostgreSQL tiene un objetivo de punto de recuperación (RPO) establecido para su parámetro rds.global_db_rpo, asegúrese de restablecer el parámetro antes de actualizar. El proceso de actualización de la versión principal no funciona si el RPO está activado. De forma predeterminada, este parámetro está desactivado. Para obtener más información sobre las bases de datos globales de Aurora PostgreSQL y RPO, consulte Administración de RPO para bases de datos globales basadas en Aurora PostgreSQL–.

Si verifica que sus aplicaciones pueden ejecutarse como se espera en la implementación de prueba de la nueva versión, puede iniciar el proceso de actualización. Para ello, consulte Actualización del motor de Aurora PostgreSQL a una nueva versión principal. Asegúrese de elegir el elemento de nivel superior de la lista Databases (Bases de datos) en la consola de RDS, Global database (Base de datos global), como se muestra en la siguiente imagen.

Como con cualquier modificación, puede confirmar que desea que el proceso continúe cuando se le solicite.

En lugar de utilizar la consola, puede iniciar el proceso de actualización mediante la AWS CLI o la API de RDS. Al igual que con la consola, se opera en el clúster de base de datos global de Aurora en lugar de hacerlo en cualquiera de sus componentes, como se indica a continuación: