Méthodes de mise à jour de PostgreSQL vers une nouvelle version

Hostman Team

Technical writer

Bases de données PostgreSQL

06.11.2025

Reading time: 9 min

Dans PostgreSQL, la mise à jour des versions peut se faire de différentes manières :

Installation de packages avec une nouvelle version de PostgreSQL. Cette méthode est adaptée uniquement aux mises à jour mineures. Avant de procéder à la mise à jour, consultez les notes de version.
Utilisation du programme standard pg_dumpall. Il s'agit d'une méthode fiable, mais elle peut entraîner un long temps d'arrêt.
Utilisation du programme standard pg_upgrade. Une autre méthode rapide de mise à jour, mais des erreurs peuvent survenir.
Mise à jour via réplication logique. Cette option minimise le temps d'arrêt mais est uniquement adaptée aux versions de PostgreSQL supérieures à 10.0. Les versions antérieures nécessitent des extensions. Le choix dépend de la version utilisée sur le serveur et de la version vers laquelle vous souhaitez effectuer la mise à jour.
Dans cet article, nous allons examiner toutes les méthodes de mise à jour ci-dessus.

Notes importantes avant de mettre à jour

Il est essentiel de comprendre les particularités des mises à jour entre différentes versions.
Les numéros de version sont constitués de deux chiffres, par exemple, 10.1. Le premier chiffre est le numéro de la version principale (10). Le deuxième chiffre est le numéro de la version mineure (1).
Avant PostgreSQL 10, les numéros de version étaient composés de trois chiffres. Par exemple, dans 9.6.3, 9.6 est le numéro de version principal et 3 est le numéro de version mineure.

Il est important de comprendre cette différence pour choisir la méthode de mise à jour appropriée.

Dans les versions mineures, le format de stockage des données ne change pas, il n'y a donc pas de problèmes de compatibilité. Par conséquent, la transition de PostgreSQL 10.1 à 10.6 peut se faire très facilement. Pour effectuer la mise à jour, il suffit d'éteindre le serveur, de remplacer les fichiers exécutables et de redémarrer le serveur.
Cependant, la documentation note que certaines versions peuvent nécessiter des modifications manuelles. Par conséquent, lisez toujours les notes de version avant de procéder à la mise à jour.

Dans les versions majeures, le format des données peut changer. Cela rend la mise à jour plus complexe. Vous devrez soit décharger les données et les recharger, soit utiliser le programme pg_upgrade ou recourir à la réplication logique.

Mise à jour au sein d'une même version majeure

Examinons comment mettre à jour PostgreSQL de la version 14.1 à la version 14.3 sur un serveur Ubuntu.

PostgreSQL est disponible par défaut sur Ubuntu. Commencez par la commande :

sudo apt-get upgrade

Debian et Ubuntu ne publient qu'une version de PostgreSQL par version du système d'exploitation. Par exemple, Debian Squeeze/6.0 ne propose que PostgreSQL 8.4. Si vous avez besoin d'une version différente de PostgreSQL, utilisez les paquets PGDG.

Si vous souhaitez la dernière version de PostgreSQL, vous devez d'abord installer le dépôt Postgres.

Ajoutez un dépôt :

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

Importez la clé de signature :

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

Mettez à jour la liste des paquets dans le système :

sudo apt-get update

Installez la version requise de PostgreSQL :

sudo apt-get -y install postgresql-14.3

Pour afficher la liste des systèmes de gestion de bases de données (DBMS) installés, exécutez :

dpkg --get-selections | grep postgres

Vérifiez également la liste des clusters :

pg_lsclusters

Arrêtez PostgreSQL avant de procéder aux modifications :

sudo service postgresql stop

Lorsque les paquets PostgreSQL sont installés, ils créent un cluster par défaut pour vous. Vous devez renommer le nouveau cluster PostgreSQL afin qu'il n'y ait pas de conflit avec l'ancien nom de cluster lors de la mise à jour.

sudo pg_renamecluster 14.3 main main_pristine

Mettez à jour l'ancien cluster :

sudo pg_upgradecluster 14.1 main

Démarrez le service :

sudo service postgresql start

Vérifiez à nouveau la liste des clusters et assurez-vous que le nouveau cluster fonctionne :

pg_lsclusters

Supprimez l'ancien cluster :

sudo pg_dropcluster 14.1 main

Mise à jour via pg_dumpall

Si vous devez changer de version majeure, utilisez le programme pg_dumpall. L'essence de cette méthode est de décharger les données d'une version principale et de les charger dans une autre.

