Metodtips för pg_dump och pg_restore för Azure Database for PostgreSQL – flexibel server
GÄLLER FÖR: 
Azure Database for PostgreSQL – flexibel server
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 Autovacuum tuning in Azure Database for 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.
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
Metodtips för pg_restore
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: