Delen via

Aanbevolen procedures voor pg_dump en pg_restore voor Azure Database for PostgreSQL

In dit artikel worden opties en aanbevolen procedures besproken voor het versnellen van pg_dump en pg_restore. Ook worden de beste serverconfiguraties voor het uitvoeren van pg_restore uitgelegd.

Aanbevolen procedures voor pg_dump

U kunt het hulpprogramma pg_dump gebruiken om een flexibele Azure Database for PostgreSQL-serverdatabase te extraheren in een scriptbestand of archiefbestand. Enkele van de opdrachtregelopties die u kunt gebruiken om de totale dumptijd te verminderen met behulp van pg_dump worden vermeld in de volgende secties.

Mapindeling (-Fd)

Met deze optie wordt een archief met mapindeling uitgevoerd dat u kunt invoeren voor pg_restore. Standaard wordt de uitvoer gecomprimeerd.

Parallelle taken (-j)

Met pg_dump kunt u dumptaken gelijktijdig uitvoeren met behulp van de optie parallelle taken. Deze optie vermindert de totale dumptijd, maar verhoogt de belasting op de databaseserver. We raden u aan om bij een parallelle taakwaarde te komen nadat u de metrische gegevens van de bronserver, zoals CPU, geheugen en IOPS-gebruik (invoer-/uitvoerbewerkingen per seconde), nauwkeurig hebt gecontroleerd.

Wanneer u een waarde instelt voor de optie parallelle taken, hebt pg_dump het volgende nodig:

  • Het aantal verbindingen moet gelijk zijn aan het aantal parallelle taken +1, dus zorg ervoor dat u de max_connections waarde dienovereenkomstig instelt.
  • Het aantal parallelle taken moet kleiner zijn dan of gelijk zijn aan het aantal vCPU's dat is toegewezen voor de databaseserver.

Compressie (-Z0)

Met deze optie geeft u het compressieniveau op dat moet worden gebruikt. Nul betekent geen compressie. Nulcompressie tijdens het pg_dump proces kan helpen bij prestatieverbeteringen.

Tabelbloats en vacuüm

Voordat u het pg_dump-proces start, moet u overwegen of tabelvacuüming nodig is. Bloat op tabellen neemt aanzienlijk toe pg_dump tijden. Voer de volgende query uit om tabelbloats te identificeren:

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;

De dead_pct kolom in deze query is het percentage dode tuples in vergelijking met live tuples. Een hoge dead_pct waarde voor een tabel kan erop wijzen dat de tabel niet goed wordt leeggezogen. Voor meer informatie, zie Autovacuum tuning in Azure Database voor PostgreSQL flexibele server.

Voor elke tabel die u identificeert, kunt u een handmatige vacuümanalyse uitvoeren door het volgende uit te voeren:

vacuum(analyze, verbose) <table_name>

Een PITR-server gebruiken

U kunt een pg_dump uitvoeren op een online- of liveserver. Het maakt consistente back-ups, zelfs als de database wordt gebruikt. Het blokkeert niet dat andere gebruikers de database gebruiken. Houd rekening met de grootte van de database en andere zakelijke of klantbehoeften voordat u het pg_dump proces start. Kleine databases kunnen goede kandidaten zijn voor het uitvoeren van een pg_dump op de productieserver.

Voor grote databases kunt u een herstelserver (point-in-time) maken vanaf de productieserver en het pg_dump proces uitvoeren op de PITR-server. Het uitvoeren van pg_dump op een PITR zou een cold run-proces zijn. De afweging voor deze aanpak is dat u zich geen zorgen hoeft te maken over extra CPU-, geheugen- en IO-gebruik dat wordt geleverd met een pg_dump proces dat wordt uitgevoerd op een werkelijke productieserver. U kunt pg_dump uitvoeren op een PITR-server en vervolgens de PITR-server verwijderen nadat het pg_dump proces is voltooid.

Wanneer u trage pg_dump prestaties ziet terwijl de netwerkbandbreedte hoog is, kunt u overwegen een hogere vCore-SKU te gebruiken. Hogere vCore-SKU's bieden doorgaans extra CPU- en netwerkdoorvoer, wat de totale dumptijd kan verminderen. Bewaak metrische gegevens over CPU, netwerk en IOPS om te controleren of bandbreedte of berekening het knelpunt is voordat u schaalt.

Parameterafstemming

