PostgreSQL-Minor-Update (Patch)

Minor-Update innerhalb derselben Hauptversion (z. B. 17.4 → 17.x): Prüfung der Release Notes, Backup und Aufbewahrung der vorhandenen RPM/deb-Pakete für den Rückweg. Auf einem einzelnen Server mit kurzer Downtime; in einem Cluster mit Streaming Replication werden zuerst die Standbys und danach per Switchover der Primary aktualisiert (rolling); in einem Patroni-Cluster werden die Replicas mit patronictl restart und der Leader nach patronictl switchover aktualisiert. Inklusive Extension-Update, Verifizierung und Runbook für das Zurückrollen (Downgrade). Am Ende laufen alle Server mit derselben neuen Minor-Version, und die Dateien der vorherigen Version stehen dir für den Rückweg zur Verfügung.

Wechselt die Hauptversion (z. B. 16 → 17), verwendest du statt dieses Guides pg-major-upgrade; das Update der Patroni-Software selbst steht in pg-patroni.

Topologie: 1 Server, Primary + Standbys oder Patroni-Cluster

Szenarien

• Minor-Update — Wechsel auf eine neue Minor-Version innerhalb derselben Hauptversion (z. B. 17.4 → 17.6): Sicherheits- und Fehlerkorrekturen. Auf einem einzelnen Server kurze Downtime, im Cluster rolling.
• Zurückrollen: auf die vorherige Minor-Version zurück (Downgrade) — In der neuen Minor-Version ist ein Fehler bzw. eine Regression aufgetreten: Mit den gesicherten RPM/deb-Paketen der vorherigen Version wird zurückgerollt. Das Datenverzeichnis bleibt unverändert.

Vor dem Start

• PostgreSQL … ist aus dem PGDG-Repository installiert und läuft (pg-install). Das Update erfolgt innerhalb derselben Hauptversion; für … → eine andere Hauptversion verwendest du den Guide pg-major-upgrade.
• Die Release Notes jeder Minor-Version zwischen aktueller und Zielversion sind gelesen. Insbesondere ist notiert, ob im Abschnitt „Migration to Version …“ zusätzliche Schritte (REINDEX, Änderung einer Einstellung) verlangt werden: https://www.postgresql.org/docs/release/
• Die Server erreichen das PGDG-Repository oder einen internen Mirror, und der Mirror ist aktuell.
• Das Wartungsfenster ist genehmigt… (der Dienst ist einige Sekunden bis einige Minuten nicht verfügbar)… (beim Switchover/Restart brechen Verbindungen für einige Sekunden ab)…; das Anwendungsteam ist informiert.
• Das letzte Backup war erfolgreich… (pgbackrest info status ok)…, und von den Servern lassen sich VM- bzw. Platten-Snapshots erstellen.
• Alle Standbys sind im Zustand streaming und ohne Verzögerung.
• Da sich nach dem Switchover die Rollen ändern, erlaubt die pg_hba.conf jedes Nodes replication-Verbindungen von den anderen Nodes, und das Passwort von … steht auf allen Nodes in der Datei ~/.pgpass des Benutzers postgres.
• Der Cluster wird nicht von einem HA-Werkzeug wie Patroni oder repmgr verwaltet. Verwaltet ihn Patroni, wähle unter Topologie Patroni; zu repmgr siehe die Hinweise. Die manuellen Switchover-Schritte dieses Wegs kollidieren mit den Entscheidungen eines HA-Werkzeugs.
• Der Patroni-Cluster ist gesund: ein Leader, alle Replicas streaming, Lag klein und Maintenance mode aus. … ist der aktuelle Leader; die Replica-Namen entsprechen den Patroni-Membernamen.
• Ändernde patronictl-Befehle (restart, switchover) verlangen eine Authentifizierung an der REST API; Benutzer und Passwort stehen auf allen Nodes in der Datei /etc/patroni/patroni.env (Installation nach pg-patroni). Verwendest du einen anderen Aufbau, muss restapi.authentication in der Datei definiert sein, die patronictl über -c liest.
• Vor dem Update wurden die RPM/deb-Dateien der vorherigen Version im Verzeichnis … gesichert, und die vorherige Versionsnummer steht in …/prev-version.txt. Fehlt die Sicherung, musst du die vorherige Version aus dem Repository herunterladen (EL: PGDG hält ältere Versionen vor; Debian/Ubuntu: apt-archive.postgresql.org).

Phasen der Anleitung

• Vorabprüfung — Aktuelle Version festhalten · Versionen im Repository auflisten · Release Notes prüfen · Installierte Extensions auflisten · Lange Transaktionen und Prepared Transactions prüfen
• Backup und Rückfallpunkt — Backup erstellen (pgBackRest) · Backup erstellen (pg_dumpall + Snapshot) · Vorhandene RPM/deb-Dateien sichern
• Patroni-Cluster: Vorabprüfung — Cluster-Status und Rollen prüfen
• Update — Checkpoint ausführen · PostgreSQL stoppen · Software aktualisieren · PostgreSQL starten
• Update des Primary (kurze Downtime) — Checkpoint ausführen · Primary stoppen · Software aktualisieren · Primary starten
• Switchover und Update des alten Primary — Prüfen, ob die Replikation aktuell ist · Schreibzugriffe der Anwendungen stoppen · Alten Primary sauber herunterfahren und letzten Checkpoint notieren · …: vollständigen WAL-Empfang prüfen und promoten · Anwendungen auf den neuen Primary umleiten · Replication Slot für den alten Primary anlegen …
• Leader: Switchover und Update des alten Leaders — Alter Leader: Software aktualisieren · Switchover: … wird Leader · Alten Leader (…) neu starten · Endzustand des Clusters prüfen
• Extensions und Verifizierung — Extensions aktualisieren (ALTER EXTENSION … UPDATE) · Extensions aktualisieren (ALTER EXTENSION … UPDATE) · Zusätzliche Schritte aus den Release Notes ausführen · Version und Status prüfen · Logs nach Fehlern durchsuchen · Backup nach dem Update …
• Zurückrollen (Downgrade) — Vorherige Version prüfen · …: stoppen, vorherige Version installieren, starten · …: vorherige Version installieren und mit Patroni neu starten · Leader: vorherige Version installieren · Leader übergeben und alten Leader neu starten · …Primary stoppen…PostgreSQL stoppen… …