Actualización de clústeres de base de datos PostgreSQL de Amazon Aurora - Amazon Aurora

Actualización de clústeres de base de datos PostgreSQL de Amazon Aurora

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 versiones secundarias (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 característica ZDP no es compatible con los siguientes casos:

  • Cuando los clústeres de base de datos de Aurora PostgreSQL se configuran como Aurora Serverless v1.

  • Durante la actualización de las instancias del lector en la base de datos global de Aurora.

  • Durante los parches y actualizaciones del sistema operativo.

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 Prueba de la actualización del 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.

En ocasiones, los clústeres de base de datos de Aurora PostgreSQL requieren actualizaciones del sistema operativo. Estas actualizaciones a veces pueden incluir una versión más reciente de la biblioteca glibc. Durante estas actualizaciones, le recomendamos que siga las directrices que se describen en Intercalaciones admitidas en Aurora PostgreSQL.

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

Puede obtener una lista de todas las versiones de motor disponibles como destinos de actualización 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[*].{EngineVersion:EngineVersion}' \ --output text

Para Windows:

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

Por ejemplo, para identificar los destinos de actualización válidos para un clúster de bases de datos de Aurora PostgreSQL versión 12.10, ejecute el siguiente comando de la AWS CLI:

Para Linux, macOS o Unix:

aws rds describe-db-engine-versions \ --engine aurora-postgresql \ --engine-version 12.10 \ --query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \ --output text

Para Windows:

aws rds describe-db-engine-versions ^ --engine aurora-postgresql ^ --engine-version 12.10 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^ --output text

En esta tabla, puede encontrar los destinos de actualización de versiones principales y secundarias que están disponibles para varias versiones de la base de datos Aurora PostgreSQL.

Versión de origen actual Destinos de actualización
15.2 15.3
14.8 15.3 15.2
14.7 15.3 15.2 14.8
14.6 15.3 15.2 14.8 14.7
14.5 15.3 15.2 14.8 14.7 14.6
14.4 15.3 15.2 14.8 14.7 14.6 14.5
14.3 15.3 15.2 14.8 14.7 14.6 14.5 14.4
13.11 15.3 14.8
13.10 15.3 15.2 14.8 14.7 13.11
13.9 15.3 15.2 14.8 14.7 14.6 13.11 13.10
13.8 15.3 15.2 14.8 14.7 14.6 14.5 13.11 13.10 13.9
13.7 15.3 15.2 14.8 14.7 14.6 14.5 14.4 14.3 13.11 13.10 13.9 13.8
13.6 15.3 15.2 14.8 14.7 14.6 14.5 14.4 14.3 13.11 13.10 13.9 13.8 13.7
13.5 15.3 15.2 14.8 14.7 14.6 14.5 14.4 14.3 13.11 13.10 13.9 13.8 13.7 13.6
13.4 15.3 15.2 14.8 14.7 14.6 14.5 14.4 14.3 13.11 13.10 13.9 13.8 13.7 13.6 13.5
13.3 15.3 15.2 14.8 14.7 14.6 14.5 14.4 14.3 13.11 13.10 13.9 13.8 13.7 13.6 13.5 13.4
12.15 15.3 14.8 13.11
12.14 15.3 15.2 14.8 14.7 13.11 13.10 12.15
12.13 15.3 15.2 14.8 14.7 14.6 13.11 13.10 13.9 12.15 12.14
12.12 15.3 15.2 14.8 14.7 14.6 14.5 13.11 13.10 13.9 13.8 12.15 12.14 12.13
12.11 15.3 15.2 14.8 14.7 14.5 14.4 14.3 13.11 13.10 13.9 13.8 13.7 12.15 12.14 12.13 12.12
12.10 15.3 15.2 14.8 14.7 13.11 13.10 13.9 13.8 13.7 13.6 12.15 12.14 12.13 12.12 12.11
12.9 15.3 15.2 14.8 14.7 13.11 13.10 13.9 13.8 13.7 13.6 13.5 12.15 12.14 12.13 12.12 12.11 12.10
12.8 15.3 15.2 14.8 14.7 13.11 13.10 13.9 13.8 13.7 13.6 13.5 13.4 12.15 12.14 12.13 12.12 12.11 12.10 12.9
12.7 15.3 15.2 14.8 14.7 13.11 13.10 13.9 13.8 13.7 13.6 13.5 13.4 13.3 12.15 12.14 12.13 12.12 12.11 12.10 12.9 12.8
11.20 15.3 14.8 13.11 12.15
11.19 15.3 15.2 14.8 14.7 13.11 13.10 12.15 12.14 11.20
11.18 15.3 15.2 14.8 14.7 14.6 13.11 13.10 13.9 12.15 12.14 12.13 11.20 11.19
11.17 15.3 15.2 14.8 14.7 14.5 13.11 13.10 13.8 12.15 12.14 12.13 12.12 11.20 11.19 11.18
11.16 15.3 15.2 14.8 14.7 14.5 14.4 14.3 13.11 13.10 13.9 13.7 12.15 12.14 12.13 12.12 12.11 11.20 11.19 11.18 11.17
11.15 15.3 15.2 14.8 14.7 13.11 13.10 13.6 12.15 12.14 12.13 12.12 12.11 12.10 11.20 11.19 11.18 11.17 11.16
11.14 15.3 15.2 14.8 14.7 13.11 13.10 13.5 12.15 12.14 12.13 12.12 12.11 12.10 12.9 11.20 11.19 11.18 11.17 11.16 11.15
11.13 15.3 15.2 14.8 14.7 13.11 13.10 13.4 12.15 12.14 12.13 12.12 12.11 12.10 12.9 12.8 11.20 11.19 11.18 11.17 11.16 11.15 11.14
11.9 15.3 15.2 14.8 14.7 13.11 13.10 12.15 12.14 12.13 12.12 12.11 12.10 12.9 12.8 12.7 11.20 11.19 11.18 11.17 11.16 11.15 11.14 11.13 11.12

Para cualquier versión que esté considerando, compruebe siempre la disponibilidad de la clase de instancia de base de datos del clúster. Por ejemplo, db.r4 no admite Aurora PostgreSQL 13. Si su clúster de base de datos de Aurora PostgreSQL utiliza actualmente una clase de instancia db.r4, debe pasar a db.r5 antes de intentar la actualización. 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 de Aurora.

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 Prueba de la actualización del 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

Puede realizar una actualización de la versión principal de las versiones basadas en Babelfish para Aurora PostgreSQL 13 a partir de la versión 13.6 a las versiones basadas en Aurora PostgreSQL 14 a partir de la versión 14.6. Babelfish para Aurora PostgreSQL 13.4 y 13.5 no admite la actualización de versiones principales.

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

Para 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:

  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.

      Si va a actualizar una versión de Aurora PostgreSQL 10.x que tiene instalada la extensión pg_repack versión 1.4.3, elimine la extensión antes de actualizar a una versión superior.

  3. Compruebe las bases de datos template1 y template0.

    Para que la actualización se realice correctamente, las bases de datos de plantilla 1 y plantilla 0 deben existir y figurar como plantilla. Para comprobarlo, utilice el siguiente comando:

    SELECT datname, datistemplate FROM pg_database; datname | datistemplate -----------+--------------- template0 | t rdsadmin | f template1 | t postgres | f

    En el resultado del comando, el valor datistemplate de las bases de datos template1 y template0 debe ser t.

  4. Elimine las ranuras 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 ranuras de replicación lógica. Las ranuras 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 las ranuras de replicación lógica existentes y confirme que es correcto eliminarlos. Puede comprobar las ranuras de replicación lógica mediante la siguiente consulta:

    SELECT * FROM pg_replication_slots;

    Si las ranuras 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 las ranuras de replicación lógica, puede eliminarlos con la siguiente SQL:

    SELECT pg_drop_replication_slot(slot_name);

    Los escenarios de replicación lógica que utilizan la extensión pglogical también deben tener espacios eliminados del nodo de publicación para que la actualización de la versión principal se realice correctamente en dicho nodo. Sin embargo, puede reiniciar el proceso de replicación desde el nodo de suscriptor después de la actualización. Para obtener más información, consulte Restablecimiento de la replicación lógica después de una actualización principal.

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

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

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

  8. 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');
  9. 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. Puede supervisar los planes de ejecución de la instancia de prueba duplicada para detectar posibles regresiones del plan de ejecución y evaluar su rendimiento. 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.

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

  11. 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. Debe hacerlo para cada base de datos en todas las instancias de base de datos de PostgreSQL. Las estadísticas del optimizador no se transfieren durante una actualización de la versión principal, por lo que debe regenerar todas las estadísticas para evitar problemas de rendimiento. Ejecute el comando sin parámetros para generar estadísticas para todas las tablas normales de la base de datos actual, de la siguiente manera:

    ANALYZE VERBOSE;

    La marca VERBOSE es opcional, pero su uso muestra el progreso. Para obtener más información, consulte ANALYZE en la documentación de PostgreSQL.

    nota

    Ejecute ANALYZE en el sistema después de la actualización para evitar problemas de rendimiento.

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


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


                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 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 N/A
Versión 11.16.0 y versiones posteriores a la 11.16 N/A
Versión 11.17 y posteriores N/A
Versión 12.11.0 y versiones posteriores a la 12.11 N/A
Versión 12.12 y posteriores N/A
Versión 13.7.0 y versiones posteriores a la 13.7 N/A
Versión 13.8 y posteriores
Versión 14.3.1 y versiones posteriores a la 14.3 N/A
Versión 14.4.0 y versiones posteriores a la 14.4 N/A
Versión 14.5 y posteriores
Versión 15.3 y posteriores
nota

La ZDP no es compatible con los clústeres de base de datos de Aurora PostgreSQL que están configurados como Aurora Serverless v1, ni en bases de datos globales de Aurora. La ZDP no se admite durante la aplicación de revisiones ni actualizaciones del sistema operativo.

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.

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

Al actualizar el clúster de base de datos de Aurora PostgreSQL a una nueva versión principal o secundaria, no se actualizan al mismo tiempo las extensiones de PostgreSQL. En la mayoría de los casos, debe actualizarla la extensión después de que se complete la actualización de la versión principal o secundaria. 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 Prueba de la actualización del clúster de base de datos de producción a una nueva versión principal.

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 la extensión pg_repack, elimínela y, a continuación, cree la nueva versión en la instancia de base de datos actualizada. Para obtener más información, consulte pg_repack installation (Instalación de pg_repack) en la documentación de pg_repack.

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;

Técnica alternativa de actualización azul/verde

En algunas situaciones, su prioridad principal es realizar un cambio inmediato del clúster antiguo a uno actualizado. En tales situaciones, puede utilizar un proceso de varios pasos que ejecuta los clústeres antiguo y nuevo en paralelo. Aquí, replicará los datos del clúster anterior al nuevo hasta que esté listo para que el nuevo clúster asuma el control. Para obtener información, consulte Uso de las implementaciones azul/verde de Amazon RDS para actualizar las bases de datos.