Hauptversionsupgrades in Azure Database für PostgreSQL Flexible Server

Ihr Azure Database for PostgreSQL flexibler Server unterstützt PostgreSQL-Versionen 18, 17, 16, 15, 14, 13, 12, 11. Die Postgres-Community veröffentlicht etwa einmal im Jahr eine neue Hauptversion mit neuen Features. Darüber hinaus werden für jede Hauptversion regelmäßig Fehlerbehebungen in Form von Nebenversionen veröffentlicht. Nebenversionsupgrades enthalten Änderungen, die mit bereits vorhandenen Anwendungen abwärtskompatibel sind. Ein Azure Database for PostgreSQL flexibler Server aktualisiert die Nebenversionen regelmäßig während des Wartungsfensters eines Kunden.

Hauptversionsupgrades sind komplizierter als Nebenversionsupgrades. Sie können interne Änderungen und neue Features enthalten, die nicht abwärtskompatibel mit vorhandenen Anwendungen sind.

Ihr Azure Database for PostgreSQL – Flexibler Server verfügt über eine Funktion, die ein direktes Upgrade auf eine höhere Hauptversion des Servers ermöglicht. Dieses Feature vereinfacht den Upgradeprozess, indem die Unterbrechung von Benutzern und Anwendungen, die auf den Server zugreifen, minimiert wird.

Direkte Upgrades behalten den Servernamen und andere Einstellungen des aktuellen Servers nach dem Upgrade einer Hauptversion bei. Sie erfordern keine Datenmigration oder Änderungen an den Anwendungsverbindungszeichenfolgen. Direkte Upgrades sind schneller und mit weniger Downtime verbunden als eine Datenmigration.

Überprüfungsprüfungen für Upgrades (Vorschau)

Azure Database for PostgreSQL – Flexibler Server bietet Überprüfungen zur Upgradevalidierung, mit denen Sie die Bereitschaft für ein Upgrade bewerten können, bevor Sie ein Upgrade auf eine höhere Hauptversion starten.

Upgradeüberprüfungen führen eine Reihe von Kompatibilitäts- und Konfigurationsüberprüfungen für den Server aus, um Bedingungen zu identifizieren, die dazu führen können, dass das Upgrade fehlschlägt oder sich unerwartet verhält. Zu den üblichen Prüfungen gehören nicht unterstützte Erweiterungen, logische Replikationsslots, vorbereitete Transaktionen, Ereignistrigger, nicht unterstützte Objektabhängigkeiten und ausstehende Konfigurationsänderungen, die einen Neustart erfordern.

Der Überprüfungsprozess wurde entwickelt, um die Upgradebereitschaft auszuwerten, ohne den tatsächlichen Upgradevorgang zu initiieren. Die gleichen Überprüfungen werden auch während des Hauptversionsupgradeworkflows automatisch ausgeführt. Diese Prüfungen ändern die Serverversion nicht, lösen Ausfallzeiten aus oder starten den Server neu. Führen Sie Überprüfungen vor der Planung eines Produktionsupgradefensters aus.

Nach Abschluss der Überprüfung wird eines der folgenden Ergebnisse zurückgegeben:

• Es wurden keine Blockierungsprobleme erkannt: Upgradeüberprüfungen wurden erfolgreich abgeschlossen und haben keine Probleme identifiziert, die das Upgrade blockieren.
• Blockierende Probleme erkannt: Upgrade-Validierungsprüfungen haben ein oder mehrere Probleme identifiziert, die behoben werden müssen, bevor das Upgrade fortgesetzt werden kann.

Abhängig von den Ergebnissen können Sie entweder mit dem Upgrade fortfahren oder die gemeldeten Probleme beheben und die Überprüfung erneut ausführen.

Einschränkungen

Beachten Sie bei der Verwendung der Upgrade-Validierungsprüfungen die folgenden Einschränkungen:

• Der Serverstatus muss bereit sein.
• Überprüfungen werden für Lesereplikate nicht unterstützt.
• Die Überprüfung kann nicht ausgeführt werden, während bereits ein anderer Servervorgang ausgeführt wird.
• Überprüfungen erfordern eine Verbindung mit allen Datenbanken auf dem Server. Nicht reagierende oder nicht zugängliche Datenbanken können zu Überprüfungsfehlern führen.
• Obwohl Validierungsprüfungen keine Ausfallzeiten verursachen, sollten Sie sie in Erwägung ziehen, sie in Zeiträumen niedrigerer Datenbankaktivitäten auszuführen.

