Dotaz: Oprava pozkozene PostgreSQL database

[Radim Kolář]

po havarii filesystemu doslo k poskozeni postgresql database. V adresari kde se normalne nachazeji data postgresu existuji jen podadresare:

base  pg_clog pg_multixact    pg_xlog

Tedy schazi predevsim podadresar global a pg_twophase. neexistujici twophase asi nevadi, aplikace nikdy 2pc nepouzivala.

Je nejaka moznost jak se dostat k ulozenym datum? Zkousel jsem prekopirovat global z jine instalace pgsql nefungovalo to. Je potreba pouzit pg_resetxlog?

Odpovědi

[okbob]

global obsahuje data k sdilenym tabulkam - napr. pg_database, pg_tablespace a dalsi. Tudiz kopirovani z jine database tezko muze fungovat - i kdyby byl zhruba stejny obsah, tak tezko budou tabulky drzet identifikatory - tady by pomohla asi jenom zaloha. 

Pokud máte verzi do 8.2 můžete zkusit http://svana.org/kleptog/pgsql/pgfsck.html abyste se dostal k datům.

Pavel Stěhule

[Radim Kolář]

 

Otazka je, co vsechno je ulozene v adresari globals. Pgfsck mi nefunguje a autor mi napsal ze:

Tricky, the global contains all information about databases, users and
tablespaces.

Definice uzivatelu muzu s klidnym srdcem ozelet - na vlastniku objektu mi nezalezi stejne tak na pristupovych pravech, definice tablespaces take (zadne nebyly pouzity), a pak je tam mapa OID -> database name v global/pg_database coz je textovy soubor vyhlizejici jako:

 

"template1" 1 1663 524
"template0" 10818 1663 524
 

Tedy nic vyznamneho se vlastne neztratilo, asi jediny problem bude obsah souboru global/pg_control ktery ma za nasledek to, ze se databaze v pgsql neotevre.

[misch]

Nepomohlo by jít na to z druhé strany? Tzn. vytvořit si někde bokem novou prázdnou instalaci (initdb ...), a v ní jednu databázi (tím pádem tam bude existovat kromě funkčního adresáře "global" i adresář "base" s touhle jedinou databází). Pak ten nový pomocný PostgreSQL ukončit, adresář base/xyz promazat a zkopírovat do něj jednu z těch vadných databází, a zkusit jestli se k ní pak PostgreSQL bude hlásit?

[okbob]

Teoreticky by to slo, ale jinak. Vytvorit si globals, a pak do clusteru nakopirovat na odpovidajici misto datove soubory - ktere bude 100% nutne prejmenovat. Pokud aplikace pouziva pouze vestavene datove typy, tak by to mohlo projit.

[Hlípa]

Pokud jsou zachovany adresare clog a base, tak by global mel jit zrekonstruovat, alespon k tomu, aby se dal provest dump. Defakto neco podobneho se dela pri upgradu databaze pomoci pg_migratoru. Datove typy nejsou problem, neb ty jsou uchovany v base. Misto prejmenovani souboru, je mozna lepsi provest update tech rekordu v databazi. Komplikace by mohlo zpusobit nastaveni veci pro vacuum, ale pro dump to neni nutne.

[Radim Kolář]

ten pgfsck ma jeste hodne chyb, zdaleka jeste neni vhodny pro realne nasazeni. Pokusy s nim dopadly dost blede. vydumpoval mi uspesne jenom par tabulek; tezko rici zda alespon kompletne. U nekterych databazi si neskrtl vubec.

Kdyz se do toho scriptu zadratuje napevno OID databaze (jak autor poradil) tak umi pracovat i bez adresare global.

[okbob]

Jakou používáte verzi PostgreSQL?

[Radim Kolář]

8.2

[okbob]

To by jeste melo zvladnout. Je ovsem otazkou, zda-li nebyly naboreny i datove soubory.

[Radim Kolář]

On je to hroznej soft. Ted jsem ho spustil na db, kterou jsem uspesne naimportoval ze zalohy a dava hlasky jako:

-- Table sql_packages(10752):Page 0:Tuple 6: Unknown type character_data (10637)

-- Table pg_class(1259):Page 3:Tuple 19: Unknown type xid (28)

a nevydumpne prakticky zadna data. Na tom softu se musi opravdu jeste hodne zapracovat aby byl alespon trochu pouzitelny. Navic je to v Perlu, kdyby to bylo alespon v nejakem rozumnejsim/citelnejsim jazyku, tak bych se byl ochoten s tim zabyvat a pripadne ho opravit. Perl mi nestoji za tu (neplacenou) namahu.

