Hauptversionsupgrades in Azure Database für PostgreSQL Flexible Server

2025-06-19

GILT FÜR: Azure Database for PostgreSQL – Flexibler Server

Azure Database for PostgreSQL – Flexibler Server unterstützt PostgreSQL-Versionen 17 (Preview) und 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. Azure Database for PostgreSQL – Flexible Server aktualisiert regelmäßig die Nebenversionen während eines Wartungsfensters des Kunden.

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

Azure Database for PostgreSQL – Flexible Server hat ein Feature, das direkte Hauptversionsupgrades mit nur einem Klick direkt auf den Server durchführt. 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.

Upgradeprozess

Im Anschluss folgen einige wichtige Überlegungen im Zusammenhang mit direkten Hauptversionsupgrades:

Sorgen Sie dafür, dass Ihr Server vor dem Start des Upgrades mindestens über 10 bis 20% freien Speicherplatz verfügt. 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 Hauptversionsupgrades führt der Azure Database for PostgreSQL – Flexible Server eine Vorabüberprüfung durch, um potenzielle Probleme zu identifizieren, die unter Umständen dazu führen können, dass das Upgrade nicht erfolgreich ist.
- 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.
- Ist die Vorabüberprüfung erfolgreich, beendet der Azure Database for PostgreSQL – Flexible Server den Dienst und erstellt vor Beginn des Upgrades eine implizite Sicherung. Der Dienst kann diese Sicherung verwenden, um die Datenbankinstanz in der vorherigen Version wiederherzustellen, falls ein Upgradefehler auftritt.
Azure Database for PostgreSQL – Flexible Server verwendet das pg_upgrade-Tool, um direkte Upgrades von Hauptversionen durchzuführen. Der Dienst bietet die Flexibilität, Versionen zu überspringen und direkt auf spätere Versionen zu aktualisieren.
Bei einem vor Ort durchgeführten Hauptversionsupgrade eines Servers mit Hochverfügbarkeit deaktiviert der Dienst die Hochverfügbarkeit, führt das Upgrade auf dem Hauptserver durch und aktiviert die Hochverfügbarkeit nach Abschluss des Upgrades wieder.
Die meisten Erweiterungen werden während eines direkten Hauptversionsupgrades automatisch auf spätere Versionen aktualisiert. Es gibt allerdings einige Ausnahmen.
Bei dem Prozess eines direkten Hauptversionsupgrades für Azure Database for PostgreSQL – Flexible Server wird automatisch die neueste unterstützte Nebenversion bereitgestellt.
Ein unmittelbares Upgrade auf eine neue Hauptversion ist ein Vorgang, der offline abläuft, was bedeutet, dass der Server während des Prozesses nicht verfügbar ist. Während die meisten Upgrades in weniger als 15 Minuten abgeschlossen sind, hängt die tatsächliche Dauer von der Größe und Komplexität der Datenbank ab. Insbesondere ist die erforderliche Zeit direkt proportional zur Anzahl der Objekte (Tabellen, Indizes, Schemas) in Ihrer PostgreSQL-Instanz. Größere oder komplexere Schemas 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 allerdings eine Zeitpunktwiederherstellung (Point-In-Time Recovery, PITR) auf einen Zustand vor dem Upgrade durchführen, um die vorherige Version der Datenbankinstanz wiederherzustellen.
Azure Database for PostgreSQL Flexible Server erstellt während eines Upgrades Momentaufnahmen Ihrer Datenbank. Die Momentaufnahme wird vor dem Start des Upgrades erstellt. Wenn das Upgrade fehlschlägt, stellt das System die Datenbank automatisch wieder in den Zustand aus der Momentaufnahme zurück.
PostgreSQL 16 führt rollenbasierte Sicherheitsmaßnahmen ein. Nach einem Upgrade der Hauptversion auf dem flexiblen Server von Azure Database for PostgreSQL erhält der erste Benutzer, der auf dem Server erstellt wird und dem die ADMIN-Option zugewiesen wird, nun Administratorrechte über andere Rollen für wesentliche Wartungsvorgänge.

Überlegungen und Einschränkungen für Upgrades

Wenn ein Vorabcheckvorgang während eines direkten Hauptversionsupgrades fehlschlägt, wird das Upgrade mit einer detaillierten Fehlermeldung blockiert. Nachfolgend sind die bekannten Einschränkungen aufgeführt, die dazu führen können, dass das Upgrade fehlschlägt oder sich unerwartet verhält:

Nicht unterstützte Serverkonfigurationen

Lesereplikate werden bei direkten Upgrades nicht unterstützt. Sie müssen das Lesereplikat löschen, bevor Sie den primären Server aktualisieren. Nach dem Upgrade können Sie das Replikat wieder erstellen.
Netzwerkdatenverkehrsregeln können Upgradevorgänge blockieren.
- Stellen Sie sicher, dass Ihr flexibler Server Datenverkehr auf den Ports 5432 und 6432 innerhalb seines virtuellen Netzwerks senden und empfangen kann und an Azure Storage (für die Protokollarchivierung).
- Wenn Netzwerksicherheitsgruppen (NSG) diesen Datenverkehr einschränken, wird die Hochverfügbarkeit nach dem Upgrade nicht automatisch wieder aktiviert. Möglicherweise müssen Sie NSG-Regeln manuell aktualisieren und HA erneut aktivieren.
Logische Replikationsslots werden bei direkten Hauptversionsupgrades nicht unterstützt.
Server, die SSDv2-Speicher verwenden, sind für Upgrades der Hauptversion nicht berechtigt.
Ansichten, die von pg_stat_activity abhängig sind, werden während der Hauptversionsupgrades nicht unterstützt.

Erweiterungseinschränkungen

Interne Hauptversionsupgrades unterstützen nicht alle PostgreSQL-Erweiterungen. Das Upgrade schlägt während der Vorabüberprüfung fehl, wenn nicht unterstützte Erweiterungen gefunden werden.

Die folgenden Erweiterungen werden in keiner PostgreSQL-Version unterstützt: timescaledb, , dblink, orafce, pg_partmanpostgres_fdw
Die folgenden Erweiterungen werden nicht unterstützt, wenn das Upgradeziel PostgreSQL 16 oder höher ist: pgrouting
Die folgenden Erweiterungen werden beim Upgrade auf PostgreSQL 17 nicht unterstützt: pgrouting, , age, azure_ai, hllpg_diskann
Erweiterungen wie pg_repack, und hypopg unterstützen keine direkten Upgrades und sollten vor dem Upgrade verworfen und nach dem Upgrade neu erstellt werden. Diese Erweiterungen sind nicht persistent und können nach dem Upgrade sicher neu konfiguriert werden.

Diese Erweiterungen müssen vor dem Upgrade aus dem Serverparameter "azure.extensions " entfernt werden. Falls vorhanden, wird das Upgrade blockiert.

PostGIS-spezifische Aspekte

Wenn Sie PostGIS oder abhängige Erweiterungen verwenden, müssen Sie den search_path Serverparameter so konfigurieren, dass folgendes enthalten ist:

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
Fehler beim Konfigurieren der search_path können zu Upgradefehlern oder fehlerhaften Objekten nach dem Upgrade führen.

Weitere Überlegungen zum Upgrade

Große Objekte (LOs): Datenbanken mit Millionen großer Objekte (gespeichert in pg_largeobject) können Zu Upgradefehlern aufgrund einer hohen Speicherauslastung oder des Protokollvolumes führen. Verwenden Sie vakuumlo Utility, um nicht verwendete LOs zu bereinigen, und erwägen Sie die Skalierung Ihres Servers vor dem Upgrade, wenn viele LOs noch verwendet werden.

Warnung

Gehen Sie bei „vacuumlo“ vorsichtig vor. vacuumlo identifiziert verwaiste große Objekte basierend auf herkömmlichen Bezugsspalten (oid, lo). Wenn Ihre Anwendung benutzerdefinierte oder indirekte Verweistypen verwendet, werden gültige große Objekte möglicherweise versehentlich gelöscht. vacuumlo Darüber hinaus können erhebliche CPU, Arbeitsspeicher und IOPS verbrauchen, insbesondere in Datenbanken mit Millionen großer Objekte. Führen Sie es während Wartungszeiten aus, und testen Sie es zuerst in einer Nicht-Produktionsumgebung.

Nach dem Upgrade

Nach Abschluss des Upgrades der Hauptversion wird empfohlen, den Befehl ANALYZE in jeder Datenbank auszuführen, um die Tabelle pg_statistic 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

Hauptversionsupgrade-Protokolle (PG_Upgrade_Logs) bieten direkten Zugriff auf detaillierte Serverprotokolle. Die Integration PG_Upgrade_Logs in Ihren Upgradeprozess kann dazu beitragen, einen reibungsloseren und transparenteren Übergang zu neuen PostgreSQL-Versionen zu gewährleisten.

Sie können die Upgradeprotokolle der Hauptversion auf die gleiche Weise wie Serverprotokolle unter Verwendung der folgenden Serverparameter konfigurieren:

Um das Feature zu aktivieren, legen Sie die Einstellung logfiles.download_enable auf ON fest.
Verwenden Sie logfiles.retention_days, um die Aufbewahrung von Protokolldateien in Tagen zu definieren.

Setupupgradeprotokolle

Um mit der Verwendung von PG_Upgrade_Logs zu beginnen, können Sie die Erfassung von PostgreSQL-Serverprotokollen und Aktualisierungsprotokollen der Hauptversion konfigurieren.

Sie können über die Benutzeroberfläche für Serverprotokolle auf die Upgradeprotokolle zugreifen. Dort können Sie den Fortschritt und die Details Ihrer PostgreSQL-Hauptversionsupgrades in Echtzeit überwachen. Diese Benutzeroberfläche bietet einen zentralen Ort zum Anzeigen von Protokollen, sodass Sie den Upgradeprozess einfacher nachverfolgen und Fehler beheben können.

Vorteile der Verwendung von Aktualisierungsprotokollen

Aussagekräftige Diagnosen: PG_Upgrade_Logs bietet wertvolle Erkenntnisse in den Upgradeprozess. Es erfasst detaillierte Informationen zu den ausgeführten Vorgängen und hebt alle aufgetretenen Fehler oder Warnungen hervor. Diese Detailgenauigkeit ist für die Diagnose und Lösung von Problemen, die während des Upgrades auftreten können, von entscheidender Bedeutung und gewährleistet einen reibungslosen Übergang.
Optimierte Problembehandlung: Durch den direkten Zugriff auf diese Protokolle können Sie potenzielle Upgradehindernisse schnell erkennen und beheben, wodurch Downtime reduziert und die Auswirkungen auf Ihren Betrieb minimiert werden. Die Protokolle sind ein wichtiges Tool bei der Fehlersuche und ermöglichen eine effizientere und effektivere Problemlösung.

Hinweis

Direkte Hauptversionsupgrades werden auf automatisch migrierten Servernunterstützt. Nach einem erfolgreichen direkten Hauptversionsupgrade auf einem automatisch migrierten Server wird das Benutzernamenformat username@servername nicht mehr unterstützt. Stattdessen müssen Sie das Standardformat verwenden: Benutzername. Um Authentifizierungsprobleme zu vermeiden, überprüfen und aktualisieren Sie alle Verbindungszeichenfolgen in Ihren Anwendungen und Skripts sorgfältig, um sicherzustellen, dass sie nach dem Upgrade das aktualisierte Benutzernamenformat verwenden.

Freigeben über