Större versionsuppgraderingar i Azure Database for PostgreSQL

Din flexibla Azure Database for PostgreSQL-serverinstans stöder PostgreSQL version 18 (förhandsversion), 17, 16, 15, 14, 13, 12, 11. Postgres-communityn släpper en ny huvudversion som innehåller nya funktioner ungefär en gång om året. Dessutom får varje större version periodiska felkorrigeringar i form av mindre versioner. Delversionsuppgraderingar omfattar ändringar som är bakåtkompatibla med befintliga program. En flexibel Azure Database for PostgreSQL-serverinstans uppdaterar regelbundet de mindre versionerna under kundens underhållsperiod.

Större versionsuppgraderingar är mer komplicerade än delversionsuppgraderingar. De kan innehålla interna ändringar och nya funktioner som kanske inte är bakåtkompatibla med befintliga program.

Din flexibla Azure Database for PostgreSQL-serverinstans har en funktion som utför en huvudversionsuppgradering på plats av servern med bara ett klick. Den här funktionen förenklar uppgraderingsprocessen genom att minimera störningarna för användare och program som har åtkomst till servern.

Uppgraderingar på plats behåller servernamnet och andra inställningar för den aktuella servern efter uppgraderingen av en huvudversion. De kräver inte datamigrering eller ändringar i programmet anslutningssträng. Uppgraderingar på plats går snabbare och innebär kortare stilleståndstid än datamigrering.

Uppgraderingsprocess

Här är några av de viktiga övervägandena med huvudversionsuppgraderingar på plats:

• Kontrollera att servern har minst 10–20% ledigt lagringsutrymme innan du påbörjar uppgraderingen. Under uppgraderingsprocessen kan tillfälliga loggfiler och metadataåtgärder öka diskanvändningen. Otillräckligt ledigt utrymme kan leda till uppgraderingsfel eller återställningsproblem.
• Under processen med en huvudversionsuppgradering på plats kör din flexibla Azure Database for PostgreSQL-serverinstans en förkontroll för att identifiera eventuella problem som kan orsaka att uppgraderingen misslyckas.
  • Om förkontrollen hittar eventuella inkompatibiliteter skapar den en logghändelse som visar att förkontrollen av uppgraderingen misslyckades, tillsammans med ett felmeddelande.
  • Om förkontrollen lyckas stoppar Azure Database for PostgreSQL flexibel serverinstans tjänsten och gör en implicit säkerhetskopiering precis innan uppgraderingen påbörjas. Tjänsten kan använda den här säkerhetskopian för att återställa databasinstansen till sin tidigare version om det uppstår ett uppgraderingsfel.
• En flexibel Azure Database for PostgreSQL-serverinstans använder verktyget pg_upgrade för att utföra huvudversionsuppgraderingar på plats. Tjänsten ger flexibiliteten att hoppa över versioner och uppgradera direkt till senare versioner.
• Under en huvudversionsuppgradering på plats av en server som är aktiverad för hög tillgänglighet (HA) inaktiverar tjänsten HA, utför uppgraderingen på den primära servern och aktiverar ha igen när uppgraderingen är klar.
• De flesta tillägg uppgraderas automatiskt till senare versioner under en huvudversionsuppgradering på plats, med vissa undantag.
• Processen för en huvudversionsuppgradering på plats för en flexibel Azure Database for PostgreSQL-serverinstans distribuerar automatiskt den senaste delversionen som stöds.
• En huvudversionsuppgradering på plats är en offlineåtgärd, vilket innebär att servern inte är tillgänglig under processen. Även om de flesta uppgraderingar slutförs på mindre än 15 minuter beror den faktiska varaktigheten på databasens storlek och komplexitet. Mer specifikt är den tid som krävs direkt proportionell mot antalet objekt (tabeller, index, scheman) i PostgreSQL-instansen. Större eller mer komplexa scheman kan uppleva längre uppgraderingstider.
• Långvariga transaktioner eller hög arbetsbelastning före uppgraderingen kan öka tiden det tar att stänga av databasen och öka uppgraderingstiden.
• När en huvudversionsuppgradering på plats har slutförts finns det inga automatiserade sätt att återgå till den tidigare versionen. Du kan dock utföra en återställning till tidpunkt (PITR) för att återställa databasinstansen till en tidigare version som fanns före uppgraderingen.
• Din flexibla Azure Database for PostgreSQL-serverinstans tar en ögonblicksbild av databasen under en uppgradering. Ögonblicksbilden tas innan uppgraderingen startar. Om uppgraderingen misslyckas återställer systemet automatiskt databasen till dess tillstånd från ögonblicksbilden.
• PostgreSQL 16 introducerar rollbaserade säkerhetsåtgärder . Efter en större versionsuppgradering på en flexibel Azure Database for PostgreSQL-serverinstans har den första användaren som skapats på servern – som har beviljats administratörsalternativet – nu administratörsbehörighet för andra roller för viktiga underhållsåtgärder.

Överväganden och begränsningar för uppgradering

Om en förkontroll misslyckas under en uppgradering av huvudversionen på plats blockeras uppgraderingen med ett detaljerat felmeddelande. Nedan visas kända begränsningar som kan orsaka att uppgraderingen misslyckas eller fungerar oväntat:

Serverkonfigurationer som inte stöds

