Actualización del motor de base de datos de PostgreSQL para Aurora PostgreSQL - Amazon Aurora

Actualización del motor de base de datos de PostgreSQL para Aurora PostgreSQL

Amazon Aurora hace que estén disponibles en Regiones de AWS las nuevas versiones del motor de base de datos PostgreSQL solo después de realizar pruebas exhaustivas. Puede actualizar los clústeres de base de datos de Aurora PostgreSQL a la nueva versión cuando esté disponible en su región.

Según la versión de Aurora PostgreSQL que el clúster de base de datos esté ejecutando actualmente, una actualización a la nueva versión es una actualización secundaria o principal. Por ejemplo, actualizar un clúster de base de datos de Aurora PostgreSQL 11.15 a Aurora PostgreSQL 13.6 es una actualización de versión principal. La actualización de un clúster de base de datos de Aurora PostgreSQL 13.3 a Aurora PostgreSQL 13.7 es una actualización de versión secundaria. En los temas siguientes, encontrará información sobre cómo realizar ambos tipos de actualizaciones.

Información general de los procesos de actualización de Aurora PostgreSQL

Las diferencias entre las actualizaciones de versión principales y secundarias son las siguientes:

Actualizaciones y revisiones de versión secundarias

Las actualizaciones y revisiones de versiones secundarias incluyen solo los cambios que son compatibles con las aplicaciones existentes. Las actualizaciones y revisiones de versión secundarias estarán disponibles solo después de que Aurora PostgreSQL las pruebe y apruebe.

