Större versionsuppgraderingar i Azure Database for PostgreSQL – flexibel server

Din Azure Database for PostgreSQL flexibla servern stöder PostgreSQL-version 18, 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 Azure Database for PostgreSQL flexibel server 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 inte är bakåtkompatibla med befintliga program.

Din Azure Database for PostgreSQL flexibla servern har en funktion som utför en huvudversionsuppgradering på plats av servern. 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.

Anmärkning

Azure Database for PostgreSQL stöder huvudversionsuppgraderingar på plats endast till postgreSQL-versioner som stöds för närvarande. Målversionen måste stödjas officiellt av Azure vid tidpunkten för uppgraderingen. Den Azure portalen förhindrar att du väljer versioner som inte stöds, men API- eller CLI-anrop som riktar sig mot en inaktuell version misslyckas. Läs alltid versionspolicyn för Azure PostgreSQL och uppgraderingshandboken innan du påbörjar en större versionsuppgradering.

Uppgradera valideringskontroller

Azure Database for PostgreSQL flexibel server tillhandahåller uppgraderingsverifieringskontroller för att utvärdera uppgraderingsberedskap innan du påbörjar en större versionsuppgradering.

Uppgraderingsverifieringskontroller kör en serie kompatibilitets- och konfigurationsvalideringar mot servern för att identifiera villkor som kan orsaka att uppgraderingen misslyckas eller beter sig oväntat. Vanliga kontroller är tillägg som inte stöds, logiska replikeringsplatser, förberedda transaktioner, händelseutlösare, objektberoenden som inte stöds och väntande konfigurationsändringar som krävs för omstart.

Valideringsprocessen är utformad för att utvärdera uppgraderingsberedskapen utan att initiera den faktiska uppgraderingsåtgärden. Samma valideringskontroller utförs också automatiskt under arbetsflödet för uppgradering av huvudversioner. Dessa kontroller ändrar inte serverversionen, utlöser stilleståndstid eller startar om servern. Kör valideringskontroller innan du schemalägger ett produktionsuppgraderingsfönster.

Du kan köra uppgraderingsverifieringskontroller i Azure-portalen eller med Azure CLI. Anvisningar finns i Köra valideringskontroller för uppgradering.

När valideringen har slutförts returneras något av följande resultat:

  • Inga blockeringsproblem har identifierats: Uppgraderingsverifieringskontrollerna har slutförts och har inte identifierat några problem som blockerar uppgraderingen.
  • Blockeringsproblem har identifierats: Uppgraderingsverifieringskontroller identifierade ett eller flera problem som måste lösas innan uppgraderingen kan fortsätta.

Beroende på resultatet kan du antingen fortsätta med uppgraderingen eller åtgärda de rapporterade problemen och köra valideringen igen.

Limitations

När du använder verifieringskontrollerna för uppgradering bör du överväga följande begränsningar:

  • Serverstatusen måste vara Klar.
  • Verifieringskontroller stöds inte på läsrepliker.
  • Validering kan inte köras medan en annan serveråtgärd redan pågår.
  • Verifieringskontroller kräver anslutning till alla databaser på servern. Databaser som inte svarar eller är otillgängliga kan orsaka valideringsfel.
  • Även om verifieringskontroller inte orsakar driftstopp kan du överväga att köra dem under perioder med lägre databasaktivitet.

Stegvisa instruktioner finns i Köra uppgraderingsverifieringskontroller.

Uppgraderingsprocess

Här följer några viktiga överväganden för 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 Azure Database for PostgreSQL flexibla server en förkontrollprocedur 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 den Azure Database for PostgreSQL flexibla servern tjänsten och utför en implicit säkerhetskopiering precis innan uppgraderingen påbörjas. Tjänsten kan använda den här implicita säkerhetskopieringen för att återställa databasinstansen till sin tidigare version om det uppstår ett uppgraderingsfel.
  • En Azure Database for PostgreSQL flexibel server använder verktyget pg_upgrade för att utföra större versionsuppgraderingar 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. Återaktivering av ha kräver tillräcklig kapacitet för att etablera en ny väntelägesinstans.
  • De flesta tillägg uppgraderas automatiskt till senare versioner under en huvudversionsuppgradering på plats, med vissa undantag.
  • Processen med en huvudversionsuppgradering på plats för en Azure Database for PostgreSQL flexibel server distribuerar automatiskt den senaste delversionen som stöds.
  • Uppgraderingstiden beror på databasens storlek och komplexitet, inklusive antalet objekt (tabeller, index, scheman), stora objekt och tillägg. Större eller mer komplexa arbetsbelastningar 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 utföra en point-in-time-återställning (PITR) till en tidpunkt innan uppgraderingen för att återställa den tidigare versionen på en ny server.
  • Skydda Azure Database for PostgreSQL-servern. Efter en större versionsuppgradering på en Azure Database for PostgreSQL flexibel server har den första användaren som skapats på servern, som har beviljats admin-alternativet, 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 stoppas uppgraderingsprocessen och ett detaljerat felmeddelande visas. Följande kända begränsningar kan orsaka att uppgraderingen misslyckas eller beter sig oväntat:

Important

Kraven på uppgraderingskompatibilitet kan variera beroende på källa och postgreSQL-målversion och ändras över tid. Listorna i det här avsnittet är en allmän referens och kanske inte återspeglar de exakta kontrollerna för din uppgraderingssökväg. Innan du planerar en uppgradering kör du valideringskontroller för uppgradering på servern för att få den aktuella, fullständiga och tillförlitliga listan över problem som blockerar just din uppgradering, inklusive eventuella krav på logiska replikeringsplatser.

Serverkonfigurationer som inte stöds

  • Geo-replikering i Azure Database for PostgreSQL stöds inte vid uppgraderingar på plats. 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 server kan skicka och 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 återaktiveras inte hög tillgänglighet (HA) automatiskt efter uppgraderingen. Du kan behöva uppdatera NSG-regler manuellt och återaktivera HA.
  • Vyer som är beroende pg_stat_activity av stöds inte vid större versionsuppgraderingar.
  • Om du uppgraderar från PostgreSQL 11 till en högre version måste du först konfigurera din flexibla server för att använda SCRAM-autentisering genom att aktivera SCRAM och återställa alla lösenord för autentiseringsrollen.

Tilläggsbegränsningar

Huvudversionsuppgraderingar på plats stöder inte alla PostgreSQL-tillägg. Uppgraderingen misslyckas under förkontrollen om ett blockerat tillägg finns på en berörd uppgraderingssökväg. De flesta block är begränsade till specifika målversioner (och ibland källversioner) i stället för varje uppgradering, enligt följande listor.

  • Följande tillägg blockerar en huvudversionsuppgradering på plats på alla uppgraderingsvägar. Ta bort dem före uppgraderingen och återaktivera dem efter, om det stöds på målversionen: session_variable, anon, age.

  • Följande tillägg är icke-beständiga verktygstillägg och måste tas bort innan uppgraderingen och återskapas efter, avsiktligt (alla uppgraderingssökvägar): pg_repack, hypopg, pg_partman.

  • Följande tillägg blockeras endast på specifika versionssökvägar. Ta bort dem före uppgraderingen om uppgraderingen matchar det angivna villkoret och återaktivera dem efter om det stöds i målversionen:

    Extension Blockerad när
    pg_hint_plan Målversionen är PostgreSQL 14
    semver Målversionen är PostgreSQL 16 eller 17
    azure_local_ai Målversionen är PostgreSQL 17 eller 18
    pg_failover_slots Målversionen är PostgreSQL 17 eller 18 (delat förinläsningsbibliotek)
    azure_ai Målversionen är PostgreSQL 18
    azure_storage Målversionen är PostgreSQL 18
    pg_diskann Målversionen är PostgreSQL 18
    pgrouting Målversionen är PostgreSQL 15; eller källan är tidigare än PostgreSQL 16 och målet är PostgreSQL 16 eller senare; eller målversionen är PostgreSQL 18
    orafce Källversionen är PostgreSQL 11, 12 eller 13

  • Följande tillägg blockeras när andra databasobjekt är beroende av deras objekt, eftersom uppgraderingen annars skulle misslyckas. Lös beroendena före uppgraderingen:

    • pg_stat_statements: blockeras när andra objekt är beroende av dess vy eller funktion, vilket skulle orsaka ALTER EXTENSION pg_stat_statements UPDATE fel. Ta först bort de beroende objekten.
    • pgcrypto: När det installeras i pg_catalog schemat och uppgraderas från PostgreSQL 11 eller 12 till PostgreSQL 13 eller senare, blockeras när kundobjekt är beroende av det (en konflikt med den inbyggda gen_random_uuid() funktionen). Flytta tillägget till ett annat schema eller släpp de beroende objekten först.

Anmärkning

Du måste köra åtgärden DROP EXTENSION för att ta bort tillägg som inte stöds innan du uppgraderar. Du behöver inte ta bort tillägget från listan över tillåtna.

PostGIS-specifika överväganden

