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

Descripción breve

Cuando Amazon RDS admite una nueva versión de un motor de base de datos, puede actualizar las instancias de base de datos a la nueva versión. Puede llevar a cabo una actualización de versión secundaria o una actualización de versión principal para sus instancias de base de datos.

Las actualizaciones de versiones secundarias se utilizan para corregir las vulnerabilidades de seguridad y corregir errores. Por lo general, estas actualizaciones no agregan ninguna funcionalidad nueva y no cambian el formato de almacenamiento interno. Siempre son compatibles con las versiones menores anteriores y posteriores de la misma versión principal. Sin embargo, las actualizaciones de versiones principales contienen cambios en la base de datos que no son compatibles con 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 la utilidad pg_upgrade de PostgreSQL para llevar a cabo las actualizaciones de versiones principales.

Durante la actualización de una versión principal de una instancia de PostgreSQL, Amazon RDS ejecuta un procedimiento de comprobación previa. Este procedimiento identifica cualquier problema que pueda 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. Para obtener más información sobre el proceso de comprobación previa de todas las bases de datos, consulte el registro de actualización de pg_upgrade_precheck.log. Amazon RDS agrega una marca de tiempo al nombre del archivo. Los eventos de RDS también pueden indicar los motivos del error de actualización. Sin embargo, para los problemas que son específicos del motor, debe comprobar los archivos de registro de la base de datos.

Para más información, consulte Visualización y descripción de archivos de registro de base de datos para RDS para PostgreSQL. O bien, consulte Visualización y descripción de archivos de registro de base de datos de Aurora para PostgreSQL.

Durante la actualización de una versión principal, RDS lleva a cabo estos pasos:

1. Crear una instantánea de la instancia antes de la actualización. Esto solo ocurre si establece el periodo de retención de copias de seguridad de la instancia de base de datos en un número mayor que cero.
2. Desactivar la instancia.
3. Usar la utilidad pg_upgrade para ejecutar el trabajo de actualización en la instancia.
4. Crear una instantánea de la instancia después de la actualización.

Resolución

Aunque Amazon RDS administra estas actualizaciones, es posible que encuentre los siguientes problemas durante la actualización de una versión:

• La actualización lleva más tiempo.
• Error en la actualización.

La actualización lleva más tiempo

Actividades de mantenimiento pendientes: cualquier actividad de mantenimiento pendiente se aplica automáticamente en las actualizaciones de la versión del motor. Esto podría incluir la aplicación de un parche del sistema operativo en la instancia de RDS. En ese caso, primero se aplica el parche y, a continuación, se actualiza la versión del motor. Por lo tanto, las actividades de mantenimiento del sistema operativo aumentan el tiempo necesario para completar la actualización.

Además, si la instancia de RDS está en una implementación Multi-AZ, el mantenimiento del sistema operativo produce una conmutación por error. Cuando configura su instancia en Multi-AZ, la copia de seguridad de la instancia normalmente se crea en la instancia secundaria. En caso de una conmutación por error, se 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 copia de seguridad. Por lo tanto, se puede activar una copia de seguridad completa en lugar de una copia de seguridad progresiva. Crear una copia de seguridad completa puede llevar mucho tiempo, especialmente si la base de datos es muy grande.

Para evitar este problema, busque las actividades de mantenimiento pendientes en la sección Pending maintenance (Mantenimiento pendiente) en la consola de RDS. En el caso de Aurora para PostgreSQL, consulte Vista de mantenimiento pendiente.

O bien, use el comando describe-pending-maintenance-actions de la 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: Asegúrese de completar estas actividades de mantenimiento antes de llevar a cabo las actualizaciones de la versión del motor de la base de datos.

No se creó una instantánea antes de la actualización: se considera una práctica recomendada crear una instantánea de RDS o una instantánea del clúster de Aurora para PostgreSQL antes de llevar a cabo la actualización. Si ya habilitó las copias de seguridad para la instancia, se creará automáticamente una instantánea como parte del proceso de actualización. La creación de una instantánea antes de la actualización reduce el tiempo necesario para que finalice el proceso de actualización. Esto se debe a que, en este caso, solo se crea una copia de seguridad progresiva durante este proceso.

Actualizaciones de réplicas de lectura de RDS para PostgreSQL: cuando lleva a cabo la actualización de una versión principal de la instancia de base de datos principal, todas las réplicas de lectura de la misma región se actualizan automáticamente. Una vez iniciado el flujo de trabajo de actualización, las réplicas de lectura esperan a que pg_upgrade se complete correctamente en la instancia de base de datos principal. Luego, la actualización de la instancia principal espera a que se completen las actualizaciones de las réplicas de lectura. Experimenta una interrupción hasta que se completen todas las actualizaciones. Si el periodo de inactividad de la actualización es limitado, puede promover o eliminar la instancia de réplica. A continuación, vuelva a crear las réplicas de lectura una vez finalizada la actualización.

