Hauptversionsupgrades in Azure Database for PostgreSQL – Flexible Server

  • Artikel

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

Azure Database for PostgreSQL Flexible Server unterstützt die PostgreSQL-Versionen 16, 15, 14, 13, 12 und 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.

Prozess

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

  • 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 direkten Hauptversionsupgrade eines Servers mit Hochverfügbarkeit deaktiviert der Dienst die Hochverfügbarkeit, führt das Upgrade auf dem primären Server 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 direktes Hauptversionsupgrade ist ein Offline-Vorgang, der zu einer kurzen Ausfallzeit führt. Die Ausfallzeiten sind in der Regel weniger als 15 Minuten. Die Dauer kann je nach Anzahl der beteiligten Systemtabellen variieren.

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

Hauptversionsupgrade-Protokolle

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.

Setup von Upgradeprotokollen

Um mit der Verwendung von PG_Upgrade_Logs zu beginnen, können Sie die Protokolle entweder über das Azure-Portal oder die Azure CLI konfigurieren. Wählen Sie die Methode aus, die am besten zu Ihrem Workflow passt.

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 Upgradeprotokollen

  • Einblicke in die Diagnose: PG_Upgrade_Logs bietet wertvolle Einblicke 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.

Begrenzungen

Wenn die Vorprüfung für ein direktes Hauptversionsupgrade fehlschlägt, schlägt das Upgrade mit einer detaillierten Fehlermeldung mit allen folgenden Einschränkungen fehl:

  • Direkte Hauptversionsupgrades unterstützen derzeit keine Lesereplikate. Wenn Sie über einen Server verfügen, der als Lesereplikat fungiert, müssen Sie das Replikat löschen, bevor Sie das Upgrade auf dem primären Server ausführen. Nach dem Upgrade können Sie das Replikat wieder erstellen.

  • Azure Database for PostgreSQL – Flexible Server erfordert die Möglichkeit, Datenverkehr an Zielports 5432 und 6432 innerhalb des virtuellen Netzwerks zu senden und zu empfangen, in dem der flexible Server bereitgestellt wird, und an Azure Storage für die Protokollarchivierung geht.

    Wenn Sie Netzwerksicherheitsgruppen (Network Security Groups, NSGs) so konfigurieren, dass der Datenverkehr zu oder vom flexiblen Server innerhalb des bereitgestellten Subnetzes eingeschränkt wird, müssen Sie sicherstellen, dass die datenverkehrsbezogenen Ports 5432 und 6432 innerhalb des Subnetzes zulässig sind. Zulassen von Datenverkehr zu Azure Storage mithilfe des Diensttags Azure Storage als Ziel.

    Wenn Netzwerkregeln nicht ordnungsgemäß eingerichtet sind, wird HA nach einem Upgrade der Hauptversion nicht automatisch aktiviert und Sie sollten HA manuell aktivieren. Ändern Sie Ihre NSG-Regeln, um Datenverkehr für die Zielports und den Speicher zuzulassen und ein HA-Feature auf dem Server zu aktivieren.

  • Von direkten Hauptversionsupgrades werden bestimmte Erweiterungen nicht unterstützt, und es gibt einige Einschränkungen für das Upgraden bestimmter Erweiterungen. Die folgenden Erweiterungen werden für alle PostgreSQL-Versionen nicht unterstützt: Timescaledb, pgaudit, dblink, orafce, pg_partman, postgres_fdw.

  • Wenn Sie Server mit der installierten PostGIS-Erweiterung aktualisieren, legen Sie den search_path-Serverparameter explizit auf Folgendes fest:

    • Schemas der PostGIS-Erweiterung.
    • Erweiterungen, die von PostGIS abhängen.
    • Erweiterungen, die als Abhängigkeiten für die folgenden Erweiterungen dienen: postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_us, fuzzystrmatch (erforderlich für postgis_tiger_geocoder).

  • Mit logischen Replikationsslots konfigurierte Server werden nicht unterstützt.

Nächste Schritte