Aurora puede aplicar automáticamente las actualizaciones de versión secundarias. Cuando crea un nuevo clúster de base de datos Aurora PostgreSQL, la opción Enable minor version upgrade (Habilitar la actualización de la versión menor) está preseleccionada. A menos que desactive esta opción, las actualizaciones de versión secundarias se aplican automáticamente durante el período de mantenimiento programado. Para obtener más información sobre la opción de actualización automática de versión secundaria (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 .

Si la opción de actualización automática de versión secundaria no está establecida para el clúster de base de datos de Aurora PostgreSQL, Aurora PostgreSQL no se actualiza automáticamente a la nueva versión secundaria. En su lugar, cuando se publica una nueva versión secundaria en su Región de AWS y el clúster de base de datos de Aurora PostgreSQL ejecuta una versión secundaria anterior, Aurora le pide que efectúe la actualización. Para ello, agrega una recomendación a las tareas de mantenimiento del clúster.

Las revisiones no se consideran una actualización y no se aplican automáticamente. Aurora PostgreSQL le pide que aplique revisiones mediante la incorporación de una recomendación a las tareas de mantenimiento de su clúster de base de datos de Aurora PostgreSQL. Para obtener más información, consulte Cómo realizar actualizaciones de versión secundarias y aplicar revisiones .

nota

Las revisiones que resuelven problemas de seguridad u otros problemas críticos también se agregan como tareas de mantenimiento. No obstante, estas revisiones son necesarias. Asegúrese de aplicar revisiones de seguridad a su clúster de base de datos de Aurora PostgreSQL cuando estén disponibles en sus tareas de mantenimiento pendientes.

El proceso de actualización implica la posibilidad de que se produzcan breves interrupciones mientras se actualiza cada instancia del clúster a la nueva versión. No obstante, después de las versiones 14.3.3, 13.7.3, 12.11.3, 11.16.3, 10.21.3 de Aurora PostgreSQL y otras versiones posteriores de estas versiones secundarias y las versiones principales recientes, el proceso de actualización utiliza la característica de aplicación de revisiones sin tiempo de inactividad (ZDP). Esta característica minimiza las interrupciones y, en la mayoría de los casos, las elimina por completo. Para obtener más información, consulte Actualizaciones de versión secundarias y aplicación de revisiones sin tiempo de inactividad .

nota

La ZDP no es compatible con los clústeres de base de datos de Aurora PostgreSQL que están configurados como Aurora Serverless v2, Aurora Serverless v1, bases de datos globales de Aurora o Babelfish.

Actualizaciones de la versión principal

A diferencia de lo que ocurre con las actualizaciones de versión secundarias y las revisiones, Aurora PostgreSQL no dispone de una opción de actualización automática de la versión principal. Las nuevas versiones principales de PostgreSQL pueden contener cambios en la base de datos que no sean compatibles con las aplicaciones existentes. La nueva funcionalidad puede provocar que sus aplicaciones existentes dejen de funcionar correctamente.

Para evitar problemas, le recomendamos que siga el proceso descrito en Antes de actualizar el clúster de base de datos de producción a una nueva versión principal antes de actualizar las instancias de base de datos en sus clústeres de Aurora PostgreSQL. En primer lugar, asegúrese de que las aplicaciones pueden ejecutarse en la nueva versión con ese procedimiento. Después, puede actualizar manualmente el clúster de base de datos de Aurora PostgreSQL a la nueva versión.

El proceso de actualización implica la posibilidad de que se produzcan breves interrupciones mientras se actualiza cada instancia del clúster a la nueva versión. El proceso de planificación preliminar también lleva tiempo. Le recomendamos que realice siempre las tareas de actualización durante el período de mantenimiento del clúster o cuando las operaciones sean mínimas. Para obtener más información, consulte Cómo realizar una actualización de versión principal .

nota

Tanto las actualizaciones de versión secundarias como las actualizaciones de versión principales podrían conllevar interrupciones breves. Por este motivo, le recomendamos que realice o programe actualizaciones durante el período de mantenimiento o durante otros períodos de poca utilización.

Cómo realizar una actualización de 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:

  1. Elija la versión principal que desee de la lista de objetivos disponibles de los mostrados para su versión en la tabla. Puede obtener una lista precisa de las versiones disponibles en su Región de AWS correspondientes a la versión actual mediante la AWS CLI. Para obtener más información, consulte Obtención de una lista de versiones disponibles en su Región de AWS.

  2. Compruebe que las aplicaciones funcionan según lo esperado en una implementación de prueba de la nueva versión. Para obtener información sobre el proceso completo, consulte Antes de actualizar el clúster de base de datos de producción a una nueva versión principal.

  3. Después de comprobar que las aplicaciones funcionan según lo previsto en la implementación de prueba, puede actualizar el clúster. Para obtener más información, consulte Actualización del motor de Aurora PostgreSQL a una nueva versión principal.

nota

En la actualidad, no se puede actualizar un clúster de base de datos de Aurora PostgreSQL que ejecuta Babelfish a una nueva versión principal.

En la tabla, puede encontrar las actualizaciones de versión principales que están disponibles para varias versiones de base de datos de Aurora PostgreSQL.

Para cualquier versión que esté considerando, compruebe siempre la disponibilidad de la clase de instancia de base de datos del clúster. Para obtener más información sobre las clases de instancias de bases de datos, incluidas las basadas en Graviton2 y las basadas en Intel, consulte Clases de instancia de base de datos Aurora .

Obtención de una lista de versiones disponibles en su Región de AWS

Puede obtener una lista de las versiones de motor disponibles como destinos de actualización para su base de datos Aurora PostgreSQL mediante una consulta de 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 12.10 \ --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \ --output text

Para Windows:

aws rds describe-db-engine-versions ^ --engine aurora-postgresql ^ --engine-version 12.10 ^ --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.

Antes de actualizar el 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:

  1. Tenga preparado un grupo de parámetros compatible con la versión.

    Si utiliza una instancia de base de datos personalizada o un grupo de parámetros de clúster de base de datos, puede elegir una de estas dos opciones:

    1. Especifique la instancia de base de datos predeterminada, el grupo de parámetros del clúster de base de datos o ambos para la nueva versión del motor de base de datos.

    2. Cree su propio grupo de parámetros personalizado para la nueva versión del motor de base de datos.

    Si asocia un nuevo grupo de parámetros de instancia de base de datos o clúster de base de datos como parte de la solicitud de actualización, asegúrese de reiniciar la base de datos una vez finalizada la actualización para aplicar los parámetros. Si una instancia de base de datos tiene que reiniciarse para aplicar los cambios del grupo de parámetros, el estado del grupo de parámetros de la instancia mostrará pending-reboot. Puede ver el estado del grupo de parámetros de una instancia en la consola o mediante un comando de la CLI como describe-db-instances o describe-db-clusters.

  2. Compruebe si hay algún uso no admitido:

    • Confirme o revierta todas las transacciones preparadas abiertas antes de intentar una actualización. Puede usar la siguiente consulta para comprobar que no haya transacciones preparadas abiertas en la instancia.

      SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
    • Elimine todos los usos de los tipos de datos reg* antes de intentar realizar una actualización. Salvo en el caso de regtype y regclass, no se puede actualizar los tipos de datos reg*. La utilidad pg_upgrade (que Amazon Aurora usa para realizar la actualización.) no puede hacer persistir este tipo de datos. Para obtener más información sobre esta utilidad, consulte pg_upgrade en la documentación de PostgreSQL.

      Para comprobar que no se usan tipos de datos reg* incompatibles, utilice la consulta siguiente en cada base de datos.

      SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a WHERE c.oid = a.attrelid AND NOT a.attisdropped AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype, 'pg_catalog.regprocedure'::pg_catalog.regtype, 'pg_catalog.regoper'::pg_catalog.regtype, 'pg_catalog.regoperator'::pg_catalog.regtype, 'pg_catalog.regconfig'::pg_catalog.regtype, 'pg_catalog.regdictionary'::pg_catalog.regtype) AND c.relnamespace = n.oid AND n.nspname NOT IN ('pg_catalog', 'information_schema');
    • Si va a actualizar un clúster de base de datos de Aurora PostgreSQL 10.18 o una versión posterior y tiene instalada la extensión pgRouting, elimínela antes de actualizar a la versión 12.4 o posterior.

  3. Elimine los slots de replicación lógica.

    El proceso de actualización no puede continuar si el clúster de base de datos de Aurora PostgreSQL utiliza slots de replicación lógica. Los slots de replicación lógica se utilizan habitualmente para tareas de migración de datos a corto plazo, como migrar datos con AWS DMS o replicar tablas de la base de datos en lagos de datos, las herramientas de inteligencia empresarial (BI) y otros destinos. Antes de actualizar, asegúrese de conocer el propósito de los slots de replicación lógica existentes y confirme que es correcto eliminarlos. Puede comprobar los slots de replicación lógica mediante la siguiente consulta:

    SELECT * FROM pg_replication_slots;

    Si los slots de replicación lógica se siguen utilizando, no debe eliminarlos y no puede continuar con la actualización. Sin embargo, si no se necesitan los slots de replicación lógica, puede eliminarlos con la siguiente SQL:

    SELECT pg_drop_replication_slot(slot_name);
  4. Realice una copia de seguridad.

    El proceso de actualización crea una instantánea del clúster de base de datos durante la actualización. Si también desea realizar una copia de seguridad manual antes del proceso de actualización, consulte Creación de una instantánea de clúster de base de datos para obtener más información.

  5. Actualice ciertas extensiones a la última versión disponible antes de realizar la actualización de la versión principal. Las extensiones que se van a actualizar incluyen las siguientes:

    • pgRouting

    • postgis_raster

    • postgis_tiger_geocoder

    • postgis_topology

    • address_standardizer

    • address_standardizer_data_us

    Ejecute el comando siguiente para cada extensión instalada actualmente.

    ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version'

    Para obtener más información, consulte Actualización de las extensiones de PostgreSQL . Para obtener más información acerca de la actualización de PostGIS, consulte Paso 6: actualice la extensión de PostGIS.

  6. Si va a actualizar a la versión 11.x, elimine las extensiones que no admita antes de realizar la actualización de la versión principal. Las extensiones que se van a eliminar incluyen:

    • chkpass

    • tsearch2

  7. Elimine los tipos de datos unknown, en función de la versión de destino.

    La versión 10 de PostgreSQL no admite el tipo de datos unknown. Si una base de datos de la versión 9.6 usa el tipo de datos unknown, una actualización a la versión 10 muestra un mensaje de error como el siguiente.

    Database instance is in a state that cannot be upgraded: PreUpgrade checks failed: The instance could not be upgraded because the 'unknown' data type is used in user tables. Please remove all usages of the 'unknown' data type and try again."

    Para encontrar el tipo de datos unknown en la base de datos y así poder eliminar dichas columnas o cambiarlas por tipos de datos compatibles, utilice el siguiente código SQL para cada base de datos.

    SELECT n.nspname, c.relname, a.attname FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a WHERE c.oid = a.attrelid AND NOT a.attisdropped AND a.atttypid = 'pg_catalog.unknown'::pg_catalog.regtype AND c.relkind IN ('r','m','c') AND c.relnamespace = n.oid AND n.nspname !~ '^pg_temp_' AND n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema');
  8. Realice una actualización de prueba.

    Es muy recomendable probar una actualización de versión principal en un duplicado de la base de datos de producción antes de intentar llevarla a cabo en la base de datos de producción. Para crear una instancia de prueba duplicada, puede restaurar su base de datos a partir de una instantánea reciente o clonar la base de datos. Para obtener más información, consulte Restauración a partir de una instantánea o Clonación de un volumen de clúster de base de datos de Amazon Aurora.

    Para obtener más información, consulte Actualización del motor de Aurora PostgreSQL a una nueva versión principal.

  9. Actualice su instancia de producción.

    Si la actualización de la versión principal de prueba se ha completado correctamente, debería poder actualizar su base de datos de producción con confianza. Para obtener más información, consulte Actualización del motor de Aurora PostgreSQL a una nueva versión principal .

    nota

    Durante el proceso de actualización, Aurora PostgreSQL toma una instantánea del clúster de base de datos si el periodo de retención de copia de seguridad es mayor que 0. Durante este proceso no puede realizar una restauración del clúster en un momento determinado. Más adelante, podrá realizar una restauración en un momento determinado anterior al inicio de la actualización y posterior a la finalización de la instantánea automática de la instancia. Sin embargo, no se puede restaurar a una versión secundaria anterior.

    Para obtener información acerca de una actualización en curso, puede usar Amazon RDS para ver dos registros que la utilidad pg_upgrade produce. Estos son pg_upgrade_internal.log y pg_upgrade_server.log. Amazon Aurora agrega una marca temporal al nombre de archivo de estos registros. Puede ver estos registros como cualquier otro registro. Para obtener más información, consulte Supervisión de archivos de registro de Amazon Aurora.

  10. Actualice las extensiones de PostgreSQL. El proceso de actualización de PostgreSQL no actualiza ninguna extensión de PostgreSQL. Para obtener más información, consulte Actualización de las extensiones de PostgreSQL.

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

  • Ejecute la operación ANALYZE para actualizar la tabla pg_statistic.

  • Si actualizó a la versión 10 de PostgreSQL, ejecute REINDEX en los índices hash que tenga. Los índices hash se cambiaron en la versión 10 y se deben reconstruir. Para localizar índices hash no válidos, ejecute el siguiente SQL para cada base de datos que contenga índices hash.

    SELECT idx.indrelid::regclass AS table_name, idx.indexrelid::regclass AS index_name FROM pg_catalog.pg_index idx JOIN pg_catalog.pg_class cls ON cls.oid = idx.indexrelid JOIN pg_catalog.pg_am am ON am.oid = cls.relam WHERE am.amname = 'hash' AND NOT idx.indisvalid;
  • Le recomendamos que pruebe su aplicación en la base de datos actualizada con una carga de trabajo similar para comprobar que todo funciona del modo previsto. Cuando haya comprobado la actualización, podrá eliminar esta instancia de prueba.

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.