• Läsrepliker stöds inte vid direkt uppgraderingar. Du måste ta bort läsrepliken (inklusive alla beroende läsreplikor) innan du uppgraderar den primära servern. Efter uppgraderingen kan du återskapa repliken.
• Regler för nätverkstrafik kan blockera uppgraderingsåtgärder.
  • Se till att din flexibla serverinstans kan skicka/ta emot trafik på portarna 5432 och 6432 i det virtuella nätverket och till Azure Storage (för loggarkivering).
  • Om nätverkssäkerhetsgrupper (NSG:er) begränsar den här trafiken, återaktiverar HA inte automatiskt efter uppgradering. Du kan behöva uppdatera NSG-regler manuellt och återaktivera HA.
• Logiska replikeringsfack stöds inte vid uppgradering av huvudversioner på plats.
• Servrar som använder SSDv2-lagring är inte berättigade till större versionsuppgraderingar.
• Vyer som är beroende pg_stat_activity av stöds inte vid större versionsuppgraderingar.
• Om du utför uppgraderingen från PG11 till en högre version måste du först konfigurera den flexibla servern för att använda SCRAM-autentisering genom att aktivera SCRAM och återställa alla lösenord för inloggningsrollen.

Tilläggsbegränsningar

Huvudversionsuppgraderingar på plats stöder inte alla PostgreSQL-tillägg. Uppgraderingen misslyckas under förkontrollen om tillägg som inte stöds hittas.

• Följande tillägg stöds för regelbunden användning, men blockerar en huvudversionsuppgradering på plats om det finns. Ta bort dem före uppgraderingen och återaktivera dem efter, om det stöds på målversionen: timescaledb, dblink, orafce, postgres_fdw.
• Följande tillägg är icke-beständiga verktygstillägg och måste tas bort och återskapas efter uppgraderingen avsiktligt: pg_repack, hypopg.
• När du uppgraderar till PostgreSQL 17 stöds inte följande tillägg och måste tas bort före uppgraderingen. Du kan bara återaktivera dem om det stöds i målversionen: age, azure_ai, hll, pg_diskann, pgrouting.

Not: Om något av dessa tillägg visas i azure.extensions serverparametern blockeras uppgraderingen. Ta bort dem från parametern innan du påbörjar uppgraderingen.

PostGIS-Specific överväganden

Om du använder PostGIS eller beroende tillägg måste du konfigurera search_path-serverparametern så att den inkluderar:

• Scheman relaterade till PostGIS
• Beroende tillägg, inklusive: postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_us, fuzzystrmatch
• Om search_path inte konfigureras korrekt kan det leda till uppgraderingsfel eller brutna objekt efter uppgraderingen.

Andra uppgraderingsöverväganden

• Händelseutlösare: Förhandskontroll vid uppgradering blockerar händelseutlösare eftersom de ansluter till DDL-kommandon och kan referera till systemkatalogerna som ändras mellan huvudversioner – ta bort alla EVENT TRIGGER innan uppgradering och återskapa dem därefter för att säkerställa en smidig uppgradering.
• Stora objekt (LOs): Databaser med miljontals stora objekt (lagrade i pg_largeobject) kan orsaka uppgraderingsfel på grund av hög minnesanvändning eller loggvolym. Använd vacuumlo-verktyget för att rensa oanvända LOs och överväg att skala upp servern före uppgraderingen om många LOs fortfarande används.

Efter uppgraderingen

När uppgraderingen av huvudversionen är klar rekommenderar vi att du kör ANALYZE kommandot i varje databas för att uppdatera pg_statistic tabellen. Saknad eller inaktuell statistik kan leda till dåliga frågeplaner, vilket i sin tur kan försämra prestanda och ta upp för mycket minne.

postgres=> analyze;
ANALYZE

Visa uppgraderingsloggar

Huvudversionsuppgraderingsloggar (PG_Upgrade_Logs) ger direkt åtkomst till detaljerade serverloggar. Genom att PG_Upgrade_Logs integrera i uppgraderingsprocessen kan du säkerställa en smidigare och mer transparent övergång till nya PostgreSQL-versioner.

Du kan konfigurera dina huvudversionsuppgraderingsloggar på samma sätt som serverloggar med hjälp av följande serverparametrar:

• Om du vill aktivera funktionen anger du logfiles.download_enable till ON.
• Om du vill definiera kvarhållning av loggfiler i dagar använder du logfiles.retention_days.

Konfigurera uppgraderingsloggar

Om du vill börja använda PG_Upgrade_Logskan du konfigurera avbildning av PostgreSQL-serverloggar och huvudversionsuppgraderingsloggar.

Du kan komma åt uppgraderingsloggarna via användargränssnittet för serverloggar. Där kan du övervaka förloppet och informationen om dina postgreSQL-huvudversionsuppgraderingar i realtid. Det här användargränssnittet tillhandahåller en central plats för att visa loggar, så att du enklare kan spåra och felsöka uppgraderingsprocessen.

Fördelar med att använda uppgraderingsloggar

• Insiktsfull diagnostik: PG_Upgrade_Logs ger värdefulla insikter om uppgraderingsprocessen. Den samlar in detaljerad information om de åtgärder som utförs och visar eventuella fel eller varningar som inträffar. Den här detaljnivån är avgörande för att diagnostisera och lösa problem som kan uppstå under uppgraderingen för en smidigare övergång.
• Effektiv felsökning: Med direkt åtkomst till dessa loggar kan du snabbt identifiera och åtgärda potentiella uppgraderingshinder, minska stilleståndstiden och minimera påverkan på dina åtgärder. Loggarna fungerar som ett viktigt felsökningsverktyg genom att möjliggöra effektivare och effektivare problemlösning.

Relaterat innehåll

• Huvudversionsuppgradering.
• Hög tillgänglighet i Azure Database for PostgreSQL.
• Säkerhetskopiera och återställa i Azure Database for PostgreSQL.