Zalohovaci software - testovanie

[Pavel Kankovsky]

On Fri, 23 Jul 2004, Michal Kubecek wrote:

> Pokud to chápete takto, pak do té popelnice patří naprostá většina
> databázových systémů a také poměrně značná část filesystémů.

Nekdy holt ty cisarovy nove saty opravdu nestoji za nic...

> Na zabezpečení proti takovým mimořádným situacím jsou určeny úplně
> jiné nástroje - třeba replikace. Transakce k tomu neslouží a ani
> s takovým cílem nebyly navrženy.

Nezamenujte replikace a distribuovane transakce (i kdyz distribuovana
transakce muze byt chapana jako specificka *synchronni* replikace).

(Jinak samozrejme distribuovane transakce jsou dalsi "plechovka cervu",
uz jenom z toho duvodu, ze je principialne vylouceno spolehlive dosazeni
distribuovaneho konsensu v pripade preruseni komunikace, coz sam
zarazujete do kategorie "standarnich vypadku".)


On Fri, 23 Jul 2004, Michal Kubecek wrote:

> A právě z tohoto popisu vyplývá i to, co jsem se snažil naznačit hned ve
> svém úvodním příspěvku, který celou tuto větev rozpoutal. Protože
> zanesení jedné transakce znamená větší počet různých diskových operací,
> není problém jen v tom, že klasický zálohovací software zpracovává
> soubor(y) postupně. Protože i kdyby byl filesystém+zálohovač schopen
> udělat okamžitý snapshot, může se s ním stejně trefit do okamžiku mezi
> ty dva zápisy. A pak dostane nekonzistentní mezistav.

Ale v tom neni zasadni problem, protoze rozumne navrzeny db system
s transakcemi nejdriv zapisuje zmeny do redo logu a z nej to teprve po
commitu opise do "hlavniho souboru" (pripadne vice souboru). A nakonec
transakci v redo logu oznaci jako dokoncenou.

Cili po opetovnem startu nastanou dve mozne nekonzistence:
- transakce v redo logu neni uplna => zrusi se (rollback)
- transakce v redo logu je uplna, ale nebyl dokoncen commit =>
  zjistim, ktere zmeny byly provedene a ktere ne, a ty chybejici
  provedu (idealni je, kdyz jsou do redo logu zaznamenavany idempotentni
  operace, protoze pak staci commit spustit znovu od zacatku)

V obou pripadech je vysledkem konzistentni db.

Ony ty transakce lze delat i jinak, treba undo logem, ale to je mnohem
mene odolne proti poskozeni a nevim o tom, ze by to melo nejake zasadni
vyhody podle jinych kriterii.

> Jediné, co by mohlo v tomto případě pomoci, by byla realizace jakési
> analogie transakcí na úrovni filesystému, tedy něčeho jako start(),
> commit() a rollback() ve vztahu k filesystému. Přiznám se, že nevím,
> jestli vůbec nějaké OS a filesystémy něco takového nabízejí. Ale jsem si
> jistý, že to není standardní součást běžných systémů.

Bezne filesystemy maji jiste transakcni vlastnosti. Napr. vsechny operace
nad metadaty by mely byt atomicke a serializovatelne (a pochopitelne
zachovavat prislusna integritni omezeni na strukturu fs). Specialne je
zajimavy syscall rename(), s jehoz pomoci (pripadne v kombinaci
s fsync() nebo neco podobnym, pokud jsou zapisy metadat asynchronni) lze
implementovat "levny" commit. Atomicke a serializovatelne jsou take velmi
kratke zapisy do souboru (obvykle lze predpokladat, ze jsou to zapisy do
useku v ramci jednoho bloku, u jednobajtovych useku je to sichr).

Filesystem, ktery by transakce implementoval "nativne" by byla mimochodem
velmi uzitecna vec, protoze by to prirozene resilo takove potize, jako ze
se treba instaluje nova verze sw, nejak se to v pulce nepovede a co ted?


On Fri, 23 Jul 2004, Michal Kubecek wrote:

> Vůbec ne. Ale problém je, že sama operace zápisu transakce na disk
> nemusí být atomická z pohledu nižších vrstev systému. Navíc, jak už
> podotkli jiní, mnohé systémy nenabízejí dostatečně spolehlivé nástroje
> k tomu, aby mohl program zajistit, že data, která se rozhodl zapsat na
> disk, tam opravdu budou.

