PostgreSQL über Hauptversionen hinweg aktualisieren: pg_upgrade, Dump und Restore, oder ein Umschalten per logischer Replikation

Ziel

Eine Datenbank mit bekannter Ausfallzeit, einem geprobten Rollback und ohne nachträgliche Überraschungen bei Planer-Statistiken, Erweiterungen oder Kollationen auf eine neue Hauptversion umziehen.

Voraussetzungen

Der Abschnitt „Migration“ der Release Notes für jede übersprungene Hauptversion (das Kapitel zum Upgrade rät, alle dazwischenliegenden Notes zu lesen). Ein getestetes Backup. Die neuen Binärdateien neben den alten installiert, mit den für die neue Version gebauten gemeinsamen Bibliotheken der Erweiterungen. Eine Test-Suite der Anwendung, die gegen den neuen Server laufen kann.

Schritte

1. Die Methode wählen. Dump und Restore mit pg_dumpall aus den neueren Binärdateien ist der traditionelle Weg, kann in einen parallel laufenden Server auf einem anderen Port streamen und ist bei grossen Datenbanken langsam. pg_upgrade migriert an Ort und Stelle; die Dokumentation besagt, dass Upgrades in Minuten durchgeführt werden können, insbesondere mit --link. Ein Standby mit logischer Replikation auf der neuen Version ist der dritte dokumentierte Weg: wenige Sekunden Umschaltzeit, auf Kosten von Einrichtungsaufwand und den Einschränkungen der logischen Replikation.
2. Für pg_upgrade pg_upgrade --check mit dem vorgesehenen Modus-Flag (--link, --clone oder --swap) ausführen, während der alte Server noch läuft; es meldet Inkompatibilitäten und die zu erwartenden manuellen Schritte.
3. Auf einer Kopie proben. Die Dokumentation schlägt eine Kopie mit nur dem Schema und Testdaten für den Bereitstellungstest vor, oder einen kopierten Cluster, der im Link-Modus aktualisiert wird.
4. Den Rollback vor dem Start festlegen. Im Copy- oder Clone-Modus bleibt der alte Cluster unverändert. Bei --link ist der alte Cluster nicht mehr sicher nutzbar, sobald der neue gestartet wurde; bei --swap wird er während der Dateiübertragung destruktiv verändert. In diesen beiden Fällen bedeutet Rollback eine Wiederherstellung aus dem Backup.
5. Das Upgrade im Wartungsfenster durchführen; Änderungen an pg_hba.conf und postgresql.conf auf den neuen Cluster übertragen.
6. Nachgenerieren, was nicht übertragen wurde. Ab PostgreSQL 18 behält pg_upgrade die meisten Optimizer-Statistiken, aber nicht die erweiterten Statistiken; die Dokumentation weist an, zunächst vacuumdb --all --analyze-in-stages --missing-stats-only und danach vacuumdb --all --analyze-only auszuführen. Ältere Versionen übertragen keine Statistiken, sodass die Pläne schlecht sind, bis ANALYZE überall gelaufen ist.
7. Die von pg_upgrade erzeugten Post-Upgrade-Skriptdateien ausführen (darunter Erweiterungs-Updates), alles neu indexieren, was die Release Notes oder Kollations-Versionswarnungen verlangen, die Test-Suite laufen lassen und den alten Cluster erst löschen, wenn alles zufriedenstellend ist.

Erwartetes Ergebnis

Ein Cluster auf der neuen Version mit frischen Statistiken und aktuellen Erweiterungen, ein bewusst gewählter Rollback-Weg, sowie eine Notiz, wie lange jeder Schritt dauerte, für das nächste Upgrade.

Grenzen und Prüfbasis

Die Schritte folgen der zitierten Dokumentation; die Dauer hängt von Grösse, Modus und Hardware ab und wird nicht beziffert. Standbys brauchen ein eigenes Verfahren (die pg_upgrade-Seite beschreibt eines auf Basis von rsync), und der Replikationsweg braucht einen Primärschlüssel oder eine Replikat-Identität auf jeder Tabelle, die Updates oder Löschungen erhält.

Ein Upgrade im Link-Modus rückgängig machen

Im Link-Modus liegt der Punkt ohne Umkehr beim ersten Start des neuen Clusters, nicht bei pg_upgrade selbst. Bricht der Lauf ab, bevor das Verlinken beginnt, bleibt der alte Cluster unberührt. Hat das Verlinken begonnen, wurde der neue Server aber noch nicht gestartet, ist der alte Cluster intakt bis auf global/pg_control, das pg_upgrade in pg_control.old umbenannt hat; das Entfernen des Suffixes stellt ihn wieder her. Sobald der neue Cluster gestartet wurde, hat er in die gemeinsamen Dateien geschrieben, und der alte Cluster darf nicht mehr verwendet werden; ab diesem Zeitpunkt bedeutet Rollback eine Wiederherstellung aus dem Backup. Das Intervall zwischen beidem proben: jede Prüfung, die keinen laufenden Server braucht, vor diesem ersten Start ausführen. Im Swap-Modus wird der alte Cluster während der Übertragung verändert, sodass nur der Backup-Weg gilt.