Actualizaciones de versión principal de Azure Database for PostgreSQL: servidor flexible

El servidor flexible de Azure Database for PostgreSQL admite las versiones 18, 17, 16, 15, 14, 13, 12, 11. La comunidad de Postgres lanza una nueva versión principal que contiene nuevas características aproximadamente una vez al año. Además, cada versión principal recibe correcciones periódicas de errores en forma de versiones secundarias. Las actualizaciones de versiones secundarias incluyen cambios compatibles con versiones anteriores de las aplicaciones existentes. Un servidor flexible Azure Database for PostgreSQL actualiza periódicamente las versiones secundarias durante la ventana de mantenimiento de un cliente.

Las actualizaciones de versiones principales son más complicadas que las actualizaciones de versiones secundarias. Pueden incluir cambios internos y nuevas funciones que no son compatibles con versiones anteriores de las aplicaciones existentes.

Su servidor flexible de Azure Database for PostgreSQL cuenta con una función que realiza una actualización in situ de la versión principal del servidor. Esta característica simplifica el proceso de actualización minimizando la interrupción de los usuarios y las aplicaciones que acceden al servidor.

Las actualizaciones en contexto conservan el nombre del servidor y otras configuraciones del servidor actual después de la actualización de una versión principal. No requieren migración de datos ni cambios en las cadenas de conexión de la aplicación. Las actualizaciones locales son más rápidas e implican un menor tiempo de inactividad que la migración de datos.

Mejorar las comprobaciones de validación

Azure Database for PostgreSQL - Servidor flexible ofrece comprobaciones de validación de actualización para ayudar a evaluar la preparación para la actualización antes de iniciar una actualización de versión principal.

Las comprobaciones de validación de actualización ejecutan una serie de validaciones de compatibilidad y configuración en el servidor para identificar condiciones que podrían provocar un error en la actualización o comportarse inesperadamente. Las comprobaciones comunes incluyen extensiones no admitidas, ranuras de replicación lógica, transacciones preparadas, desencadenadores de eventos, dependencias de objetos no admitidas y cambios de configuración pendientes que requieren reinicio.

El proceso de validación está diseñado para evaluar la preparación de la actualización sin iniciar la operación de actualización real. Las mismas comprobaciones de validación también se realizan automáticamente durante el flujo de trabajo de actualización de la versión principal. Estas comprobaciones no modifican la versión del servidor, desencadenan el tiempo de inactividad ni reinician el servidor. Ejecute comprobaciones de validación antes de programar una ventana de actualización de producción.

Puede ejecutar comprobaciones de validación de actualización en el portal de Azure o con el CLI de Azure. Para obtener instrucciones, consulte Ejecución de comprobaciones de validación de actualización.

Una vez completada la validación, se devuelve uno de los siguientes resultados:

• No se detectaron problemas de bloqueo: las comprobaciones de validación de actualización se completaron correctamente y no identificaron ningún problema que bloquee la actualización.
• Problemas de bloqueo detectados: las comprobaciones de validación de actualización han identificado uno o varios problemas que se deben resolver antes de que pueda continuar la actualización.

En función de los resultados, puede continuar con la actualización o corregir los problemas notificados y volver a ejecutar la validación.

Limitaciones

Al usar las comprobaciones de validación de actualización, tenga en cuenta las siguientes limitaciones:

• El estado del servidor debe ser Listo.
• Las comprobaciones de validación no se admiten en réplicas de lectura.
• La validación no se puede ejecutar mientras otra operación del servidor ya está en curso.
• Las comprobaciones de validación requieren conectividad con todas las bases de datos del servidor. Las bases de datos no respondes o inaccesibles pueden provocar errores de validación.
• Aunque las comprobaciones de validación no provocan tiempo de inactividad, considere la posibilidad de ejecutarlas durante períodos de menor actividad de la base de datos.

Para obtener instrucciones paso a paso, consulte Ejecución de comprobaciones de validación de actualización.

Proceso de actualización

Estas son algunas consideraciones importantes para las actualizaciones locales de versión principal:

• Antes de iniciar la actualización, asegúrese de que el servidor tenga al menos 10-20% almacenamiento gratuito disponible. Durante el proceso de actualización, los archivos de registro temporales y las operaciones de metadatos pueden aumentar el uso del disco. El espacio disponible insuficiente puede provocar errores de actualización o problemas de reversión.
• Durante el proceso de una actualización de versión principal local, el servidor flexible de Azure Database for PostgreSQL ejecuta un procedimiento de comprobación previa para identificar los posibles problemas que podrían provocar un error en la actualización.
  • Si la comprobación previa encuentra incompatibilidades, crea un evento de registro que muestra que se produjo un error en la comprobación previa de la actualización, junto con un mensaje de error.
  • Si la comprobación previa se realiza correctamente, el Azure Database for PostgreSQL servidor flexible detiene el servicio y toma una copia de seguridad implícita justo antes de iniciar la actualización. El servicio puede usar esta copia de seguridad implícita para restaurar la instancia de base de datos a su versión anterior si se produce un error de actualización.
