Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexible Server
Azure Database for PostgreSQL flexibele server ondersteunt PostgreSQL-versies 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. Azure Database voor PostgreSQL flexibele server werkt de kleine versies regelmatig 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 mogelijk niet achterwaarts compatibel zijn met bestaande toepassingen.
Azure Database for PostgreSQL flexibele server heeft een functie die met slechts één klik 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.
Upgradeproces
Hier volgen enkele belangrijke overwegingen bij in-place grote versie-upgrades:
- Voordat u de upgrade start, moet u ervoor zorgen dat uw server ten minste 10 tot 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 het proces van een in-place grote versie-upgrade voert Azure Database for PostgreSQL flexible server een voorlopige procedure uit om potentiële problemen te identificeren die ervoor kunnen zorgen dat de upgrade 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 Azure Database for PostgreSQL Flexible Server de service en maakt een impliciete back-up vlak voordat de upgrade start. De service kan deze back-up gebruiken om het database-exemplaar te herstellen naar de vorige versie als er een upgradefout optreedt.
- Azure Database for PostgreSQL flexible server maakt gebruik van het hulpprogramma pg_upgrade voor het uitvoeren van in-place grotere versie-upgrades. De service biedt de flexibiliteit om versies over te slaan en rechtstreeks naar latere versies te upgraden.
- Tijdens een in-place primaire versie-upgrade van een server die is ingeschakeld voor hoge beschikbaarheid (HA), schakelt de service hoge beschikbaarheid uit, voert de upgrade uit op de primaire server en schakelt de hoge beschikbaarheid vervolgens opnieuw in nadat de upgrade is voltooid.
- De meeste extensies worden automatisch bijgewerkt naar latere versies tijdens een in-place primaire versie-upgrade, met enkele uitzonderingen.
- Tijdens het proces van een in-place primaire versie-upgrade voor een flexibele Azure Database for PostgreSQL-server wordt automatisch de meest recente ondersteunde secundaire versie geïmplementeerd.
- Een in-place primaire versie-upgrade is een offlinebewerking, wat betekent dat de server tijdens het proces niet beschikbaar is. Hoewel de meeste upgrades in minder dan 15 minuten zijn voltooid, is de werkelijke duur afhankelijk van de grootte en complexiteit van de database. De benodigde tijd is met name rechtstreeks evenredig met het aantal objecten (tabellen, indexen, schema's) in uw PostgreSQL-exemplaar. Grotere of complexere schema's 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 echter een herstel naar een bepaald tijdstip (PITR) uitvoeren voordat de upgrade de vorige versie van het database-exemplaar herstelt.
- Een flexibele Azure Database for PostgreSQL-server maakt een momentopname van uw database tijdens een upgrade. De momentopname wordt gemaakt voordat de upgrade wordt gestart. Als de upgrade mislukt, herstelt het systeem uw database automatisch naar de status van de momentopname.
- PostgreSQL 16 introduceert op rollen gebaseerde beveiligingsmaatregelen . Na een belangrijke versie-upgrade op een Azure Database for PostgreSQL-flexibele server zal de eerste gebruiker die op de server is aangemaakt—en de ADMIN-optie krijgt—nu beheerdersbevoegdheden hebben over andere rollen voor essentiële onderhoudsbewerkingen.
Overwegingen en beperkingen voor upgrades
Als een voorafgaande controle mislukt tijdens een in-place grote versie-upgrade, wordt de upgrade geblokkeerd met een gedetailleerde foutmelding. Hieronder vindt u de bekende beperkingen die ertoe kunnen leiden dat de upgrade mislukt of onverwacht werkt:
Niet-ondersteunde serverconfiguraties
- Leesreplica's worden niet ondersteund tijdens in-place upgrades. U moet de leesreplica verwijderen voordat u de primaire server upgrade. Na de upgrade kunt u de replica opnieuw maken.
- Regels voor netwerkverkeer kunnen upgradebewerkingen blokkeren.
- Zorg ervoor dat uw flexibele server verkeer kan verzenden/ontvangen op poorten 5432 en 6432 binnen het virtuele netwerk en naar Azure Storage (voor logboekarchivering).
- Als netwerkbeveiligingsgroepen (NSG's) dit verkeer beperken, wordt ha niet automatisch opnieuw ingeschakeld na de upgrade. Mogelijk moet u NSG-regels handmatig bijwerken en HA opnieuw inschakelen.
- Logische replicatiesleuven worden niet ondersteund tijdens in-place upgrades van grote versies.
- Servers die SSDv2-opslag gebruiken, komen niet in aanmerking voor primaire versie-upgrades.
- Weergaven die afhankelijk zijn van
pg_stat_activity
worden niet ondersteund tijdens upgrades naar major versies.
Uitbreidingsbeperkingen
In-place primaire versie-upgrades bieden geen ondersteuning voor alle PostgreSQL-extensies. De upgrade mislukt tijdens de precheck als er niet-ondersteunde extensies worden gevonden.
- De volgende extensies worden niet ondersteund in alle PostgreSQL-versies:
timescaledb
,dblink
,orafce
, ,pg_partman
postgres_fdw
- De volgende extensies worden niet ondersteund wanneer het upgradedoel PostgreSQL 16 of hoger is:
pgrouting
- De volgende extensies worden niet ondersteund bij het upgraden naar PostgreSQL 17:
pgrouting
,age
,azure_ai
,hll
pg_diskann
- Extensies zoals
pg_repack
, enhypopg
bieden geen ondersteuning voor in-place upgrades en moeten worden verwijderd vóór de upgrade en opnieuw worden gemaakt na. Deze extensies zijn niet-persistent en veilig om na de upgrade opnieuw te configureren.
Deze extensies moeten worden verwijderd uit de serverparameter azure.extensions voordat u een upgrade uitvoert. Indien aanwezig, wordt de upgrade geblokkeerd.
Overwegingen PostGIS-Specific
Als u PostGIS of afhankelijke extensies gebruikt, moet u de search_path-serverparameter configureren om het volgende op te nemen:
- Schema's met betrekking tot PostGIS
- Afhankelijke extensies, waaronder:
postgis
,postgis_raster
,postgis_sfcgal
,postgis_tiger_geocoder
,postgis_topology
,address_standardizer
address_standardizer_data_us
fuzzystrmatch
- Als u de search_path niet correct configureert, kan dit leiden tot upgradefouten of beschadigde objecten na de upgrade.
Andere overwegingen bij de upgrade
- Gebeurtenistriggers: De voorcontrole van de upgrade blokkeert gebeurtenistriggers omdat ze worden gekoppeld aan DDL-opdrachten en mogelijk verwijzen naar systeemcatalogi die verschillen tussen hoofdreleases. Verwijder alle
EVENT TRIGGER
s voordat u een upgrade uitvoert en maak ze vervolgens opnieuw na de upgrade voor een probleemloze upgrade. - Grote objecten (LO's): databases met miljoenen grote objecten (opgeslagen in
pg_largeobject
) kunnen upgradefouten veroorzaken vanwege een hoog geheugengebruik of logboekvolume. Gebruik het hulpprogramma vacuumlo om ongebruikte LO's op te schonen en overweeg om uw server omhoog te schalen voordat u een upgrade uitvoert als er nog veel LO's in gebruik zijn.
Waarschuwing
Wees voorzichtig met de stofzuiger.
vacuumlo
identificeert zwevende grote objecten op basis van conventionele referentiekolommen (oid, lo). Als uw toepassing aangepaste of indirecte verwijzingstypen gebruikt, kunnen geldige grote objecten per ongeluk worden verwijderd. Bovendien vacuumlo
kan dit aanzienlijke CPU, geheugen en IOPS verbruiken, met name in databases met miljoenen grote objecten. Voer deze uit tijdens onderhoudsperiodes en test eerst in een niet-productieomgeving.
Na upgrade
Nadat de upgrade van de primaire versie is voltooid, raden we u aan de ANALYZE
opdracht in elke database uit te voeren 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
Upgradelogboeken voor primaire versies (PG_Upgrade_Logs
) bieden directe toegang tot gedetailleerde serverlogboeken.
PG_Upgrade_Logs
Integratie in uw upgradeproces kan helpen bij een soepelere en transparantere overgang naar nieuwe PostgreSQL-versies.
U kunt uw primaire versie-upgradelogboeken op dezelfde manier configureren als serverlogboeken, met behulp van de volgende serverparameters:
- Als u de functie wilt inschakelen, stelt u in
logfiles.download_enable
opON
. - Als u de retentie van logboekbestanden in dagen wilt definiëren, gebruikt u
logfiles.retention_days
.
Upgradelogboeken instellen
Als u wilt beginnen met PG_Upgrade_Logs
, kunt u de vastlegging van PostgreSQL-serverlogboeken en logboeken voor de upgrade van de hoofdversie configureren.
U kunt de upgradelogboeken openen via de gebruikersinterface voor serverlogboeken. Daar kunt u de voortgang en details van uw primaire postgreSQL-versie-upgrades in realtime bewaken. Deze gebruikersinterface biedt een centrale locatie voor het weergeven van logboeken, zodat u het upgradeproces gemakkelijker kunt bijhouden en problemen kunt oplossen.
Voordelen van het gebruik van upgradelogboeken
-
Inzichtelijke diagnostische gegevens:
PG_Upgrade_Logs
biedt waardevolle inzichten in het upgradeproces. Het legt gedetailleerde informatie vast over de uitgevoerde bewerkingen en markeert eventuele fouten of waarschuwingen die optreden. Dit detailniveau is van groot belang bij het diagnosticeren en oplossen van problemen die zich kunnen voordoen tijdens de upgrade, voor een soepelere overgang. - Gestroomlijnde probleemoplossing: Met directe toegang tot deze logboeken kunt u snel potentiële upgradeproblemen identificeren en aanpakken, downtime verminderen en de impact op uw bewerkingen minimaliseren. De logboeken fungeren als een cruciaal hulpprogramma voor probleemoplossing door efficiëntere en effectievere probleemoplossing mogelijk te maken.
Opmerking
Hoofdversie-upgrades op locatie worden ondersteund op automatisch gemigreerde servers. Na een geslaagde in-place primaire versie-upgrade op een automatisch gemigreerde server, wordt de indeling van de gebruikersnaam username@servername niet meer ondersteund. In plaats daarvan moet u de standaardindeling gebruiken: gebruikersnaam. Om verificatieproblemen te voorkomen, moet u alle verbindingsreeksen in uw toepassingen en scripts zorgvuldig controleren en bijwerken om ervoor te zorgen dat ze de bijgewerkte indeling van de gebruikersnaam na de upgrade gebruiken.