Dela via

Metodtips för pg_dump och pg_restore för Azure Database for PostgreSQL

Den här artikeln granskar alternativ och metodtips för att påskynda pg_dump och pg_restore. Den förklarar också de bästa serverkonfigurationerna för att utföra pg_restore.

Metodtips för pg_dump

Du kan använda verktyget pg_dump för att extrahera en flexibel Azure Database for PostgreSQL-serverdatabas till en skriptfil eller arkivfil. Några av de kommandoradsalternativ som du kan använda för att minska den totala dumptiden med hjälp av pg_dump visas i följande avsnitt.

Katalogformat(-Fd)

Det här alternativet matar ut ett arkiv i katalogformat som du kan mata in till pg_restore. Som standard komprimeras utdata.

Parallella jobb(-j)

Med pg_dump kan du köra dumpjobb samtidigt med hjälp av alternativet parallella jobb. Det här alternativet minskar den totala dumptiden men ökar belastningen på databasservern. Vi rekommenderar att du anländer till ett parallellt jobbvärde efter noggrann övervakning av källservermåtten, till exempel cpu-, minnes- och IOPS-användning (indata-/utdataåtgärder per sekund).

När du anger ett värde för alternativet parallella jobb kräver pg_dump följande:

  • Antalet anslutningar måste vara lika med antalet parallella jobb +1, så se till att ange värdet i enlighet med detta max_connections .
  • Antalet parallella jobb ska vara mindre än eller lika med antalet virtuella processorer som allokeras för databasservern.

Komprimering(-Z0)

Det här alternativet anger vilken komprimeringsnivå som ska användas. Noll innebär ingen komprimering. Ingen komprimering under pg_dump processen kan hjälpa till med prestandavinster.

Uppsvälld tabell och dammsugning

Innan du börjar pg_dump processen bör du överväga om tabelldammsugning är nödvändigt. Uppsvälldhet på tabeller ökar avsevärt pg_dump gånger. Kör följande fråga för att identifiera uppsvälld tabell:

select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;

Kolumnen dead_pct i den här frågan är procentandelen döda tupplar jämfört med levande tupplar. Ett högt dead_pct värde för en tabell kan tyda på att tabellen inte dammsugas korrekt. Mer information finns i autovakuuminställningar i Azure Database för PostgreSQL - flexibel server.

För varje tabell som du identifierar kan du utföra en manuell vakuumanalys genom att köra följande:

vacuum(analyze, verbose) <table_name>

Använda en PITR-server

Du kan utföra en pg_dump på en online- eller liveserver. Den gör konsekventa säkerhetskopieringar även om databasen används. Det blockerar inte andra användare från att använda databasen. Överväg databasens storlek och andra affärs- eller kundbehov innan du startar pg_dump processen. Små databaser kan vara bra kandidater för att utföra en pg_dump på produktionsservern.

För stora databaser kan du skapa en PITR-server (point-in-time recovery) från produktionsservern och utföra pg_dump processen på PITR-servern. Att köra pg_dump på en PITR skulle vara en kall körningsprocess. Kompromissen för den här metoden är att du inte skulle bry dig om extra processor-, minnes- och I/O-användning som medföljer en pg_dump process som körs på en faktisk produktionsserver. Du kan köra pg_dump på en PITR-server och sedan släppa PITR-servern när pg_dump processen har slutförts.

När du ser prestationsproblem med pg_dump när nätverksbandbredden är hög bör du överväga att använda en högre vCore SKU. SKU:er med högre virtuella kärnor ger vanligtvis ytterligare processor- och nätverksdataflöde, vilket kan minska den totala dumptiden. Övervaka CPU-, nätverks- och IOPS-mått för att bekräfta om bandbredd eller beräkning är flaskhalsen innan du skalar.

Parameterjustering

Justera följande serverparametrar för att påskynda skapande av index under återställningsåtgärder. pg_dump arkiv innehåller ofta kommandon för att skapa index (till exempel CREATE INDEX eller ALTER TABLE ... LÄGG TILL VILLKOR); förbättra prestanda för indexskapande kan förkorta den totala migreringstiden:

  • maintenance_work_mem = 2097151 (2 GB) – Öka det här värdet för att allokera mer minne för att skapa index och andra underhållsaktiviteter. För stora index bör du överväga att höja den här inställningen (till exempel hundratals megabyte till flera gigabyte) och verifiera minnesanvändningen på en icke-produktionsinstans innan du tillämpar den i produktion.
  • max_parallel_maintenance_workers = 4 – Öka det här värdet så att parallella index skapas på servrar med flera virtuella kärnor. Ange detta i förhållande till antalet virtuella kärnor och testa för att fastställa den optimala nivån för din arbetsbelastning.

