Hauptversions-Upgrades in Azure Database für PostgreSQL

Ihre Azure Database for PostgreSQL flexible Serverinstanz 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. Eine Azure Database for PostgreSQL flexible Serverinstanz aktualisiert die Nebenversionen während des Wartungsfensters eines Kunden regelmäßig.

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

Ihre Azure Database for PostgreSQL – Flexibler Server-Instanz verfügt über eine Funktion, die ein In-Place-Upgrade des Servers auf eine höhere Hauptversion 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.

Validierungsprü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. Es wird dringend empfohlen, Überprüfungen vor der Planung eines Produktionsupgradefensters auszuführen.

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

• Es wurden keine Blockierungsprobleme erkannt: Upgradeüberprüfungen wurden erfolgreich abgeschlossen und identifizierten keine Probleme, die das Upgrade blockieren würden.
• 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

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

• 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 des Prozesses eines direkten Hauptversionsupgrades führt Ihre Azure Database for PostgreSQL flexible Serverinstanz eine Vorabprüfung aus, um potenzielle Probleme zu identifizieren, die dazu führen können, dass das Upgrade fehlschlägt.
  • 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 die Azure Database for PostgreSQL flexible Serverinstanz 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.
• Eine flexible Azure Database for PostgreSQL-Serverinstanz verwendet das Tool pg_upgrade, um direkte Upgrades von 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.
• Durch das direkte Upgrade einer Hauptversion für eine flexible Azure Database for PostgreSQL-Serverinstanz wird automatisch die neueste unterstützte Nebenversion bereitgestellt.
• 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.
• Ihre Azure Database for PostgreSQL flexible Serverinstanz übernimmt während eines Upgrades eine implizite Sicherung Ihrer Datenbank. Die implizite Sicherung wird ausgeführt, bevor das Upgrade gestartet wird. Wenn das Upgrade fehlschlägt, stellt das System Die Datenbank automatisch aus der impliziten Sicherung wieder in den Zustand zurück.
• Maßnahmen zum Schutz Ihres Azure Database for PostgreSQL Server. Nach einem Upgrade auf eine neue Hauptversion bei einer Azure Database for PostgreSQL Flexible Server-Instanz verfügt der erste auf dem Server erstellte Benutzer, dem die Option ADMIN gewährt wird, nun über Administratorrechte 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, wird das Upgrade mit einer detaillierten Fehlermeldung blockiert. Im Folgenden 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

• Georeplikation in Azure Database for PostgreSQL wird während direkter 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 Ihre flexible Serverinstanz Datenverkehr an den Ports 5432 und 6432 innerhalb des virtuellen Netzwerks und an Azure Storage (für die Protokollarchivierung) senden/empfangen kann.
  • Wenn Netzwerksicherheitsgruppen (Network Security Groups, NSGs) diesen Datenverkehr einschränken, wird HA nach dem Upgrade nicht automatisch wieder aktiviert. Möglicherweise müssen Sie NSG-Regeln manuell aktualisieren und HA erneut aktivieren.
• Die Slots für die logische Replikation müssen vor einem In-Place Upgrade der Hauptversion gedroppt werden. Sie können sie nach Abschluss des Upgrades neu erstellen.
• Ansichten, die von pg_stat_activity abhängen, werden bei Upgrades auf eine Hauptversion nicht unterstützt.
• Wenn Sie das Upgrade von PostgreSQL 11 auf eine höhere Version durchführen, müssen Sie zuerst Ihren flexiblen Server für die Verwendung der SCRAM-Authentifizierung konfigurieren, indem Sie SCRAM aktivieren und alle Anmelderollen-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 nicht unterstützte Erweiterungen gefunden werden.

• Die folgenden Erweiterungen werden für die normale Verwendung unterstützt, blockieren jedoch ein direktes Upgrade der Hauptversion, falls vorhanden. Entfernen Sie sie vor dem Upgrade, und aktivieren Sie sie erneut, wenn sie in der Zielversion unterstützt werden: timescaledb, , , postgres_fdw, session_variable, pg_hint_plan. plv8
• Die folgenden Erweiterungen sind nicht persistente Hilfsprogrammerweiterungen und müssen nach dem Upgrade nach dem Entwurf gelöscht und neu erstellt werden: pg_repack, hypopg.
• Beim Upgrade auf PostgreSQL 17 oder höher werden die folgenden Erweiterungen nicht unterstützt und müssen vor dem Upgrade entfernt werden. Sie können sie nur dann erneut aktivieren, wenn sie in der Zielversion unterstützt werden: age, , , azure_ai, . hllpg_diskannpgrouting

PostGIS-spezifische Überlegungen

Wenn Sie PostGIS oder abhängige Erweiterungen verwenden, müssen Sie den search_path Parameter 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

• 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): 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.

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.

Aktivieren von Upgradeprotokollen mithilfe von Serverprotokollparametern

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

Lesen Sie PostgreSQL und Upgrade-Protokolle herunterladen, um zu beginnen.

Auf PG_Upgrade_Logs über die UI für Serverprotokolle zugreifen

• Überprüfen Sie PG_Upgrade_Logs während und nach dem Upgrade, um den Fortschritt zu überwachen und Fehler oder Verzögerungen zu diagnostizieren.
• Überprüfen Sie auf Fehler oder Warnungen, wenn das Upgrade fehlschlägt oder länger als erwartet dauert.
• Verwenden Sie Protokolle, um Blockierungsprobleme zu identifizieren und schnell Korrekturmaßnahmen zu ergreifen.

Vorteile der Verwendung von Aktualisierungsprotokollen

• Schnelles Diagnostizieren von Problemen: Verwenden Sie diese PG_Upgrade_Logs , um jeden Schritt des Upgrades zu überprüfen und Fehler oder Warnungen zu identifizieren.
• Probleme effizient beheben: Analysieren Sie Protokolle, um Fehler zu identifizieren, Ausfallzeiten zu reduzieren und schneller Korrekturmaßnahmen zu ergreifen.

PG_Upgrade_Logs hilft Ihnen zu verstehen, was während des Upgrades passiert ist, und Probleme mit Vertrauen zu beheben.

Verwandte Inhalte

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