Mises à niveau de versions majeures dans un serveur flexible Azure Database pour PostgreSQL

Votre serveur flexible Azure Database pour PostgreSQL prend en charge PostgreSQL versions 18, 17, 16, 15, 14, 13, 12, 11. La communauté Postgres publie une nouvelle version principale contenant de nouvelles fonctionnalités environ une fois par an. En outre, chaque version principale reçoit des correctifs de bogues périodiques sous la forme de versions mineures. Les mises à niveau de version mineures incluent des modifications qui sont rétrocompatibles avec les applications existantes. Un serveur flexible Azure Database pour PostgreSQL met régulièrement à jour les versions mineures pendant la fenêtre de maintenance d'un client.

Les mises à niveau de versions principales sont plus complexes que les mises à niveau de version mineures. Ils peuvent inclure des modifications internes et de nouvelles fonctionnalités qui ne sont pas compatibles avec les applications existantes.

Votre serveur flexible Azure Database pour PostgreSQL dispose d’une fonctionnalité qui effectue une mise à niveau majeure sur place du serveur. Cette fonctionnalité simplifie le processus de mise à niveau en minimisant les interruptions pour les utilisateurs et les applications accédant au serveur.

Les mises à niveau sur place conservent le nom du serveur et d’autres paramètres du serveur actuel après la mise à niveau de version principale. Elles ne nécessitent pas de migration de données ni de modifications des chaînes de connexion d’application. Les mise à niveau sur place sont plus rapides et impliquent un temps d’arrêt plus court que la migration des données.

Note

Azure Database pour PostgreSQL prend en charge les mises à niveau principales sur place uniquement vers les versions PostgreSQL actuellement prises en charge. La version cible doit être officiellement prise en charge par Azure au moment de la mise à niveau. Le portail Azure empêche la sélection de versions non prises en charge, mais les appels API ou CLI qui ciblent une version déconseillée échouent. Consultez toujours la stratégie de contrôle de version Azure PostgreSQL et guide pratique avant de lancer une mise à niveau de version majeure.

Vérifications de validation de mise à niveau

Azure Database pour PostgreSQL serveur flexible fournit des vérifications de validation de mise à niveau pour vous aider à évaluer la préparation de la mise à niveau avant de commencer une mise à niveau de version majeure.

Les vérifications de validation de mise à niveau exécutent une série de validations de compatibilité et de configuration sur le serveur pour identifier les conditions susceptibles d’entraîner l’échec ou le comportement inattendu de la mise à niveau. Les vérifications courantes incluent les extensions non prises en charge, les emplacements de réplication logique, les transactions préparées, les déclencheurs d’événements, les dépendances d’objet non prises en charge et les modifications de configuration requises pour le redémarrage en attente.

Le processus de validation est conçu pour évaluer la préparation à la mise à niveau sans lancer l’opération de mise à niveau réelle. Les mêmes vérifications de validation sont également effectuées automatiquement pendant le workflow de mise à niveau de version majeure. Ces vérifications ne modifient pas la version du serveur, déclenchent un temps d’arrêt ou redémarrent le serveur. Exécutez des vérifications de validation avant de planifier une fenêtre de mise à niveau de production.

Vous pouvez exécuter des vérifications de validation de mise à niveau dans le portail Azure ou avec le Azure CLI. Pour obtenir des instructions, consultez Exécuter les vérifications de validation de mise à niveau.

Une fois la validation terminée, l’un des résultats suivants est retourné :

  • Aucun problème de blocage détecté : les vérifications de validation de mise à niveau ont réussi et n’ont pas identifié de problèmes qui bloquent la mise à niveau.
  • Problèmes de blocage détectés : les vérifications de validation de mise à niveau ont identifié un ou plusieurs problèmes qui doivent être résolus avant que la mise à niveau puisse continuer.

Selon les résultats, vous pouvez poursuivre la mise à niveau ou corriger les problèmes signalés et réexécuter la validation.

Limitations

Lorsque vous utilisez les vérifications de validation de mise à niveau, tenez compte des limitations suivantes :

  • L’état du serveur doit être Prêt.
  • Les vérifications de validation ne sont pas prises en charge sur les réplicas en lecture.
  • La validation ne peut pas s’exécuter pendant qu’une autre opération de serveur est déjà en cours.
  • Les vérifications de validation nécessitent une connectivité à toutes les bases de données sur le serveur. Les bases de données non répondantes ou inaccessibles peuvent entraîner des échecs de validation.
  • Bien que les vérifications de validation ne provoquent pas de temps d’arrêt, envisagez de les exécuter pendant des périodes d’activité de base de données inférieure.

Pour obtenir des instructions pas à pas, consultez Exécuter les vérifications de validation de mise à niveau.