sugerencia

En general, las instantáneas proporcionan muchas maneras de restaurar el clúster de base de datos de Aurora a varios momentos. Para obtener más información, consulte Restauración de una instantánea de clúster de base de datos y Restauración de un clúster de base de dato a un momento indicado. Sin embargo, Aurora PostgreSQL no admite el uso de instantáneas para restaurar a una versión secundaria anterior.

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:

  • Puede ver las entradas y métricas de facturación tanto para el volumen original como para el volumen clonado asignado durante la actualización. Aurora PostgreSQL limpia el volumen adicional después de que el periodo de retención de copia de seguridad del clúster supere el momento de la actualización.

  • La siguiente copia instantánea entre regiones de este clúster será una copia completa en lugar de una copia incremental.

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.

Para actualizar la versión del motor de un clúster de base de datos
  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 cluster (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 Cluster (Modificar clúster) para guardarlos.

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

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

  • --db-cluster-identifier: el nombre del clúster de bases de datos.

  • --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.

  • --allow-major-version-upgrade: un indicador requerido cuando el parámetro --engine-version es una versión principal diferente de la versión principal actual del clúster de base de datos.

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

ejemplo

Para Linux, macOS o Unix:

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

Para Windows:

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

Para actualizar la versión del motor de un clúster de base de datos, utilice la operación ModifyDBCluster. 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.

  • AllowMajorVersionUpgrade: un indicador requerido cuando el parámetro EngineVersion es una versión principal diferente de la versión principal actual del clúster de base de datos.

  • 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.

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 Antes de actualizar el 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 Antes de actualizar el 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.


                    Imagen de la consola que muestra una base de datos global de Aurora, un clúster de base de datos de Aurora Serverless y otro clúster de base de datos de Aurora PostgreSQL

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


                    Imagen de la consola que muestra el aviso para confirmar el proceso de actualización de un clúster de base de datos de Aurora PostgreSQL

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:

  • Use el comando modify-global-cluster de la AWS CLI para iniciar la actualización de la base de datos global de Aurora mediante la AWS CLI.

  • Use la API ModifyGlobalCluster para iniciar la actualización.

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.

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.


                Imagen de la consola que muestra la recomendación de actualizar a una versión secundaria más reciente.

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 14.3.3, 13.7.3, 12.11.3, 10.21.3 y otras versiones posteriores de estas versiones secundarias y versiones principales más recientes de Aurora PostgreSQL. Es decir, la actualización a nuevas versiones secundarias desde cualquiera de estas versiones en adelante utiliza ZDP.

nota

La ZDP no es compatible con los clústeres de base de datos de Aurora PostgreSQL que están configurados como Aurora Serverless v2, Aurora Serverless v1, bases de datos globales de Aurora o Babelfish.

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. Cuando la ZDP se completa correctamente, las sesiones de aplicación se conservan y el motor de base de datos se reinicia a la vez que la actualización está en curso. Aunque el reinicio del motor de base de datos puede provocar una disminución 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, si hay consultas o transacciones de larga duración en curso, es posible que ZDP tenga que cancelarlas para terminar. Si se están ejecutando instrucciones del lenguaje de definición de datos (DDL) o si se están utilizando tablas temporales o bloqueos de tabla por cualquier otro motivo, es posible que ZDP tenga que cancelar la transacción abierta. 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.

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 cluster (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 Cluster (Modificar clúster) para guardarlos.

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

Para actualizar la versión del motor de un clúster de base de datos, utilice el comando modify-db-cluster 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

Para Windows:

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

Para actualizar la versión del motor de un clúster de base de datos, utilice la operación ModifyDBCluster. 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.

Actualización de las extensiones de PostgreSQL

La actualización del clúster de base de datos de Aurora PostgreSQL a una nueva versión principal no actualiza al mismo tiempo las extensiones de PostgreSQL. Para la mayoría de las extensiones, se actualiza la extensión después de que se complete la actualización de la versión principal. No obstante, en algunos casos, se actualiza la extensión antes de actualizar el motor de base de datos de Aurora PostgreSQL. Para obtener más información, consulte list of extensions to update en list of extensions to update.

La instalación de las extensiones de PostgreSQL requiere privilegios de rds_superuser. Por lo general, un rds_superuser delega permisos sobre extensiones específicas a usuarios (roles) relevantes, para facilitar la administración de una extensión determinada. Esto significa que la tarea de actualizar todas las extensiones del clúster de base de datos de Aurora PostgreSQL puede implicar a muchos usuarios diferentes (roles). Tenga esto en cuenta sobre todo si desea automatizar el proceso de actualización mediante el uso de scripts. Para obtener más información sobre los privilegios y roles de PostgreSQL, consulte Seguridad con Amazon Aurora PostgreSQL.

nota

Para obtener información sobre la actualización de la extensión de PostGIS, consulte Administración de datos espaciales con la extensión PostGIS (Paso 6: actualice la extensión de PostGIS).

Para actualizar una extensión después de una actualización del motor, utilice el comando ALTER EXTENSION UPDATE.

ALTER EXTENSION extension_name UPDATE TO 'new_version';

Para enumerar las extensiones instaladas actualmente, utilice el catálogo pg_extension de PostgreSQL en el siguiente comando.

SELECT * FROM pg_extension;

Para ver una lista de las versiones específicas de la extensión que están disponibles para su instalación, utilice la visualización pg_available_extension_versions de PostgreSQL en el siguiente comando.

SELECT * FROM pg_available_extension_versions;