Avant de décharger les données, assurez-vous qu'aucune modification n'est effectuée sur la base de données à ce moment. Sinon, certaines des modifications peuvent ne pas être incluses dans le dump final.

Obtenez le dump et écrivez-le dans un fichier :

pg_dumpall > output_file

Arrêtez le serveur :

pg_ctl stop

Changez le nom du répertoire ancien pour éviter les conflits de nom :

mv /usr/local/pgsql /usr/local/pgsql.old

Le répertoire ancien peut être supprimé. Mais il serait plus sage de le renommer pour laisser de la place à la restauration. Au lieu de /usr/local/pgsql, spécifiez le chemin de votre répertoire.

Installez la nouvelle version à partir des sources. Il existe un guide détaillé dans la documentation.

Créez un nouveau cluster :

/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data

Transférez toutes les modifications dans les fichiers pg_hba.conf et postgresql.conf.

Démarrez le serveur de base de données :

/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data

Restaurez les données depuis la sauvegarde :

/usr/local/pgsql/bin/psql -d postgres -f output_file

L'inconvénient de cette méthode est que le serveur sera éteint pendant un certain temps. Pour réduire le temps d'arrêt, vous pouvez installer le nouveau serveur dans un répertoire différent et exécuter les anciens et nouveaux serveurs sur des ports différents. Pour transférer les données, utilisez la commande :

pg_dumpall -p 5432 | psql -d postgres -p 5433

Au lieu de 5432 et 5433, spécifiez les numéros de port sur lesquels vous avez exécuté les serveurs.

Mise à jour via pg_upgrade

Pour éviter de décharger et de recharger les données, utilisez le programme pg_upgrade. Il permet de mettre à jour plus rapidement. Le programme pg_upgrade crée de nouvelles tables système, en tenant compte des changements dans les dernières versions de PostgreSQL. Dans ce cas, les anciens fichiers de données sont conservés. De plus, pg_upgrade vérifie la compatibilité des clusters.

Le programme pg_upgrade vous aide à mettre à jour de PostgreSQL 8.4.X vers la version actuelle du DBMS.

Voyons un plan de mise à jour général en utilisant pg_upgrade.

Déplacez l'ancien cluster. Cela doit être fait si le répertoire n'était pas lié à la version précédente. Par exemple, il est situé dans /usr/local/pgsql. Si vous ne le renommez pas, un conflit se produira lors de la mise à jour.

Le renommage se fait lorsque le serveur est éteint avec la commande :

mv /usr/local/pgsql /usr/local/pgsql.old

Construisez la nouvelle version à partir des sources. Adaptez le configure afin que les options soient compatibles avec la configuration du cluster ancien. Avant de commencer la mise à jour, pg_upgrade vérifiera la compatibilité des options.

Installez les nouveaux fichiers exécutables. Pour placer le serveur dans un répertoire non standard, utilisez le préfixe :

make prefix=/usr/local/pgsql.new install

Utilisez initdb pour initialiser un nouveau cluster. Vérifiez que les options sont compatibles avec celles du cluster ancien.

Installez les fichiers objets d'extension. Si des mises à jour sont disponibles, pg_upgrade créera automatiquement un script pour leur installation ultérieure.

Transférez les fichiers de recherche en texte complet.

Configurez l'authentification par paire dans pg_hba.conf. Cela doit être fait car pg_upgrade se connectera plusieurs fois aux anciens et nouveaux hôtes.

Vérifiez que les anciens et nouveaux serveurs sont arrêtés :

pg_ctl -D /opt/PostgreSQL/9.6 stop

pg_ctl -D /opt/PostgreSQL/14 stop

Exécutez pg_upgrade depuis le nouveau serveur. D'abord, exécutez le programme en mode vérification en ajoutant l'option : pg_upgrade --check. En réponse, vous recevrez une liste des ajustements à effectuer manuellement après la mise à jour.

Si vous avez modifié le fichier pg_hba.conf, restaurez-le dans son état précédent. Parfois, d'autres configurations sur le nouveau cluster doivent être modifiées pour correspondre aux paramètres de l'ancien cluster.

Démarrez le serveur.

Si vous êtes satisfait du résultat, supprimez l'ancien cluster.

Utilisation de la Réplication Logique

À partir de la version 10 de PostgreSQL, nous disposons d'une méthode de réplication logique des objets de données et de leurs modifications. Elle repose sur l'utilisation d'identifiants de réplication ; généralement, ce sont des clés primaires.

