Sdílet prostřednictvím

Osvědčené postupy pro pg_dump a pg_restore pro Azure Database for PostgreSQL

Tento článek popisuje možnosti a osvědčené postupy pro urychlení pg_dump a pg_restore. Vysvětluje také nejlepší konfigurace serveru pro provádění pg_restore.

Osvědčené postupy pro pg_dump

Pomocí nástroje pg_dump můžete extrahovat databázi flexibilního serveru Azure Database for PostgreSQL do souboru skriptu nebo archivu. Několik možností příkazového řádku, které můžete použít ke snížení celkové doby výpisu paměti pomocí pg_dump jsou uvedeny v následujících částech.

Formát adresáře (-Fd)

Tato možnost vypíše archiv ve formátu adresáře, který můžete zadat do pg_restore. Ve výchozím nastavení je výstup komprimován.

Paralelní úlohy(-j)

S pg_dump můžete spouštět úlohy výpisu paměti souběžně pomocí možnosti paralelních úloh. Tato možnost snižuje celkovou dobu výpisu paměti, ale zvyšuje zatížení databázového serveru. Doporučujeme, abyste po úzkém monitorování metrik zdrojového serveru, jako jsou využití procesoru, paměti a IOPS (vstupně-výstupní operace za sekundu), přišli na hodnotu paralelní úlohy.

Pokud nastavujete hodnotu pro možnost paralelních úloh, pg_dump vyžaduje následující:

  • Počet připojení se musí shodovat s počtem paralelních úloh +1, proto nezapomeňte nastavit max_connections hodnotu odpovídajícím způsobem.
  • Počet paralelních úloh by měl být menší nebo roven počtu virtuálních procesorů přidělených pro databázový server.

Komprese(-Z0)

Tato možnost určuje úroveň komprese, která se má použít. Nula znamená bez komprese. Nulová komprese během procesu pg_dump by mohla pomoct se zvýšením výkonu.

Vyprázdnění a úklid tabulek

Než začnete s procesem pg_dump, zvažte, jestli je potřeba úklid tabulky. U tabulek se výrazně zvyšuje pg_dump časy. Spuštěním následujícího dotazu identifikujte bloudy tabulky:

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;

Sloupec dead_pct v tomto dotazu je procento mrtvých řazených kolekcí členů ve srovnání s živými řazené kolekcemi členů. Vysoká dead_pct hodnota tabulky může znamenat, že tabulka není správně vysátá. Další informace najdete v tématu Automatické ladění na flexibilním serveru Azure Database for PostgreSQL.

Pro každou tabulku, kterou identifikujete, můžete provést ruční analýzu vakua spuštěním následujícího příkazu:

vacuum(analyze, verbose) <table_name>

Použití serveru obnovení k určitému bodu v čase

Můžete provést pg_dump na online nebo živém serveru. Vytváří konzistentní zálohy i v případě, že se databáze používá. Nezablokuje používání databáze jiným uživatelům. Než začnete s procesem pg_dump, zvažte velikost databáze a další potřeby firmy nebo zákazníka. Malé databáze můžou být vhodnými kandidáty pro provádění pg_dump na produkčním serveru.

U velkých databází můžete vytvořit server obnovení k určitému bodu v čase (PITR) z produkčního serveru a provést proces pg_dump na serveru obnovení k určitému bodu v čase. Spuštění pg_dump v pitru by bylo procesem studeného spuštění. Kompromisem pro tento přístup je, že byste se nezabíjeli s dodatečným využitím procesoru, paměti a vstupně-výstupních operací, které jsou součástí pg_dump procesu, který běží na skutečném produkčním serveru. Můžete spustit pg_dump na serveru obnovení k určitému bodu v čase a po dokončení pg_dump procesu pak server PITR vypustit.

Když zjistíte nízký výkon pg_dump při vysoké šířce pásma sítě, zvažte použití vyššího SKU virtuálních jader. Vyšší konfigurace virtuálních jader (vCore) obvykle poskytují další výpočetní kapacitu a propustnost sítě, což může snížit čas potřebný pro zpracování výpisu dat. Před škálováním monitorujte metriky procesoru, sítě a IOPS a ověřte, jestli je šířka pásma nebo výpočetní výkon kritickým bodem.

Ladění parametrů

