Zalohovaci software - testovanie

[Michal Kubecek]

On Fri, Jul 23, 2004 at 01:58:14PM +0200, Pavel Kankovsky wrote:
> 
> Treba to, ze transakce jsou charakterizovany 4 vlastnostmi souhrne
> oznacovanymi zkratkou ACID? Tedy Atomicity, Consistency, Isolation,
> Durability.

Třeba to. Ale také to, že transakce jsou záležitostí komunikace mezi
databázovým serverem a jeho klienty (v některých případech je tím
klientem databázový server sám). Nemají žádný vztah k tomu, co se děje
mezi databázovým serverem a filesystémem.

> >   V žádném případě není pravdou, že vás transakce ochrání před ztrátou
> >   dat nebo poškozením databáze, ať už v případě selhání serveru či
> >   klientské aplikace, nebo při kolapsu hardwaru.
> 
> Absolutne jiste ne (pokud do selhani klientske aplikace zahrneme i
> moznost, ze svevolne vygeneruje prikazy, ktere budou z hlediska serveru
> opravnene a nebudou *technicky* porusovat integritni omezeni).

Přesně tak. Pokud klient provede dvě části atomické operace pod dvěma
samostatnými transakcemi, server nepozná, že je to chyba. Použije-li
klient úroveň izolace "read uncommitted", nemůže se divit, že uvidí
databázi v nekonzistentním stavu. A tak by se dalo pokračovat.

Ale důležitější tady je, že transakce nebyly nikdy zamýšleny jako
prostředek proti problémům _pod_ databází. A proto nelze považovat za
jejich chybu, pokud nás nechrání před takovými problémy. Stejně jako
nebudu považovat za chybu procesoru, že mne jeho systém ochran paměti
nechrání před vadou paměťového čipu.

> Ale nepovazuji za zodpovedne rezignovat na vyreseni 99 % situaci, kdy
> to vyresit lze, jenom proto, ze je zde 1 % takovych, ktere software
> z principu nedokaze osetrit (ovsem z nich jeste v dalsich 99 % pripadu
> lze aspon vznikly problem spolehlive detekovat).

Nikdo ale netvrdil, že se tak má postupovat. Ono to také v těch 99
procentech případů funguje. Ale je dobré vědět, že pořád je tady to
jedno procento. Někdy je sice možné tu spolehlivost zvednout ze dvou
devítek na čtyři - ale už jsem viděl na vlastní oči situaci, kdy zapnutí
takové featury (maximální garance, že on-disk databáze přežije i výpadek
napájení) způsobilo u některých operací zpomalení na třicetinu.

Výpadky napájení (nebo jejich ekvivalenty) u systémů s UPS nepřicházejí
rozhodně tak často, aby pravděpodobnost těch velkých průšvihů byla
příliš velká. A tam, kde opravdu potřebuji takovou míru spolehlivosti,
bude pořád výrazně levnější zdvojit klíčové komponenty (včetně zdroje a
té UPS) než paranoidní politikou zápisu na disk řádově zpomalit běh
aplikace a dohánět to nákupy hardware, který by to utáhl.

> >   Účelem transakčního zpracování je totiž pouze zabezpečit konzistenci
> >   dat, nic více a nic méně.
> 
> A ztrata dat ci poskozeni db neni naruseni konzistence dat?
> (Nemluve o tom, ze to je to v rozporu s D ve vyse uvedenem ACID.)

Jak už jsem napsal výše: všechna ta čtyři písmenka se týkají toho, jak
to funguje směrem ven. Ne toho, jak databáze komunikuje s nižšími
vrstvami.

> Mimochodem, jak by se Vam libil filesystem, ktery by se musel kompletne
> obnovit ze zalohy pokazde, kdyz by operacni system padnul na drzku (at uz
> z jakehokoli duvodu)? Udrzeni konzistence fs a udrzeni konzistence
> databaze je koneckoncu uplne ten samy problem!

Vy jste snad viděl, že bych napsal něco takového, jako že ta databáze
bude _vždy_ ve zcela nepoužitelném stavu? Já si ničeho takového nevšiml.
Napsal jsem pouze, že vám nikdo negarantuje, že ta databáze bude zcela
konzistentní. A na tom trvám. Je možné (a pravděpodobné), že půjde více
či méně snadno opravit. Ale ani to není úplně zaručeno. Co se týká
analogie s filesystémy, co třeba filesystém, který je po násilném pádu
systému (výpadku napájení) potřeba zkontrolovat a případně opravit
příkazem fsck? Vážně jste takový ještě neviděl?

							  Michal Kubeček