Compartir vía

Actualizaciones de versión principal de Azure Database for PostgreSQL

La instancia de servidor flexible de Azure Database for PostgreSQL admite las versiones 18, 17, 16, 15, 14, 13, 12 y 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. Una instancia de servidor flexible de 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 características que podrían no ser compatibles con versiones anteriores de las aplicaciones existentes.

La instancia de 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.

Nota:

Azure Database for PostgreSQL admite actualizaciones de versiones principales en contexto solo a las versiones de PostgreSQL admitidas actualmente. Por ejemplo, puede actualizar la versión actual dado que Azure admite oficialmente la versión de destino en el momento de la actualización. Las versiones no admitidas no se pueden seleccionar como destinos de actualización y el intento de actualizar a una versión en desuso puede provocar errores o interrupciones del servicio. Consulte siempre la directiva de control de versiones de Azure PostgreSQL y la documentación de actualización antes de iniciar una actualización de la versión principal.

Nota:

Las actualizaciones de la versión principal a PostgreSQL 18 se habilitan en fases. En este momento, MVU a PostgreSQL 18 está disponible en las regiones NorthCentralUS y WestCentralUS.

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 una actualización de la versión principal local, la instancia de 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, la instancia de servidor flexible de Azure Database for PostgreSQL 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 para restaurar la instancia de base de datos a su versión anterior si se produce un error de actualización.
  • Una instancia de servidor flexible de Azure Database for PostgreSQL usa la herramienta pg_upgrade para realizar actualizaciones de versiones principales en contexto. 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 una actualización de versión principal local para una instancia de 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.
  • La instancia de 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 una instancia de 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 contexto. 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 la instancia de 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.
  • Si va a realizar la actualización de PG11 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 inicio de sesión.

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 se admiten para uso normal, pero bloquearán una actualización de versión principal local si existe. Quítelos antes de la actualización y vuelva a habilitarlos después, si se admite en la versión de destino: timescaledb, dblink, orafce, postgres_fdw.
  • Las siguientes extensiones son extensiones de utilidad no persistentes y deben quitarse y volver a crearse después de la actualización por diseño: pg_repack, hypopg.
  • Al actualizar a PostgreSQL 17, no se admiten las siguientes extensiones y se deben quitar antes de la actualización. Solo puede volver a habilitarlos si se admite en la versión de destino: age, azure_ai, hll, pg_diskann, . pgrouting

Nota: Si alguna de estas extensiones aparece en el parámetro de azure.extensions servidor, se bloqueará la actualización. Quítelos del parámetro antes de iniciar 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

  • Desencadenadores de eventos: bloqueará los desencadenadores de eventos en la pre-comprobación de actualización porque se enlazan a comandos DDL y pueden hacer referencia a catálogos del sistema que cambian entre versiones principales. Quite todos los desencadenadores EVENT TRIGGER antes de actualizar y vuelva a crearlos después de la actualización para garantizar una actualización sin problemas.
  • 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

  • Last updated on