Vlákno názorů k článku Upgrade databáze z PostgreSQL 9.6 na verzi 13 v doménovém registru od Doda - Prekvapuje me, jak rychle se nacte dump cele...
-
Prekvapuje me, jak rychle se nacte dump cele databaze zpet. Mame na Postgresu informacni system, jeho databaze ma cca jen 20GB a jeji nacteni trva nekolik hodin. Vim ze na to mozna nejde snadno odpovedet, ale nemame vhodny postup, nebo je rychlost dana strukturou dat? Nemame Postgres jen jako uloziste radku, ale obsahuje integritni omezeni, trigery, procedury.... a kontroly toho vseho mozna nacteni zpomaluji. Muze to byt?
-
Určitě bude záležet, jak velké indexy v databázi jsou, zda-li máte plotnové disky nebo SSD a také na míře paralelismu při obnově. Obecně tedy hodně záleží na HW. Produkční servery registru mají vždy 2x Intel Gold procesory nebo ekvivalent v AMD, 128GB RAM a výhradně SSD disky. Ty jsou (v RAID svazcích) používány zvlášť pro “/var/lib/postgres”, zvlášt pro XLOGy a zvlášt pro OS+backupy. Hodně také záleží na tom, abyste dump měli a jiné partišně, než datové soubory databáze.
-
Není to normální - těžko říct, v čem je problém, ale v uložených procedurách a constrainech to nebude. To se aktivuje až nakonec (Postgres důvěřuje svému exportu). Vzpomínám si, že před 15roky 50GB databáze se restorovala 2 hodiny (včetně dumpu).
Co může být problém - buďto málo RAM, pomalé IO, možná používáte GIN indexy, které jsou náročnější na vytvoření. Zkuste restore na jiném železe, případně se podívejte, co vám restore vypisuje a na čem to vázne. 20GB bych čekal do půl hodiny.
-
To musi byt v HW, resp. I/O subsystemem (bud fyzickym nebo SW). To je zaklad rychlosti backup/restore. Nemam zkusenosti s Postgresem, ale napriklad s Oraclem a Informixem a tam je rychlost I/O pro backup/restore klicova (pochopitelne).
Mam napriklad "all flash" diskove pole pripojene k hostu pomoci 16 Gbit fibre channel (SAN), tak mi zaloha 3 TB databaze bezi 1h20min (a to jeste v ramci optimalizace hrnu backup via "pigz -4 -p 16" (paralelni gzip na 16 CPU) a az pak ukladam na disk (jina array nez kde lezi databaze).
Restore takove zalohy pak bezi necele 4h, ale jsem limitovan siti (obnovuje se napr. testovaci instance na jinem serveru, nez kde lezi ten backup z primaru). Takze byt to lokalne, realne budu nekde kolem 3h odhaduji.
V mem vyse uvedem pripade pak dokaze jet I/O subsytem serveru (AIX/Linux) ve vyssi stovkach MB/s, na serveru s NAND flash disky i pres 1 GB/s.
-
Jo, těžko říct bez podrobnějších informací o verzi a konfiguraci Postgresu, hardware, jak přesně se dumpuje/restoruje, atd. Ideální by bylo při tom restore zapnout logování trvání pro všechny přípazy a podívat se na čem to drhne.
Pro srovnání, na "malém" stroji který používám pro testování (4 jádra, 8GB RAM, SSD) trvá načtení 16GB pgbench databáze cca 2 minuty, na větším stroji se 120GB generuje cca 15 minut. Jasně, je to jednoduchá strutura, nejsou tam FK, ale prostě 20GB to musí dát za pár minut, pokud stíhají disky.
-
HW mame odpovidajici, to dneska neni problem poridit, stejne tak (snad) nastaveni. Disky to stihaji bez problemu, mame 3x vice RAM nez je velikost te databaze na disku, takze se pouziva spis jen cache a IO jdou minimlani. Dela to velkou zatez na CPU. Ja necekam presnou odpoved, potrebujeme to ta jednou za rok, coz neni problem. Pravdepodobne je to strukturou databaze, protoze ten informacni system je napsany prakticky cely v tom postgresu a jeho klient je jen "browser". DIky za napady.
-
Bez přístupu k tomu systému, tak vám nikdo nic nemůže říct. Křišťálovou kouli nevedeme. pg_restore má flag --verbose, zkuste ho použít a měřit si, kdy, co vypisuje. Ale tím, že je ten systém napsaný ve storkách to nebude. Ty se načtou během několika málo sec. Na internetu můžete najít kontakt na mne (Pavel Stěhule), a pokud mi umožníte ssh na ten db server, tak vám řeknu, čím to je, ale podle vašeho popisu vůbec netuším, čím by to mohlo být.
ČLÁNKY DO MAILU