DBAtlas · Atlas für Datenbankbetrieb

Assistent für Versions-Upgrades

Patch oder Major, in-place oder per Migration? Plane das Upgrade Schritt für Schritt; jeder Zweig umfasst Vorabprüfungen, Methode und Nacharbeiten. Probe es hier, bevor du die Produktion anfasst.

Welche Art von Upgrade führst du durch?

Ein Patch/eine Minor-Version (innerhalb derselben Major-Version, z. B. 16.2 -> 16.4, oder ein SQL Server CU) ist risikoarm und wird meist in-place durchgeführt. Eine Major-Version (z. B. 15 -> 16) kann Änderungen am Datenformat mit sich bringen und erfordert sorgfältigere Planung.

SELECT * FROM v$version;
SELECT patch_id, action, status FROM dba_registry_sqlpatch ORDER BY action_time DESC;
  • Minor-Version / Patch (gleiche Major-Version, CU)
  • Major-Version (die Major-Version ändert sich)
  • Ich kenne den Unterschied nicht; erkläre ihn

Patch oder Major?

Patch: Die Major-Version bleibt gleich (16.2 -> 16.4); das Format der Datendateien ändert sich nicht, meist Binärdateien austauschen + Neustart. Major: Die Major-Version ändert sich (15 -> 16); Katalog/Format können sich ändern, pg_upgrade / AutoUpgrade / Dump-Restore ist nötig, und die Kompatibilität der Anwendung muss getestet werden.

  • Bei mir ist es ein Patch (gleiche Major-Version)
  • Bei mir ist es ein Major (die Major-Version ändert sich)

Sind Backup und Rollback-Plan bereit?

Auch wenn ein Patch wenig riskant ist, gilt für jedes Upgrade die goldene Regel: zuerst ein Vollbackup (und wenn möglich ein Snapshot). Du brauchst einen Punkt, zu dem du zurückkehren kannst, falls etwas schiefgeht.

  • Ja, Backup + Rollback sind bereit
  • Nein, noch nicht

Zuerst Backup + Rollback-Plan

Richte das Sicherheitsnetz ein, bevor du mit dem Upgrade beginnst.

Patch einspielen

Ein Patch innerhalb derselben Major-Version. Das rollierende Einspielen im Cluster (beginnend mit den Replicas) verringert die Downtime.

Methode für Major-Upgrades

Zwei Hauptwege: (1) In-place: auf dem bestehenden Server konvertieren (pg_upgrade, Oracle AutoUpgrade/DBUA, MySQL in-place). Schnell, aber schwer zurückzunehmen. (2) Per Migration: einen frischen Server mit der neuen Version aufbauen, die Daten übertragen (per Dump/Restore oder Replikation), dann umschalten. Sicherer, mit minimaler Downtime.

  • Zuerst eine Vorbereitungs-/Kompatibilitätsprüfung ausführen
  • In-place
  • Per Migration auf einen neuen Server (minimale Downtime)

Kompatibilitäts- / Bereitschaftsprüfung

Vor dem Upgrade die Warnungen der Zielversion sammeln: entfernte (veraltete) Features, ungültige Objekte, Compatibility Level.

-- AutoUpgrade analyze mode: java -jar autoupgrade.jar -config cfg -mode analyze
  • Saubere Ausgabe, weiter
  • Es gibt Warnungen/Inkompatibilitäten

Zuerst die Warnungen beheben

Behebe jede Warnung im Bericht VOR dem Upgrade; sonst kann das Upgrade mittendrin scheitern oder die Anwendung kaputtgehen.

In-place-Major-Upgrade

Auf dem bestehenden Server konvertieren. Schnell, aber ein Rollback bedeutet meist einen Restore aus dem Backup, ein Snapshot ist daher Pflicht.

Upgrade per Migration (minimale Downtime)

Einen frischen Server mit der neuen Version aufbauen, die Daten übertragen und dann mit einem kurzen Cutover umschalten. Die sicherste Methode; das alte System bleibt unangetastet.

In DBAtlas öffnen →