Mate pravdu v tom ze investovat do podobneho nastroje nema asi moc smysl, protoze kolik je lidi vubec ochotno platit za recovery pgsql databaze. Mohlo by mozna neco byt ve standardni instalaci pgsql, kdyby to uzivatele nejak vice potrebovali. Treba db2 ma nastroj pro dumpovani dat z poskozenych tablic v zakladni instalaci.

[okbob]

Evidentně se mu dlouho nikdo nevěnoval - tohle jsou pravděpodobně nové věci z 8.2. Problém s takovým softem je ten, že musí obsahovat kompletní slovník dané verze (jelikož běží bez databáze). Tady nejde o opravu jako spíš o doplnění. Z 8.2 to nepodporuje plnou množinu datových typů.

Kdyby někdo takový sw psal a udržoval, tak proč ne. Aktuálně to může existovat jen jako školní práce. Technicky by to neměl být problém - všechny informace jsou k dispozici, včetně kódu implementace datových typů a čtení datových stránek. V podstatě jde o low level sekvenční čtení datového souboru. Dovedu si představit hack do postgresu, který umožní přípojení externího datového souboru s externím popisem struktury třeba v txt formátu. Ale to je minimálně týden hackingu, pro někoho, kdo ví, co dělá - a dva pro laika. Ale i kdyby to někdo napsal, tak to zálohu nenahradí - pg nemá kontrolní součty na stránkách, takže se nepozná, jestli daná stránka byla nabořena nebo nikoliv - a jelikož nebylo provedeno recovery, tak data v tabulce mohou být nekonzistentní. A nesmí se zapomínat na MVCC - bez transakčního logu se nedá poznat, která transakce byla potvrzena a která nikoliv, takže se v dumpu exaktně nepoznají aktivní a mrtvé záznamy.

Je to v podstatě neřešitelné - ti, co mají prostředky a znalosti, na vytvoření tohoto sw, tak ti vědí co a jak zálohovat, a těm ostatním buďto chybí znalosti nebo prostředky případně obojí.

[Radim Kolář]

Tak jsem se nakonec na to vybodnul, nenasel jsem nikoho kdo by to umel a komu by se to chtelo do 2k EUR udelat. To jsou nevyhody OSS databazi, moc lidi to komercne nedela a ti co prodavaji support delaji jen zakladni veci. Kdyby to byl Oracle tak tam se obnova ponicenych databazi bezne dela.

Ze vsech databazi co zarvaly opravdu dulezite byly jen dve. Jedna zaloha byla z prosince 2007 (mene dulezita db, vicemene archivovana data) a druha z 1. kvetna 2009 (kdyz delali upgrade). Oni zalohovali sice poctive ale jen filesystem s /home a instalaci unixu nikoliv vlastni data v databazich, asi nevedeli ze se mohou take ponicit. Zalohy databazi meli jen kdyz jim nekdo delal upgrade, tak to pred nim zazalohoval.

Obe dve jsem jim obnovil ze zaloh, to pg_restore to je ale pekne pomaly obnovovalo tak 2GB/hodinu.

[okbob]

Za 2K euro bych se i pokusil fixnout pgfsck. A třeba by to to něco zachránilo. Za 200e bych zkusil jednodenní rekonstrukci chybějících souborů.

U PostgreSQL se nestává, že by někdo přicházel o data - tudíž se nevyplatí investovat do vývoje sw :(. Prostě to není na uživení - Oracle je něco jiného - tam se donedávna nediskutovalo o nákladech - podniky byli dojná kráva. Za pět let, co dělám v ČR veřejně s PostgreSQL jsem osobně fixoval db jenom jednou a jednou radil po telefonu. A stejně nevíte - při poruše file systému, jestli data jsou konzistentní nebo nikoliv - v tom zálohu nic nezastoupí.

Restore se dá urychlit - chová se dle konfigurace - měl byste se dostat na cca 30GB/h (záleží na velikosti operační paměti a rychlosti disku). S dvěma GB bych se podíval na konfiguraci db a systému.

po dobu restore na 8.2

fsync = off
maintenance_work_mem=alespon 256MB (pokud mel server alespon 512MB)

Po dokonceni restore fsync=on, a m_w_m na optimum pro provoz

[Hlípa]

pg_restore z verze 8.4 umi cpat data paralelne, takze obnova je pak rychlejsi. Mel by to jit pouzit i na starsi verze.