¿Cómo soluciono los problemas relacionados con las actualizaciones de las versiones principales de Amazon RDS para PostgreSQL o compatibles con Aurora PostgreSQL?

Descripción corta

Las actualizaciones de las versiones principales incluyen cambios en la base de datos que no son compatibles con versiones anteriores de las aplicaciones existentes. Las 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. 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 los registros: pg_upgrade_internal.log y the pg_upgrade_server.log. Amazon RDS anexa una marca de tiempo al nombre del archivo de los registros. Revisa 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.

Actualizaciones de larga duración

Comprobación de si hay actividades de mantenimiento pendientes

Si se muestran errores al ejecutar comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), consulta Solución de problemas de AWS CLI. Además, asegúrate de utilizar la versión más reciente de la AWS CLI.

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 Amazon 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 Amazon RDS se encuentra en un despliegue multi-AZ, el mantenimiento del sistema operativo provoca una conmutación por error. Cuando configuras la instancia en un entorno 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 cuando 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, ejecuta el siguiente comando describe-pending-maintenance-actions de la 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.

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

Antes de actualizar la versió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. 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. Las instantáneas reducen 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. La instancia de base de datos se cierra hasta que finalicen todas las actualizaciones. Si el tiempo 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 del lector se cierra cuando pg_upgrade la actualiza a la nueva versión principal.

Nota: 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 transacción de larga duración, usa pg_cancel_backend o pg_terminate_backend para finalizar la transacción. Para obtener más información sobre pg_cancel_backend y pg_terminate_backend, consulta Funciones de señalización del servidor en el sitio web de PostgreSQL.

Asegurarse de tener suficiente capacidad de procesamiento

La utilidad pg_upgrade puede hacer un uso intensivo de los recursos informáticos. Para comprobar que tengas suficiente capacidad de procesamiento o memoria, se recomienda realizar una actualización de prueba antes de actualizar las bases de datos de producción. La actualización de prueba también verifica si se pueden producir errores de comprobación previa o de actualización. Puedes restaurar la instantánea de la instancia de producción y realizar una prueba con la misma clase de instancia que la clase de instancia de la base de datos de producción.

Fallos de actualización

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» en el archivo pg_upgrade.log. Antes de iniciar la actualización, confirma o anula todas las transacciones abiertas preparadas.

Para comprobar si hay transacciones preparadas abiertas en tu instancia, usa la siguiente consulta:

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

Uso de 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 mensaje de 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».

Normalmente las ranuras de replicación lógica se utilizan 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 usas para determinar 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 los siguientes comandos 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 mensaje de 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»

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 puedes 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 mensaje de 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».

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

Para resolver este problema, crea otro usuario con el rol rds_superuser que no comience por pg_.

Comprobación de si hay parámetros incompatibles

El error «incompatible parameters» 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, vuelve 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á el mensaje de error en el archivo pg_upgrade.log similar al 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».

El mensaje de 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 el siguiente comando:

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 cambios en el catálogo del sistema de la versión de destino que provoquen problemas en las vistas

Las columnas de determinadas vistas varían según las diferentes versiones de PostgreSQL. Por ejemplo, es posible que recibas un mensaje de 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».

Este error se produce al actualizar la base de datos de la versión 9.5 a la 9.6. En el mensaje de error del 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.

O bien, es posible que recibas un mensaje de 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"».

El mensaje de error del ejemplo anterior muestra que el error se produjo 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: Antes de eliminar las vistas, se recomienda usar pgdump para hacer copias de seguridad de las vistas o capturar su definición. Al eliminar una vista, tú o el administrador de la base de datos debéis volver a crear manualmente la vista después de la actualización de la versión.

Finalización 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