• Un servidor flexible de Azure Database for PostgreSQL utiliza la herramienta pg_upgrade para realizar actualizaciones locales de versión principal. El servicio proporciona la flexibilidad de omitir las versiones y actualizar directamente a versiones posteriores.
• Durante una actualización de versión principal local de un servidor, que está habilitado para alta disponibilidad (HA), el servicio deshabilita la alta disponibilidad, realiza la actualización en el servidor principal y, a continuación, vuelve a habilitar la alta disponibilidad una vez completada la actualización. Volver a habilitar la alta disponibilidad requiere tener capacidad suficiente para aprovisionar una nueva instancia de reserva.
• La mayoría de las extensiones se actualizan automáticamente a versiones posteriores durante una actualización de la versión principal local, con algunas excepciones.
• El proceso de una actualización de versión principal local para un servidor flexible de Azure Database for PostgreSQL implementa automáticamente la versión secundaria compatible más reciente.
• La duración de la actualización depende del tamaño y la complejidad de la base de datos, incluido el número de objetos (tablas, índices, esquemas), objetos grandes y extensiones. Es posible que las cargas de trabajo más grandes o más complejas experimenten tiempos de actualización más largos.
• Las transacciones de larga duración o una carga de trabajo elevada antes de la actualización pueden aumentar el tiempo necesario para apagar la base de datos y aumentar el tiempo de actualización.
• Una vez que la actualización de la versión principal local se realiza correctamente, no hay formas automatizadas de revertir a la versión anterior. Puede realizar una recuperación a un momento dado (PITR) a un momento anterior a la actualización para restaurar la versión anterior en un nuevo servidor.
• Proteja el servidor Azure Database for PostgreSQL. Después de actualizar una versión principal en un servidor flexible Azure Database for PostgreSQL, el primer usuario creado en el servidor, al que se le concede la opción ADMIN, ahora tiene privilegios administrativos sobre otros roles para las operaciones de mantenimiento esenciales.

Consideraciones y limitaciones de actualización

Si se produce un error en una operación de comprobación previa durante una actualización de la versión principal local, el proceso de actualización se detiene y muestra un mensaje de error detallado. Las siguientes limitaciones conocidas pueden provocar un error en la actualización o comportarse inesperadamente:

Configuraciones de servidor no admitidas

• La georreplicación en Azure Database for PostgreSQL no se admite durante las actualizaciones locales. Debe eliminar la réplica de lectura (incluida cualquier réplica de lectura en cascada) antes de actualizar el servidor principal. Después de la actualización, puede volver a crear la réplica.
• Las reglas de tráfico de red pueden bloquear las operaciones de actualización.
  • Asegúrese de que el servidor flexible puede enviar y recibir tráfico en los puertos 5432 y 6432 dentro de su red virtual y en Azure Storage (para el archivado de registros).
  • Si los grupos de seguridad de red (NSG) restringen este tráfico, la alta disponibilidad (HA) no se vuelve a habilitar automáticamente tras la actualización. Es posible que tenga que actualizar manualmente las reglas de NSG y volver a habilitar HA.
• Las vistas que dependen de pg_stat_activity no se admiten durante las actualizaciones a versiones principales.
• Si va a actualizar de PostgreSQL 11 a una versión superior, primero debe configurar el servidor flexible para usar la autenticación SCRAM habilitando SCRAM y restableciendo todas las contraseñas de rol de autenticación.

Limitaciones de extensión

Las actualizaciones in situ de versiones principales no admiten todas las extensiones de PostgreSQL. La actualización produce un error durante la comprobación previa si hay una extensión bloqueada en una ruta de actualización afectada. La mayoría de los bloques se aplican a versiones concretas de destino (y, en ocasiones, de origen) en lugar de a todas las actualizaciones, como se indica en las listas siguientes.

• Las siguientes extensiones bloquean una actualización in situ a una versión principal en todas las rutas de actualización. Quítelos antes de la actualización y vuelva a habilitarlos después, si se admite en la versión de destino: session_variable, anon, age.

• Las siguientes extensiones son extensiones de utilidad no persistentes y deben quitarse antes de la actualización y volver a crearse después, por diseño (todas las rutas de actualización): pg_repack, , hypopgpg_partman.

• Las siguientes extensiones solo se bloquean en rutas de acceso de versión específicas. Quítelos antes de la actualización si la actualización coincide con la condición indicada y vuelve a habilitarla después de si se admite en la versión de destino:

  Extension	Bloqueado cuando
  pg_hint_plan	La versión de destino es PostgreSQL 14
  semver	La versión de destino es PostgreSQL 16 o 17
  azure_local_ai	La versión de destino es PostgreSQL 17 o 18
  pg_failover_slots	La versión de destino es PostgreSQL 17 o 18 (biblioteca de precarga compartida)
  azure_ai	La versión de destino es PostgreSQL 18
  azure_storage	La versión de destino es PostgreSQL 18
  pg_diskann	La versión de destino es PostgreSQL 18
  pgrouting	La versión de destino es PostgreSQL 15; o el origen es anterior a PostgreSQL 16 y el destino es PostgreSQL 16 o posterior; o la versión de destino es PostgreSQL 18
  orafce	La versión de origen es PostgreSQL 11, 12 o 13

