physar / Datenbankadministration für Sysadmins / Versionswechsel und Migration

Versionswechsel und Migration

Der Wechsel mit Rückweg: Kompatibilität vor dem Termin prüfen, Umstellungsverfahren nach zulässiger Ausfallzeit wählen und ein Abbruchkriterium, das vor dem Wechsel feststeht.

Der Wechsel mit Rückweg

Einführung · 5 Abschnitte · ~15 Min Lesezeit · Stand

Betriebsfrage

Ein Versionswechsel ist selten technisch schwierig. Schwierig ist die Frage, was passiert, wenn die neue Version sich nach zwei Stunden Produktivbetrieb anders verhält als im Test — und ob dann noch ein Weg zurück existiert.

Mentales Modell

  1. Kompatibilität prüfen
  2. Verfahren wählen
  3. Proben
  4. Umstellen
  5. Bestätigen oder zurück

Verfahren nach zulässiger Ausfallzeit

Wechsel am OrtKürzeste Vorbereitung, aber der Rückweg führt über eine Wiederherstellung aus der Sicherung — die Ausfallzeit im Fehlerfall ist die Wiederherstellungsdauer.
Neuaufbau mit ÜbernahmeDie alte Umgebung bleibt bestehen und ist der Rückweg. Dafür sind zwei Umgebungen und ein Datenabgleich nötig.
Übernahme über ReplikationKürzeste Umschaltzeit, höchste Vorbereitung — und ein Rückweg nur, solange die alte Seite konsistent nachgeführt bleibt.

Was vorher zu prüfen ist

  • Verhaltensänderungen, die keine Fehlermeldung erzeugen — geänderte Vorgaben bei Sortierung, Zeitzonen oder Zahlenformaten.
  • Abfragen, deren Ausführungsplan sich mit der neuen Version ändert.
  • Abhängige Werkzeuge: Treiber, Sicherungsverfahren, Überwachung und Berichtssysteme.

Route

Gelesen ist nicht geprüft: Im Modul entscheidest du die Fälle selbst und siehst danach, wo dein Urteil trägt.

3 Checks starten →

Modul-Aufbau

EINFÜHRUNGDer Wechsel mit Rückweg~15 Min
ADR-001UMSTELLVERFAHRENsenior
ADR-002STILLE ÄNDERUNGsenior
FLOW-003MISSION · UMSCHALTPUNKTprincipal

Quellen

  1. 01postgresql.org/docs/current/upgrading.html
  2. 02postgresql.org/docs/current/continuous-archiving.html

Verfasst von Julian Zentgraf