Versionswechsel und Migration: Format, Rückweg und der Punkt ohne Umkehr

Der Rückfallplan lautet „notfalls starten wir den alten Cluster“ — und die gewählte Betriebsart des Wechselwerkzeugs macht genau das unmöglich, sobald der Vorgang beginnt. Dieses Modul trennt den Nebenversionswechsel, der laut Dokumentation nur ein Austausch der Programmdateien ist, vom Hauptversionswechsel, bei dem sich das Speicherformat ändert — und zeigt, dass die Wahl des Verfahrens in Wahrheit eine Wahl über den Rückweg ist.

Lehrtext · 10 Abschnitte · zuletzt geprüft: 2026-09-12

Zwei Arten von Versionswechsel, die nichts gemeinsam haben

„Wir müssen die Datenbank aktualisieren“ beschreibt zwei völlig verschiedene Vorhaben. Das eine ist ein Neustart, das andere ein Projekt. Welches davon ansteht, entscheidet die Versionsnummer — und die Unterscheidung ist bei PostgreSQL formal festgelegt.

Nebenversion — Die zweite Zahl innerhalb einer Hauptversion — in 18.4 also die 4. Sie bringt Fehlerkorrekturen und Sicherheitsbehebungen.

Hauptversion — Die erste Zahl — in 18.4 also die 18. Ein Wechsel hierher ändert das interne Speicherformat und die sichtbaren Eigenschaften.

Die Regel, die den Unterschied ausmachtNebenversionen ändern laut Dokumentation niemals das interne Speicherformat und sind immer mit früheren und späteren Nebenversionen derselben Hauptversion kompatibel. Für Hauptversionen gilt das Gegenteil: Dort kann sich das interne Format ändern, was den Wechsel verkompliziert.

Daraus folgt die Aufwandsverteilung, die viele überrascht: Nebenversionswechsel sind häufig, klein und sollten routiniert laufen. Hauptversionswechsel sind selten, groß und brauchen eine eigene Planung. Wer beide gleich behandelt, macht entweder das eine unnötig teuer oder das andere gefährlich billig.

Der Nebenversionswechsel ist wirklich so einfach

Die Dokumentation beschreibt das Verfahren in einem Satz, und es lohnt, ihn ernst zu nehmen, weil er eine verbreitete Scheu ausräumt.

WörtlichUm zwischen kompatiblen Versionen zu aktualisieren, ersetzt man einfach die ausführbaren Dateien, während der Server gestoppt ist, und startet den Server neu. Das Datenverzeichnis bleibt unverändert — Nebenversionswechsel sind so einfach.

Kein Export, kein Import, keine Umwandlung. Die Ausfallzeit ist die eines Dienstneustarts. Das heißt nicht, dass man sie ungeprüft einspielt — Fehlerkorrekturen können Verhalten ändern, und die Anmerkungen zur jeweiligen Version gehören gelesen. Aber der Vorgang ist ein Wartungsfenster von Minuten, kein Vorhaben.

Die Folge für den BetriebsalltagWeil der Vorgang so klein ist, gibt es kaum einen guten Grund, Nebenversionen auflaufen zu lassen — und sie enthalten genau die Sicherheitsbehebungen, wegen derer man aktualisiert. Ein Bestand, der drei Nebenversionen hinterherhängt, hat nicht Aufwand gespart, sondern bekannte Fehler behalten.

Beim Hauptversionswechsel ändert sich das Format

Weil sich das interne Speicherformat ändern kann, lässt sich ein Datenverzeichnis nicht einfach mit der neuen Version starten. Die Dokumentation hält dazu zwei Dinge fest, die im Ernstfall beruhigen.

Es gibt Prüfungen, die verhindern, dass man ein Datenverzeichnis mit einer inkompatiblen Version verwendet — ein versehentlicher Start der falschen Serverversion richtet daher keinen großen Schaden an.
Ein Export für den Wechsel muss mit einem logischen Werkzeug erfolgen; Sicherungsverfahren auf Dateisystemebene funktionieren dafür nicht.

