Compartir a través de

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

SE APLICA A: Azure Database for PostgreSQL: servidor flexible

El servidor flexible de Azure Database for PostgreSQL admite las versiones 17 (versión preliminar) y 16, 15, 14, 13, 12 y 11 de PostgreSQL. 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. El servidor flexible de Azure Database for PostgreSQL actualiza periódicamente las versiones secundarias durante el período de mantenimiento del cliente.

Las actualizaciones de versiones principales son más complicadas que las actualizaciones de versiones secundarias. Pueden incluir cambios internos y nuevas características que podrían no ser compatibles con versiones anteriores de las aplicaciones existentes.

El servidor flexible de Azure Database for PostgreSQL tiene una característica que realiza una actualización de la versión principal local del servidor con solo un clic. 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.

Proceso de actualización

Estas son algunas de las consideraciones importantes a tener en cuenta al actualizar localmente una 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 actualización local de la versión principal, el servidor flexible de Azure Database for PostgreSQL ejecuta un procedimiento de comprobación previa para identificar cualquier problema potencial que pueda provocar un fallo 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 servidor flexible de Azure Database for PostgreSQL detiene el servicio y realiza una copia de seguridad implícita justo antes de iniciar la actualización. El servicio puede usar esta copia de seguridad para restaurar la instancia de base de datos a su versión anterior si se produce un error de actualización.
  • El servidor flexible de Azure Database for PostgreSQL usa la herramienta pg_upgrade para realizar actualizaciones de versiones principales in situ. 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 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.
  • 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 actualización de la versión principal local del servidor flexible de Azure Database for PostgreSQL implementa automáticamente la versión secundaria compatible más reciente.
  • Una actualización de versión principal local es una operación sin conexión, lo que significa que el servidor no estará disponible durante el proceso. Aunque la mayoría de las actualizaciones se completan en menos de 15 minutos, la duración real depende del tamaño y la complejidad de la base de datos. En concreto, el tiempo necesario es directamente proporcional al número de objetos (tablas, índices, esquemas) en la instancia de PostgreSQL. Los esquemas más grandes o más complejos pueden experimentar 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. Sin embargo, puede realizar una recuperación a un punto específico en el tiempo (PITR) antes de la actualización para restaurar la versión anterior de la instancia de base de datos.
  • El servidor flexible de Azure Database for PostgreSQL toma una instantánea de la base de datos durante una actualización. La instantánea se toma antes de que se inicie la actualización. Si se produce un error en la actualización, el sistema restaura automáticamente la base de datos a su estado a partir de la instantánea.
  • PostgreSQL 16 presenta medidas de seguridad basadas en roles. Después de una actualización de la versión principal en el servidor flexible de Azure Database for PostgreSQL, el primer usuario creado en el servidor ,al que se concede la opción ADMIN, ahora tendrá 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 versión principal local, la actualización se bloquea con un mensaje de error detallado. A continuación se muestran las limitaciones conocidas que pueden hacer que la actualización produzca un error o se comporte inesperadamente:

Configuraciones de servidor no admitidas

  • Las réplicas de lectura no se admiten durante las actualizaciones en el lugar. Debe eliminar la réplica de lectura 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 o 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 no se volverá a habilitar automáticamente tras la actualización. Es posible que tenga que actualizar manualmente las reglas de NSG y volver a habilitar la alta disponibilidad.
  • Las ranuras de replicación lógica no son compatibles durante las actualizaciones de versiones principales in situ.
  • Los servidores que usan almacenamiento SSDv2 no son aptos para las actualizaciones de versiones principales.
  • Las vistas que dependen de pg_stat_activity no se admiten durante las actualizaciones de versiones principales.

Limitaciones de extensión

Las actualizaciones de versión principal in situ no admiten todas las extensiones de PostgreSQL. Se producirá un error en la actualización durante la comprobación previa si se encuentran extensiones no admitidas.

  • Las siguientes extensiones no se admiten en ninguna versión de PostgreSQL: timescaledb, dblink, orafce, , pg_partman, postgres_fdw
  • No se admiten las siguientes extensiones cuando el destino de actualización es PostgreSQL 16 o superior: pgrouting
  • No se admiten las siguientes extensiones al actualizar a PostgreSQL 17: pgrouting, age, azure_ai, , , hllpg_diskann
  • Las extensiones como pg_repack, y hypopg no admiten actualizaciones en contexto y deben quitarse antes de la actualización y volver a crearla después. Estas extensiones son no persistentes y seguras para volver a configurar después de la actualización.