Vylaďte následující parametry serveru, které vám pomůžou urychlit vytváření indexů během operací obnovení. pg_dump archivy často zahrnují příkazy pro vytváření indexů (například CREATE INDEX nebo ALTER TABLE ... PŘIDAT OMEZENÍ); zlepšení výkonu sestavení indexu může zkrátit celkovou dobu migrace:

  • maintenance_work_mem = 2097151 (2 GB) – Zvyšte tuto hodnotu, aby se přidělila více paměti pro vytváření indexů a další úlohy údržby. U velkých indexů zvažte zvýšení tohoto nastavení (například stovky megabajtů na více gigabajtů) a před použitím v produkční instanci ověřte využití paměti v neprodukční instanci.
  • max_parallel_maintenance_workers = 4 – Zvyšte tuto hodnotu, abyste umožnili paralelní vytváření indexů na serverech s více virtuálními jádry. Nastavte tuto hodnotu vzhledem k počtu virtuálních jader a otestujte, abyste určili optimální úroveň pro váš pracovní zátěž.

Otestujte všechny změny parametrů nebo skladových položek na neprodukčním serveru nebo serveru PITR. Ověřte výkon a stabilitu a pak proveďte změny v produkčním prostředí. Po dokončení migrace nebo velkých obnovení vraťte parametry k hodnotám, které odpovídají běžným požadavkům na úlohy.

Syntaxe pro pg_dump

Pro pg_dump použijte následující syntaxi:

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

Pomocí nástroje pg_restore můžete obnovit flexibilní serverovou databázi Azure Database for PostgreSQL z archivu vytvořeného pg_dump. Několik možností příkazového řádku pro snížení celkové doby obnovení najdete v následujících částech.

Paralelní obnovení

Použitím více souběžných úloh můžete zkrátit dobu potřebnou k obnovení velké databáze na cílovém serveru s více virtuálními jádry. Počet úloh může být roven nebo menší než počet virtuálních procesorů přidělených cílovému serveru.

Parametry serveru

Pokud obnovujete data na nový server nebo neprodukční server, můžete před spuštěním pg_restore optimalizovat následující parametry serveru:

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

Po dokončení obnovení se ujistěte, že se všechny tyto parametry odpovídajícím způsobem aktualizují podle požadavků na úlohy.

Poznámka:

Postupujte podle předchozích doporučení jenom v případě, že je dostatek paměti a místa na disku. Pokud máte malý server s 2, 4 nebo 8 virtuálními jádry, nastavte parametry odpovídajícím způsobem.

Ostatní úvahy

  • Před spuštěním pg_restore zakažte vysokou dostupnost (HA).
  • Analyzujte všechny tabulky, které se migrují po dokončení obnovení.

Syntaxe pro pg_restore

Pro pg_restore použijte následující syntaxi:

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

  • -Fd: Formát adresáře.
  • -j: Počet úloh.
  • -C: Spusťte výstup příkazem pro vytvoření samotné databáze a pak se k ní znovu připojte.

Tady je příklad, jak se tato syntaxe může zobrazit:

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

Důležité informace o virtuálních počítačích

Vytvořte virtuální počítač ve stejné oblasti a zóně dostupnosti, nejlépe tam, kde máte cílový i zdrojový server. Nebo alespoň vytvořte virtuální počítač blíže ke zdrojovému serveru nebo cílovému serveru. Doporučujeme používat Azure Virtual Machines s vysoce výkonným místním SSD.

Další informace o skladových posílaných posílacích najdete tady:

Příklady

Tady je několik příkladů použití pg_dump a pg_restore osvědčených postupů probíraných výše.

Použití pg_dump s formátem adresáře a paralelními úlohami

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

Vysvětlení:

  • -Fd: Výpisy paměti ve formátu adresáře, který je nutný pro paralelní obnovení.
  • -j 4: K urychlení výpisu paměti se používá 4 paralelní úlohy.
  • -f: Určuje výstupní adresář.

Použití pg_dump bez komprese pro výkon

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

Vysvětlení:

  • -F c: Vlastní formát.
  • -Z 0: Zakáže kompresi, aby se zlepšil výkon.

Použití pg_restore s paralelními pozorováními

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

Vysvětlení:

  • -Fd: Odpovídá formátu adresáře použitému ve výpisu.
  • -j 4: K urychlení obnovení se používá 4 paralelní úlohy.

Související obsah

  • Last updated on