Testa eventuella parameter- eller SKU-ändringar på en icke-produktions- eller PITR-server. Verifiera prestanda och stabilitet och tillämpa sedan ändringarna på produktion. När migreringen eller stora återställningar har slutförts återställer du parametrarna till värden som matchar normala arbetsbelastningskrav.

Syntax för pg_dump

Använd följande syntax för pg_dump:

pg_dump -h <hostname> -U <username> -d <databasename> -Fd -j <Num of parallel jobs> -Z0 -f sampledb_dir_format

Du kan använda verktyget pg_restore för att återställa en flexibel Azure Database for PostgreSQL-serverdatabas från ett arkiv som skapas av pg_dump. Några kommandoradsalternativ för att minska den totala återställningstiden visas i följande avsnitt.

Parallell återställning

Genom att använda flera samtidiga jobb kan du minska den tid det tar att återställa en stor databas på en målserver med flera virtuella kärnor. Antalet jobb kan vara lika med eller mindre än antalet vCPU:er som allokeras för målservern.

Serverparametrar

Om du återställer data till en ny server eller icke-produktionsserver kan du optimera följande serverparametrar innan du kör pg_restore:

work_mem = 32 MB
max_wal_size = 65536 (64 GB)
checkpoint_timeout = 3600 #60min
maintenance_work_mem = 2097151 (2 GB)
autovacuum = av
wal_compression = på

När återställningen har slutförts kontrollerar du att alla dessa parametrar uppdateras korrekt enligt arbetsbelastningskraven.

Kommentar

Följ endast föregående rekommendationer om det finns tillräckligt med minne och diskutrymme. Om du har en liten server med 2, 4 eller 8 virtuella kärnor anger du parametrarna därefter.

Övriga beaktanden

  • Inaktivera hög tillgänglighet (HA) innan du kör pg_restore.
  • Analysera alla tabeller som migreras när återställningen är klar.

Syntax för pg_restore

Använd följande syntax för pg_restore:

pg_restore -h <hostname> -U <username> -d <db name> -Fd -j <NUM> -C <dump directory>

  • -Fd: Katalogformatet.
  • -j: Antalet jobb.
  • -C: Börja utdata med ett kommando för att skapa själva databasen och sedan återansluta till den.

Här är ett exempel på hur den här syntaxen kan visas:

pg_restore -h <hostname> -U <username> -j <Num of parallel jobs> -Fd -C -d <databasename> sampledb_dir_format

Överväganden för virtuella datorer

Skapa en virtuell dator i samma region och tillgänglighetszon, helst där du har både mål- och källservrar. Du kan också åtminstone skapa den virtuella datorn närmare källservern eller en målserver. Vi rekommenderar att du använder Azure Virtual Machines med en lokal SSD med höga prestanda.

Mer information om SKU:er finns i:

Exempel

Här är några exempel på hur du använder pg_dump och pg_restore med de metodtips som beskrivs ovan.

Använda pg_dump med katalogformat och parallella jobb

pg_dump -h <server>.postgres.database.azure.com -U <username> -d <database> \
  -Fd -j 4 -f /backups/mydb_dump_dir

Förklaring:

  • -Fd: Dumpar i katalogformat, vilket krävs för parallell återställning.
  • -j 4: Använder 4 parallella jobb för att påskynda dumpen.
  • -f: Specificerar utmatningsmappen.

Använda pg_dump utan komprimering för prestanda

pg_dump -h <server>.postgres.database.azure.com -U <username> -d <database> \
  -F c -Z 0 -f /backups/mydb_nocompress.dump

Förklaring:

  • -F c: Anpassat format.
  • -Z 0: Inaktiverar komprimering för att förbättra prestanda.

Använda pg_restore med parallell observation

pg_restore -h <server>.postgres.database.azure.com -U <username> -d <target_database> \
  -Fd -j 4 /backups/mydb_dump_dir

Förklaring:

  • -Fd: Matchar katalogformatet som används i dumpen.
  • -j 4: Använder 4 parallella jobb för att påskynda återställningen.

Relaterat innehåll

  • Last updated on