Stratégie de version d’Azure Database pour PostgreSQL

Cet article décrit la stratégie de contrôle de version d’Azure Database pour PostgreSQL.

Version principale

Une version majeure est une modification du premier numéro de la version. Par exemple, PostgreSQL 16 vers PostgreSQL 17 est une mise à niveau de version majeure. Les versions majeures introduisent de nouvelles fonctionnalités et capacités. Ils peuvent inclure des modifications qui nécessitent des mises à jour de code d’application. Azure Database pour PostgreSQL prend en charge chaque version principale de PostgreSQL à partir de la date à laquelle Azure commence à offrir la prise en charge jusqu’à ce que la version atteigne la fin de vie (fin de support) telle que définie par la communauté PostgreSQL. Pour plus d’informations, consultez la stratégie de contrôle de version de la communauté PostgreSQL.

Stratégie de support

Le tableau suivant fournit les détails de mise hors service pour les versions principales de PostgreSQL. Les dates suivent la stratégie de contrôle de version de la communauté PostgreSQL.

PostgreSQL 18 est actuellement disponible en préversion sur Azure Database pour PostgreSQL avec une disponibilité initiale dans la région Asie Est.

Prise en charge de la version mineure

Une instance de serveur flexible Azure Database pour PostgreSQL met automatiquement à niveau les versions mineures vers la version PostgreSQL préférée d’Azure pendant la maintenance périodique.

Support étendu

Pour vous aider à maintenir des charges de travail sécurisées et conformes au-delà de la fin de vie de la communauté (fin de support), Azure introduit le support étendu pour Azure Database pour PostgreSQL.

Le support étendu vous offre un accès continu aux mises à jour de sécurité critiques et à l’assistance technique. Avec le support étendu, vous avez le temps de planifier et d’implémenter votre stratégie de mise à niveau en toute confiance.

La prise en charge étendue fournit les éléments suivants :

• Jusqu’à trois années de support supplémentaires après la fin du support standard
• Correctifs de sécurité et correctifs de bogues critiques
• Support technique via des canaux de support Azure (conformément à votre plan existant)

Pourquoi utiliser le support étendu ?

Le support étendu est idéal pour les clients qui...

• Besoin de plus de temps pour mettre à niveau des charges de travail complexes.
• Exiger la conformité et la couverture de sécurité pendant la planification de la mise à niveau.
• Dépendez d’une prise en charge technique ininterrompue pour les environnements critiques.

Meilleures pratiques

• Traitez le support étendu comme un pont temporaire, et non comme une solution à long terme.
• Commencez la planification de la mise à niveau bien avant la date de fin de vie (fin de support).
• Envisagez de mettre à niveau vers des versions plus récentes telles que PostgreSQL 15 ou 16 pour améliorer les performances et la prise en charge.

Versions de PostgreSQL éligibles

Inscription et prix

• Inscription automatique : les serveurs PostgreSQL exécutant des versions non prises en charge sont automatiquement inscrits dans le support étendu le 1er mars 2026.
• Opt-Out Option : Vous pouvez choisir de ne plus participer à tout moment en passant à une version prise en charge.
• Période de grâce : une période de grâce d’un mois s’applique. La facturation commence le 1er avril 2026.
• Tarification : les détails seront publiés sur cette page avant le début de la facturation.

Questions Fréquemment Posées (FAQ)

Q : Que se passe-t-il si je souhaite continuer à exécuter sans support étendu ? Puis-je refuser ?

R : Non.

Q : Que se passe-t-il si je continue d’exécuter une version PostgreSQL non prise en charge sur Azure après sa fin de support communautaire ?

R : Votre serveur est automatiquement inscrit au support étendu un mois après la date de fin du support communautaire (ou le 1er mars 2026, pour les versions 11, 12 et 13).

Q : Puis-je continuer à utiliser mon instance PostgreSQL sans support étendu ?

R : Oui, mais après la période de grâce, vous êtes automatiquement inscrit au support étendu payant, sauf si vous effectuez une mise à niveau vers une version prise en charge. Pendant la période de grâce, vous assumez un risque opérationnel complet et le support Microsoft ne peut pas garantir la résolution des problèmes.

Q : Mes applications peuvent-elles s’interrompre lors d’une mise à niveau de version majeure ?

R. Les mises à niveau principales de versions PostgreSQL peuvent introduire des modifications susceptibles d’avoir un impact sur votre application, telles que des paramètres de configuration déconseillés, des extensions incompatibles ou des différences de comportement SQL. Nous vous recommandons de valider les mises à niveau dans un environnement hors production avant de les appliquer en production. Pour plus d’informations, consultez les principales considérations et limitations de la documentation sur les mises à niveau des versions majeures.

Q : Comment savoir si mon serveur est en support étendu ?

R : Le portail Azure et l’interface CLI indiquent clairement si un serveur est inscrit dans le support étendu.

Q : Dois-je mettre à jour les paramètres du serveur après les mises à niveau de version majeure ?

R : Aucune modification manuelle n’est requise. Le flux de travail de mise à niveau met automatiquement à jour les paramètres de la nouvelle version de PostgreSQL.

Q : Les extensions PostgreSQL sont-elles automatiquement mises à niveau pendant une mise à niveau de version majeure ?