Der zweite Punkt ist der, der Konzepte umwirft. Die physische Sicherung, die im Modul über Backup und Recovery die Grundlage für Point-in-Time-Recovery war, taugt nicht als Weg auf eine neue Hauptversion. Sie ist an das Format der alten Version gebunden. Wer also glaubt, er könne im Notfall die Sicherung einfach auf der neuen Version einspielen, irrt.

Die Dokumentation nennt drei gangbare Wege: Export und Import über ein logisches Werkzeug, das Werkzeug pg_upgrade, und Verfahren über Replikation. Sie unterscheiden sich fast ausschließlich in zwei Größen — wie lange der Dienst steht, und wie der Rückweg aussieht.

Export und Import: Langsam, laut Dokumentation die traditionelle Methode. Dafür entsteht ein vollständig getrennter neuer Bestand; der alte bleibt unangetastet.
pg_upgrade: Deutlich schneller. Der Rückweg hängt an der gewählten Betriebsart — siehe unten.
Über Replikation: Kürzeste Ausfallzeit, weil der neue Stand vorab aufgebaut wird. Dafür der größte Einrichtungsaufwand.

Ein Hinweis, der Zeit spartDie Dokumentation empfiehlt, die Export-Werkzeuge der neueren Version zu verwenden, um von deren Verbesserungen zu profitieren. Das klingt zunächst widersinnig, weil die neue Version noch gar nicht installiert ist — und ergibt genau dann Sinn, wenn man sie parallel zur alten installiert. Das verkürzt zugleich die Ausfallzeit.

Die Anmerkungen auch der übersprungenen Versionen

Der teuerste Fehler bei einem Hauptversionswechsel ist keiner der Technik, sondern der Vorbereitung — und die Dokumentation formuliert die Pflicht dazu ungewöhnlich direkt.

Wörtlich aus der DokumentationNeue Hauptversionen führen typischerweise einige für Benutzer sichtbare Inkompatibilitäten ein, sodass Änderungen an der Anwendungsprogrammierung nötig sein können. Alle für Benutzer sichtbaren Änderungen stehen in den Versionsanmerkungen; besondere Aufmerksamkeit gebührt dem Abschnitt „Migration“. Obwohl man von einer Hauptversion zu einer anderen wechseln kann, ohne die dazwischenliegenden Versionen zu durchlaufen, sollte man die Anmerkungen zu allen dazwischenliegenden Hauptversionen lesen.

Das ist der Punkt, an dem ein Sprung von drei Hauptversionen teurer wird als drei einzelne Wechsel — nicht technisch, sondern in der Lesearbeit. Und diese Arbeit lässt sich nicht delegieren oder überspringen: Eine Inkompatibilität, die vor zwei Versionen eingeführt wurde, betrifft den Bestand genauso, als hätte man den Zwischenschritt gemacht.

Die Dokumentation nennt dabei drei Kategorien, auf die beim Testen zu achten ist: die Verwaltungsmöglichkeiten zur Beobachtung und Steuerung des Servers, die auf SQL sichtbaren Änderungen — typischerweise neue Fähigkeiten und keine Verhaltensänderungen, sofern die Anmerkungen nichts anderes sagen — und die Schnittstellen der Programmbibliotheken.

Was daraus folgtDie Lesearbeit gehört in die Aufwandsschätzung, nicht in die Restzeit vor dem Wartungsfenster. Wer den Wechsel als Infrastrukturaufgabe plant und die Anwendungsseite erst am Abend entdeckt, hat die Hälfte des Vorhabens übersehen.

Die Betriebsart ist die Entscheidung über den Rückweg

pg_upgrade kennt mehrere Arten, die Daten in den neuen Cluster zu bringen. Sie unterscheiden sich in der Geschwindigkeit — und, wichtiger, darin, ob der alte Cluster danach noch startfähig ist. Genau das ist der Rückweg.