La réplication logique utilise le modèle publication-abonnement. L'utilisateur crée un instantané de la base de données publiée et le copie dans le souscripteur. Dans la documentation PostgreSQL, un des scénarios typiques pour utiliser la réplication logique est précisément la réplication entre différentes versions majeures de PostgreSQL.

Le serveur de sauvegarde peut être situé sur le même hôte ou sur un autre. Une fois la synchronisation terminée, plusieurs options sont possibles. Par exemple, vous pouvez faire du nouveau serveur le principal et éteindre l'ancien.

L'avantage principal de la réplication logique est le temps d'arrêt minimal. L'interruption du serveur, dans certains cas, est limitée à quelques secondes.

Conclusion

Nous avons examiné les méthodes universelles pour mettre à jour PostgreSQL vers une nouvelle version majeure et mettre à jour au sein d'une version majeure.

Avec ce guide, vous pouvez sélectionner la méthode qui convient le mieux à votre cas particulier et mettre à jour votre version actuelle de PostgreSQL.

Bases de données PostgreSQL

06.11.2025

Reading time: 9 min

Similaire

Plateforme Kubernetes

Déployer PostgreSQL sur Kubernetes : guide pas à pas

PostgreSQL est un SGBDR (RDBMS) populaire offrant des fonctionnalités de haute disponibilité comme la réplication en flux (streaming replication), la réplication logique et des solutions de bascule (failover). Le déploiement de PostgreSQL sur Kubernetes permet de construire des systèmes résilients garantissant une disponibilité des données et un temps d’arrêt minimal. Avec les StatefulSets Kubernetes, vous pouvez faire évoluer votre déploiement PostgreSQL selon la demande. Choose hour server now! Préparation de l’environnement Kubernetes Assurez-vous de disposer des éléments suivants : Cluster Kubernetes (cloud ou local) : vous pouvez créer un cluster Kubernetes sur Hostman en quelques minutes. Pour un cluster local, utilisez k3s, minikube, microk8s ou kind. kubectl : l’outil pour interagir avec le cluster. Il a besoin d’un fichier de configuration YAML contenant les détails du cluster (fourni par votre fournisseur cloud). Depuis le tableau de bord Hostman, téléchargez ce fichier en un clic, puis exportez la variable d’environnement : Pour vous connecter, vous devez définir la variable d’environnement KUBECONFIG en conséquence. export KUBECONFIG=/absolute/path/to/file/k8s-cluster-config.yaml Helm : la CLI Helm est nécessaire pour installer des charts. Helm v3 est requis. Déployer PostgreSQL avec un chart Helm Helm est un gestionnaire de paquets pour Kubernetes (à la manière de apt pour Ubuntu/Debian). Plutôt que de créer manuellement plusieurs YAML (Pods, Services, PV, Secrets, etc.), un chart Helm permet un déploiement en une commande. Étape 1 : Ajouter le dépôt Helm helm repo add bitnami https://charts.bitnami.com/bitnami Pour synchroniser votre référentiel Helm local avec celui distant : helm repo update Étape 2 : Gérer la persistance des données PostgreSQL nécessite un stockage persistant pour préserver les données lors d’un crash de pod ou d’un rescheduling. Créez un PersistentVolume local (démo/lab) — fichier postgres-local-pv.yaml : apiVersion: v1 kind: PersistentVolume metadata: name: postgresql-local-pv spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: manual hostPath: path: /mnt/data/postgresql ⚠️ Attention : hostPath pointe vers un dossier local du nœud. Si le nœud devient indisponible, les données le deviennent aussi. En production, privilégiez un stockage cloud-native (Ceph, Portworx, OpenEBS, Gluster, etc.) pour la fiabilité et l’évolutivité. Créez la PVC — fichier postgres-local-pvc.yaml : apiVersion: v1 kind: PersistentVolumeClaim metadata: name: postgresql-local-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi storageClassName: manual ReadWriteOnce signifie qu’un seul nœud peut monter le volume en lecture/écriture à la fois. Passer en ReadWriteMany n’apporte pas de HA automatique pour PostgreSQL et peut engendrer des corruptions/concurrences d’accès. Appliquez : kubectl apply -f postgres-local-pv.yamlkubectl apply -f postgres-local-pvc.yaml Étape 3 : Installer le chart PostgreSQL helm install tutorial-db bitnami/postgresql --set auth.username=bhuwan \ --set auth.password=”AeSeigh2gieshe” \ --set auth.database=k8s-tutorial \ --set auth.postgresPassword=”Ze4hahshez6dop9vaing” \ --set primary.persistence.existingClaim=postgresql-local-pvc \ --set volumePermissions.enabled=true Vérifiez après quelques minutes : kubectl get all Étape 4 : Tester et se connecter Récupérez le mot de passe depuis le Secret et lancez un pod client temporaire : export POSTGRES_PASSWORD=$(kubectl get secret --namespace default tutorial-db-postgresql -o jsonpath="{.data.password}" | base64 -d) kubectl run tutorial-db-postgresql-client --rm --tty -i --restart='Never' \ --image docker.io/bitnami/postgresql:17.2.0-debian-12-r6 \ --env="PGPASSWORD=$POSTGRES_PASSWORD" \ --command -- psql --host tutorial-db-postgresql \ -U bhuwan -d k8s-tutorial -p 5432 Le pod sera supprimé automatiquement grâce à --rm. 👉 Si vous avez modifié le Release name, l’utilisateur ou le nom de DB, adaptez les commandes. Déployer PostgreSQL sur Kubernetes « from scratch » Un StatefulSet est la ressource adaptée aux applications avec état comme PostgreSQL: noms réseau stables et volumes persistants par pod. Commencez par nettoyer et recréer le PV et la PVC : helm delete tutorial-db kubectl delete pvc postgresql-local-pvc kubectl delete pv postgresql-local-pv kubectl apply -f postgres-local-pv.yaml -f postgres-local-pvc.yaml Créez postgres-statefulset.yaml : apiVersion: apps/v1 kind: StatefulSet metadata: name: postgres-statefulset labels: app: postgres spec: serviceName: "postgresql-headless-svc" replicas: 1 selector: matchLabels: app: postgres template: metadata: labels: app: postgres spec: containers: - name: postgres image: postgres:17.2 envFrom: - secretRef: name: postgresql-secret ports: - containerPort: 5432 name: postgresdb volumeMounts: - name: pv-data mountPath: /var/lib/postgresql/db volumes: - name: pv-data persistentVolumeClaim: claimName: postgresql-local-pvc Créez le Secret des informations sensibles (mot de passe) : kubectl create secret generic postgresql-secret --from-literal=POSTGRES_PASSWORD=Ze4hahshez6dop9vaing kubectl apply -f postgres-statefulset.yaml Si le pod reste Pending, créez une StorageClass manuelle : kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: manual provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer Diagnostiquer un problème : kubectl describe pod postgres-statefulset-0 Exposez PostgreSQL via un Headless Service (accès interne) — postgres-service.yaml : apiVersion: v1 kind: Service metadata: name: postgresql-headless-svc spec: type: ClusterIP selector: app: postgres ports: - port: 5432 targetPort: 5432 clusterIP: None Test de connexion : kubectl run tutorial-db-postgresql-client --rm --tty -i --restart='Never' \ --image docker.io/bitnami/postgresql:17.2.0-debian-12-r6 \ --env="PGPASSWORD=Ze4hahshez6dop9vaing" \ --command -- psql --host postgres-statefulset-0.postgresql-headless-svc \ -U postgres -p 5432 Mise à l’échelle, réplication et sauvegardes Scaler un StatefulSet : kubectl scale statefulset postgres-statefulset --replicas=3 Grâce au Headless Service, vous pouvez joindre un pod en particulier, par ex. postgres-statefulset-1.postgresql-headless-svc. Sauvegardes : créez un CronJob utilisant pg_dump. Vous pouvez aussi envisager les VolumeSnapshots si votre stockage le supporte. Bonnes pratiques Requests/Limits : définissez des demandes et des limites CPU/Mémoire appropriées pour éviter la sous/sur-allocation. Backups réguliers : CronJobs + snapshots si possible. Supervision & logs : Prometheus + Grafana pour les métriques PostgreSQL (perf des requêtes, espace disque, statut de la réplication). Pod Disruption Budgets (PDB) : évitent trop d’indisponibilités simultanées (rolling updates, etc.). Choose your server now! Conclusion Le chart Helm est la méthode recommandée pour les déploiements complexes et production-ready. Il automatise la gestion de versions et masque la complexité de la configuration des composants Kubernetes. Avec helm template, vous pouvez rendre les manifests en local et les adapter. Kubernetes offre scalabilité, flexibilité et automatisation pour PostgreSQL. En utilisant StatefulSets, PVCs, PDBs et la gestion des Secrets, vous adaptez PostgreSQL aux exigences d’un environnement de production.

27 October 2025 · 7 min to read