R : Non. Alors qu’Azure met à niveau le moteur de base de données, les extensions noncore (par exemple, pgvector, timescaledb) nécessitent des mises à jour manuelles. Utilisez ALTER EXTENSION ... UPDATE ou recréez des extensions non prises en charge après la mise à niveau.

Q : Comment puis-je réduire les temps d’arrêt pendant une mise à niveau majeure ?

R : Pour réduire les temps d’arrêt :

• Planifiez les mises à niveau pendant les heures de faible trafic.
• Identifiez et corrigez les bloqueurs de mise à niveau (par exemple, les extensions, les rôles, les emplacements de réplication) avant la mise à niveau.
• Suspendre les travaux en arrière-plan et les sessions longues.
• Effectuez un scale-up temporaire du calcul pour accélérer pg_upgrade.
• Nettoyez l'encombrement avec VACUUM ou REINDEX si nécessaire.
• Exécutez ANALYZE après la mise à niveau pour restaurer les performances.

Q : Où puis-je suivre laquelle de mes serveurs est proche de la fin de la prise en charge ?

R : Azure offre une visibilité via le portail.

Q : Quelles options de support sont disponibles pendant la phase de support étendu ?

R : Les serveurs dans le support étendu peuvent déclencher des cas de support uniquement pour les problèmes liés à la sécurité. Les demandes de fonctionnalités, le réglage des performances et les corrections générales de bogues ne sont pas pris en charge pour les versions en fin de support. Les améliorations apportées aux fonctionnalités existantes pour les versions dont le support a pris fin ne seront pas appliquées rétroactivement.

Q : Comment la période entre le 13 novembre 2025 et le 1er mars 2026 sera-t-elle gérée pour PostgreSQL version 13 ? Le soutien sera-t-il poursuivi pendant cette période ? Comment cela va-t-il différer de la période antérieure au 13 novembre 2025 ?

R : Selon la stratégie de gestion des versions de la communauté PostgreSQL, chaque version majeure est prise en charge jusqu’à la mise hors service de la communauté. Le support étendu gratuit d’Azure sera fourni jusqu’au 31 mars 2026. Les clients sont facturés pour le support étendu à compter du 1er avril. Pour garantir une prise en charge et un accès continus aux nouvelles fonctionnalités, effectuez une mise à niveau vers des versions plus récentes.

Versions de moteur PostgreSQL retirées non prises en charge dans Azure Database pour PostgreSQL

Vous pouvez continuer à utiliser la version supprimée dans les instances de serveur flexible Azure Database pour PostgreSQL. Toutefois, après la date de mise hors service de chaque version de base de données PostgreSQL, les restrictions suivantes s’appliquent :

• Lorsque la communauté met hors service une version PostgreSQL, Azure Database pour PostgreSQL cesse d’appliquer des correctifs de bogues ou de sécurité au moteur de base de données. Cette modification peut exposer votre serveur à des risques de sécurité ou à d’autres problèmes. Toutefois, Azure continue de gérer et de corriger l’hôte sous-jacent, le système d’exploitation, les conteneurs et les composants de service associés.

• Si vous rencontrez un problème de support lié au moteur PostgreSQL lui-même, nous ne pouvons peut-être pas fournir de support, car la communauté ne fournit plus les correctifs. Dans ce cas, vous devez mettre à niveau votre base de données vers l’une des versions prises en charge.

• Vous ne pouvez pas créer de serveurs à l’aide d’une version PostgreSQL mise hors service. Toutefois, vous pouvez effectuer des récupérations à un instant dans le passé et créer des réplicas en lecture pour vos serveurs existants.

• Les nouvelles fonctionnalités de service développées par le serveur Azure Database pour PostgreSQL peuvent uniquement être disponibles pour les versions de serveur de base de données prises en charge.

• Les contrats SLA de temps d’activité s’appliquent uniquement aux problèmes liés aux services d’instance de serveur flexible Azure Database pour PostgreSQL et ne s’appliquent pas aux temps d’arrêt causés par les bogues liés au moteur de base de données.

• Dans de rares cas où une vulnérabilité critique dans une version PostgreSQL supprimée constitue une menace pour le service, Azure peut arrêter les serveurs affectés pour protéger la plateforme. Dans ce cas, vous êtes averti de mettre à niveau le serveur avant de mettre en ligne le serveur.

• Les nouvelles extensions introduites pour les instances de serveur flexible Azure Database pour PostgreSQL ne sont pas prises en charge sur les versions de PostgreSQL supprimées par la communauté.

Syntaxe de version PostgreSQL

Avant PostgreSQL version 10, la stratégie de gestion des versions PostgreSQL considère qu’une mise à niveau de version majeure est une augmentation du premier ou du deuxième nombre. Par exemple, 9.5 à 9.6 a été considéré comme une mise à niveau de version majeure. Depuis la version 10, seule une modification du premier chiffre est considérée comme une mise à niveau de version majeure. Par exemple, 10.0 à 10.1 est une mise à niveau de version mineure. La version 10 à 11 est une mise à niveau de version majeure.

Contenu connexe

• Versions prises en charge de PostgreSQL dans Azure Database pour PostgreSQL