Mises à niveau de version principale dans Azure Database pour PostgreSQL – Serveur flexible

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL – Serveur flexible

Le serveur flexible Azure Database pour PostgreSQL prend en charge PostgreSQL versions 16, 15, 14, 13, 12, and 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. Le serveur flexible d’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.

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

Processus

Voici quelques-unes des considérations importantes relatives aux mises à niveau de version principale sur place :

  • Pendant le processus de mise à niveau de version principale sur place, le serveur flexible d’Azure Database pour PostgreSQL exécute une procédure de vérification préalable pour identifier les problèmes potentiels 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 d’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.

  • Le 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.

  • Lors d’une mise à niveau de version principale sur place d’un serveur avec haute disponibilité (HA) 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 principale sur place pour le serveur flexible d’Azure Database pour PostgreSQL déploie automatiquement la dernière version mineure prise en charge.

  • Une mise à niveau de version principale sur place est une opération hors ligne qui entraîne une brève période d’indisponibilité. Le temps d’arrêt est généralement inférieur à 15 minutes. La durée peut varier en fonction du nombre de tables système impliquées.

  • 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.

Journaux de mise à niveau de version principale

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.

Configuration des journaux de mise à niveau

Pour commencer à utiliser PG_Upgrade_Logs, vous pouvez configurer les journaux via le portail Azure ou l’interface de ligne de commande Azure. Choisissez la méthode qui convient le mieux à votre flux de travail.

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.

Limites

Si les opérations de vérification préalable échouent pour une mise à niveau de version principale sur place, la mise à niveau échoue avec un message d’erreur détaillé pour toutes les limitations suivantes :

  • Actuellement, les mises à niveau des versions principales sur place ne prennent pas en charge les réplicas en lecture. Si vous disposez d’un serveur qui agit en tant que réplica en lecture, vous devez supprimer le réplica avant d’effectuer la mise à niveau sur le serveur principal. Après la mise à niveau, vous pouvez recréer le réplica.

  • Azure Database pour PostgreSQL – Serveur flexible doit pouvoir envoyer et recevoir le trafic vers les ports de destination 5432 et 6432 dans le réseau virtuel où le serveur flexible est déployé, et vers le stockage Azure pour l’archivage des journaux.

    Si vous configurez des groupes de sécurité réseau (NSG) pour limiter le trafic vers ou depuis votre serveur flexible au sein de son sous-réseau déployé, veillez à autoriser le trafic vers les ports de destination 5432 et 6432 dans le sous-réseau. Autorisez le trafic vers Stockage Azure en utilisant la balise de service Stockage Azure en tant que destination.

    Si les règles de réseau ne sont pas configurées correctement, la haute disponibilité n’est pas activée automatiquement après une mise à niveau de version principale, et vous devez activer manuellement la haute disponibilité. Modifiez vos règles de groupe de sécurité réseau (NSG) pour qu’elles autorisent le trafic des ports et le stockage de destination, et pour activez la fonctionnalité haute disponibilité sur le serveur.

  • Les mises à niveau de version principale sur place ne prennent pas en charge certaines extensions et présentent quelques limitations à la mise à niveau de certaines extensions. Les extensions suivantes ne sont plus prises en charge pour toutes les versions de PostgreSQL : Timescaledb, pgaudit, dblink, orafce, pg_partman, postgres_fdw.

  • Lorsque vous mettez à niveau des serveurs avec l’extension PostGIS installée, définissez le paramètre de serveur search_path de manière explicite :

    • Schémas de l’extension PostGIS.
    • Extensions qui dépendent de PostGIS.
    • Extensions qui servent de dépendances pour les extensions suivantes : postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_us, fuzzystrmatch (obligatoire pour postgis_tiger_geocoder).

  • Les serveurs configurés avec des emplacements de réplication logique ne sont pas pris en charge.

Étapes suivantes