Mises à niveau de versions majeures dans Azure Database pour PostgreSQL

Votre instance de 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. Une instance de 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. Elles peuvent inclure des modifications internes et de nouvelles fonctionnalités qui peuvent ne pas être rétrocompatibles avec les applications existantes.

Votre instance de serveur flexible Azure Database pour PostgreSQL dispose d’une fonctionnalité qui effectue une mise à niveau majeure sur place du serveur en un clic. 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.

Remarque

Azure Database pour PostgreSQL prend en charge les mises à niveau principales sur place uniquement vers les versions PostgreSQL actuellement prises en charge. Par exemple, vous pouvez mettre à niveau la version actuelle en fonction de la version cible officiellement prise en charge par Azure au moment de la mise à niveau. Les versions non prises en charge ne peuvent pas être sélectionnées comme cibles de mise à niveau et la tentative de mise à niveau vers une version déconseillée peut entraîner une défaillance ou une interruption de service. Consultez toujours la stratégie de contrôle de version Azure PostgreSQL et la documentation de mise à niveau avant de lancer une mise à niveau de version majeure.

Remarque

Les mises à niveau principales vers PostgreSQL 18 sont activées en phases. À ce stade, MVU vers PostgreSQL 18 est disponible dans les régions AustraliaSoutheast, CanadaCentral, CentralIndia, CentralUS, EastAsia, EastUS, EastUS, EastUS2, NorthCentralUS, South AfricaNorth, SouthCentralUS, SuèdeCentral, WestCentralUS, WestUS2 et WestUS3.

Processus de mise à niveau

Voici quelques-unes des considérations importantes relatives aux mises à niveau de version principale 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 instance de serveur flexible Azure Database pour PostgreSQL exécute une procédure de vérification préalable pour identifier les éventuels problèmes susceptibles de provoquer 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, l’instance de 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 pour restaurer l’instance de base de données à sa version précédente en cas d’erreur de mise à niveau.
• Une instance de serveur flexible Azure Database pour PostgreSQL utilise l’outil pg_upgrade pour effectuer des mises à niveau de version principales sur place. Le service offre la possibilité d’ignorer les versions et de mettre à niveau directement vers les versions ultérieures.
• Lors de la mise à niveau de version majeure sur place d’un serveur pour lequel la haute disponibilité (HA) est activée, 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 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 une instance de serveur flexible Azure Database pour PostgreSQL déploie automatiquement la dernière version mineure prise en charge.
• Une mise à niveau de version majeure sur place est une opération hors connexion, ce qui signifie que le serveur n’est pas disponible pendant le processus. Bien que la plupart des mises à niveau se terminent en moins de 15 minutes, la durée réelle dépend de la taille et de la complexité de la base de données. Plus précisément, le temps nécessaire est directement proportionnel au nombre d’objets (tables, index, schémas) dans votre instance PostgreSQL. Des schémas plus volumineux 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. Toutefois, vous pouvez effectuer une récupération à une date et heure antérieure à la mise à niveau pour restaurer la version précédente de l’instance de base de données.
• Votre instance de serveur flexible Azure Database pour PostgreSQL prend un instantané de votre base de données lors d’une mise à niveau. La capture instantanée est prise avant le démarrage de la mise à niveau. Si la mise à niveau échoue, le système restaure automatiquement votre base de données à son état à partir de la capture instantanée.
• PostgreSQL 16 introduit des mesures de sécurité basées sur des rôles. Après la mise à niveau d’une version majeure sur une instance de serveur flexible Azure Database pour PostgreSQL, le premier utilisateur créé sur le serveur, qui dispose de l’option ADMIN, aura désormais des privilèges d’administration sur d’autres rôles pour les opérations de maintenance essentielles.

Considérations et limitations de mise à niveau

Si une opération de pré-vérification échoue lors d’une mise à niveau de version majeure sur place, la mise à niveau est bloquée avec un message d’erreur détaillé. Voici les limitations connues qui peuvent entraîner l’échec ou le comportement inattendu de la mise à niveau :

Configurations de serveur non prises en charge

• Les réplicas en lecture ne sont pas pris 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 instance de serveur flexible peut envoyer/recevoir du trafic sur les ports 5432 et 6432 au sein de son réseau virtuel et vers stockage Azure (pour l’archivage des journaux).
  • Si les groupes de sécurité réseau (NSG) limitent ce trafic, la HA ne se réactive pas automatiquement 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 emplacements de réplication logique ne sont pas pris en charge pendant les mises à niveau sur place de versions majeures.
• Les serveurs utilisant le stockage SSDv2 ne sont pas éligibles pour les mises à niveau de version majeure.
• Les vues dépendantes de pg_stat_activity ne sont pas prises en charge pendant les mises à niveau de version majeures.
• Si vous effectuez la mise à niveau de PG11 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 de connexion.

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 des extensions non prises en charge sont trouvées.