Schritt-für-Schritt-Anweisungen finden Sie unter Validierungsprüfungen für Upgrades ausführen (Vorschau).

Upgradeprozess

Hier sind einige wichtige Aspekte, die Sie bei In-Place-Upgrades auf eine neue Hauptversion beachten sollten:

• Stellen Sie vor dem Starten des Upgrades sicher, dass ihr Server mindestens 10-20% kostenlosen Speicherplatz zur Verfügung hat. Während des Upgradevorgangs können temporäre Protokolldateien und Metadatenvorgänge die Datenträgerauslastung erhöhen. Unzureichender freier Speicherplatz kann zu Upgradefehlern oder Rollbackproblemen führen.
• Während eines direkten Upgrades auf eine neue Hauptversion führt Ihr flexibler Azure Database for PostgreSQL-Server eine Vorabprüfung durch, um mögliche Probleme zu identifizieren, die zum Fehlschlagen des Upgrades führen könnten.
  • Wenn bei der Vorabüberprüfung Inkompatibilitäten gefunden werden, werden ein Protokollereignis mit der Information, dass bei der Vorabüberprüfung für das Upgrade ein Fehler aufgetreten ist, und eine Fehlermeldung erstellt.
  • Wenn die Vorabüberprüfung erfolgreich ist, beendet der Azure Database for PostgreSQL flexible Server den Dienst und übernimmt eine implizite Sicherung unmittelbar vor dem Starten des Upgrades. Der Dienst kann diese implizite Sicherung verwenden, um die Datenbankinstanz in der vorherigen Version wiederherzustellen, wenn ein Upgradefehler auftritt.
• Ein flexibler Server von Azure Database for PostgreSQL verwendet das Tool pg_upgrade, um In-Place-Upgrades auf höhere Hauptversionen durchzuführen. Der Dienst bietet die Flexibilität, Versionen zu überspringen und direkt auf spätere Versionen zu aktualisieren.
• Während eines direkten Upgrades eines Servers auf eine neue Hauptversion, der für Hochverfügbarkeit (HA) konfiguriert ist, deaktiviert der Dienst HA, führt das Upgrade auf dem primären Server durch und aktiviert HA nach Abschluss des Upgrades wieder. Für die erneute Aktivierung von HA ist ausreichend Kapazität erforderlich, um eine neue Standbyinstanz bereitzustellen.
• Die meisten Erweiterungen werden während eines direkten Hauptversionsupgrades automatisch auf spätere Versionen aktualisiert. Es gibt allerdings einige Ausnahmen.
• Der Prozess eines direkten Hauptversionsupgrades für einen Azure Database for PostgreSQL flexiblen Server stellt automatisch die neueste unterstützte Nebenversion bereit.
• Die Upgradedauer hängt von der Größe und Komplexität Ihrer Datenbank ab, einschließlich der Anzahl der Objekte (Tabellen, Indizes, Schemas), großen Objekten und Erweiterungen. Größere oder komplexere Workloads können längere Upgradezeiten haben.
• Im Falle von zeitintensiven Transaktionen oder einer hohen Arbeitsauslastung vor einem Upgrade können das Herunterfahren der Datenbank und das Upgrade länger dauern.
• Nach einem erfolgreichen direkten Hauptversionsupgrade gibt es keine automatisierte Möglichkeit mehr, zur vorherigen Version zurückzukehren. Sie können eine Point-in-Time-Wiederherstellung (PITR) auf einen Zeitpunkt vor dem Upgrade ausführen, um die vorherige Version auf einem neuen Server wiederherzustellen.
• Sichern Sie Ihren Azure Database for PostgreSQL Server. Nach einem Upgrade auf eine neue Hauptversion auf einem flexiblen Azure Database for PostgreSQL-Server verfügt der erste auf dem Server erstellte Benutzer, dem die ADMIN-Option gewährt wird, nun über Administratorberechtigungen gegenüber anderen Rollen für wesentliche Wartungsvorgänge.

Überlegungen und Einschränkungen für Upgrades

Wenn ein Vorabcheckvorgang während eines direkten Hauptversionsupgrades fehlschlägt, stoppt der Upgradevorgang und zeigt eine detaillierte Fehlermeldung an. Die folgenden bekannten Einschränkungen können dazu führen, dass das Upgrade fehlschlägt oder sich unerwartet verhält:

Nicht unterstützte Serverkonfigurationen

