Upgrades van primaire versies in flexibele Azure Database for PostgreSQL-server

Uw Azure Database for PostgreSQL flexibele server ondersteunt PostgreSQL-versies 18, 17, 16, 15, 14, 13, 12, 11. De Postgres-community brengt een nieuwe primaire versie uit die ongeveer één keer per jaar nieuwe functies bevat. Daarnaast ontvangt elke primaire versie periodieke bugfixes in de vorm van secundaire releases. Secundaire versie-upgrades omvatten wijzigingen die compatibel zijn met bestaande toepassingen. Een Azure Database for PostgreSQL flexibele server werkt regelmatig de secundaire versies bij tijdens het onderhoudsvenster van een klant.

Upgrades van primaire versies zijn ingewikkelder dan upgrades van secundaire versies. Ze kunnen interne wijzigingen en nieuwe functies bevatten die niet achterwaarts compatibel zijn met bestaande toepassingen.

Uw Azure Database for PostgreSQL flexibele server heeft een functie die een in-place primaire versie-upgrade van de server uitvoert. Deze functie vereenvoudigt het upgradeproces door de onderbreking van gebruikers en toepassingen die toegang hebben tot de server te minimaliseren.

In-place upgrades behouden de servernaam en andere instellingen van de huidige server na de upgrade van een primaire versie. Ze vereisen geen gegevensmigratie of wijzigingen in de connectiestrings van de toepassing. In-place upgrades zijn sneller en hebben een kortere downtime dan gegevensmigratie.

Controles voor upgradevalidatie

Azure Database for PostgreSQL flexibele server biedt upgradevalidatiecontroles om de gereedheid van de upgrade te beoordelen voordat een primaire versie-upgrade wordt gestart.

Tijdens de upgradevalidatiecontroles wordt een reeks compatibiliteits- en configuratievalidaties uitgevoerd op de server om voorwaarden te identificeren die ertoe kunnen leiden dat de upgrade mislukt of onverwacht werkt. Veelvoorkomende controles zijn onder meer niet-ondersteunde extensies, logische replicatieslots, voorbereide transacties, gebeurtenistriggers, niet-ondersteunde objectafhankelijkheden en openstaande configuratiewijzigingen waarvoor opnieuw opstarten vereist is.

Het validatieproces is ontworpen om de gereedheid van de upgrade te evalueren zonder de daadwerkelijke upgradebewerking te starten. Dezelfde validatiecontroles worden ook automatisch uitgevoerd tijdens de werkstroom voor de upgrade van de primaire versie. Met deze controles wordt de serverversie niet gewijzigd, wordt downtime geactiveerd of wordt de server opnieuw opgestart. Voer validatiecontroles uit voordat u een tijdvenster voor een productie-upgrade plant.

U kunt upgradevalidatiecontroles uitvoeren in de Azure-portal of met de Azure CLI. Zie Validatiecontroles voor de upgrade uitvoeren voor instructies.

Nadat de validatie is voltooid, wordt een van de volgende resultaten geretourneerd:

• Er zijn geen blokkeringsproblemen gedetecteerd: de upgradevalidatiecontroles zijn voltooid en er zijn geen problemen geïdentificeerd die de upgrade blokkeren.
• Gedetecteerde blokkeringsproblemen: validatiecontroles voor upgrades hebben een of meer problemen geïdentificeerd die moeten worden opgelost voordat de upgrade kan worden voortgezet.

Afhankelijk van de resultaten kunt u doorgaan met de upgrade of de gerapporteerde problemen oplossen en validatie opnieuw uitvoeren.

Limitations

Houd rekening met de volgende beperkingen bij het gebruik van de controles voor upgradevalidatie:

• De serverstatus moet gereed zijn.
• Validatiecontroles worden niet ondersteund voor leesreplica's.
• Validatie kan niet worden uitgevoerd terwijl er al een andere serverbewerking wordt uitgevoerd.
• Validatiecontroles vereisen connectiviteit met alle databases op de server. Niet-reagerende of niet-toegankelijke databases kunnen validatiefouten veroorzaken.
• Hoewel validatiecontroles geen downtime veroorzaken, kunt u overwegen deze uit te voeren tijdens perioden met een lagere databaseactiviteit.

