Zalohovaci software - testovanie

[Chlopcik Ales]

Jan Houstek wrote:
> 
> On Sat, 24 Jul 2004, Chlopcik Ales wrote:
> 
> >       Jelikoz se IMHO jiz jen snazime _zlomit_ p. P.Kankovskeho, navrhuji
> > HOWGH. Mozna se diky jeho oponenture (advocatus diaboli :-) podarilo
> > celemu svetu vysvetlit, jak spravne zalohovat bazi, k cemu jsou
> > transakce, atd. ale myslim ze uz stacilo.
> 
> Pavel se vam jen snazi vysvetlit, ze pokud ty transakce jsou ACID, pak se
> musi byt schopna databaze vzpamatovat z konzistentniho snapshotu (napr.
> takoveho, jak ho dela LVM) i v pripade, ze byl proveden za behu SRDB.
> 
> Ten snapshot je totiz konzistentni v tom, ze obsahuje stav tech souboru k
> nejakemu konkretnimu casovemu okamziku (mysleno tak, ze vsechny operace
> provedene pred timto okamzikem v nem jsou promitnuty a vsechny provedene
> po nem nejsou).

	Ne, neni. V souboru je (muze byt => je) zapsana cast transakce (treba
sekvencni cisla) PO, ale dalsi data PRED transakci cislo 1234. Neboli :
V souboru je (diky trefe MEZI zapisy teze transakce) zapsana pouze cast
transakce => soubor(y) NENI konzistentni. Pokud BEHEM vytvareni snapsotu
neni ZAJISTENA konzistentnost souboru, pak je nejista. V tom je totiz
jadro cokla, na kterem se nemuzeme shodnout. Ja tvrdim, ze transakce
vyvolava VICE nez jeden zapis do databazovych souboru => jsem schopen se
pri vytvareni klonu/kopie/... trefit mezi dva zapisy teze transakce.
Samozrejme, ze u MultiFile databazi je tato pravdepodobnost vyssi.

> 
> Pokud se trefim doprostred transakce, tak by to po spusteni mel SRDB
> poznat a tu nedokoncenou transakci odrolovat.

	A to je prave TO, co si nemyslim. Nebudu citovat nejake ucebice ani
ISO/IEE/CCITT ci NevimJake normy (stejne je neznam :-), IMHO transakce
byla, je (a IMHO i bude) definovana POUZE mezi klientem a SRDB. Rozhodne
ne mezi SRDB a OS/FS.
	Respektive : Pokud bude SRDB pri kazdem restartu (nebo NedejBoze pri
kazdem cteni dat z disku :-) proverovat konzistentnost nactenych (svych
vlastnich :-) dat, pak TO bude mit dost tristni nasledky na jeji
vykonnost. Pokud SRDB nebude moci verit uz ani svym vlastnim datum
(nebot zalohovani jinymi nez databazovymi prostredky se u
komercnich/vestich/lepsich/.... SRDB asi /IMHO/ nepredpoklada), pak se
dostavame do dosti divokych oblasti.
	Netvrdim, ze kontrolu konzistentnosti pri startu zadne SRDB nedela, ale
mam zkusenost (nastesi jen zprostredkovanou, ale z duveryhodneho zdroje
:-), ze konkretne Informix (verzi neznam, cca 10 let) obnovu z
NevimJakUdelaneZalohy nerozdychal. Takze se toho chopili TeoReTici a
vydali zaver, jehoz dusledky zde prezentuju.
	Opakuju. Pokud _jsou_/_funguji_/_vyhovuji_mi_ databazove prostredky pro
zalohovani, pak je pouzivam. Pokud ne, pouzivam systemove, ale zastavuji
SRDB.

> 
> Pri rutinnim zalohovani je asi vhodne SRDB pred provedenim snapshotu
> zamrazit na aplikacni urovni (nebo rovnou vypnout), do neprustrelneho skla
> se taky nestrili kazdy den. Nicmene nic to nemeni na faktu, ze by to ta
> databaze mela rozchodit (stejne jako sklo tu strelu).

	SRDB je pro mne priliz komplikovany system (a data v nem prilis cenna),
nez abych riskoval. Takze pouzivam overenou cestu.Jestlize je NECO
teoreticky mozne, pricem tomu lze praktickymi kroky predejit, pak
nezkousim pravdepodobnost vyskytu, ale roznou kracim ke 100 proc.
jistote.

> 
> Schvalne jsem vyzkousel spustit soucasne 100 klientu, kteri s vyzitim
> transakci zapisovali do postgresu (verze 7.4.2) a delal jsem snapshoty nad
> tou datovou partition. Zkousel jsem to 20x, pokazde se z toho postgres
> vzpamatoval a podle vseho ta databaze zustala konzistentni.
> 
> Zkusim tu testovaci aplikaci preportovat jeste na MySQL a Firebird,
> uvidime.
> 
> -- Honza Houstek
>