Stem de volgende serverparameters af om het maken van indexen tijdens herstelbewerkingen te versnellen. pg_dump archieven bevatten vaak opdrachten voor het maken van indexen (bijvoorbeeld CREATE INDEX of ALTER TABLE... BEPERKING TOEVOEGEN); het verbeteren van de prestaties van indexbuild kan de totale migratietijd verkorten:

  • maintenance_work_mem = 2097151 (2 GB): verhoog deze waarde om meer geheugen toe te wijzen voor het maken van indexen en andere onderhoudstaken. Voor grote indexen kunt u deze instelling verhogen (bijvoorbeeld honderden megabytes naar meerdere gigabytes) en het geheugengebruik op een niet-productie-exemplaar valideren voordat u deze in productie toepast.
  • max_parallel_maintenance_workers = 4 — Verhoog deze waarde zodat parallelle index kan worden gemaakt op multi-vCore-servers. Stel dit in ten opzichte van het aantal vCores en test om het optimale niveau voor uw workload te bepalen.

Test eventuele parameter- of SKU-wijzigingen op een niet-productie- of PITR-server. Valideer de prestaties en stabiliteit en pas vervolgens de wijzigingen toe op de productie. Nadat de migratie of grote herstelbewerkingen zijn voltooid, kunt u parameters herstellen naar waarden die voldoen aan de normale workloadvereisten.

Syntaxis voor pg_dump

Gebruik de volgende syntaxis voor pg_dump:

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

U kunt het hulpprogramma pg_restore gebruiken om een flexibele Azure Database for PostgreSQL-serverdatabase te herstellen vanuit een archief dat is gemaakt door pg_dump. Een aantal opdrachtregelopties voor het verminderen van de totale hersteltijd worden weergegeven in de volgende secties.

Parallel herstellen

Door meerdere gelijktijdige taken te gebruiken, kunt u de tijd beperken die nodig is om een grote database op een multi-vCore-doelserver te herstellen. Het aantal taken kan gelijk zijn aan of kleiner zijn dan het aantal vCPU's dat is toegewezen voor de doelserver.

Serverparameters

Als u gegevens herstelt naar een nieuwe server of niet-productieserver, kunt u de volgende serverparameters optimaliseren voordat u pg_restore uitvoert:

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

Nadat het herstellen is voltooid, moet u ervoor zorgen dat al deze parameters op de juiste wijze worden bijgewerkt volgens de vereisten van de workload.

Notitie

Volg de voorgaande aanbevelingen alleen als er voldoende geheugen en schijfruimte beschikbaar zijn. Als u een kleine server met 2, 4 of 8 vCores hebt, stelt u de parameters dienovereenkomstig in.

Andere overwegingen

  • Schakel hoge beschikbaarheid (HA) uit voordat u pg_restore uitvoert.
  • Analyseer alle tabellen die worden gemigreerd nadat het herstellen is voltooid.

Syntaxis voor pg_restore

Gebruik de volgende syntaxis voor pg_restore:

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

  • -Fd: De mapindeling.
  • -j: Het aantal taken.
  • -C: Begin de uitvoer met een opdracht om de database zelf te maken en maak vervolgens opnieuw verbinding met de database.

Hier volgt een voorbeeld van hoe deze syntaxis kan worden weergegeven:

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

Overwegingen voor virtuele machines

Maak een virtuele machine in dezelfde regio en beschikbaarheidszone, bij voorkeur waar u zowel uw doelservers als bronservers hebt. Of maak minimaal de virtuele machine dichter bij de bronserver of een doelserver. U wordt aangeraden Azure Virtual Machines te gebruiken met een lokale SSD met hoge prestaties.

Zie voor meer informatie over de SKU's:

Voorbeelden

Hier volgen enkele voorbeelden van het gebruik van pg_dump en pg_restore met de beste praktijken die hierboven zijn besproken.

Gebruiken pg_dump met mapindeling en parallelle taken

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

Uitleg:

  • -Fd: Dumps in mapindeling, die vereist is voor parallelle herstelbewerking.
  • -j 4: maakt gebruik van vier parallelle taken om de dump te versnellen.
  • -f: Specificeert de uitvoermap.

Zonder pg_dump compressie gebruiken voor prestaties

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

Uitleg:

  • -F c: Aangepaste indeling.
  • -Z 0: schakelt compressie uit om de prestaties te verbeteren.

Gebruik van pg_restore met parallelle obs

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

Uitleg:

  • -Fd: komt overeen met de mapindeling die wordt gebruikt in de dump.
  • -j 4: maakt gebruik van vier parallelle taken om de herstelbewerking te versnellen.

Gerelateerde inhoud