Zie de instructie Controles voor upgradevalidatie uitvoeren voor stapsgewijze instructies.

Upgradeproces

Hier volgen enkele belangrijke overwegingen voor in-place upgrades van primaire versies:

• Voordat u de upgrade start, moet u ervoor zorgen dat uw server ten minste 10-20% beschikbare opslagruimte heeft. Tijdens het upgradeproces kunnen tijdelijke logboekbestanden en metagegevensbewerkingen het schijfgebruik verhogen. Onvoldoende vrije ruimte kan leiden tot upgradefouten of terugdraaiproblemen.
• Tijdens een in-place-upgrade van een hoofdversie wordt op uw Azure Database for PostgreSQL Flexible Server vooraf een controle uitgevoerd om mogelijke problemen vast te stellen waardoor de upgrade mogelijk mislukt.
  • Als met de precheck compatibiliteitsproblemen worden gevonden, wordt er een logboekgebeurtenis gemaakt die laat zien dat de precheck voor de upgrade is mislukt, samen met een foutbericht.
  • Als de precheck is geslaagd, stopt de Azure Database for PostgreSQL flexibele server de service en wordt een impliciete back-up gemaakt vlak voordat de upgrade wordt gestart. De service kan deze impliciete back-up gebruiken om het database-exemplaar te herstellen naar de vorige versie als er een upgradefout optreedt.