• Les extensions suivantes sont prises en charge pour une utilisation régulière, mais bloquent une mise à niveau principale sur place si elles sont présentes. Supprimez-les avant la mise à niveau et réactivez-les après, si elles sont prises en charge sur la version cible : timescaledb, dblink, , orafcepostgres_fdw.
• Les extensions suivantes sont des extensions utilitaires non persistantes et doivent être supprimées et recréées après la mise à niveau par conception : pg_repack, hypopg.
• Lors de la mise à niveau vers PostgreSQL 17, les extensions suivantes ne sont pas prises en charge et doivent être supprimées avant la mise à niveau. Vous pouvez les réactiver uniquement si elles sont prises en charge sur la version cible : age, , azure_aihll, pg_diskann, . pgrouting

Note: Si l’une de ces extensions apparaît dans le paramètre de azure.extensions serveur, la mise à niveau est bloquée. Supprimez-les du paramètre avant de commencer la mise à niveau.

Considérations spécifiques à PostGIS

Si vous utilisez PostGIS ou toutes les extensions dépendantes, vous devez configurer le paramètre de serveur search_path pour inclure :

• Schémas liés à PostGIS
• Extensions dépendantes, notamment : postgis, , , postgis_rasterpostgis_sfcgalpostgis_tiger_geocoderpostgis_topologyaddress_standardizeraddress_standardizer_data_usfuzzystrmatch
• L’échec de la configuration du search_path peut entraîner des échecs de mise à niveau ou des objets rompus après la mise à niveau.

Autres considérations relatives à la mise à niveau

• Déclencheurs d’événements : les pré-vérifications de mise à niveau bloquent les déclencheurs d'événements, car ils se connectent à des commandes DDL et peuvent référencer des catalogues système qui changent entre les versions principales—supprimez tous les EVENT TRIGGER avant la mise à niveau, puis recréez-les après la mise à niveau pour garantir une transition fluide.
• Objets volumineux (LO) : les bases de données avec des millions d’objets volumineux (stockés dans pg_largeobject) peuvent provoquer des échecs de mise à niveau en raison d'une mémoire fortement sollicitée ou d'un important volume de journaux. Utilisez l’utilitaire vacuumlo pour nettoyer les objets LO inutilisés et envisagez d’effectuer un scale-up de votre serveur avant de procéder à la mise à niveau si de nombreux objets de domaine sont toujours en cours d’utilisation.

Avertissement

Utilisez la prudence 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 créneaux de maintenance et testez d'abord sur un environnement non-production.

Après la mise à niveau

Une fois la mise à niveau de la version majeure terminée, nous vous recommandons d’exécuter la commande ANALYZE dans chaque base de données pour actualiser la table pg_statistic. 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

Les journaux de mise à niveau de version principale (PG_Upgrade_Logs) fournissent un accès direct aux journaux de serveur détaillés. Intégrer PG_Upgrade_Logs à votre processus de mise à niveau permet de garantir une transition plus fluide et plus transparente vers de nouvelles versions de PostgreSQL.

Vous pouvez configurer vos journaux de mise à niveau de version principale comme vous l’avez fait pour les journaux de serveur, en utilisant les paramètres serveur suivants :

• Pour activer la fonctionnalité, définissez logfiles.download_enable sur ON.
• Pour définir la rétention des fichiers journaux en jours, utilisez logfiles.retention_days.

Configurer les journaux de mise à niveau

Pour commencer à utiliser PG_Upgrade_Logs, vous pouvez configurer la capture des journaux du serveur PostgreSQL et des journaux de mise à niveau de version majeure.

Vous pouvez accéder aux journaux de mise à niveau via l’interface utilisateur pour les journaux du serveur. Là, vous pouvez surveiller la progression et les détails de vos mises à niveau de version principale PostgreSQL en temps réel. Cette interface utilisateur fournit un emplacement centralisé pour afficher les journaux, ce qui vous facilite le suivi et la résolution des problèmes du processus de mise à niveau.

Avantages de l’utilisation des journaux de mise à niveau

• Diagnostics pertinents : PG_Upgrade_Logs fournit des informations précieuses sur le processus de mise à niveau. Il capture des informations détaillées sur les opérations effectuées et met en évidence les erreurs ou avertissements qui se produisent. Ce niveau de détail est essentiel pour diagnostiquer et résoudre les problèmes pouvant survenir lors de la mise à niveau, ce qui garantit une transition plus facile.
• Résolution simplifiée des problèmes : avec un accès direct à ces journaux, vous pouvez rapidement identifier et résoudre les obstacles potentiels à la mise à niveau, réduire les temps d’arrêt ainsi que l’impact sur vos opérations. Les journaux constituent un outil crucial de résolution des problèmes en permettant une résolution plus efficace et efficiente des problèmes.

Remarque

Les mises à niveau des versions principales in situ sont prises en charge sur les serveurs migrés automatiquement. Après une mise à niveau majeure réussie sur place sur un serveur migré automatiquement, le format de nom d’utilisateur username@servername ne sera plus pris en charge. Au lieu de cela, vous devez utiliser 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

• Mise à niveau de version majeure.
• Haute disponibilité dans Azure Database pour PostgreSQL.
• Sauvegarde et restauration dans Azure Database pour PostgreSQL.