Para actualizar de forma segura las instancias de base de datos que componen el clúster, Aurora para PostgreSQL usa la utilidad pg_upgrade. Una vez completada la actualización del escritor, cada instancia del lector sufre una breve interrupción mientras se actualiza a la nueva versión principal.

Transacciones de larga duración o carga de trabajo elevada previas a la actualización: las transacciones de larga duración o una carga de trabajo elevada ejecutadas antes de la actualización pueden aumentar el tiempo necesario para cerrar la base de datos e incrementar el tiempo de actualización.

Ejecute esta consulta para identificar transacciones de larga duración:

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;

Capacidad de computación insuficiente: la utilidad pg_upgrade puede hacer un uso intensivo de la computación. Por lo tanto, se recomienda llevar a cabo una actualización simulada antes de actualizar las bases de datos de producción. Puede restaurar una instantánea de la instancia de producción y llevar a cabo una ejecución simulada con la misma clase de instancia que la de la base de datos de producción.

Error en la actualización

Clases de instancia de bases de datos no compatibles: se puede producir un error en la actualización si la clase de la instancia de base de datos no es compatible con la versión de PostgreSQL a la que va a actualizar. Asegúrese de verificar la compatibilidad de la clase de instancia con la versión del motor. Para más información, consulte los motores de base de datos compatibles para clases de instancias de base de datos para RDS para PostgreSQL. O bien, consulte los motores de base de datos compatibles para clases de instancias de base de datos de Aurora para PostgreSQL.

Transacciones preparadas abiertas: las transacciones preparadas que están abiertas en la base de datos pueden provocar un error de actualización. Asegúrese de confirmar o deshacer todas las transacciones abiertas preparadas antes de iniciar una actualización.

Ejecute esta consulta para comprobar si hay transacciones preparadas abiertas en la instancia:

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

En este caso, el error del archivo pg_upgrade.log tiene un aspecto similar al siguiente:

------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with 
the requested major engine version upgrade and try the upgrade again.

*There are uncommitted prepared transactions. Please commit or rollback 
all prepared transactions.*

Tipos de datos no compatibles: se produce un error en la actualización si se intenta actualizar la base de datos con tipos de datos no compatibles, como los siguientes:

• regcollation
• regconfig
• regdictionary
• regnamespace
• regoper
• regoperator
• regproc
• regprocedure

Nota: Se admiten los tipos de datos regclass, regrole y regtype.

La utilidad de actualización de PostgreSQL pg_upgrade no admite la actualización de bases de datos que incluyen columnas de tabla mediante los tipos de datos del sistema de referencia de OID reg*. Elimine todos los usos de los tipos de datos reg*, excepto regclass, regrole y regtype, antes de intentar una actualización.

Ejecute esta consulta para comprobar el uso de tipos de datos reg* no compatibles:

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');

Ranuras de replicación lógica: no se puede actualizar si la instancia tiene alguna ranura de replicación lógica. Las ranuras de replicación lógica se usan normalmente para la migración de AWS Database Migration Service (AWS DMS). También se usan para replicar tablas desde bases de datos hasta lagos de datos, herramientas de inteligencia empresarial y otros objetivos. Antes de actualizar, asegúrese de conocer el propósito de las ranuras de replicación lógica que están en uso y confirme que se puedan eliminar.

Si las ranuras de replicación lógica se siguen utilizando, no debe eliminarlas. En este caso, no puede continuar con la actualización.

El error relacionado del archivo de registro pg_upgrade tiene un aspecto similar al siguiente:

"The instance could not be upgraded because one or more databases have logical replication slots. Please drop all logical replication slots and try again."

Si no se necesitan las ranuras de replicación lógica, ejecute estas consultas para eliminarlas:

SELECT * FROM pg_replication_slots;

SELECT pg_drop_replication_slot(slot_name);

Problemas de almacenamiento: mientras se ejecuta el script pg_upgrade, es posible que la instancia se quede sin espacio. Esto provoca un error en el script, que hace que aparezca un mensaje de error similar al siguiente:

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úrese de que la instancia tenga suficiente espacio de almacenamiento gratuito antes de iniciar la actualización.

Tipos de datos desconocidos: las versiones 10 y posteriores de PostgreSQL no admiten tipos de datos unknown (desconocidos). Si una base de datos de la versión 9.6 de PostgreSQL usa el tipo de datos unknown (desconocido), una actualización a la versión 10 muestra un mensaje de error como este:

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