Processus de mise à niveau

Voici quelques points importants à prendre en compte pour les mises à niveau des versions principales sur place :

  • Avant de commencer la mise à niveau, vérifiez que votre serveur dispose d’au moins 10 à 20% stockage gratuit disponible. Pendant le processus de mise à niveau, les fichiers journaux temporaires et les opérations de métadonnées peuvent augmenter l’utilisation du disque. L’espace libre insuffisant peut entraîner des échecs de mise à niveau ou des problèmes de restauration.
  • Pendant le processus de mise à niveau de version majeure sur place, votre serveur flexible Azure Database pour PostgreSQL exécute une procédure de pré-vérification pour identifier les éventuels problèmes susceptibles d’entraîner l’échec de la mise à niveau.
    • Si la vérification préalable détecte des incompatibilités, elle crée un événement de journal indiquant que la vérification préalable de la mise à niveau a échoué, avec un message d’erreur.
    • Si la vérification préalable réussit, le serveur flexible Azure Database pour PostgreSQL arrête le service et effectue une sauvegarde implicite juste avant de commencer la mise à niveau. Le service peut utiliser cette sauvegarde implicite pour restaurer l’instance de base de données vers sa version précédente en cas d’erreur de mise à niveau.
  • Un serveur flexible Azure Database pour PostgreSQL utilise l’outil pg_upgrade pour effectuer des mises à niveau principales sur place. Le service offre la possibilité d’ignorer les versions et de mettre à niveau directement vers les versions ultérieures.
  • Au cours d’une mise à niveau principale sur place d’un serveur, qui est activée pour la haute disponibilité(HA), le service désactive la haute disponibilité, effectue la mise à niveau sur le serveur principal, puis réactive la haute disponibilité une fois la mise à niveau terminée. La réactivation de la haute disponibilité nécessite une capacité suffisante pour provisionner une nouvelle instance de secours.
  • La plupart des extensions sont automatiquement mises à niveau vers des versions ultérieures lors d’une mise à niveau de version principale sur place, à quelques exceptions près.
  • Le processus de mise à niveau de version majeure sur place pour un serveur flexible Azure Database pour PostgreSQL déploie automatiquement la dernière version mineure prise en charge.
  • La durée de mise à niveau dépend de la taille et de la complexité de votre base de données, y compris le nombre d’objets (tables, index, schémas), les objets volumineux et les extensions. Des charges de travail plus volumineuses ou plus complexes peuvent rencontrer des temps de mise à niveau plus longs.
  • Les transactions de longue durée ou une charge de travail élevée avant la mise à niveau peuvent augmenter le temps nécessaire pour arrêter la base de données et augmenter le temps de mise à niveau.
  • Après une mise à niveau de version principale sur place réussie, il n’existe aucun moyen automatisé de revenir à la version antérieure. Vous pouvez effectuer une récupération à un instant donné (PITR) à un moment avant la mise à niveau pour restaurer la version précédente sur un nouveau serveur.
  • Sécurisez votre serveur Azure Database pour PostgreSQL. Après une mise à niveau de version majeure sur un serveur flexible Azure Database pour PostgreSQL, le premier utilisateur créé sur le serveur, qui dispose de l’option ADMIN, dispose désormais de privilèges d’administration sur d’autres rôles pour les opérations de maintenance essentielles.

Considérations et limitations relatives à la mise à niveau

Si une opération de pré-vérification échoue lors d’une mise à niveau de version majeure sur place, le processus de mise à niveau s’arrête et affiche un message d’erreur détaillé. Les limitations connues suivantes peuvent entraîner l’échec ou le comportement inattendu de la mise à niveau :

Important

Les exigences de compatibilité de mise à niveau peuvent varier selon la version source et cible de PostgreSQL et changer au fil du temps. Les listes de cette section sont une référence générale et peuvent ne pas refléter les vérifications exactes de votre chemin de mise à niveau. Avant de planifier une mise à niveau, exécutez des vérifications de validation de mise à niveau sur votre serveur pour obtenir l’ensemble actuel et faisant autorité des problèmes qui bloquent votre mise à niveau spécifique, y compris les exigences d’emplacement de réplication logique.

