Share via

Uppgradera PostgreSQL-databasen med hjälp av dump och återställning

  • Artikel

GÄLLER FÖR: Azure Database for PostgreSQL – enskild server

Viktigt!

Azure Database for PostgreSQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till Azure Database for PostgreSQL – flexibel server. Mer information om hur du migrerar till Azure Database for PostgreSQL – flexibel server finns i Vad händer med Azure Database for PostgreSQL – enskild server?.

Kommentar

Begreppen som förklaras i den här dokumentationen gäller för både Azure Database for PostgreSQL – enskild server och Azure Database for PostgreSQL – flexibel server.

Du kan uppgradera din PostgreSQL-server som distribuerats i Azure Database for PostgreSQL genom att migrera dina databaser till en högre huvudversionsserver med hjälp av följande metoder.

  • Offlinemetod med PostgreSQL-pg_dump och pg_restore som medför stilleståndstid för migrering av data. Det här dokumentet behandlar den här metoden för uppgradering/migrering.
  • Onlinemetod med hjälp av Database Migration Service (DMS). Den här metoden ger en reducerad stilleståndstidsmigrering och håller måldatabasen synkroniserad med källan och du kan välja när du ska skära ned. Det finns dock några krav och begränsningar som måste åtgärdas för att kunna använda DMS. Mer information finns i dokumentationen för DMS.
  • Metod för högre versionsuppgradering på plats med hjälp av Azure Database for PostgreSQL – flexibel server. Huvudversionsuppgraderingsfunktionen på plats utför större versionsuppgradering av servern med bara ett klick. Detta förenklar uppgraderingsprocessen, vilket minimerar störningarna för användare och program som kommer åt servern. På plats-uppgraderingar är ett enklare sätt att uppgradera huvudversionen av instansen, eftersom de behåller servernamnet och andra inställningar för den aktuella servern efter uppgraderingen och inte kräver datamigrering eller ändringar i programmet anslutningssträng s. Uppgraderingar på plats går snabbare och innebär kortare stilleståndstid än datamigrering.

Följande tabell innehåller några rekommendationer baserat på databasstorlekar och scenarier.

Databas/scenario Dumpa/återställa (offline) DMS (Online)
Du har en liten databas och har råd med stilleståndstid för uppgradering X
Små databaser (< 10 GB) X X
Små medelstora databaser (10 GB – 100 GB) X X
Stora databaser (> 100 GB) X
Har råd med stilleståndstid för uppgradering (oavsett databasstorlek) X
Kan du hantera DMS-förutsättningar, inklusive en omstart? X
Kan du undvika DDL:er och ologgade tabeller under uppgraderingsprocessen? X

Den här guiden innehåller få offlinemigreringsmetoder och exempel som visar hur du kan migrera från källservern till målservern som kör en högre version av PostgreSQL.

Kommentar

PostgreSQL-dump och återställning kan utföras på många sätt. Du kan välja att migrera med någon av metoderna i den här guiden eller välja alternativa sätt att passa dina behov. Detaljerad dumpnings- och återställningssyntax med ytterligare parametrar finns i artiklarna pg_dump och pg_restore.

Förutsättningar för att använda dump och återställning med Azure Database for PostgreSQL

Om du vill gå igenom den här instruktionsguiden behöver du:

  • En PostgreSQL-källdatabasserver som kör en lägre version av motorn som du vill uppgradera.
  • En PostgreSQL-måldatabasserver med den önskade huvudversionen Azure Database for PostgreSQL-server – enskild server eller Azure Database for PostgreSQL – flexibel server.
  • Ett PostgreSQL-klientsystem för att köra dump- och återställningskommandona. Vi rekommenderar att du använder den högre databasversionen. Om du till exempel uppgraderar från PostgreSQL version 9.6 till 11 använder du PostgreSQL version 11-klienten.
    • Det kan vara en Linux- eller Windows-klient som har PostgreSQL installerat och som har pg_dump och pg_restore kommandoradsverktyg installerade.
    • Du kan också använda Azure Cloud Shell eller genom att välja Azure Cloud Shell på menyraden längst upp till höger i Azure-portalen. Du måste logga in på ditt konto az login innan du kör dump- och återställningskommandona.
  • PostgreSQL-klienten körs helst i samma region som käll- och målservrarna.

Ytterligare information och överväganden

  • Du hittar anslutningssträng till käll- och måldatabaserna genom att välja "Anslut ionssträngar" från portalen.
  • Du kanske kör mer än en databas på servern. Du hittar listan över databaser genom att ansluta till källservern och köra \l.
  • Skapa motsvarande databaser i måldatabasservern eller lägg till -C alternativet i pg_dump kommandot som skapar databaserna.
  • Du får inte uppgradera azure_maintenance eller malldatabaser. Om du har gjort ändringar i malldatabaser kan du välja att migrera ändringarna eller göra dessa ändringar i måldatabasen.
  • Se tabellerna ovan för att fastställa att databasen är lämplig för det här migreringsläget.
  • Om du vill använda Azure Cloud Shell bör du observera att tidsgränsen för sessionen uppnås efter 20 minuter. Om databasstorleken är < 10 GB kanske du kan slutföra uppgraderingen utan tidsgränsen för sessionen. Annars kan du behöva hålla sessionen öppen på annat sätt, till exempel genom att trycka på valfri tangent en gång på 10–15 minuter.