--copy (Voreinstellung): Kopiert die Dateien. Am langsamsten, dafür bleibt der alte Cluster vollständig unangetastet und jederzeit startbar.
--clone: Nutzt effizientes Datei-Klonen — „Reflinks“. Laut Dokumentation nahezu augenblickliches Kopieren mit der Geschwindigkeit von --link, wobei der alte Cluster unangetastet bleibt. Nur auf bestimmten Systemen und Dateisystemen unterstützt; wird es gewählt und nicht unterstützt, bricht der Lauf mit einem Fehler ab.
--link: Verwendet harte Verweise statt zu kopieren. Sehr schnell — alter und neuer Cluster teilen sich dann die Dateien.
--swap: Verschiebt die Datenverzeichnisse. Kann laut Dokumentation die anderen Arten übertreffen, besonders bei vielen Relationen. Aber: Sobald der Dateiübertragungsschritt beginnt, wird der alte Cluster verändernd angefasst und ist danach nicht mehr sicher startbar.

Die Entscheidung in einem SatzJe schneller die Betriebsart, desto enger die Kopplung an den alten Cluster — und desto weniger bleibt vom Rückweg. --clone ist die bemerkenswerte Ausnahme: Sie kauft die Geschwindigkeit, ohne den alten Bestand zu opfern, ist aber an Betriebssystem und Dateisystem gebunden. Wo sie verfügbar ist, ist sie in aller Regel die richtige Wahl.

Eine Kombination, die die Dokumentation ausdrücklich empfiehltWer --swap wählt, sollte laut Dokumentation zugleich --sync-method=fsync setzen — die voreingestellte Methode. Der Grund: Diese Betriebsart hinterlässt viele überflüssige Dateien im alten Cluster, und die alternative Methode syncfs, die das Betriebssystem ganze Dateisysteme synchronisieren lässt, würde den Synchronisationsschritt dadurch unnötig verlängern. Das ist ein gutes Beispiel dafür, wie zwei Optionen, die jede für sich vernünftig aussehen, zusammen langsamer sind als jede einzeln — und warum sich der Blick in die Anmerkungen zu beiden lohnt, bevor man sie kombiniert.

Und eine Option, die nicht in die Produktion gehört--no-sync lässt das Werkzeug zurückkehren, ohne darauf zu warten, dass alle Dateien des aktualisierten Clusters sicher auf Platte geschrieben sind. Das ist schneller — bedeutet aber laut Dokumentation, dass ein anschließender Betriebssystemabsturz das Datenverzeichnis beschädigt zurücklassen kann. Die Dokumentation nennt die Option nützlich für Tests und hält ausdrücklich fest, dass sie in einer Produktionsinstallation nicht verwendet werden sollte.

Die Nebeninstallation ist der halbe Test

Die Dokumentation empfiehlt vorsichtigen Anwendern, ihre Client-Anwendungen auf der neuen Version zu testen, bevor vollständig umgestellt wird — und dafür gleichzeitige Installationen der alten und neuen Version einzurichten. Das ist mehr als eine Vorsichtsmaßnahme: Es ist die einzige Gelegenheit, die Inkompatibilitäten aus den Versionsanmerkungen an der eigenen Anwendung zu prüfen statt am Text.

Was auf der Nebeninstallation tatsächlich geprüft wird

Szenario

Vor einem Hauptversionswechsel steht eine parallel installierte neue Version bereit, befüllt aus einem Export der Produktion.

Anforderungen

Ein Bestand, der dem produktiven ähnelt — personenbezogene Daten vorher umgewandelt
Dieselben Anwendungsfassungen wie in der Produktion
Genug Zeit, um Auswertungen wirklich laufen zu lassen

Schritte

Die Anwendungen verbinden und die üblichen Abläufe durchspielen — dabei gezielt das prüfen, was in den Anmerkungen unter „Migration“ stand.
Die langlaufenden Auswertungen ansehen: Ein geänderter Planer kann bei gleicher Abfrage einen anderen Weg wählen. Das ist kein Fehler, aber es kann Laufzeiten verschieben.
Die eigenen Betriebsskripte prüfen — Sichten und Verwaltungsmöglichkeiten ändern sich laut Dokumentation häufig zwischen Hauptversionen, und genau darauf greifen Überwachung und Wartungsaufträge zu.
Den Wechselvorgang selbst mitstoppen: Wie lange dauert er auf dieser Datenmenge? Diese Zahl ist die Grundlage des Wartungsfensters und lässt sich nirgends nachschlagen.

Merksatz: Die Nebeninstallation beantwortet „läuft es“ und „wie lange dauert es“. Was sie nicht beantwortet, ist das Verhalten unter echter Last — dafür ist sie zu ruhig.

Der Teil, den auch ein guter Test nicht abdecktEine Kollationsfrage aus dem Grundlagenmodul kommt hier wieder: Ein Cluster kann laut Dokumentation nicht auf eine inkompatible Version der Kollations-Bibliothek wechseln — und ein Betriebssystem-Upgrade ist ausdrücklich einer der Wege, auf denen das passiert. Wer den Datenbankwechsel mit einem Betriebssystemwechsel verbindet, weil beides ohnehin ein Fenster braucht, ändert damit zwei Dinge gleichzeitig, von denen eines die Sortierordnung in den Indizes betrifft.

Der Plattformwechsel, der stillschweigend mitläuft

Ein Versionswechsel fällt oft mit neuer Hardware zusammen — das Fenster ist ohnehin da, die alte Maschine ist ohnehin alt. Damit ändern sich aber zwei Dinge gleichzeitig, und das zweite bringt Eigenheiten mit, die in keiner Versionsanmerkung stehen.

Die Überraschung aus der Werkzeugdokumentationpg_upgrade kennt eine Option --set-char-signedness, mit der sich die Vorzeichenbehandlung des Zeichentyps für neue Cluster ausdrücklich festlegen lässt. Der Grund steht daneben: In der Sprache C unterscheidet sich die voreingestellte Vorzeichenbehandlung des Typs char zwischen Plattformen — auf x86-Prozessoren gilt voreingestellt signed char, auf ARM-Prozessoren dagegen unsigned char. Dass es diese Option überhaupt gibt, ist der Hinweis: Ein Wechsel der Prozessorarchitektur ist keine reine Umzugsfrage.

Dazu kommt der Befund aus dem Grundlagenmodul, der hier ein zweites Mal greift: Ein Cluster kann laut Dokumentation nicht auf eine inkompatible Version der Kollations-Bibliothek wechseln — und sie nennt dabei ausdrücklich ein anderes Betriebssystem und ein Betriebssystem-Upgrade als Wege, auf denen genau das passiert. Betroffen ist die Sortierordnung, und die steckt in den Indizes.

Neue Datenbankversion: Ändert das Speicherformat und möglicherweise sichtbares Verhalten. Vorbereitet über die Versionsanmerkungen.
Neues Betriebssystem: Kann die Kollations-Bibliothek wechseln. Betrifft die Sortierordnung in Indizes — steht in keiner Datenbank-Versionsanmerkung.
Neue Prozessorarchitektur: Kann Grundannahmen wie die Vorzeichenbehandlung von char ändern. Dafür gibt es eine eigene Option, die man kennen muss.

Was daraus für die Planung folgtDrei Änderungen in einem Fenster heißt auch: drei mögliche Ursachen für jeden Befund danach. Wer die Möglichkeit hat, trennt sie — erst die Hardware mit gleicher Datenbankversion, dann die Version. Wer die Möglichkeit nicht hat, sollte wenigstens vorher wissen, welche der drei Ebenen sich mitändert, damit die Fehlersuche nicht bei der falschen beginnt.

Praktisch hilfreich ist dabei, dass sich beide Versionen nebeneinander betreiben lassen. Die Dokumentation zeigt das über verschiedene Ports: Der alte Server läuft weiter auf 5432, der neue auf 5433, und die Daten wandern mit einem Aufruf der Form pg_dumpall -p 5432 | psql -d postgres -p 5433 hinüber. Dieselben Werkzeuge lassen sich übrigens weit zurück einsetzen: Die aktuellen Export-Programme können laut Dokumentation Daten von Servern bis hinunter zu Version 9.2 lesen.

Der Punkt ohne Rückweg

Jeder Hauptversionswechsel hat einen Moment, ab dem die Rückkehr auf die alte Version nicht mehr durch Zurücknehmen erfolgt, sondern nur noch durch Wiederherstellung aus einer Sicherung — mit Verlust aller Änderungen seit dem Wechsel.

