Realización de una actualización de la versión principal de RDS para PostgreSQL - Amazon Relational Database Service

Realización de una actualización de la versión principal de RDS para PostgreSQL

Se recomienda seguir el siguiente proceso al realizar una actualización de versión principal en una base de datos de Amazon RDS para PostgreSQL:

  1. Tenga preparado un grupo de parámetros compatibles con la versión: si utiliza un grupo de parámetros personalizado, tiene dos opciones. Puede especificar un grupo de parámetros predeterminado para la nueva versión del motor de base de datos. O bien puede crear su propio grupo de parámetros personalizado para la nueva versión del motor de base de datos. Para obtener más información, consulte Grupos de parámetros para Amazon RDS y Trabajo con grupos de parámetros de clúster de base de datos para clústeres de base de datos Multi-AZ.

  2. Compruebe si hay clases de base de datos no admitidas: compruebe que la clase de instancia de la base de datos sea compatible con la versión de PostgreSQL a la que está actualizando. Para obtener más información, consulte Motores de base de datos compatibles para clases de instancia de base de datos.

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

    • Transacciones preparadas: 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 base de datos.

      SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
    • Tipos de datos reg*: elimine todos los tipos de datos reg* utilizados 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 no puede hacer persistir este tipo de datos, que Amazon RDS utiliza para realizar la actualización.

      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');
  4. Compruebe si hay bases de datos no válidas:

    • Asegúrese de que no haya bases de datos no válidas. La columna datconnlimit del catálogo de pg_database incluye un valor de -2 para marcar como no válidas las bases de datos que se interrumpieron durante una operación DROP DATABASE.

      Utilice la siguiente consulta para comprobar si hay bases de datos no válidas:

      SELECT datname FROM pg_database WHERE datconnlimit = - 2;
    • La consulta anterior devuelve nombres de bases de datos no válidos. Puede utilizar DROP DATABASE invalid_db_name; para eliminar las bases de datos no válidas. También puede utilizar el siguiente comando para eliminar bases de datos no válidas:

      SELECT 'DROP DATABASE ' || quote_ident(datname) || ';' FROM pg_database WHERE datconnlimit = -2 \gexec

    Para obtener más información sobre las bases de datos no válidas, consulte Comportamiento de autovacuum con bases de datos no válidas.

  5. Gestione los espacios de replicación lógicos: no se puede llevar a cabo una actualización si la base de datos tiene espacios de replicación lógicos. Los espacios de replicación lógicos se utilizan habitualmente para la migración de AWS DMS y la replicación de tablas de la base de datos a lagos de datos, herramientas de inteligencia empresarial (BI) y otros destinos. Antes de actualizar, asegúrese de conocer el propósito de los espacios de replicación lógicos que se están utilizando y confirme que es correcto eliminarlos. Si los espacios de replicación lógicos se siguen utilizando, no debe eliminarlos y no puede continuar con la actualización.

    Si no se necesitan los espacios de replicación lógicos, puede eliminarlos con el siguiente SQL:

    SELECT * FROM pg_replication_slots; SELECT pg_drop_replication_slot(slot_name);

    Las configuraciones de replicación lógica que utilizan la extensión pglogical también deben tener espacios eliminados para que la actualización de la versión principal se realice correctamente. Para obtener información sobre cómo identificar y eliminar los espacios creados con la extensión pglogical, consulte Administración de ranuras de replicación lógica para RDS para PostgreSQL.

  6. Gestione las réplicas de lectura: una actualización de una implementación de una instancia de base de datos Single-AZ o una instancia de base de datos Multi-AZ también actualiza las réplicas de lectura dentro de la región junto con la instancia de base de datos principal. Amazon RDS no actualiza réplicas de lectura de clústeres de base de datos Multi-AZ.

    No puede actualizar las réplicas de lectura por separado. Si pudiera, podría dar lugar a situaciones en las que las bases de datos principal y de réplica tienen distintas versiones principales de PostgreSQL. Sin embargo, las actualizaciones de réplica de lectura pueden aumentar el tiempo de inactividad en la instancia de base de datos principal. Para evitar una actualización de réplica de lectura, promueva la réplica a una instancia independiente o elimínela antes de iniciar el proceso de actualización.

    El proceso de actualización vuelve a crear el grupo de parámetros de la réplica de lectura basado en el grupo de parámetros actual de la réplica de lectura. Puede aplicar un grupo de parámetros personalizado a una réplica de lectura solo una vez finalizada la actualización con la modificación de la réplica de lectura. Para obtener más información acerca de las réplicas de lectura, consulte Uso de réplicas de lectura para Amazon RDS para PostgreSQL.

  7. Haga una copia de seguridad: es recomendable que realice una copia de seguridad antes de ejecutar la actualización de versión principal a fin de tener un punto de restauración conocido para la base de datos. Si el período de retención de copia de seguridad es mayor que 0, el proceso de actualización crea instantáneas de base de datos de su base de datos antes y después de la actualización. Para cambiar el periodo de retención de copia de seguridad, consulte Modificación de una instancia de base de datos de Amazon RDS y Modificación de un clúster de base de datos multi-AZ para Amazon RDS..

    Para realizar manualmente una copia de seguridad, consulte Creación de una instantánea de base de datos para una instancia de base de datos single-AZ para Amazon RDS y Creación de una instantánea de clúster de base de datos multi-AZ.

  8. Actualice determinadas extensiones antes de la actualización de versión principal: si prevé omitir una versión principal con la actualización, tiene que actualizar determinadas extensiones antes de llevar a cabo la actualización de versión principal. Por ejemplo, la actualización de las versiones 9.5.x o 9.6.x a las versiones 11.x omite una versión principal. Las extensiones que se van a actualizar incluyen PostGIS y las extensiones relacionadas para procesar datos espaciales.

    • address_standardizer

    • address_standardizer_data_us

    • postgis_raster

    • postgis_tiger_geocoder

    • postgis_topology

    Ejecute el comando siguiente para cada extensión que utilice:

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

    Para obtener más información, consulte Actualización de las extensiones de PostgreSQL en bases de datos de RDS para PostgreSQL. Para obtener más información acerca de la actualización de PostGIS, consulte Paso 6: Actualice la extensión de PostGIS.

  9. Eliminar determinadas extensiones antes de la actualización de versión principal: una actualización que omite una versión principal a la versión 11.x no es compatible con la actualización de la extensión pgRouting. La actualización de las versiones 9.4.x, 9.5.x o 9.6.x a las versiones 11.x omite una versión principal. Es seguro eliminar la extensión pgRouting y, a continuación, volver a instalarla en una versión compatible después de la actualización. Para conocer las versiones de extensión que puede actualizar, consulte Versiones de extensiones de PostgreSQL compatibles.

    Las extensiones tsearch2 y chkpass ya no se admiten para PostgreSQL versiones 11 o posteriores. Si está actualizando a la versión 11.x, elimine las extensiones tsearch2 y chkpass antes de la actualización.

  10. Elimine los tipos de datos desconocidos: elimine los tipos de datos unknown según la versión de destino.

    En la versión 10 de PostgreSQL se dejo de admitir el tipo de datos unknown. Si una base de datos de versión 9.6 utiliza el tipo de datos unknown, una actualización a una 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 buscar el tipo de datos unknown en la base de datos de modo que pueda eliminar la columna problemática o cambiarla a un tipo de datos compatible, utilice el siguiente SQL:

    SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';
  11. Ejecute un simulacro de actualización: es muy recomendable probar la 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 monitorizar los planes de ejecución de la base de datos 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 realizar una restauración de un momento dado de su base de datos en el último momento que se pueda restaurar.

    Para obtener más información, consulte Restauración a partir de una instantánea o Restauración de una instancia de base de datos a un momento especificado para Amazon RDS. Para los clústeres de base de datos Multi-AZ, consulte Restauración de una instantánea de clúster de base de datos Multi-AZ o Restauración de un clúster de base de datos Multi-AZ a un momento indicado.

    Para obtener información detallada sobre la realización de la actualización, consulte Actualización manual de la versión del motor.

    Al actualizar una base de datos de la versión 9.6 a la versión 10, tenga en cuenta que PostgreSQL 10 habilita consultas paralelas de forma predeterminada. Para probar el impacto del paralelismo antes de la actualización, cambie el parámetro max_parallel_workers_per_gather de la base de datos de prueba a 2.

    nota

    El valor predeterminado del parámetro max_parallel_workers_per_gather del grupo de parámetros de base de datos default.postgresql10 es 2.

    Para más información, consulte Parallel Query (Consulta paralela) en la documentación de PostgreSQL. Para desactivar el paralelismo en la versión 10, establezca el parámetro max_parallel_workers_per_gather a 0.

    Durante la actualización de la versión principal, se cambia temporalmente el nombre de las bases de datos public y template1, y del esquema public en todas las bases de datos. Estos objetos aparecen en los registros con su nombre original y una cadena aleatoria añadida. La cadena se añade de manera que ajustes personalizados, como locale y owner, se conserven durante la actualización de la versión principal. Cuando se complete la actualización, el nombre de los objetos se vuelve a cambiar al original.

    nota

    Durante el proceso de actualización a la versión principal, no puede realizar una restauración a un momento dado de la instancia de base datos o el clúster de base de datos Multi-AZ. Cuando Amazon RDS finaliza la actualización, realiza una copia de seguridad automática de la base de datos. Puede realizar una restauración a momentos anteriores al inicio de la actualización y posteriores a la finalización que la copia de seguridad automática de la base de datos.

  12. Si una actualización devuelve un error de procedimiento de comprobación previa: durante el proceso de actualización de versión principal, Amazon RDS for PostgreSQL primero ejecuta un procedimiento de comprobación previa para identificar algún problema que pueda provocar un error de actualización. El procedimiento de comprobación previa comprueba todas las posibles condiciones incompatibles en todas las bases de datos en la instancia.

    Si la comprobación previa encuentra un error, crea un evento de registro que indica que se ha producido un error en la comprobación previa de actualización. Los detalles del proceso de comprobación previa están en un registro de actualización denominado pg_upgrade_precheck.log para todas las bases de datos de una base de datos. Amazon RDS agrega una marca temporal al nombre de archivo. Para obtener más información acerca de cómo visualizar los archivos de registro, consulte Supervisión de archivos de registro de Amazon RDS.

    Si una actualización de réplica de lectura falla en la comprobación previa, la replicación en la réplica de lectura fallida se rompe y la réplica de lectura se pone en estado terminado. Elimine la réplica de lectura y vuelva a crear una nueva réplica de lectura basada en la instancia de base de datos principal actualizada.

    Resuelva todos los problemas identificados en el registro de comprobación previa y, a continuación, vuelva a intentar la actualización de versión principal. A continuación se muestra un ejemplo de un registro de comprobación previa.

    ------------------------------------------------------------------------ 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.* One or more role names start with 'pg_'. Rename all role names that start with 'pg_'. * The following issues in the database 'my"million$"db' need to be corrected before upgrading:** The ["line","reg*"] data types are used in user tables. Remove all usage of these data types. ** The database name contains characters that are not supported by RDS for PostgreSQL. Rename the database. ** The database has extensions installed that are not supported on the target database version. Drop the following extensions from your database: ["tsearch2"]. * The following issues in the database 'mydb' need to be corrected before upgrading:** The database has views or materialized views that depend on 'pg_stat_activity'. Drop the views.
  13. Si se produce un error en una actualización de réplica de lectura al actualizar la base de datos, resuelva el problema: una réplica de lectura con error se coloca en el estado incompatible-restore y la replicación termina en la base de datos. Elimine la réplica de lectura y vuelva a crear una nueva réplica de lectura basada en la instancia de base de datos principal actualizada.

    nota

    Amazon RDS no actualiza réplicas de lectura de clústeres de base de datos Multi-AZ. Si actualiza la versión principal de un clúster de base de datos multi-AZ, el estado de replicación de las réplicas de lectura cambia a terminado.

    Una actualización de réplica de lectura puede devolver un error por los siguientes motivos:

    • No se ha podido poner al día con la instancia de base de datos principal incluso después de un tiempo de espera.

    • Se encontraba en un estado de ciclo de vida de terminal o incompatible, como almacenamiento completo, restauración incompatible, etc.

    • Cuando se inició la actualización de la instancia de base de datos principal, había una actualización de versión secundaria independiente ejecutándose en la réplica de lectura.

    • La instancia de réplica de lectura utilizó parámetros incompatibles.

    • La réplica de lectura no ha podido comunicarse con la instancia de base de datos principal para sincronizar la carpeta de datos.

  14. Actualice su base de datos de producción: si el simulacro de actualización de la versión principal se ha completado correctamente, debe poder actualizar su base de datos de producción con confianza. Para obtener más información, consulte Actualización manual de la versión del motor.

  15. Ejecute la operación ANALYZE para actualizar la tabla pg_statistic. Debe hacerlo para cada base de datos en todas las bases 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.

Una vez completada una actualización de versión principal, le recomendamos lo siguiente: