Mise à jour mineure de PostgreSQL (patch)

Mise à jour mineure au sein d'une même version majeure (par ex. 17.4 → 17.x) : contrôle des release notes, sauvegarde et conservation des RPM/deb actuels pour le retour arrière. Sur un serveur unique, avec une courte interruption ; dans un cluster en streaming replication, les standbys d'abord, puis le primary après un switchover (rolling) ; dans un cluster Patroni, les replicas avec patronictl restart, le leader après patronictl switchover. Mise à jour des extensions, vérification et runbook de retour arrière (downgrade) inclus. À la fin, tous les serveurs exécutent la même nouvelle version mineure et vous conservez les fichiers de la version précédente pour un retour arrière.

Si la version majeure change (par ex. 16 → 17), utilisez pg-major-upgrade et non ce guide ; la mise à jour du logiciel Patroni lui-même se trouve dans pg-patroni.

Topologie: 1 serveur, primary + standbys ou cluster Patroni

Scénarios

• Mise à jour mineure — Passage à une nouvelle version mineure au sein de la même version majeure (par ex. 17.4 → 17.6) : correctifs de sécurité et de bugs. Courte interruption sur un serveur unique, rolling dans un cluster.
• Retour arrière : revenir à la version mineure précédente (downgrade) — Une erreur ou une régression est apparue dans la nouvelle version mineure : on revient en arrière avec les RPM/deb de la version précédente conservés. Le répertoire de données ne change pas.

Avant de commencer

• PostgreSQL … est installé depuis le dépôt PGDG et fonctionne (pg-install). La mise à jour se fait au sein de la même version majeure ; pour passer de … à une autre version majeure, utilisez le guide pg-major-upgrade.
• Les release notes de chaque version mineure entre la version actuelle et la version cible ont été lues. En particulier, on a noté si la section « Migration to Version … » exige une opération supplémentaire (REINDEX, changement de paramètre) : https://www.postgresql.org/docs/release/
• Les serveurs accèdent au dépôt PGDG ou au miroir interne, et le miroir est à jour.
• La fenêtre de maintenance est validée… (le service reste arrêté de quelques secondes à quelques minutes)… (les connexions sont coupées quelques secondes au moment du switchover/restart)… ; l'équipe applicative est informée.
• La dernière sauvegarde a réussi… (pgbackrest info status ok)… et un snapshot machine virtuelle/disque des serveurs peut être pris.
• Tous les standbys sont en streaming, sans retard.
• Les rôles changeant après le switchover, le pg_hba.conf de chaque nœud autorise la connexion replication depuis les autres nœuds et le mot de passe de … figure dans le fichier ~/.pgpass de l'utilisateur postgres sur tous les nœuds.
• Le cluster n'est pas géré par un outil de HA comme Patroni ou repmgr. S'il est géré par Patroni, choisissez Patroni dans la topologie ; pour repmgr, voir les Notes. Les étapes de switchover manuel de ce parcours entrent en conflit avec les décisions de l'outil de HA.
• Le cluster Patroni est sain : un Leader, toutes les replicas en streaming, Lag faible et Maintenance mode désactivé. … est le leader actuel ; les noms des replicas correspondent aux noms de membre Patroni.
• Les commandes patronictl qui modifient l'état (restart, switchover) exigent une authentification à la REST API ; l'utilisateur et le mot de passe se trouvent dans le fichier /etc/patroni/patroni.env sur tous les nœuds (installation pg-patroni). Si vous utilisez une autre organisation, restapi.authentication doit être défini dans le fichier que patronictl lit avec -c.
• Avant la mise à jour, les fichiers RPM/deb de la version précédente ont été enregistrés dans le répertoire … et le numéro de la version précédente se trouve dans le fichier …/prev-version.txt. Sans cette sauvegarde, vous devrez télécharger la version précédente depuis le dépôt (EL : PGDG conserve les anciennes versions ; Debian/Ubuntu : apt-archive.postgresql.org).

Phases du guide

• Contrôle préalable — Enregistrer la version actuelle · Lister les versions du dépôt · Vérifier les release notes · Lister les extensions installées · Vérifier les transactions longues et les prepared transactions
• Sauvegarde et point de retour — Faire une sauvegarde (pgBackRest) · Faire une sauvegarde (pg_dumpall + snapshot) · Conserver les fichiers RPM/deb actuels
• Cluster Patroni : contrôle préalable — Vérifier l'état du cluster et les rôles
• Mise à jour — Lancer un checkpoint · Arrêter PostgreSQL · Mettre à jour le logiciel · Démarrer PostgreSQL
• Mise à jour du primary (courte interruption) — Lancer un checkpoint · Arrêter le primary · Mettre à jour le logiciel · Démarrer le primary
• Switchover et mise à jour de l'ancien primary — Vérifier que la réplication est à jour · Arrêter les écritures applicatives · Arrêter proprement l'ancien primary et noter le dernier checkpoint · … : vérifier que tous les WAL sont arrivés et promouvoir · Rediriger les applications vers le nouveau primary · Créer un replication slot pour l'ancien primary …
• Leader : switchover et mise à jour de l'ancien leader — Ancien leader : mettre à jour le logiciel · Switchover : faire de … le leader · Redémarrer l'ancien leader (…) · Vérifier l'état final du cluster
• Extensions et vérification — Mettre à jour les extensions (ALTER EXTENSION … UPDATE) · Mettre à jour les extensions (ALTER EXTENSION … UPDATE) · Appliquer les opérations supplémentaires des release notes · Vérifier la version et l'état · Rechercher des erreurs dans les logs · Sauvegarde après la mise à jour …
• Retour arrière (downgrade) — Vérifier la version précédente · … : arrêter, installer la version précédente, démarrer · … : installer la version précédente et redémarrer avec Patroni · Leader : installer la version précédente · Transférer le leader et redémarrer l'ancien leader · …Arrêter le primary…Arrêter PostgreSQL… …