Configurations de serveur non prises en charge

  • La géoréplication dans Azure Database pour PostgreSQL n'est pas prise en charge pendant les mises à niveau sur place. Vous devez supprimer le réplica en lecture (y compris tout réplica en cascade) avant de mettre à niveau le serveur principal. Après la mise à niveau, vous pouvez recréer le réplica.
  • Les règles de trafic réseau peuvent bloquer les opérations de mise à niveau.
    • Vérifiez que votre serveur flexible peut envoyer et recevoir du trafic sur les ports 5432 et 6432 au sein de son réseau virtuel et à stockage Azure (pour l’archivage des journaux).
    • Si les groupes de sécurité réseau (NSG) limitent ce trafic, la haute disponibilité (HA) n’est pas automatiquement réactivé après la mise à niveau. Vous devrez peut-être mettre à jour manuellement les règles de groupe de sécurité réseau et réactiver la haute disponibilité.
  • Les vues dépendant de pg_stat_activity ne sont pas prises en charge lors des mises à niveau vers une version majeure.
  • Si vous effectuez une mise à niveau de PostgreSQL 11 vers une version ultérieure, vous devez d’abord configurer votre serveur flexible pour utiliser l’authentification SCRAM en activant SCRAM et en réinitialisant tous les mots de passe de rôle d’authentification.

Limitations de l’extension

Les mises à niveau des versions principales sur place ne prennent pas en charge toutes les extensions PostgreSQL. La mise à niveau échoue pendant la vérification préalable si une extension bloquée est présente sur un chemin de mise à niveau affecté. La plupart des blocs sont limités à des versions cibles (et parfois sources) spécifiques plutôt qu’à chaque mise à niveau, comme indiqué dans les listes suivantes.

  • Les extensions suivantes bloquent une mise à niveau majeure sur place sur l’ensemble des scénarios de mise à niveau. Supprimez-les avant la mise à niveau et réactivez-les après, si elles sont prises en charge sur la version cible : session_variable, anon, age.

  • Les extensions suivantes sont des extensions utilitaires non persistantes et doivent être supprimées avant la mise à niveau et recréées après, par conception (tous les chemins de mise à niveau) : pg_repack, hypopgpg_partman.

  • Les extensions suivantes sont bloquées uniquement sur des chemins de version spécifiques. Supprimez-les avant la mise à niveau si votre mise à niveau correspond à la condition répertoriée et réactivez-les après si elle est prise en charge sur la version cible :

    Extension Bloqué quand
    pg_hint_plan La version cible est PostgreSQL 14
    semver La version cible est PostgreSQL 16 ou 17
    azure_local_ai La version cible est PostgreSQL 17 ou 18
    pg_failover_slots La version cible est PostgreSQL 17 ou 18 (bibliothèque de préchargement partagé)
    azure_ai La version cible est PostgreSQL 18
    azure_storage La version cible est PostgreSQL 18
    pg_diskann La version cible est PostgreSQL 18
    pgrouting La version cible est PostgreSQL 15 ; ou la source est antérieure à PostgreSQL 16 et la cible est PostgreSQL 16 ou version ultérieure ; ou version cible est PostgreSQL 18
    orafce La version source est PostgreSQL 11, 12 ou 13

  • Les extensions suivantes sont bloquées lorsque d’autres objets de base de données dépendent de leurs objets, car la mise à niveau échoue autrement. Résolvez les dépendances avant la mise à niveau :

    • pg_stat_statements: bloqué lorsque d’autres objets dépendent de sa vue ou de sa fonction, ce qui provoquerait ALTER EXTENSION pg_stat_statements UPDATE l’échec. Supprimez d’abord les objets dépendants.
    • pgcrypto : lorsqu’il est installé dans le schéma pg_catalog et lors d’une mise à niveau de PostgreSQL 11 ou 12 vers PostgreSQL 13 ou une version ultérieure, l’opération est bloquée lorsque des objets du client en dépendent (conflit avec la fonction intégrée gen_random_uuid()). Déplacez l’extension vers un autre schéma ou supprimez d’abord les objets dépendants.

Note

Vous devez exécuter l’opération « DROP EXTENSION » pour supprimer les extensions non prises en charge avant la mise à niveau. Vous n’avez pas besoin de supprimer l’extension de la liste d’autorisation.

Considérations spécifiques à PostGIS

Si vous utilisez PostGIS ou toutes les extensions dépendantes, configurez le search_path paramètre de façon à inclure :

  • Schémas liés à PostGIS
  • Extensions dépendantes, notamment : postgis, , , postgis_rasterpostgis_sfcgalpostgis_tiger_geocoderpostgis_topologyaddress_standardizeraddress_standardizer_data_usfuzzystrmatch
  • Si vous ne configurez pas correctement le search_path, la mise à niveau peut échouer ou endommager des objets après la mise à niveau.

Considérations spécifiques à TimescaleDB

Si vous utilisez TimescaleDB, les mises à niveau des versions principales sur place sont prises en charge uniquement pour des combinaisons de versions source et cible PostgreSQL spécifiques :