Pokud na obvyklem unixovem systemu fsync() nezaridi zapis na disk (resp.
nepodnikne jine kroky redukujici riziko ztraty zapisovanych dat na
zanedbatelnou uroven), pak to lze chapat jako podraz ze strany OS nebo
HW. To, aby db stroj resil podrazy ze strany nizsich vrstev, to urcite
nikdo nepozaduje.


On Fri, 23 Jul 2004, Michal Kubecek wrote:

> Zdvojení nepomůže - už v minulém příspěvku jsem psal, že to zpomalení
> bylo více než o řád, i u naprosto běžných operací typu jednoduchého
> 'update T1 set C1=C1*1.1' to byly 3 sekundy versus 90 sekund. Proto je
> v takovém případě podle mne vhodnější paranoidní politiku nezapínat a
> raději provést replikaci na další dva servery - je to levnější,
> rychlejší a přinejmenším stejně spolehlivé.

To bylo tedy asi naprogramovano pekne idiotsky. Bohate postacuje:

1. zapis novych dat do redo logu, fsync(),
2. zapis znacky oznacujici konec transakce, fsync()
3. zapis novych dat do hlavniho souboru (ci hlavnich souboru), fsync()
4. vyrazeni transakce z redo logu, fsync()

To mame zhruba dvojnasobne zpomaleni kvuli dvojimu zapisu (pripadne i
cteni) + nekolikero cekani, nez se to zapise na disk. Odhadem bude delat
(u jedne vetsi transakce, kde se fsync-y amortizuji) ze 3 sekund tak 7,
max. 10. Rozhodne ne 90.

Navic body 1 a 2 lze sloucit dohromady, pokud napr. umistim do znacky
konce transakce dostatecne dlouhy kontrolni soucet ostatnich dat, ktery mi
s dostatecne velkou pravdepodobnosti umozni behem recovery rozpoznat, zda
se zapis provedl cely, nebo ne. Navic to ma vyhodu, ze to detekuje i
situace, kdy dojde k poskozeni vnitrku redo logu (napr. se nabori
filesystem).


On Mon, 26 Jul 2004, Chlopcik Ales wrote:

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

Vyse je popsano, proc by to pri rozumnem navrhu nemelo vadit. Soubory sice
muzou byt nekonzistentni, ale existuje jednoduchy a spolehlivy zpusob, jak
jejich nekonzistenci behem startu db detekovat a opravit.

> 	Opakuju. Pokud _jsou_/_funguji_/_vyhovuji_mi_ databazove
> prostredky pro zalohovani, pak je pouzivam. Pokud ne, pouzivam
> systemove, ale zastavuji SRDB.

Ja nerikam, aby lidi delali prvoplanove zalohovani nejakym divokym
zpusobem. Ja se jen snazim vysvetlit, ze db stroj, co nerozchodi
obnovu ze snapshotu, je nejspis pekny smejd, protoze je v nem neco
shnileho.


On Sat, 24 Jul 2004, Chlopcik Ales wrote:

> > > (sance se sice zvysi /klonovani je kratsi nez cteni/, [...]

> 	Znate AdvFS ? Pak mi prosim reknete, v cem odflaknuty (treba jen
> jeho CLONE), nebot jej jiz nekolikero let uzivam a rad bych se
> dozvedel, co delam spatne.

AdvFS znam, ale moc zkusenosti s nim nemam. Ovsem byl jste to Vy, kdo
naznacoval, ze klonovany volume neni read consistent (viz vyse citovanou
vetu) -- coz, je-li to pravda, bych povazoval za peknou fuserinu.


On Mon, 26 Jul 2004, Ing. Pavel PaJaSoft Janoušek wrote:

> Mozna Vam to uniklo, ale jsou databaze, ktere pro optimalni beh
> nepouzivani nic jako system souboru v tradicnim podani, ale proste
> "prostor na disku" - podobne jako alokovana pamet (treba partition) a
> zcela ve vlastni rezii vse resi (co treba RAW zarizeni a Oracle?) -

Poznamka na okraj: Zajimave je, ze jsem jeste v terenu nepotkal Oracle,
ktery by byl provozovany na raw devices. (A ze jsem jich uz par videl.)


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."