Om du använder PostGIS eller beroende tillägg konfigurerar du parametern så att den search_path 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 du inte konfigurerar search_path korrekt kan uppgraderingen misslyckas eller bryta objekt efter uppgraderingen.

TimescaleDB-specifika överväganden

Om du använder TimescaleDB stöds huvudversionsuppgraderingar på plats endast för specifika kombinationer av PostgreSQL-käll- och målversioner:

PostgreSQL-källversion Målversioner som stöds
PostgreSQL 11 PostgreSQL 12
PostgreSQL 12 PostgreSQL 13, 14, 15
PostgreSQL 13 PostgreSQL 14, 15, 16
PostgreSQL 14 PostgreSQL 15, 16
PostgreSQL 15 PostgreSQL 16, 17, 18
PostgreSQL 16 PostgreSQL 17, 18
PostgreSQL 17 PostgreSQL 18

Om din uppgraderingsväg för TimescaleDB inte finns med i matrisen över uppgraderingar som stöds blockeras uppgradering på plats till en ny huvudversion. För att fortsätta kan du antingen ta bort TimescaleDB-tillägget före uppgraderingen, om möjligt, eller använda en alternativ migreringsmetod, till exempel migrering sida vid sida med logisk replikering.

Kontrollera att käll- och målversionerna ingår i matrisen som stöds innan du påbörjar uppgraderingen.

Andra uppgraderingsöverväganden

  • Händelseutlösare: Uppgraderingsförkontrollen blockerar händelseutlösare eftersom de ansluter till DDL-kommandon och kan referera till systemkataloger som ändras mellan större versioner. Släpp alla EVENT TRIGGERinnan du uppgraderar och återskapa dem sedan efter uppgraderingen för att säkerställa en smidig uppgradering.
  • Stora objekt (LOs): Hur en uppgradering hanterar databaser som innehåller miljontals stora objekt (lagras i pg_largeobject) beror på målversionen:
    • Target PostgreSQL 15 eller senare: Uppgraderingen använder en optimerad massmetod för att överföra stora objektmetadata, så minne och tillfällig diskanvändning skalas inte längre med antalet stora objekt. Databaser med tiotals eller hundratals miljoner stora objekt uppgraderas tillförlitligt utan extra förberedelse. Att köra vacuumlo eller skala upp servern i förväg krävs inte för att kringgå stora objektvolymer, även om du fortfarande kan köra vacuumlo för att ta bort oanvända stora objekt av andra skäl.
    • MålpostgreSQL 14 eller tidigare: Databaser med miljontals stora objekt kan orsaka uppgraderingsfel på grund av hög minnesanvändning eller loggvolym. Använd vacuumlo-verktyget för att rensa oanvända stora objekt och överväg att skala upp servern före uppgraderingen om många stora objekt fortfarande används.

Varning

Var försiktig med vacuumlo. vacuumlo identifierar överblivna stora objekt baserat på konventionella referenskolumner (oid, lo). Om ditt program använder anpassade eller indirekta referenstyper kan giltiga stora objekt tas bort av misstag. Dessutom vacuumlo kan förbruka betydande CPU, minne och IOPS, särskilt i databaser med miljontals stora objekt. Kör den under underhållsfönster och testa först i en icke-produktionsmiljö.

Efter uppgraderingen

När den större versionsuppgraderingen är klar, kör kommandot ANALYZE i varje databas för att uppdatera tabellen pg_statistic. 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

Använd PG_Upgrade_Logs för att övervaka uppgraderingens förlopp och felsöka problem. Granska loggarna under och efter uppgraderingen för att spåra förloppet, diagnostisera fel eller fördröjningar och identifiera blockeringsproblem så att du snabbt kan vidta korrigerande åtgärder.

Aktivera uppgraderingsloggar med hjälp av serverloggparametrar

  • Ställ in logfiles.download_enable på PÅ.
  • Konfigurera kvarhållning med logfiles.retention_days.

Se Ladda ned PostgreSQL- och uppgraderingsloggar för att komma igång.

Anmärkning

Huvudversionsuppgraderingar på plats stöds på automatiskt invandrade servrar. Efter en lyckad uppgradering av huvudversion på plats på en automatiskt inmigrerad server stöds inte längre användarnamnsformatet username@servername . Använd i stället standardformatet: användarnamn. Undvik autentiseringsproblem genom att noggrant granska och uppdatera alla anslutningssträngar i dina program och skript för att säkerställa att de använder det uppdaterade användarnamnsformatet efter uppgraderingen.

Relaterat innehåll

  • Last updated on