Compartir a través de

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

  • Artículo

SE APLICA A: Azure Database for PostgreSQL con servidor flexible

El servidor flexible de Azure Database for PostgreSQL admite las versiones 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

Estas son algunas de las consideraciones importantes a tener en cuenta al actualizar localmente una versión principal:

  • 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 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 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 que da como resultado un breve período de tiempo de inactividad. El tiempo de inactividad suele ser inferior a 15 minutos. La duración puede variar según el número de tablas del sistema implicadas.

  • 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 momento dado (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 restaurará 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 actualizar una 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.

Posterior a la actualización o migració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. De lo contrario, puede encontrarse con problemas de rendimiento.

postgres=> analyze;
ANALYZE

Registros de actualización de versiones principales

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 los registros a través de Azure Portal o la CLI de Azure. Elija el método que mejor se adapte a su flujo de trabajo.

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.

Limitaciones

Si se produce un error en las operaciones de comprobación previa para una actualización de versión principal en contexto, se produce un error en la actualización con un mensaje detallado para todas las limitaciones siguientes:

  • Las actualizaciones de versiones principales en contexto no admiten actualmente réplicas de lectura. Si tiene un servidor que actúa como réplica de lectura, deberá eliminar la réplica antes de realizar la actualización en el servidor principal. Después de la actualización, puede volver a crear la réplica.

  • Azure Database for PostgreSQL: servidor flexible requiere la capacidad de enviar y recibir tráfico a los puertos de destino 5432 y 6432 en la red virtual en la que se implementa el servidor flexible y en Azure Storage para el archivado de registros.

    Si configura grupos de seguridad de red (NSG) para restringir el tráfico hacia o desde el servidor flexible dentro de su subred implementada, asegúrese de permitir el tráfico a los puertos de destino 5432 y 6432 dentro de la subred. Permita el tráfico a Azure Storage mediante la etiqueta de servicio Azure Storage como destino.

    Si las reglas de red no están configuradas correctamente, la alta disponibilidad no se habilita automáticamente después de una actualización de la versión principal y deberá habilitarla manualmente. Modifique las reglas del grupo de seguridad de red para permitir el tráfico de los puertos de destino y el almacenamiento, y para habilitar una característica de alta disponibilidad en el servidor.

  • Las actualizaciones de la versión principal local no admiten determinadas extensiones y hay algunas limitaciones para actualizar algunas de ellas. Las siguientes extensiones no son compatibles con todas las versiones de PostgreSQL: Timescaledb, pgaudit, dblink, orafce, pg_partman, postgres_fdw.

  • Al actualizar servidores con la extensión PostGIS instalada, establezca el parámetro de servidor search_path para incluir explícitamente lo siguiente:

    • Esquemas de la extensión PostGIS.
    • Extensiones que dependen de PostGIS.
    • Extensiones que sirven como dependencias para las siguientes extensiones: postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_us, fuzzystrmatch (obligatorio para postgis_tiger_geocoder).

  • No se admiten los servidores configurados con ranuras de replicación lógica.

  • Los servidores que usan almacenamiento SSDv2 no admiten actualizaciones de versiones principales.

Pasos siguientes