Share via

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

  • Článek

PLATÍ PRO: Flexibilní server 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.

Compression(-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.

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

Osvědčené postupy pro pg_restore

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 #60min
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:

Další kroky