New user sign up using AWS Builder ID
New user sign up using AWS Builder ID is currently unavailable on re:Post. To sign up, please use the AWS Management Console instead.
¿Cómo soluciono los problemas relacionados con las actualizaciones de las versiones principales de Amazon RDS para PostgreSQL o Aurora PostgreSQL?
La actualización de la versión del motor de Amazon Relational Database Service (Amazon RDS) para PostgreSQL o de la Edición compatible con PostgreSQL de Amazon Aurora está bloqueada o falla.
Descripción corta
Las actualizaciones de versiones menores son compatibles con las versiones menores anteriores y posteriores de la misma versión principal. Sin embargo, las actualizaciones de las versiones principales incluyen cambios en la base de datos que no son compatibles con versiones anteriores de las aplicaciones existentes. Estas actualizaciones pueden cambiar el formato interno de las tablas del sistema, los archivos de datos y el almacenamiento de datos. Amazon RDS usa pg_upgrade para realizar las actualizaciones de las versiones principales. Para obtener más información, consulta pg_upgrade en el sitio web de PostgreSQL.
Durante la actualización de una versión principal, Amazon RDS pone en marcha un procedimiento de comprobación previa que identifica los problemas que pueden provocar un error en la actualización. Comprueba si hay posibles condiciones incompatibles en todas las bases de datos. Si Amazon RDS identifica un problema durante el proceso de comprobación previa, crea un evento de registro para la comprobación previa fallida. Los eventos de registro incluyen el nombre del archivo, la marca de tiempo y los motivos del error de actualización. Para obtener información sobre el proceso de comprobación previa de todas las bases de datos, consulta el registro pg_upgrade_precheck.log. Sin embargo, en caso de problemas específicos del motor, debes comprobar los archivos de registro de la base de datos de Amazon RDS para PostgreSQL o de Aurora PostgreSQL.
Resolución
La utilidad pg_upgrade que realiza las principales actualizaciones de versiones produce dos registros: pg_upgrade_internal.log y pg_upgrade_server.log. Amazon RDS añade una marca de tiempo al nombre del archivo de estos registros. Consulta estos registros para obtener más información sobre los problemas y errores encontrados durante la actualización. Para obtener más información, consulta Supervisión de archivos de registro de Amazon RDS o Supervisión de archivos de registro de Amazon Aurora.
La actualización lleva mucho tiempo
Comprobación de si hay actividades de mantenimiento pendientes
Amazon RDS utiliza automáticamente las actualizaciones de la versión del motor para aplicar las actividades de mantenimiento pendientes, como un parche del sistema operativo en la instancia de RDS. Amazon RDS aplica primero la actividad pendiente y, a continuación, actualiza la versión del motor. Si Amazon RDS debe realizar actividades de mantenimiento del sistema operativo, la actualización tardará más.
Si la instancia de RDS se encuentra en un despliegue multi-AZ, el mantenimiento del sistema operativo provoca una conmutación por error. Cuando configuras la instancia en multi-AZ, Amazon RDS normalmente crea la copia de seguridad de la instancia en la instancia secundaria. En una conmutación por error, Amazon RDS crea una copia de seguridad en una nueva instancia secundaria después de la actualización. Es posible que esta copia de seguridad de la nueva instancia secundaria no sea la última, por lo que Amazon RDS realiza una copia de seguridad completa en lugar de una copia de seguridad incremental. Una copia de seguridad completa puede llevar mucho tiempo, especialmente si la base de datos es grande.
Para evitar este problema, busca las actividades de mantenimiento pendientes de la instancia de base de datos de RDS o de la instancia de base de datos de Aurora. O bien, usa el comando describe-pending-maintenance-actions de Interfaz de la línea de comandos de AWS (AWS CLI) en la instancia:
aws rds describe-pending-maintenance-actions --resource-identifier example-arn
Nota: Sustituye example-arn por el ARN de la instancia de tu base de datos. Si se muestran errores al usar comandos de AWS CLI, consulta Solución de errores para AWS CLI. Además, asegúrate de utilizar la versión más reciente de AWS CLI.
Completa las actividades de mantenimiento pendientes antes de realizar las actualizaciones de la versión del motor de base de datos.
Creación de una instantánea antes de la actualización
Se recomienda crear una instantánea de la instancia de base de datos de RDS o del clúster de la base de datos de Aurora antes de actualizar la versión. Si ya has activado las copias de seguridad de la instancia, Amazon RDS crea automáticamente una instantánea como parte del proceso de actualización. Con una instantánea, reduces el tiempo del proceso de actualización, ya que Amazon RDS solo necesita crear una copia de seguridad incremental como parte de la actualización.
Esperar a que se actualice la réplica de lectura
Cuando actualizas la versión principal de la instancia de base de datos principal, Amazon RDS actualiza automáticamente todas las réplicas de lectura en la misma región de AWS. Una vez iniciado el flujo de trabajo de actualización, las réplicas de lectura esperan a que pg_upgrade finalice correctamente en la instancia de base de datos principal. A continuación, la actualización de la instancia de base de datos principal espera a que finalicen las actualizaciones de la réplica de lectura. Se produce una interrupción hasta que se completen todas las actualizaciones. Si el período de inactividad de la actualización es pequeño, promociona o elimina la instancia de réplica y, a continuación, vuelve a crear las réplicas de lectura una vez finalizada la actualización.
En el caso de los clústeres de bases de datos de Aurora, pg_upgrade actualiza primero la instancia de escritura. A continuación, cada instancia de base de datos de lectura sufre una interrupción cuando pg_upgrade la actualiza a la nueva versión principal. Ten en cuenta que si actualizas una base de datos global de Aurora, existen requisitos y procesos adicionales.
Resolución de las transacciones de larga duración o de las cargas de trabajo grandes antes de la actualización
Las transacciones de larga duración o las cargas de trabajo grandes pueden aumentar el tiempo que Amazon RDS tarda en cerrar la base de datos y actualizar el motor de esta.
Para identificar las transacciones de larga duración, usa la siguiente consulta:
SQL>SELECT pid, datname, application_name, state, age(query_start, clock_timestamp()), usename, query FROM pg_stat_activity WHERE query NOT ILIKE '%pg_stat_activity%' AND usename!='rdsadmin' ORDER BY query_start desc;
Si identificas una consulta de larga duración, usa pg_cancel_backend o pg_terminate_backend para finalizar la consulta. Para obtener más información sobre estas funciones, consulta 9.28.2. Server signaling functions.
Asegúrarse de tener suficiente capacidad de procesamiento
La utilidad pg_upgrade puede hacer un uso intensivo de los recursos informáticos. Se recomienda realizar una actualización de prueba antes de actualizar las bases de datos de producción para comprobar que tengas suficiente capacidad de procesamiento o memoria. La actualización de prueba también verifica si se pueden producir errores de comprobación previa o de actualización. Puedes restaurar una instantánea de la instancia de producción y realizar una prueba con la misma clase de instancia que la de la base de datos de producción.
La actualización falla
Comprobación de si hay clases de instancias de base de datos no compatibles
Si la clase de tu instancia de base de datos no es compatible con la versión de PostgreSQL a la que estás actualizando, se producirá un error en la actualización. Comprueba la compatibilidad de la versión del motor con la clase de instancia de Amazon RDS o Amazon Aurora.
Comprobación de si hay transacciones preparadas abiertas
Si hay transacciones preparadas abiertas en la base de datos, se produce un error en la actualización. Aparece el error There are uncommitted prepared transactions (Hay transacciones preparadas no confirmadas) en el archivo pg_upgrade.log. Confirma o anula todas las transacciones abiertas preparadas antes de iniciar una actualización.
Para comprobar si hay transacciones preparadas abiertas en tu instancia, usa la siguiente consulta:
SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
Asegurarse de usar un tipo de datos compatible
Solo puedes actualizar la versión para los tipos de datos regclass, regrole y regtype. La utilidad pg_upgrade no puede actualizar las bases de datos que incluyen columnas de tablas que utilizan los tipos de referencia de identificador de objeto (OID) reg*. Si utilizas un tipo de datos regcollation, regconfig, regdictionary, regnamespace, regoper, regoperator, regproc o regprocedure, la actualización dará error.
Para resolver este problema, elimina todos los usos de tipos de datos reg*, excepto para regclass, regrole y regtype, antes de actualizar el motor de datos. Para comprobar si hay tipos de datos reg* no compatibles en las tablas, usa la siguiente consulta.
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');
Comprobación de si hay ranuras de replicación lógica
Si la instancia tiene ranuras de replicación lógica, no puedes actualizarla y recibirás el siguiente error en el archivo pg_upgrade.log:
«The instance could not be upgraded because one or more databases have logical replication slots. Please drop all logical replication slots and try again» (No se pudo actualizar la instancia porque una o más bases de datos tienen ranuras de replicación lógica. Elimina todas las ranuras de replicación lógica e inténtalo de nuevo).
Las ranuras de replicación lógica se utilizan normalmente para la migración de AWS Database Migration Service (AMS DMS). También se utilizan para replicar tablas de bases de datos a lagos de datos, herramientas de inteligencia empresarial y otros objetivos. Asegúrate de conocer el propósito de las ranuras de replicación lógica que están en uso para comprobar si puedes eliminarlas. Si las ranuras de replicación lógica están en uso, no las elimines. Debes esperar para actualizar la versión hasta que puedas eliminar las ranuras de replicación lógica.
Si no necesitas las ranuras de replicación lógica, usa las siguientes consultas para eliminarlas:
SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);
Nota: Sustituye slot_name por el nombre de la ranura de replicación lógica.
Comprobación de si hay problemas de almacenamiento
Si la instancia se queda sin espacio cuando se usa el script pg_upgrade, se produce un error en la actualización y aparece el siguiente error:
«pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] could not execute query: ERROR: could not create file “base/12345/12345678”: No space keyword" left on device» (pg_restore: [archiver (db)] Error al PROCESAR TOC: pg_restore: [archiver (db)] no pudo procesar la consulta: ERROR: no pudo crear el archivo “base/12345/12345678”: No queda ninguna palabra clave con espacio en el dispositivo)
Para resolver este problema, asegúrate de que la instancia tenga suficiente almacenamiento gratuito antes de iniciar la actualización.
Comprobación de si hay tipos de datos desconocidos
No puede usar tipos de datos desconocidos en las versiones 10 y posteriores de PostgreSQL. Por ejemplo, si una base de datos de la versión 9.6 de PostgreSQL usa el tipo de datos desconocido, recibirás el siguiente error al actualizar a la versión 10:
«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» No se pudo actualizar la instancia porque se usa el tipo de datos “desconocido” en las tablas de usuarios. Elimina todos los usos del tipo de datos “desconocido” e inténtalo de nuevo)
Para resolver este problema, elimina manualmente las columnas que utilizan el tipo de datos desconocido o modifícalas por un tipo de datos compatible. Para buscar las columnas de la base de datos que utilizan el tipo de datos desconocido, usa la siguiente consulta:
SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';
(Solo para RDS para PostgreSQL) Comprobación de si hay un error de actualización de la réplica de lectura
Si la instancia de PostgreSQL tiene réplicas de lectura, los errores de actualización de la réplica de lectura pueden provocar que la actualización de la instancia principal se bloquee o falle. Amazon RDS establece una réplica de lectura fallida en el estado incompatible-restore y, a continuación, detiene la replicación en la instancia de la base de datos.
La actualización de una réplica de lectura puede fallar por uno de los siguientes motivos:
- La réplica de lectura no puede alcanzar el nivel de la instancia de base de datos principal incluso después del tiempo de espera.
- La réplica de lectura se encuentra en un estado de ciclo de vida terminal o incompatible, como storage-full o incompatible-restore.
- Cuando se inicia la actualización de la instancia de base de datos principal, se procesa una actualización de versión menor independiente en la réplica de lectura.
- La réplica de lectura usa parámetros incompatibles.
- La réplica de lectura no puede comunicarse con la instancia de base de datos principal para sincronizar la carpeta de datos.
Para resolver este problema, elimina la réplica de lectura. A continuación, vuelve a crear una nueva réplica de lectura basada en la instancia principal actualizada después de la actualización.
Asegurarse de que el nombre de usuario principal sea correcto
Si el nombre de usuario principal comienza por pg_, se produce un error en la actualización y aparece el siguiente mensaje de error:
«PreUpgrade checks failed: The instance could not be upgraded because one or more role names start with “pg_”. Please rename all roles with names that start with “pg_” and try again» (Las comprobaciones previas a la actualización fallaron: No se pudo actualizar la instancia porque uno o más nombres de rol comienzan por “pg_”. Cambie el nombre de todos los roles por nombres que comiencen por “pg_” e inténtelo de nuevo
Para resolver este problema, cree otro usuario con la función rds_superuser que no comience por pg_.
Comprobación de si hay parámetros incompatibles
El error de parámetros incompatibles se produce cuando el valor de un parámetro relacionado con la memoria, como shared_buffer o work_memory, es demasiado alto para la configuración. Este error hace que el script de actualización falle. Para resolver el problema, reduce los valores de estos parámetros y, a continuación, vuelva a procesar la actualización.
Actualización de las extensiones antes de actualizar
Las actualizaciones de versiones principales no actualizan las extensiones de PostgreSQL. Si no actualizas las extensiones antes de actualizar una versión principal, aparecerá un error en el archivo pg_upgrade.log similar al del ejemplo siguiente:
«The Logs indicates that the RDS instance “abcd” has older version of PostGIS extension or its dependent extensions (address_standardizer,address_standardizer_data_us, postgis_tiger_geocoder, postgis_topology, postgis_raster) installed as against the current version required for the upgrade» (Los registros indican que la instancia de RDS “abcd” tiene instalada una versión anterior de la extensión PostGIS o sus extensiones dependientes (address_standardizer,address_standardizer_data_us, postgis_tiger_geocoder, postgis_topology, postgis_raster) en lugar de la versión actual requerida para la actualización)
El error del ejemplo anterior muestra un problema con la extensión PostGIS. Para resolver este problema, usa la siguiente consulta para comprobar las versiones predeterminadas e instaladas de PostGIS y sus extensiones dependientes:
SELECT name, default_version, installed_versionFROM pg_available_extensions WHERE installed_version IS NOT NULL AND name LIKE 'postgis%' OR name LIKE 'address%';
Nota: Sustituye postgis% por tu extensión.
Si el valor de installed_version es inferior al valor de default_version, debes actualizar PostGIS a la versión predeterminada. Para actualizar la extensión, usa la siguiente consulta:
ALTER EXTENSION extension_name UPDATE TO 'default_version_number';
Nota: Sustituye default_version_number por el valor de default_version.
Para obtener más información, consulta Actualizaciones del motor de base de datos de RDS para PostgreSQL o Actualización de clústeres de base de datos PostgreSQL de Amazon Aurora.
Comprobación de si hay problemas en las vistas causados por un cambio en el catálogo del sistema de la versión de destino
Las columnas de determinadas vistas varían según las diferentes versiones de PostgreSQL. Por ejemplo, es posible que recibas un error similar al siguiente:
«PreUpgrade checks failed: The instance could not be upgraded because one or more databases have views or materialized views which depend on “pg_stat_activity”. Please drop them and try again» (Las comprobaciones previas a la actualización fallaron: No se pudo actualizar la instancia porque una o más bases de datos tienen vistas o vistas materializadas que dependen de “pg_stat_activity”. Elimínalas e inténtalo de nuevo).
Este error se produce al actualizar la base de datos de la versión 9.5 a la 9.6. En el ejemplo anterior, la vista pg_stat_activity es la causa del problema. En la versión 9.6, PostgreSQL reemplazó la columna waiting por las columnas wait_event_type y wait_event.
También es posible que recibas un error similar al siguiente:
«pg_restore: from TOC entry abc; abc abcd VIEW sys_user_constraints art pg_restore: error: could not execute query: ERROR: column c.consrc does not exist LINE 18: “c”.”consrc” AS “search_condition”, ^ HINT: Perhaps you meant to reference the column “c.conkey” or the column “c.conbin”» (pg_restore: de la entrada TOC abc; abc abcd VIEW sys_user_constraints art pg_restore: error: no se pudo procesar la consulta: ERROR: column c.consrc no existe LÍNEA 18: “c”.”consrc” AS “search_condition”, ^ SUGERENCIA: Quizás querías hacer referencia a la columna “c.conkey” o a la columna “c.conbin”).
En este ejemplo, el error se produce porque la estructura del catálogo pg_constraint cambió en la versión 12 de PostgreSQL.
Para resolver estos problemas, elimina las vistas basadas en los catálogos del sistema de la versión de destino.
Importante: Se recomienda usar pgdump para hacer copias de seguridad de las vistas o capturar la definición de la vista antes de eliminarla. Cuando eliminas una vista, tienes que volver a crearla manualmente después de actualizar la versión. Es posible que tengas que trabajar con el administrador de la base de datos.
Después de la actualización
Una vez completada la actualización, usa ANALYZE en todas las bases de datos de usuarios para actualizar la tabla pg_statistics. Una actualización a una versión principal no mueve el contenido de la tabla pg_statistics a la nueva versión. Si no mueves el contenido, es posible que las consultas se procesen con lentitud.
Información relacionada
Información general de los procesos de actualización de Aurora PostgreSQL

Contenido relevante
- preguntada hace 2 meseslg...
- preguntada hace 2 meseslg...
- preguntada hace 5 díaslg...
- preguntada hace un meslg...
- preguntada hace 14 díaslg...
- OFICIAL DE AWSActualizada hace 2 meses
- OFICIAL DE AWSActualizada hace 2 meses
- OFICIAL DE AWSActualizada hace un año