• Een Azure Database for PostgreSQL flexibele server maakt gebruik van het hulpprogramma pg_upgrade voor het uitvoeren van in-place primaire versie-upgrades. De service biedt de flexibiliteit om versies over te slaan en rechtstreeks naar latere versies te upgraden.
• Tijdens een in-place upgrade naar een nieuwe hoofdversie van een server waarop hoge beschikbaarheid (HA) is ingeschakeld, schakelt de service HA uit, voert de upgrade uit op de primaire server en schakelt HA weer in nadat de upgrade is voltooid. Voor het opnieuw inschakelen van HA is voldoende capaciteit vereist om een nieuw standby-exemplaar op te zetten.
• De meeste extensies worden automatisch bijgewerkt naar latere versies tijdens een in-place primaire versie-upgrade, met enkele uitzonderingen.
• Bij het proces van een in-place-upgrade van een primaire versie voor een flexibele Azure Database for PostgreSQL-server wordt automatisch de nieuwste ondersteunde secundaire versie geïnstalleerd.
• De duur van de upgrade is afhankelijk van de grootte en complexiteit van uw database, inclusief het aantal objecten (tabellen, indexen, schema's), grote objecten en extensies. Grotere of complexere workloads kunnen langere upgradetijden ervaren.
• Langlopende transacties of een hoge workload voor de upgrade kunnen de benodigde tijd voor het afsluiten van de database en de upgradetijd verhogen.
• Nadat een in-place primaire versie-upgrade is voltooid, zijn er geen geautomatiseerde manieren om terug te keren naar de eerdere versie. U kunt een herstel naar een bepaald tijdstip (PITR) uitvoeren naar een moment vóór de upgrade om de vorige versie op een nieuwe server te herstellen.
• Beveilig uw Azure Database for PostgreSQL-server. Na een upgrade naar een nieuwe hoofdversie op een Azure Database for PostgreSQL Flexible Server heeft de eerste gebruiker die op de server is gemaakt en aan wie de optie ADMIN is verleend, nu administratieve bevoegdheden over andere rollen voor essentiële onderhoudsbewerkingen.

Overwegingen en beperkingen voor upgrades

Als een precheckbewerking mislukt tijdens een in-place primaire versie-upgrade, stopt het upgradeproces en wordt een gedetailleerd foutbericht weergegeven. De volgende bekende beperkingen kunnen ertoe leiden dat de upgrade mislukt of onverwacht werkt:

Niet-ondersteunde serverconfiguraties

• Geo-replicatie in Azure Database for PostgreSQL wordt niet ondersteund tijdens in-place upgrades. u moet de leesreplica (inclusief eventuele cascaderende leesreplica) verwijderen voordat u de primaire server bijwerkt. Na de upgrade kunt u de replica opnieuw maken.
• Netwerkverkeersregels kunnen upgradebewerkingen blokkeren.
  • Zorg ervoor dat uw flexibele server verkeer kan verzenden en ontvangen op poorten 5432 en 6432 binnen het virtuele netwerk en naar Azure Storage (voor logboekarchivering).
  • Als netwerkbeveiligingsgroepen (NSG's) dit verkeer beperken, wordt hoge beschikbaarheid (HA) niet automatisch opnieuw ingeschakeld na de upgrade. Mogelijk moet u NSG-regels handmatig bijwerken en HA opnieuw inschakelen.
• Weergaven die afhankelijk zijn van pg_stat_activity worden niet ondersteund tijdens upgrades van primaire versies.
• Als u een upgrade uitvoert van PostgreSQL 11 naar een hogere versie, moet u eerst uw flexibele server configureren voor het gebruik van SCRAM-verificatie door SCRAM in te schakelen en alle wachtwoorden voor verificatierollen opnieuw in te stellen.

Uitbreidingsbeperkingen

In-place primaire versie-upgrades bieden geen ondersteuning voor alle PostgreSQL-extensies. De upgrade mislukt tijdens de precheck als er een geblokkeerde extensie aanwezig is op een beïnvloed upgradepad. De meeste blokken zijn gericht op specifieke doelversies (en soms bronversies) in plaats van elke upgrade, zoals vermeld in de volgende lijsten.

• De volgende extensies blokkeren een in-place upgrade naar een hogere hoofdversie op alle upgradepaden. Verwijder ze vóór de upgrade en schakel ze opnieuw in nadat deze worden ondersteund op de doelversie: session_variable, anon, age.

• De volgende extensies zijn niet-permanente hulpprogramma-extensies en moeten worden verwijderd vóór de upgrade en opnieuw worden gemaakt na, standaard (alle upgradepaden): pg_repack, , hypopgpg_partman.

• De volgende extensies worden alleen geblokkeerd op specifieke versiepaden. Verwijder ze vóór de upgrade als uw upgrade overeenkomt met de vermelde voorwaarde en schakel ze opnieuw in nadat deze worden ondersteund op de doelversie:

  Extension	Geblokkeerd wanneer
  pg_hint_plan	De doelversie is PostgreSQL 14
  semver	De doelversie is PostgreSQL 16 of 17
  azure_local_ai	De doelversie is PostgreSQL 17 of 18
  pg_failover_slots	De doelversie is PostgreSQL 17 of 18 (gedeelde preload-bibliotheek)
  azure_ai	De doelversie is PostgreSQL 18
  azure_storage	De doelversie is PostgreSQL 18
  pg_diskann	De doelversie is PostgreSQL 18
  pgrouting	Doelversie is PostgreSQL 15; of bron ouder is dan PostgreSQL 16 en het doel is PostgreSQL 16 of hoger; of doelversie is PostgreSQL 18
  orafce	De bronversie is PostgreSQL 11, 12 of 13

• De volgende extensies worden geblokkeerd wanneer andere databaseobjecten afhankelijk zijn van hun objecten, omdat de upgrade anders mislukt. Los de afhankelijkheden vóór de upgrade op:

  • pg_stat_statements: geblokkeerd als andere objecten afhankelijk zijn van de view of functie ervan, waardoor ALTER EXTENSION pg_stat_statements UPDATE zou mislukken. Verwijder eerst de afhankelijke objecten.
  • pgcrypto: wanneer deze is geïnstalleerd in het pg_catalog schema en een upgrade uitvoert van PostgreSQL 11 of 12 naar PostgreSQL 13 of hoger, geblokkeerd wanneer klantobjecten hiervan afhankelijk zijn (een conflict met de ingebouwde gen_random_uuid() functie). Verplaats de extensie naar een ander schema of zet de afhankelijke objecten eerst neer.

PostGIS-specifieke overwegingen

Als u PostGIS of afhankelijke extensies gebruikt, configureert u de search_path parameter zodanig dat deze het volgende bevat:

• Schema's met betrekking tot PostGIS
• Afhankelijke extensies, waaronder: postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizeraddress_standardizer_data_usfuzzystrmatch
• Als u de search_path niet correct configureert, kan de upgrade mislukken of objecten beschadigen na de upgrade.

TimescaleDB-specifieke overwegingen

Als u TimescaleDB gebruikt, worden in-place primaire versie-upgrades alleen ondersteund voor specifieke combinaties van PostgreSQL-bron- en doelversies:

Als uw TimescaleDB-upgradepad niet in de ondersteunde matrix is opgenomen, wordt de in-place-upgrade naar een nieuwe hoofdversie geblokkeerd. Als u wilt doorgaan, kunt u de TimescaleDB-extensie verwijderen vóór de upgrade, indien mogelijk, of een alternatieve migratiebenadering gebruiken, zoals migratie naast elkaar met logische replicatie.

Zorg ervoor dat uw bron- en doelversies zijn opgenomen in de ondersteunde matrix voordat u de upgrade start.

Andere overwegingen bij de upgrade

• Gebeurtenistriggers: De pre-upgradecontrole blokkeert gebeurtenistriggers omdat die inhaken op DDL-opdrachten en mogelijk verwijzen naar systeemcatalogi die tussen hoofdversies veranderen. Verwijder alle EVENT TRIGGERs voordat u een upgrade uitvoert en maak ze vervolgens opnieuw na de upgrade om een soepele upgrade te garanderen.
• Grote objecten (LO's): De manier waarop een upgrade databases verwerkt die miljoenen grote objecten (opgeslagen in pg_largeobject) bevatten, is afhankelijk van de primaire doelversie:
  • Doel PostgreSQL 15 of hoger: de upgrade maakt gebruik van een geoptimaliseerde bulkmethode voor het overdragen van metagegevens van grote objecten, zodat geheugen- en tijdelijk schijfgebruik niet meer worden geschaald met het aantal grote objecten. Databases met tientallen of honderden miljoenen grote objecten worden betrouwbaar bijgewerkt zonder extra voorbereiding. Het vooraf uitvoeren vacuumlo of omhoog schalen van de server is niet vereist om een groot objectvolume te omzeilen, hoewel u nog steeds kunt uitvoeren vacuumlo om ongebruikte grote objecten te verwijderen om andere redenen.
  • Doel PostgreSQL 14 of eerder: Databases met miljoenen grote objecten kunnen upgradefouten veroorzaken vanwege een hoog geheugengebruik of logboekvolume. Gebruik het hulpprogramma vacuumlo om ongebruikte grote objecten op te schonen en overweeg uw server omhoog te schalen voordat de upgrade wordt uitgevoerd als er nog veel grote objecten in gebruik zijn.

Na upgrade

Nadat de upgrade van de primaire versie is voltooid, voert u de ANALYZE opdracht uit in elke database om de pg_statistic tabel te vernieuwen. Ontbrekende of verouderde statistieken kunnen leiden tot slechte queryplannen, wat op zijn beurt de prestaties kan verminderen en overmatig geheugen kan in beslag nemen.

postgres=> analyze;
ANALYZE

Upgrade-logboeken bekijken

Gebruik PG_Upgrade_Logs dit om de voortgang van de upgrade te controleren en problemen op te lossen. Bekijk de logboeken tijdens en na de upgrade om de voortgang bij te houden, fouten of vertragingen vast te stellen en blokkeringsproblemen te identificeren, zodat u snel corrigerende maatregelen kunt nemen.

Upgradelogboeken inschakelen met serverlogboekparameters

• Stel logfiles.download_enable in op AAN.
• Bewaarbeleid configureren met logfiles.retention_days.

Zie PostgreSQL downloaden en logboeken upgraden om aan de slag te gaan.

Verwante inhoud

• Upgrade naar een hoofdversie
• Upgradevalidatiecontroles uitvoeren