Dieser Moment ist nicht der Start des Wechselvorgangs. Er liegt dort, wo die erste Schreiboperation auf dem neuen Stand stattfindet. Solange nur gelesen wird, ist die Rückkehr billig; ab der ersten Buchung kostet sie diese Buchung.

Vor dem Punkt: Der alte Cluster ist startbar, kein neuer Schreibvorgang ist erfolgt. Rückkehr bedeutet: alte Version starten, Clients umlenken, fertig.
Nach dem Punkt: Auf dem neuen Stand wurde geschrieben. Eine Rückkehr auf den alten Cluster verliert diese Schreibvorgänge — und ein Zurückspielen auf die alte Hauptversion geht nur über einen logischen Export, nicht über die physische Sicherung.
Die Betriebsart entscheidet mit: Bei --link und erst recht bei --swap ist der alte Cluster nicht mehr verlässlich startbar — der Punkt ohne Rückweg liegt dann schon beim Wechselvorgang selbst, nicht erst beim ersten Schreibzugriff.

Was daraus für die Planung folgtDer Punkt ohne Rückweg gehört vor dem Fenster benannt und mit einem Abbruchkriterium versehen: Was muss bis wann funktionieren, damit weitergemacht wird — und wer entscheidet das? Diese Frage nachts um drei zum ersten Mal zu stellen, ist der Grund, warum Wechsel mit „dann haben wir es halt durchgezogen“ enden.

Was nach dem Wechsel zu tun bleibt

Der Wechsel ist mit dem ersten erfolgreichen Anmelden nicht abgeschlossen. Drei Dinge stehen danach an, und alle drei werden gern vergessen.

Statistiken prüfen: pg_upgrade kennt eine Option --no-statistics, um Statistiken nicht aus dem alten Cluster zu übernehmen. Ob übernommen oder nicht — nach einem Wechsel gehört geprüft, ob der Planer auf brauchbaren Zahlen arbeitet, sonst wählt er Wege wie im Modul über Ausführungspläne beschrieben.
Sicherungskette neu beginnen: Die bisherige Kette gehört zur alten Version und zum alten Cluster. Eine neue Grundsicherung ist nach dem Wechsel keine Formalie, sondern die Voraussetzung dafür, dass überhaupt wieder ein Zeitpunkt wählbar ist.
Den alten Bestand aufbewahren: Nicht sofort löschen. Er ist der einzige verbleibende Rückweg, solange der neue Stand sich nicht bewährt hat — und er belegt Platz, was die Versuchung groß macht.

Die Reihenfolge dieser dreiErst die Sicherungskette, dann die Statistiken, dann alles Weitere. Ein neuer Stand ohne gültige Sicherung ist ein Stand ohne Netz — und die ersten Stunden nach einem Wechsel sind statistisch die, in denen etwas auffällt.

Die Reihenfolge, die das zusammenhält

Art des Wechsels bestimmen: Neben- oder Hauptversion→Bei Hauptversion: Anmerkungen aller dazwischenliegenden Versionen lesen→Verfahren und Betriebsart nach dem gewünschten Rückweg wählen→Auf einer Nebeninstallation testen und die Dauer messen→Punkt ohne Rückweg und Abbruchkriterium vor dem Fenster festlegen

Rückweg vor Geschwindigkeit

Der dritte Schritt ist der, an dem die meisten Wechsel ihre Richtung bekommen. Die schnellste Betriebsart ist fast immer die mit dem schwächsten Rückweg — und die Entscheidung zwischen beiden ist keine technische, sondern die Frage, wie viel Ausfallzeit man gegen wie viel Umkehrbarkeit tauscht. Wer sie nicht ausdrücklich trifft, trifft sie stillschweigend zugunsten der Geschwindigkeit.

AbgrenzungWie eine Schemaänderung rückwärtskompatibel ausgeliefert wird, steht im Modul über Schemaänderungen im laufenden Betrieb. Wie die Sicherungskette aufgebaut und nachgewiesen wird, steht im Modul über Backup und Recovery. Change-Verfahren, Freigaben und Terminplanung als Prozess stehen im Track itsm-operations. Hier ging es um das, was der Versionswechsel mit den Daten tut — und was er unwiderruflich macht.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität7 Primärquellen · zuletzt geprüft: 2026-09-12