Se trata de una limitación de PostgreSQL y la automatización de RDS no modifica las columnas con el tipo de datos unknown (desconocido). Es posible que tenga que modificar estas columnas manualmente antes de hacer la actualización.

Ejecute esta consulta para buscar columnas en la base de datos con tipos de datos unknown (desconocido):

SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';

Después de identificar las columnas, puede eliminarlas o modificarlas a un tipo de datos compatible.

Error de actualización de réplica de lectura (solo en el caso de RDS para PostgreSQL): la instancia de PostgreSQL leyó réplicas y, por lo tanto, los errores de actualización de la réplica de lectura pueden provocar que la actualización de la instancia principal se bloquee. Un error de actualización de la réplica de lectura también puede provocar un error en la actualización de la instancia principal. Una réplica de lectura con errores se coloca en el estado incompatible-restore (restauración incompatible) y la replicación se detiene en la instancia de base de datos.

La actualización de una réplica de lectura puede fallar por uno de estos motivos:

• La réplica de lectura no puede ponerse al día con la instancia de base de datos principal ni siquiera 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” (almacenamiento completo) o “incompatible-restore” (restauración incompatible).
• Cuando se inicia la actualización de la instancia de base de datos principal, simultáneamente se ejecuta una actualización de versión secundaria 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 solucionar este problema, elimine la réplica de lectura. A continuación, vuelva a crear una nueva réplica de lectura basada en la instancia principal actualizada después de que esta se haya actualizado.

Nombre de usuario principal incorrecto: 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, cree otro usuario con el rol rds_superuser. Puede contactar con AWS Support para actualizar este usuario como el nuevo usuario principal.

Error de parámetro incompatible: se produce si un parámetro relacionado con la memoria, como shared_buffer o work_memory, se establece en un valor superior. Esto puede provocar un error en el script de actualización. Para solucionar el problema, reduzca los valores de estos parámetros y luego intente ejecutar la actualización de nuevo.

Extensiones no actualizadas antes de la actualización: una actualización de la versión principal no actualiza ninguna extensión de PostgreSQL. Si no se actualizaron las extensiones antes de actualizar la versión principal, verá este error en el archivo pg_upgrade.log:

The Logs indicates that the RDS instance ''xxxx'' 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.

Este mensaje de error indica un problema con la extensión PostGIS.

Ejecute esta consulta para comprobar las versiones predeterminadas e instaladas de PostGIS y sus extensiones dependientes:

SELECT name, default_version, installed_version
FROM pg_available_extensions WHERE installed_version IS NOT NULL AND
name LIKE 'postgis%' OR name LIKE 'address%';

Si el valor deinstalled_version es inferior al de default_version, debe actualizar PostGIS a la versión predeterminada. Para ello, ejecute esta consulta:

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

Para más información, consulte Actualización de las extensiones de PostgreSQL para RDS para PostgreSQL o Actualización de las extensiones de PostgreSQL para Aurora PostgreSQL.

Problema en las vistas debido a 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 aparezca un mensaje de error como este:

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. Este error se debe a la vista pg_stat_activity porque la columna waiting (en espera) se reemplaza por las columnas wait_event_type y wait_event en la versión 9.6.

pg_restore: from TOC entry xxx; xxx xxxx 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".

Este error se produce porque la estructura del catálogo pg_constraint ha cambiado en la versión 12 de PostgreSQL.

Para solucionar estos problemas, puede eliminar las vistas en función de los catálogos del sistema de la versión de destino.

Nota: Tenga cuidado al eliminar estas vistas. Asegúrese de consultarlo con su administrador de base de datos.

Otras consideraciones

• La utilidad pg_upgrade produce dos registros: pg_upgrade_internal.log y pg_upgrade_server.log. Para estos registros, Amazon RDS agrega una marca de tiempo al nombre del archivo. Consulte dichos registros para obtener más información sobre los problemas y errores encontrados durante la actualización. Para obtener más información, consulte Supervisión de archivos de registro de Amazon RDS para RDS para PostgreSQL o Supervisión de archivos de registro de Amazon Aurora para Aurora para PostgreSQL.
• Cuando finalice la actualización, ejecute ANALYZE en todas las bases de datos de usuarios para actualizar la tabla pg_statistics. Una actualización importante no mueve el contenido de la tabla pg_statistics a la nueva versión. Omitir este paso puede provocar que las consultas se ejecuten con lentitud.
• Si llevó a cabo la actualización a la versión 10 de PostgreSQL, ejecute REINDEX en todos los índices de hash que tenga. Los índices de hash se modificaron en la versión 10 y es necesario volver a crearlos. Para encontrar índices de hash no válidos, ejecute este SQL en todas las bases de datos que contengan índices de 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;

---

Información relacionada

Información general sobre la actualización de PostgreSQL

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