• Georeplikation in Azure Database for PostgreSQL wird bei In-Place-Upgrades nicht unterstützt. Sie müssen das Lesereplikat (einschließlich eines kaskadierenden Lesereplikats) löschen, bevor Sie den primären Server aktualisieren. Nach dem Upgrade können Sie das Replikat wieder erstellen.
• Netzwerkdatenverkehrsregeln blockieren möglicherweise Upgradevorgänge.
  • Stellen Sie sicher, dass Ihr flexibler Server Datenverkehr an den Ports 5432 und 6432 innerhalb des virtuellen Netzwerks und an Azure Storage (für die Protokollarchivierung) senden und empfangen kann.
  • Wenn Netzwerksicherheitsgruppen (Network Security Groups, NSGs) diesen Datenverkehr einschränken, wird hohe Verfügbarkeit (HA) nach dem Upgrade nicht automatisch wieder aktiviert. Möglicherweise müssen Sie NSG-Regeln manuell aktualisieren und HA erneut aktivieren.
• Ansichten, die von pg_stat_activity abhängen, werden bei Upgrades auf eine Hauptversion nicht unterstützt.
• Wenn Sie ein Upgrade von PostgreSQL 11 auf eine höhere Version durchführen, müssen Sie zuerst Ihren flexiblen Server so konfigurieren, dass die SCRAM-Authentifizierung verwendet wird, indem Sie SCRAM aktivieren und alle Authentifizierungsrollen-Kennwörter zurücksetzen.

Erweiterungseinschränkungen

Direkte Upgrades auf eine neue Hauptversion unterstützen nicht alle PostgreSQL-Erweiterungen. Das Upgrade schlägt während der Vorabüberprüfung fehl, wenn eine blockierte Erweiterung auf einem betroffenen Upgradepfad vorhanden ist. Die meisten Blöcke sind auf bestimmte Zielversionen (und manchmal Quellversionen) und nicht auf jedes Upgrade ausgerichtet, wie in den folgenden Listen erwähnt.

• Die folgenden Erweiterungen blockieren ein direktes Hauptversionsupgrade auf allen Upgradepfaden. Entfernen Sie sie vor dem Upgrade, und aktivieren Sie sie danach wieder, falls sie in der Zielversion unterstützt werden: session_variable, anon, age.

• Die folgenden Erweiterungen sind nicht persistente Hilfsprogrammerweiterungen und müssen vor dem Upgrade verworfen und nach dem Entwurf (alle Upgradepfade) neu erstellt werden: pg_repack, , hypopgpg_partman.

• Die folgenden Erweiterungen werden nur für bestimmte Versionspfade blockiert. Entfernen Sie sie vor dem Upgrade, wenn Ihr Upgrade mit der aufgeführten Bedingung übereinstimmt, und aktivieren Sie sie nach der Unterstützung in der Zielversion erneut:

  Extension	Blockiert, wenn
  pg_hint_plan	Zielversion ist PostgreSQL 14
  semver	Zielversion ist PostgreSQL 16 oder 17
  azure_local_ai	Zielversion ist PostgreSQL 17 oder 18
  pg_failover_slots	Zielversion ist PostgreSQL 17 oder 18 (freigegebene Preload-Bibliothek)
  azure_ai	Zielversion ist PostgreSQL 18
  azure_storage	Zielversion ist PostgreSQL 18
  pg_diskann	Zielversion ist PostgreSQL 18
  pgrouting	Zielversion ist PostgreSQL 15; oder Quelle ist früher als PostgreSQL 16 und Ziel ist PostgreSQL 16 oder höher; oder Zielversion ist PostgreSQL 18
  orafce	Quellversion ist PostgreSQL 11, 12 oder 13

• Die folgenden Erweiterungen werden blockiert, wenn andere Datenbankobjekte von ihren Objekten abhängen, da das Upgrade andernfalls fehlschlägt. Beheben Sie die Abhängigkeiten vor dem Upgrade:

  • pg_stat_statements: blockiert, wenn andere Objekte von ihrer Ansicht oder Funktion abhängen, wodurch ALTER EXTENSION pg_stat_statements UPDATE fehlschlagen würde. Entfernen Sie zuerst die abhängigen Objekte.
  • pgcrypto: wird beim Installieren im pg_catalog Schema und beim Upgrade von PostgreSQL 11 oder 12 auf PostgreSQL 13 oder höher blockiert, wenn Kundenobjekte davon abhängen (ein Konflikt mit der integrierten gen_random_uuid() Funktion). Verschieben Sie die Erweiterung in ein anderes Schema, oder legen Sie die abhängigen Objekte zuerst ab.