Version source de PostgreSQL Versions cibles prises en charge
PostgreSQL 11 PostgreSQL 12
PostgreSQL 12 PostgreSQL 13, 14, 15
PostgreSQL 13 PostgreSQL 14, 15, 16
PostgreSQL 14 PostgreSQL 15, 16
PostgreSQL 15 PostgreSQL 16, 17, 18
PostgreSQL 16 PostgreSQL 17, 18
PostgreSQL 17 PostgreSQL 18

Si votre chemin de mise à niveau TimescaleDB n’est pas répertorié dans la matrice prise en charge, la mise à niveau principale sur place est bloquée. Pour continuer, supprimez l’extension TimescaleDB avant la mise à niveau, si possible, ou utilisez une autre approche de migration telle que la migration côte à côte avec la réplication logique.

Vérifiez que vos versions source et cible sont incluses dans la matrice prise en charge avant de commencer la mise à niveau.

Autres considérations relatives à la mise à niveau

  • Déclencheurs d’événements : la vérification préalable à la mise à niveau bloque les déclencheurs d’événements, car ils s’attachent aux commandes DDL et peuvent faire référence à des catalogues système qui changent entre les versions majeures. Supprimez tous les EVENT TRIGGERs avant la mise à niveau, puis recréez-les après la mise à niveau pour garantir une mise à niveau fluide.
  • Objets volumineux (LO) : la façon dont une mise à niveau gère les bases de données qui contiennent des millions d’objets volumineux (stockés dans pg_largeobject) dépend de la version principale cible :
    • Cible PostgreSQL 15 ou version ultérieure : la mise à niveau utilise une méthode de bloc optimisée pour transférer des métadonnées d’objet volumineux, de sorte que l’utilisation de la mémoire et du disque temporaire n’est plus mise à l’échelle avec le nombre d’objets volumineux. Les bases de données avec des dizaines ou des centaines de millions d’objets volumineux sont mises à niveau de manière fiable sans préparation supplémentaire. L’exécution vacuumlo ou la mise à l’échelle du serveur au préalable n’est pas nécessaire pour contourner le volume d’objets volumineux, bien que vous puissiez toujours exécuter vacuumlo pour supprimer les objets volumineux inutilisés pour d’autres raisons.
    • Cible PostgreSQL 14 ou version antérieure : les bases de données contenant des millions d’objets volumineux peuvent entraîner des échecs de mise à niveau en raison d’une utilisation élevée de la mémoire ou du volume des journaux. Utilisez l’utilitaire vacuumlo pour nettoyer les objets volumineux inutilisés et envisagez d’effectuer un scale-up de votre serveur avant la mise à niveau si de nombreux objets volumineux sont toujours utilisés.

Avertissement

Soyez prudent avec vacuumlo. vacuumlo identifie les grands objets orphelins en fonction des colonnes de référence conventionnelles (oid, lo). Si votre application utilise des types de référence personnalisés ou indirects, des objets volumineux valides peuvent être supprimés par erreur. En outre, vacuumlo il peut consommer un processeur, une mémoire et des E/S par seconde significatifs, en particulier dans les bases de données avec des millions d’objets volumineux. Exécutez-le pendant les plages de maintenance et testez-le d’abord dans un environnement hors production.

Après la mise à niveau

Une fois la mise à niveau de version majeure terminée, exécutez la ANALYZE commande dans chaque base de données pour actualiser la pg_statistic table. Les statistiques manquantes ou obsolètes peuvent entraîner des plans de requête incorrects, ce qui peut à son tour dégrader les performances et prendre une mémoire excessive.

postgres=> analyze;
ANALYZE

Afficher les journaux d’activité de mise à niveau

Utilisez PG_Upgrade_Logs pour surveiller la progression de la mise à niveau et résoudre les problèmes. Passez en revue les journaux pendant et après la mise à niveau pour suivre la progression, diagnostiquer les échecs ou les retards, et identifier les problèmes bloquants afin de pouvoir prendre des mesures correctives rapidement.

Activer les journaux de mise à niveau à l’aide des paramètres de journal du serveur

  • Défini logfiles.download_enable sur ON.
  • Configurer la rétention avec logfiles.retention_days.

Consultez Télécharger PostgreSQL et mettre à niveau les journaux pour commencer.

Note

Les mises à niveau des versions principales in situ sont prises en charge sur les serveurs migrés automatiquement. Après une mise à niveau sur place réussie vers une version majeure sur un serveur migré automatiquement, le format de nom d’utilisateur username@servername n’est plus pris en charge. Utilisez plutôt le format standard : nom d’utilisateur. Pour éviter les problèmes d’authentification, examinez et mettez à jour soigneusement toutes les chaînes de connexion dans vos applications et scripts pour vous assurer qu’elles utilisent le format de nom d’utilisateur mis à jour après la mise à niveau.

Contenu connexe

  • Last updated on