Actualización del motor de base de datos de PostgreSQL para Amazon RDS
Hay dos tipos de actualizaciones que se pueden administrar para su base de datos de PostgreSQL:
-
Actualizaciones del sistema operativo: a veces, Amazon RDS puede necesitar actualizar el sistema operativo subyacente de su base de datos para aplicar correcciones de seguridad o cambios del sistema operativo. Puede indicar cuándo Amazon RDS debe aplicar las actualizaciones del SO mediante la consola de RDS, la AWS Command Line Interface (AWS CLI) o la API de RDS. Para obtener más información acerca de las actualizaciones del sistema operativo, consulte Aplicación de actualizaciones a una instancia de base de datos o clúster de base de datos.
-
Actualizaciones del motor de la base de datos: cuando Amazon RDS admita una nueva versión de un motor de base de datos, puede actualizar sus bases de datos a la nueva versión.
En este contexto, una base de datos es una instancia de base de datos de RDS para PostgreSQL o un clúster de base de datos Multi-AZ.
Hay dos tipos de actualizaciones de motores de bases de datos de PostgreSQL: actualizaciones de versiones principales y actualizaciones de versiones secundarias.
- Actualizaciones de la versión principal
-
Las actualizaciones de la versión principal pueden contener cambios realizados en la base de datos que no son compatibles con las versiones anteriores de las aplicaciones. Por lo tanto, debe realizar manualmente las actualizaciones de versiones principales de sus bases de datos. Puede iniciar una actualización de versión principal modificando su instancia de base de datos o clúster de base de datos Multi-AZ. Antes de realizar la actualización de una versión principal, recomendamos que siga los pasos descritos en Elección de una actualización de versión principal para PostgreSQL.
Si actualiza una instancia de base de datos que tiene réplicas de lectura en la región, Amazon RDS actualiza las réplicas 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. 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. Debe eliminar las réplicas de lectura y volver a crearlas de forma manual una vez finalizada la actualización.
sugerencia
Puede minimizar el tiempo de inactividad necesario para la actualización de una versión principal mediante una implementación azul/verde. Para obtener más información, consulte Uso de las implementaciones azul/verde de Amazon RDS para actualizar las bases de datos.
- Actualizaciones de la versión secundaria
-
Por su parte, las actualizaciones de versiones secundarias solo incluyen cambios compatibles con las versiones anteriores de las aplicaciones. Puede iniciar manualmente una actualización de versiones secundarias modificando su base de datos. O puede habilitar la opción Actualización automática de versiones secundarias al crear o modificar una base de datos. Si lo hace, Amazon RDS actualizará automáticamente su base de datos tras probar y aprobar la nueva versión. Si la base de datos de PostgreSQL usa réplicas de lectura, debe actualizar todas las réplicas de lectura antes de actualizar la instancia o el clúster de origen.
Si la base de datos es una implementación de una instancia de base de datos multi-AZ, Amazon RDS actualiza simultáneamente la instancia principal y cualquier instancia en espera. Por lo tanto, es posible que su base de datos no esté disponible hasta que se complete la actualización. Si la base de datos es una implementación de un clúster de base de datos multi-AZ, Amazon RDS actualiza las instancias de base de datos del lector de una en una. A continuación, una de las instancias de base de datos de lector pasa a ser la nueva instancia de base de datos de escritor. Amazon RDS actualiza luego la antigua instancia de escritor (que ahora es una instancia de lector).
nota
El tiempo de inactividad para realizar una actualización de una versión secundaria de una implementación de una instancia de base de datos multi-AZ puede durar varios minutos. Los clústeres de bases de datos multi-AZ suelen reducir el tiempo de inactividad de las actualizaciones de versiones secundarias a aproximadamente 35 segundos. Cuando se utilizan con RDS Proxy, se puede reducir aún más el tiempo de inactividad a un segundo o menos. Para obtener más información, consulte Uso de Amazon RDS Proxy . También puede utilizar un proxy de base de datos de código abierto, como ProxySQL
, PgBouncer o el controlador JDBC de AWS para MySQL . Para obtener más información, consulte Actualizaciones de versiones secundarias automáticas para PostgreSQL. Para obtener más información acerca de cómo realizar manualmente una actualización de versiones secundarias, consulte Actualización manual de la versión del motor.
Para obtener más información acerca de las versiones del motor de base de datos y la política para dar de baja versiones del motor de base de datos, consulte Versiones del motor de base de datos
Temas
- Información general sobre la actualización de PostgreSQL
- Números de versión de PostgreSQL
- Número de versión de RDS
- Elección de una actualización de versión principal para PostgreSQL
- Cómo realizar una actualización de versión principal
- Actualizaciones de versiones secundarias automáticas para PostgreSQL
- Actualización de las extensiones de PostgreSQL
Información general sobre la actualización de PostgreSQL
Para actualizar de forma segura las bases de datos, Amazon RDS usa la utilidad pg_upgrade descrita en la documentación de PostgreSQL
Cuando se utiliza la AWS Management Console para actualizar una base de datos, muestra los destinos de actualización válidos para la base de datos. También puede utilizar el siguiente comando de la AWS CLI para identificar los destinos de actualización válidos de una base de datos:
Para Linux, macOS o:Unix
aws rds describe-db-engine-versions \ --engine postgres \ --engine-versionversion-number\ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
En:Windows
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-versionversion-number^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
Por ejemplo, para identificar los destinos de actualización válidos para una base de datos de la versión 12.13 de PostgreSQL, ejecute el siguiente comando de la:AWS CLI
Para Linux, macOS o:Unix
aws rds describe-db-engine-versions \ --engine postgres \ --engine-version 12.13 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
En:Windows
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-version 12.13 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
Si el periodo de retención de copia de seguridad es mayor que 0, Amazon RDS toma dos instantáneas de base de datos durante el proceso de actualización. La primera instantánea de base de datos es la de la base de datos antes de que se haya llevado a cabo ningún cambio. Si la actualización de sus bases de datos da por resultado un error, puede restaurar esta instantánea para crear una base de datos en la que se ejecuta la versión antigua. La segunda instantánea de base de datos se crea cuando se completa la actualización.
nota
Amazon RDS toma instantáneas de base de datos durante el proceso de actualización solo si ha definido el período de retención de copia de seguridad de su base de datos en un número mayor que 0. Para modificar el período de retención de copia de seguridad de una instancia de base de datos, consulte Modificación de una instancia de base de datos de Amazon RDS. No puede configurar un período de retención de copia de seguridad personalizado para un clúster de base de datos Multi-AZ.
Al actualizar la versión principal de una instancia de base de datos, todas las réplicas de lectura dentro de la región también se actualizan automáticamente. Una vez que se inicia 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. A continuación, la actualización de la instancia de base de datos principal espera a que se complete la actualización de la réplica de lectura. Habrá una interrupción hasta que se complete la actualización. Cuando 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 vez completada una actualización, no puede volver a la versión anterior del motor de base de datos. Si desea volver a la versión anterior, restaure la instantánea de base de datos que se realizó antes de la actualización para crear una nueva base de datos.
Números de versión de PostgreSQL
La secuencia de numeración de versiones para el motor de base de datos PostgreSQL es la siguiente:
-
Para las versiones 10 y posteriores de PostgreSQL, el número de versión del motor tiene el formato principal.secundaria. El número de versión principal es la parte entera del número de versión. El número de versión secundaria es la parte fraccional del número de versión.
Una actualización de versión principal aumenta la parte entera del número de versión, como la actualización de 10.secundaria a 11.secundaria.
-
Para las versiones de PostgreSQL anteriores a 10, el número de versión del motor tiene el formato principal.principal.secundaria. El número de versión principal del motor es tanto el entero como la primera parte fraccional del número de versión. Por ejemplo, 9.6 es una versión principal. El número de versión secundaria es la tercera parte del número de versión. Por ejemplo, para la versión 9.6.12, el 12 es el número de versión secundaria.
Una actualización de versión principal aumenta la parte principal del número de versión. Por ejemplo, una actualización de 9.6.12 a 11.14 es una actualización de versión principal, donde 9.6 y 11 son los números de la versión principal.
Para obtener información sobre la numeración de versiones del Soporte extendido de RDS, consulte Nombre de versiones con el Soporte extendido de Amazon RDS.
Número de versión de RDS
Los números de versión de RDS utilizan el esquema de nomenclatura major.minor.patch
Para identificar el número de versión de Amazon RDS de la base de datos, primero debe crear la extensión rds_tools mediante el siguiente comando:
CREATE EXTENSION rds_tools;
A partir del lanzamiento de la versión 15.2-R2 de PostgreSQL, puede averiguar el número de la versión de RDS de la base de datos de RDS para PostgreSQL con la siguiente consulta SQL:
postgres=>SELECT rds_tools.rds_version();
Por ejemplo, la consulta de una bases de datos de RDS para PostgreSQL 15.2 muestra lo siguiente:
rds_version ---------------- 15.2.R2 (1 row)
Elección de una actualización de versión principal para PostgreSQL
Las actualizaciones de la versión principal pueden contener cambios realizados en la base de datos que no son compatibles con las versiones anteriores de la base de datos. La nueva funcionalidad puede hacer que sus aplicaciones existentes dejen de funcionar correctamente. Por este motivo, Amazon RDS no aplica automáticamente actualizaciones de la versión principal. Para realizar una actualización de versión principal, modifique la base de datos manualmente. Pruebe exhaustivamente cualquier actualización para comprobar que las aplicaciones funcionen correctamente antes de aplicar la actualización a sus bases de datos de producción. Cuando realice una actualización de versión principal de PostgreSQL, recomendamos que siga los pasos descritos en Cómo realizar una actualización de versión principal.
Cuando actualiza una implementación de instancia de base de datos Multi-AZ o instancia de base de datos Single-AZ de PostgreSQL o a su siguiente versión principal, todas las réplicas de lectura asociadas a la base de datos también se actualizan a la siguiente versión principal. En algunos casos, cuando hace una actualización puede saltar hasta una versión principal superior. Si la actualización omite una versión principal, las réplicas de lectura también se actualizan a esa versión principal de destino. Las actualizaciones a la versión 11 que omiten otras versiones principales tienen ciertas limitaciones. Puede encontrar los detalles en los pasos descritos en Cómo realizar una actualización de versión principal.
La mayoría de las extensiones de PostgreSQL no se actualizan durante la actualización del motor PostgreSQL. Estas deben actualizarse por separado. Para obtener más información, consulte Actualización de las extensiones de PostgreSQL.
Puede averiguar qué versiones principales están disponibles para su base de datos de RDS para PostgreSQL mediante la ejecución de las siguientes consultas de la:AWS CLI
aws rds describe-db-engine-versions --engine postgres --engine-versionyour-version--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
En la tabla siguiente se resumen los resultados de esta consulta para todas las versiones disponibles. Un asterisco (*) en el número de versión significa que la versión ya no es compatible. Si la versión actual ya nos es compatible, le recomendamos que actualice al destino de actualización de versión secundaria más reciente o a uno de los otros destinos de actualización disponibles para esa versión.
* Esta versión ya no es compatible.
Cómo realizar una actualización de versión principal
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:
-
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.
-
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.
-
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
regtypeyregclass, no se puede actualizar los tipos de datos reg*. La utilidadpg_upgradeno 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');
-
-
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
pglogicaltambié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ónpglogical, consulte Administración de ranuras de replicación lógica para RDS para PostgreSQL. -
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.
-
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 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 y Creación de una instantánea de un clúster de base de datos Multi-AZ.
-
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 EXTENSIONPostgreSQL-extensionUPDATE 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.
-
-
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ónpgRoutingy, 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
tsearch2ychkpassya no se admiten para PostgreSQL versiones 11 o posteriores. Si está actualizando a la versión 11.x, elimine las extensionestsearch2ychkpassantes de la actualización. -
Elimine los tipos de datos desconocidos: elimine los tipos de datos
unknownsegú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 datosunknown, 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
unknownen 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'; -
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 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_gatherde la base de datos de prueba a 2.nota
El valor predeterminado del parámetro
max_parallel_workers_per_gatherdel grupo de parámetros de base de datosdefault.postgresql10es 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_gathera 0.Durante la actualización de la versión principal, se cambia temporalmente el nombre de las bases de datos
publicytemplate1, y del esquemapublicen 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, comolocaleyowner, 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.
-
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.logpara 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. -
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-restorey 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.
-
-
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.
-
Ejecute la operación
ANALYZEpara actualizar la tablapg_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
VERBOSEes opcional, pero su uso muestra el progreso. Para obtener más información, consulte ANALYZEen 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:
-
Una actualización de PostgreSQL no actualiza ninguna extensión de PostgreSQL. Para actualizar extensiones, consulte Actualización de las extensiones de PostgreSQL.
-
Como opción, utilice Amazon RDS para ver dos registros que produce la utilidad
pg_upgrade. Estos sonpg_upgrade_internal.logypg_upgrade_server.log. Amazon RDS 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 RDS.También puede cargar los registros de actualización en registros de Amazon Cloudwatch. Para obtener más información, consulte Publicación de registros de PostgreSQL en Amazon CloudWatch Logs.
-
Para comprobar que todo funciona del modo previsto, pruebe su aplicación en la base de datos actualizada con una carga de trabajo similar. Cuando haya comprobado la actualización, podrá eliminar esta instancia de prueba.
Actualizaciones de versiones secundarias automáticas para PostgreSQL
Si habilita la opción Actualización automática de versiones secundarias al crear o modificar una instancia de base de datos o un clúster de base de datos Multi-AZ, puede hacer que la base de datos se actualice automáticamente.
RDS asigna una versión secundaria como la versión de actualización automática para cada versión principal de RDS for PostgreSQL. Después de que Amazon RDS pruebe y apruebe una versión secundaria, la actualización de versión secundaria se produce automáticamente durante el periodo de mantenimiento. RDS no configura automáticamente versiones secundarias publicadas recientemente como la versión de actualización automática. Antes de que RDS asigne una versión de actualización automática más reciente, deben considerarse algunos criterios, como, por ejemplo, los que se indican a continuación:
-
Problemas de seguridad conocidos
-
Errores en la versión de la comunidad de PostgreSQL
-
Estabilidad general de la flota desde que se publicó la versión secundaria
Puede utilizar el siguiente comando de la AWS CLI para determinar la versión actual de destino de actualización secundaria automática para una versión secundaria de PostgreSQL especificada en una Región de AWS específica.
Para Linux, macOS o:Unix
aws rds describe-db-engine-versions \ --engine postgres \ --engine-versionminor-version\ --regionregion\ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \ --output text
En:Windows
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-versionminor-version^ --regionregion^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^ --output text
Por ejemplo, el siguiente comando de la AWS CLI determina el destino de actualización secundaria automática para la versión secundaria 12.13 de PostgreSQL en la Región de AWS de Este de EE. UU. (Ohio) (us-east-2).
Para Linux, macOS o:Unix
aws rds describe-db-engine-versions \ --engine postgres \ --engine-version 12.13 \ --region us-east-2 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \ --output table
En:Windows
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-version 12.13 ^ --region us-east-2 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^ --output table
Su resultado es similar al siguiente.
---------------------------------- | DescribeDBEngineVersions | +--------------+-----------------+ | AutoUpgrade | EngineVersion | +--------------+-----------------+ | True | 12.14 | | False | 12.15 | | False | 13.9 | | False | 13.10 | | False | 13.11 | | False | 14.6 | +--------------+-----------------+
En este ejemplo, el valor AutoUpgrade es True para la versión 12.14 de PostgreSQL. Por lo tanto, el destino de actualización secundaria automática es la versión 12.14 de PostgreSQL, que está resaltado en el resultado.
Una base de datos de PostgreSQL se actualiza automáticamente durante el periodo de mantenimiento si se cumplen los siguientes criterios:
-
La base de datos tiene habilitada la Actualización automática de versiones secundarias.
-
La base de datos se ejecuta en una versión secundaria del motor de base de datos que es anterior a la versión secundaria de actualización automática actual.
Para obtener más información, consulte Actualización automática de la versión secundaria del motor.
nota
Una actualización de PostgreSQL no actualiza extensiones de PostgreSQL. Para actualizar extensiones, consulte Actualización de las extensiones de PostgreSQL.
Actualización de las extensiones de PostgreSQL
Una actualización del motor de PostgreSQL no actualiza la mayoría de las extensiones de PostgreSQL. Para actualizar una extensión después de una actualización de versiones, utilice el comando ALTER
EXTENSION UPDATE.
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 base de datos actualizada. Para obtener más información, consulte pg_repack installationpg_repack.
Para actualizar una extensión, utilice el siguiente comando.
ALTER EXTENSIONextension_nameUPDATE TO 'new_version';
Para consultar la lista de versiones compatibles de extensiones de PostgreSQL, vea Versiones de extensiones de PostgreSQL compatibles.
Para enumerar las extensiones instaladas actualmente, utilice el catálogo pg_extension
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
SELECT * FROM pg_available_extension_versions;