Exempeldatabas som används i den här guiden

I den här guiden används följande käll- och målservrar och databasnamn för att illustrera med exempel.

Beskrivning Värde
Källserver (v9.5) pg-95.postgres.database.azure.com
Källdatabas bench5gb
Källdatabasens storlek 5 GB
Källanvändarnamn pg@pg-95
Målserver (v11) pg-11.postgres.database.azure.com
Måldatabas bench5gb
Målanvändarnamn pg@pg-11

Kommentar

Flexibel server stöder PostgreSQL version 11 och senare. Dessutom kräver @dbservernameinte flexibla serveranvändarnamn .

Uppgradera dina databaser med hjälp av offlinemigreringsmetoder

Du kan välja att använda någon av de metoder som beskrivs i det här avsnittet för dina uppgraderingar. Du kan använda följande tips när du utför uppgifterna.

  • Om du använder samma lösenord för källan och måldatabasen kan du ange PGPASSWORD=yourPassword miljövariabeln. Sedan behöver du inte ange lösenord varje gång du kör kommandon som psql, pg_dump och pg_restore. På samma sätt kan du konfigurera ytterligare variabler som PGUSER, PGSSLMODE osv. se till PostgreSQL-miljövariabler.

  • Om PostgreSQL-servern kräver TLS/SSL-anslutningar (på som standard i Azure Database for PostgreSQL-servrar) anger du en miljövariabel PGSSLMODE=require så att pg_restore-verktyget ansluter till TLS. Utan TLS kan felet läsas FATAL: SSL connection is required. Please specify SSL options and retry.

  • Kör kommandot SET PGSSLMODE=require på Windows-kommandoraden innan du kör kommandot pg_restore. Kör kommandot export PGSSLMODE=require i Linux eller Bash innan du kör kommandot pg_restore.

Viktigt!

Stegen och metoderna i det här dokumentet är att ge några exempel på kommandon för pg_dump/pg_restore och inte representerar alla möjliga sätt att utföra uppgraderingar. Vi rekommenderar att du testar och validerar kommandona i en testmiljö innan du använder dem i produktion.

Migrera rollerna

Roller (användare) är globala objekt och måste migreras separat till det nya klustret innan databaserna återställs. Du kan använda pg_dumpall binärt med alternativet -r (--roles-only) för att dumpa dem. Så här dumpar du alla roller med lösenord från källan – enskild server:

pg_dumpall -r --host=mySourceServer --port=5432 --username=myUser@mySourceServer --database=mySourceDB > roles.sql

Så här dumpar du alla rollnamn utan lösenord från källan Flexibel server:

pg_dumpall -r --no-role-passwords --host=mySourceServer --port=5432 --username=myUser --database=mySourceDB > roles.sql

Viktigt!

I Azure Database for PostgreSQL – Flexibel server får användare inte komma åt pg_authid tabell som innehåller information om databasauktoriseringsidentifierare tillsammans med användarens lösenord. Därför är det inte möjligt att hämta lösenord för användare. Överväg att använda Azure Key Vault för att lagra dina hemligheter på ett säkert sätt.

roles.sql Redigera och ta bort referenser till NOSUPERUSER och NOBYPASSRLS innan du återställer innehållet med psql på målservern:

psql -f roles.sql --host=myTargetServer --port=5432 --username=myUser --dbname=postgres

Dumpskriptet bör inte förväntas köras helt utan fel. Eftersom skriptet kommer att utfärda CREATE ROLE för varje roll som finns i källklustret är det säkert att få ett "roll redan finns"-fel för bootstrap-superanvändaren som azure_pg_admin eller azure_superuser. Det här felet är ofarligt och kan ignoreras. Användningen av --clean alternativet kommer sannolikt att generera ytterligare ofarliga felmeddelanden om icke-existerande objekt, även om du kan minimera dem genom att lägga till --if-exists.

Metod 1: Använda pg_dump och psql

Den här metoden omfattar två steg. Först ska du dumpa en SQL-fil från källservern med hjälp av pg_dump. Det andra steget är att importera filen till målservern med hjälp av psql. Mer information finns i dokumentationen Migrera med export och import .

Metod 2: Använda pg_dump och pg_restore

I den här uppgraderingsmetoden skapar du först en dump från källservern med hjälp av pg_dump. Sedan återställer du dumpfilen till målservern med hjälp av pg_restore. Mer information finns i dokumentationen Migrera med dump och återställning .

Metod 3: Använda direktuppspelning av dumpdata till måldatabasen

Om du inte har någon PostgreSQL-klient eller om du vill använda Azure Cloud Shell kan du använda den här metoden. Databasdumpningen strömmas direkt till måldatabasservern och lagrar inte dumpen i klienten. Detta kan därför användas med en klient med begränsad lagring och kan även köras från Azure Cloud Shell.

  1. Kontrollera att databasen finns på målservern med hjälp av \l kommandot . Om databasen inte finns skapar du databasen.

     psql "host=myTargetServer port=5432 dbname=postgres user=myUser password=###### sslmode=mySSLmode"

    postgres> \l   
postgres> create database myTargetDB;

  2. Kör dumpen och återställ som en enda kommandorad med hjälp av ett rör.

    pg_dump -Fc --host=mySourceServer --port=5432 --username=myUser --dbname=mySourceDB | pg_restore  --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDB

    Exempel:

    pg_dump -Fc --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb | pg_restore --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gb

  3. När uppgraderingsprocessen (migreringen) är klar kan du testa programmet med målservern.

  4. Upprepa den här processen för alla databaser på servern.

I följande tabell visas till exempel hur lång tid det tog att migrera med hjälp av en strömningsdumpningsmetod. Exempeldata fylls i med hjälp av pgbench. Eftersom databasen kan ha olika antal objekt med varierande storlekar än pgbenchgenererade tabeller och index rekommenderar vi starkt att du testar dump och återställning av databasen för att förstå den faktiska tid det tar att uppgradera databasen.

Databasstorlek Cirka tidsåtgång
1 GB 1–2 minuter
5 GB 8–10 minuter
10 GB 15–20 minuter
50 GB 1–1,5 timmar
100 GB 2,5–3 timmar

Metod 4: Använda parallell dump och återställning

Du kan överväga den här metoden om du har några större tabeller i databasen och vill parallellisera dump- och återställningsprocessen för databasen. Du behöver också tillräckligt med lagringsutrymme i klientsystemet för att hantera säkerhetskopieringsdumpar. Den här parallella dump- och återställningsprocessen minskar tidsförbrukningen för att slutföra hela migreringen. Till exempel slutfördes 50 GB pgbench-databasen som tog 1–1,5 timmar att migrera med metod 1 och 2 tog mindre än 30 minuter med den här metoden.

  1. Skapa en motsvarande databas på målservern för varje databas i källservern.

    psql "host=myTargetServer port=5432 dbname=postgres user=myuser password=###### sslmode=mySSLmode"

    postgres> create database myDB;

    Exempel:

    psql "host=pg-11.postgres.database.azure.com port=5432 dbname=postgres user=pg@pg-11 password=###### sslmode=require"
psql (12.3 (Ubuntu 12.3-1.pgdg18.04+1), server 13.3)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

postgres> create database bench5gb;
postgres> \q

  2. Kör kommandot pg_dump i ett katalogformat med antalet jobb = 4 (antal tabeller i databasen). Med en större beräkningsnivå och med fler tabeller kan du öka den till ett högre tal. Den pg_dump skapar en katalog för att lagra komprimerade filer för varje jobb.

    pg_dump -Fd -v --host=sourceServer --port=5432 --username=myUser --dbname=mySourceDB -j 4 -f myDumpDirectory

    Exempel:

    pg_dump -Fd -v --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb -j 4 -f dump.dir

  3. Återställ sedan säkerhetskopian på målservern.

    $ pg_restore -v --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDB -j 4 myDumpDir

    Exempel:

    $ pg_restore -v --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gb -j 4 dump.dir

Dricks

Processen som nämns i det här dokumentet kan också användas för att uppgradera din Azure Database for PostgreSQL – flexibel server. Den största skillnaden är att anslutningssträng för det flexibla servermålet är utan @dbName. Om användarnamnet till exempel är pgkommer den enskilda serverns användarnamn i anslutningssträngen att vara pg@pg-95, medan du med flexibel server helt enkelt kan använda pg.

Efter uppgradering/migrering

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. Annars kan du stöta på prestandaproblem.

postgres=> analyze;
ANALYZE

Nästa steg

  • När du är nöjd med måldatabasfunktionen kan du släppa den gamla databasservern.
  • Endast för Azure Database for PostgreSQL – enskild server. Om du vill använda samma databasslutpunkt som källservern kan du skapa en skrivskyddad replik med det gamla databasservernamnet när du har tagit bort den gamla källdatabasservern. När det stadiga replikeringstillståndet har upprättats kan du stoppa repliken, vilket gör replikservern till en oberoende server. Mer information finns i Replikering .

Viktigt!

Vi rekommenderar starkt att du testar den nya PostgreSQL-uppgraderade versionen innan du använder den direkt för produktion. Detta inkluderar att jämföra serverparametrar mellan den äldre källversionskällan och det nyare versionsmålet. Kontrollera att de är samma och kontrollera eventuella nya parametrar som har lagts till i den nya versionen. Skillnader mellan versioner finns här.