PostGIS-spezifische Überlegungen

Wenn Sie PostGIS oder abhängige Erweiterungen verwenden, konfigurieren Sie den search_path Parameter für Folgendes:

• Schemas im Zusammenhang mit PostGIS
• Abhängige Erweiterungen, einschließlich: postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_us, fuzzystrmatch
• Wenn Sie search_path nicht korrekt konfigurieren, kann das Upgrade fehlschlagen oder nach dem Upgrade Objekte beschädigen.

TimescaleDB-spezifische Besonderheiten

Wenn Sie TimescaleDB verwenden, werden direkte Hauptversionsupgrades nur für bestimmte PostgreSQL-Quell- und Zielversionskombinationen unterstützt:

Wenn Ihr TimescaleDB-Upgradepfad nicht in der unterstützten Matrix aufgeführt ist, wird das direkte Hauptversionsupgrade blockiert. Um fortzufahren, legen Sie entweder die TimescaleDB-Erweiterung vor dem Upgrade ab, falls möglich, oder verwenden Sie einen alternativen Migrationsansatz wie die parallele Migration mit logischer Replikation.

Stellen Sie sicher, dass Die Quell- und Zielversionen in der unterstützten Matrix enthalten sind, bevor Sie mit dem Upgrade beginnen.

Weitere Überlegungen zum Upgrade

• Ereignistrigger: Upgrade precheck blockiert Ereignistrigger, da sie in DDL-Befehle eingebunden sind und möglicherweise auf Systemkataloge verweisen, die sich zwischen Hauptversionen ändern. Legen Sie alle EVENT TRIGGERs vor dem Upgrade ab, und erstellen Sie sie nach dem Upgrade erneut, um ein reibungsloses Upgrade sicherzustellen.
• Große Objekte (LOs): Die Art und Weise, wie ein Upgrade Datenbanken verarbeitet, die Millionen großer Objekte (gespeichert in pg_largeobject) enthalten, hängt von der Ziel-Hauptversion ab:
  • Ziel ist PostgreSQL 15 oder höher: Das Upgrade verwendet ein optimiertes Massenverfahren zur Übertragung von Metadaten großer Objekte, sodass die Speicher- und temporäre Datenträgernutzung nicht mehr mit der Anzahl der großen Objekte skaliert. Datenbanken mit zehn oder hundert Millionen großen Objekten werden ohne zusätzliche Vorbereitung zuverlässig aktualisiert. Es ist nicht erforderlich, vacuumlo auszuführen oder den Server vorher hochzuskalieren, um als Workaround für ein hohes Large-Object-Volumen zu dienen, obwohl Sie vacuumlo weiterhin ausführen können, um nicht verwendete Large Objects aus anderen Gründen zu entfernen.
  • Ziel PostgreSQL 14 oder früher: Datenbanken mit Millionen großer Objekte können Aufgrund einer hohen Speicherauslastung oder des Protokollvolumes zu Upgradefehlern führen. Verwenden Sie das Vakuumlo-Hilfsprogramm , um nicht verwendete große Objekte zu bereinigen, und erwägen Sie, den Server vor dem Upgrade zu skalieren, wenn viele große Objekte noch verwendet werden.

Nach dem Upgrade

Führen Sie nach Abschluss des Upgrades der Hauptversion den ANALYZE Befehl in jeder Datenbank aus, um die pg_statistic Tabelle zu aktualisieren. Fehlende oder veraltete Statistiken können zu schlechten Abfrageplänen führen, was wiederum die Leistung beeinträchtigt und übermäßigen Arbeitsspeicher beansprucht.

postgres=> analyze;
ANALYZE

Anzeigen von Upgradeprotokollen

Verwenden Sie PG_Upgrade_Logs, um den Upgradestatus zu überwachen und Probleme zu beheben. Überprüfen Sie die Protokolle während und nach dem Upgrade, um den Fortschritt nachzuverfolgen, Fehler oder Verzögerungen zu diagnostizieren und Blockierungsprobleme zu identifizieren, damit Sie schnell Korrekturmaßnahmen ergreifen können.

Aktivieren von Upgradeprotokollen mithilfe von Serverprotokollparametern

• Setzen Sie logfiles.download_enable auf EIN.
• Konfigurieren Sie die Aufbewahrung mit logfiles.retention_days.

Siehe auch PostgreSQL- und Upgrade-Protokolle herunterladen, um zu beginnen.

Verwandte Inhalte

• Upgrade der Hauptversion
• Upgradeüberprüfungen ausführen (Vorschau)