• Las extensiones siguientes se bloquean cuando otros objetos de base de datos dependen de sus objetos, ya que, de lo contrario, se produciría un error en la actualización. Solucione las dependencias antes de la actualización:

  • pg_stat_statements: se bloquea cuando otros objetos dependen de su vista o función, lo que provocaría ALTER EXTENSION pg_stat_statements UPDATE un error. Quite primero los objetos dependientes.
  • pgcrypto: cuando se instala en el esquema pg_catalog y se actualiza de PostgreSQL 11 o 12 a PostgreSQL 13 o posterior, se bloquea cuando los objetos del cliente dependen de él (un conflicto con la función integrada gen_random_uuid()). Reubicar la extensión en otro esquema o quitar primero los objetos dependientes.

Consideraciones específicas de PostGIS

Si usa PostGIS o cualquier extensión dependiente, configure el search_path parámetro para incluir:

• Esquemas relacionados con PostGIS
• Extensiones dependientes, incluidas: postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoderpostgis_topology, , address_standardizeraddress_standardizer_data_usfuzzystrmatch
• Si no configuras correctamente el search_path, la actualización puede fallar o dañar objetos después de la actualización.

Consideraciones específicas de TimescaleDB

Si usa TimescaleDB, las actualizaciones de versiones principales en contexto solo se admiten para combinaciones específicas de versiones de origen y de destino de PostgreSQL:

Si la ruta de actualización de TimescaleDB no figura en la matriz compatible, la actualización in situ a una versión mayor queda bloqueada. Para continuar, quite la extensión TimescaleDB antes de la actualización, si es factible, o use un enfoque de migración alternativo, como la migración en paralelo con la replicación lógica.

Asegúrese de que las versiones de origen y destino se incluyen en la matriz admitida antes de iniciar la actualización.

Otras consideraciones de actualización

• Desencadenadores de eventos: la comprobación previa a la actualización bloquea los desencadenadores de eventos porque se enganchan a comandos DDL y pueden hacer referencia a catálogos del sistema que cambian entre versiones mayores. Quite todos los EVENT TRIGGER antes de realizar la actualización y vuelva a crearlos después para garantizar que la actualización se realice sin problemas.
• Objetos grandes (LOs): la forma en que una actualización controla las bases de datos que contienen millones de objetos grandes (almacenados en pg_largeobject) depende de la versión principal de destino:
  • PostgreSQL 15 o posterior como destino: la actualización utiliza un método optimizado de procesamiento masivo para transferir metadatos de objetos grandes, por lo que el uso de memoria y de espacio temporal en disco ya no aumenta en función del número de objetos grandes. Las bases de datos con decenas o cientos de millones de objetos grandes se actualizan de forma confiable sin preparación adicional. No es necesario ejecutar vacuumlo ni ampliar la capacidad del servidor de antemano para sortear el problema del gran volumen de objetos grandes, aunque aún puedes ejecutar vacuumlo para eliminar objetos grandes no utilizados por otros motivos.
  • PostgreSQL 14 o anterior como destino: las bases de datos con millones de objetos grandes pueden provocar fallos en la actualización debido a un uso elevado de memoria o a un gran volumen de registros. Use la utilidad vacuumlo para limpiar objetos grandes sin usar y considere la posibilidad de escalar verticalmente el servidor antes de la actualización si muchos objetos grandes todavía están en uso.

Después de la actualización

Una vez completada la actualización de la versión principal, ejecute el ANALYZE comando en cada base de datos para actualizar la pg_statistic tabla. Las estadísticas obsoletas o que faltan pueden provocar planes de consulta incorrectos, lo que a su vez podría degradar el rendimiento y ocupar memoria excesiva.

postgres=> analyze;
ANALYZE

Visualización de los registros de actualización

Use PG_Upgrade_Logs para supervisar el progreso de la actualización y solucionar problemas. Revise los registros durante y después de la actualización para realizar un seguimiento del progreso, diagnosticar errores o retrasos e identificar problemas de bloqueo para que pueda tomar medidas correctivas rápidamente.

Habilitación de registros de actualización mediante parámetros de registro de servidor

• Establezca logfiles.download_enable en ENCENDIDO.
• Configure la retención con logfiles.retention_days.

Consulte Descarga de PostgreSQL y actualización de registros para empezar.

Contenido relacionado

• Actualización de la versión principal
• Ejecución de comprobaciones de validación de actualización