Freigeben über

Hauptversionsupgrades in Azure-Datenbank für PostgreSQL

Ihre flexible Azure-Datenbankserverinstanz für PostgreSQL unterstützt die 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 Instanz von Azure Database for PostgreSQL – Flexible Server aktualisiert regelmäßig die Nebenversionen während eines Wartungsfensters der Kundschaft.

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 Instanz von Azure Database for PostgreSQL – Flexible Server verfügt über ein Feature, das direkte Hauptversionsupgrades des Servers mit nur einem Klick 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.

Hinweis

Azure Database for PostgreSQL unterstützt direkte Hauptversionsupgrades nur auf derzeit unterstützte PostgreSQL-Versionen. Sie können beispielsweise die aktuelle Version aktualisieren, wenn die Zielversion zum Zeitpunkt des Upgrades offiziell von Azure unterstützt wird. Nicht unterstützte Versionen können nicht als Upgradeziele ausgewählt werden, und der Versuch, auf eine veraltete Version zu aktualisieren, kann zu Fehlern oder Dienstunterbrechungen führen. Lesen Sie immer die Azure PostgreSQL-Versionsverwaltungsrichtlinie und aktualisieren Sie die Dokumentation , bevor Sie ein Upgrade der Hauptversion initiieren.

Hinweis

Hauptversionsupgrades auf PostgreSQL 18 werden in Phasen aktiviert. Zu diesem Zeitpunkt ist MVU to PostgreSQL 18 in den Regionen AustraliaSoutheast, CanadaCentral, CentralIndia, CentralUS, EastAsia, EastUS, EastUS, EastUS2, NorthCentralUS, SouthAfricaNorth, SouthCentralUS, SwedenCentral, WestCentralUS, WestUS2 und WestUS3 verfügbar.

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 des Prozesses eines Vor-Ort-Hauptversionsupgrades führt Ihre flexible Azure-Datenbank-Serverinstanz für PostgreSQL ein Prüfverfahren durch, 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, stoppt die Flexible Serverinstanz der Azure-Datenbank für PostgreSQL den Dienst und übernimmt eine implizite Sicherung direkt vor dem Starten des Upgrades. Der Dienst kann diese Sicherung verwenden, um die Datenbankinstanz in der vorherigen Version wiederherzustellen, falls ein Upgradefehler auftritt.
  • Eine flexible Serverinstanz von Azure Database für PostgreSQL verwendet das Tool pg_upgrade, um größere Versionsupgrades direkt 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.
  • Der Prozess eines im laufenden Betrieb durchgeführten Hauptversionsupgrades für eine flexible Server-Instanz der Azure-Datenbank für PostgreSQL stellt automatisch die neueste unterstützte Unterversion bereit.
  • 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.
  • Ihre Azure-Datenbank-Instanz vom Typ Flexible Server für PostgreSQL erstellt während eines Upgrades eine Momentaufnahme 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 Hauptversions-Upgrade einer flexiblen Serverinstanz von Azure Database für PostgreSQL verfügt der erste auf dem Server erstellte Benutzer, dem die ADMIN-Option gewährt wurde, nun über Administratorrechte für andere Rollen, um wichtige Wartungsarbeiten durchzuführen.

Ü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 (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 können Upgradevorgänge blockieren.
    • 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 (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.
  • Wenn Sie das Upgrade von PG11 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 Anmelderollen-Kennwörter zurücksetzen.

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 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 danach erneut, wenn sie in der Zielversion unterstützt werden: timescaledb, dblink, orafce, postgres_fdw.
  • 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 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, , hll, pg_diskann. pgrouting

Anmerkung: Wenn eine dieser Erweiterungen im azure.extensions Serverparameter angezeigt wird, wird das Upgrade blockiert. Entfernen Sie sie aus dem Parameter, bevor Sie das Upgrade starten.

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

  • Ereignistrigger: Upgrade pre-check blockiert Ereignistrigger, da sie in DDL-Befehle eingebunden sind und auf Systemkataloge verweisen können, die sich zwischen Hauptversionen ändern – legen Sie alle EVENT TRIGGERvor dem Upgrade ab, und erstellen Sie sie dann nach dem Upgrade neu, 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.

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.

Zugehöriger Inhalt

  • Last updated on