Estas extensiones deben quitarse del parámetro de servidor azure.extensions antes de la actualización. Si está presente, se bloqueará la actualización.

Consideraciones específicas de PostGIS

Si usa PostGIS o cualquier extensión dependiente, debe configurar el parámetro de servidor search_path 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 se configura correctamente el search_path puede provocar errores de actualización o objetos rotos después de la actualización.

Otras consideraciones de actualización

  • Objetos grandes (LO): las bases de datos con millones de objetos grandes (almacenados en pg_largeobject) pueden provocar errores de actualización debido a un uso elevado de memoria o volumen de registro. Use la utilidad vacuumlo para limpiar los LOs sin usar y considere aumentar la capacidad del servidor antes de actualizar si muchos LOs todavía están en uso.

Advertencia

Tenga cuidado con Vacuumlo. vacuumlo identifica objetos grandes huérfanos basados en columnas de referencia convencionales (oid, lo). Si la aplicación usa tipos de referencia personalizados o indirectos, los objetos grandes válidos se pueden eliminar erróneamente. Además, vacuumlo puede consumir cpu, memoria e IOPS importantes, especialmente en bases de datos con millones de objetos grandes. Ejecútelo durante las ventanas de mantenimiento y pruebe primero en no prod.

Después de la actualización

Una vez completada la actualización de la versión principal, se recomienda ejecutar el comando ANALYZE en cada base de datos para actualizar la tabla pg_statistic. 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

Los registros de actualización de versiones principales (PG_Upgrade_Logs) proporcionan acceso directo a los registros detallados del servidor. La integración de PG_Upgrade_Logs en el proceso de actualización puede ayudar a garantizar una transición más fluida y transparente a las nuevas versiones de PostgreSQL.

Puede configurar los registros de actualización de la versión principal de la misma manera que los registros de servidor mediante los siguientes parámetros de servidor:

  • Para activar la característica, establezca logfiles.download_enable en ON.
  • Para definir la retención de archivos de registro en días, use logfiles.retention_days.

Configuración de registros de actualización

Para empezar a usar PG_Upgrade_Logs, puede configurar la captura de los registros de servidor de PostgreSQL y los registros de actualización de versiones principales.

Puede acceder a los registros de actualización a través de la interfaz de usuario de los registros del servidor. Allí puede supervisar el progreso y los detalles de las actualizaciones de la versión principal de PostgreSQL en tiempo real. Esta interfaz de usuario proporciona una ubicación centralizada para ver los registros, por lo que puede realizar un seguimiento más fácil y solucionar problemas del proceso de actualización.

Ventajas del uso de registros de actualización

  • Diagnósticos detallados: PG_Upgrade_Logs proporcionan información útil sobre el proceso de actualización. Capturan información detallada de las operaciones realizadas y resaltan los errores o advertencias que se producen. Este nivel de detalle es fundamental para diagnosticar y resolver problemas que puedan surgir durante la actualización, para una transición más fluida.
  • Solución de problemas simplificada: gracias al acceso directo a estos registros, puede identificar y abordar rápidamente los posibles obstáculos de la actualización, lo que reduce el tiempo de inactividad y minimiza el impacto en las operaciones. Los registros sirven como una herramienta de solución de problemas crucial al habilitar una resolución de problemas más eficaz.

Nota:

Las actualizaciones de versiones principales locales se admiten en servidores de migración automática. Después de una actualización correcta de la versión principal en un servidor de migración automática, ya no se admitirá el formato de nombre de usuario username@servername . En su lugar, debe usar el formato estándar: nombre de usuario. Para evitar problemas de autenticación, revise detenidamente y actualice todas las cadenas de conexión de las aplicaciones y scripts para asegurarse de que usan el formato de nombre de usuario actualizado después de la actualización.

Contenido relacionado