Zalohovaci software - testovanie

[Karel Zak]

On Sat, Jul 24, 2004 at 06:09:47AM +0200, Chlopcik Ales wrote:
> Bez zastavovani je TO loterie (v nekterych firmach i ruska ruleta), se
> zastavenim je TO jistota. Zastavenim SRDB dostanu soubory do
> konzistentniho stavu.
> 	U nekterych SRDB by mohlo stacit prevedeni do ReadOnly (myslim u
> Oracle, ale otestovano nemam).

 Takto snad nikdo rozumne  zadne DB nezalohuje. Ono pravidelne zastaveni
 nebo prevod do read-only muze byt  v rade aplikacich znacne nezadouci a
 tedy nepouzitelne. Prave proto vetsina transakcnich DB obsahuje nastroj
 ktery v ramci bezne transakce udela jeji dump nebo nastroje pouzivajici
 nejaky kontinualne se tvorici log (ktery se pise treba na pasku, apod).
 
 To o  cem je  tato debata je  daleko vice o  odolnosti DB  proti jejimu
 nasilnemu  ukonceni a  naslednemu  oziveni (recovery)  --  coz je  stav
 kteremu  _muze_ odpovidat  udelani  snapshot disku. Pad  DB (i  vlastni
 chybou) je pochopitelne  neco co by mela dobra implementace  DB resit a
 byt  na to  pripravena  a zarucit,  ze po  uspesnem  startu budou  data
 odpovidat datovemu  modelu (coz  neznamena, ze  o nejaka  data nemuzete
 prijit).

On Tue, Jul 27, 2004 at 06:02:59AM +0200, Chlopcik Ales wrote:
> Pavel Kankovsky wrote:
> > 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.
> 
> 	Muzete mi rict, kde ma treba MySQL RedoLogy ?

 Vsak se take mluvilo o rozumnych implementacich :-))) 
 
 Asi by bylo  presnejsi nemluvit o tom, ze odolnost  proti padu zarucuji
 transakce,  ale rozumny  postup jak  zapisovat do  datovych souboru  DB
 (prostrednictvim  kontrolniho logu). DB  take vetsinou  nemanipuluji na
 urovni souboru  s daty  jen bezici  transakce, ale  s bloky  dat, ktere
 obsahuji zaznamy  i nekolika transakci  a treba i ruzne  verze stejnych
 dat.

 Pro zajimavost starsi verze PostgreSQL  (6.5 apod.) maji transakce, ale
 jistota,  ze DB  rozumne nastartuje  po "kill  -9" tam  prave z  duvodu
 neexistence logu neni.

 DB bych  asi snapshotem  disku nezalohoval  protoze tim  DB pridelavate
 praci  a  dostavate daleko  hure  prenositelnou  zalohu nez  v  pripade
 pouziti nejakeho k tomu urceneho nastroje.
 
 Pak jeste  snad poznamka  -- sekvencne udelany  snapshot disku  neni to
 same jako  pad DB kdy  se vse  najednou zastavi. Pokud se  vse najednou
 zastavi  tak  podle  logu  lze najit  posledni  platnou  operaci. Pokud
 sekvence  zalohujete soubory  tak dle  logu posledni  platna operace  v
 datovem souboru byt  nemusi, protoze se zalohoval  davno pred logem. To
 znamena, ze u velmi velkych  DB v pripade sekvencniho zalohovani muzete
 prijit o daleko vice dat nez pokud na tu samou DB aplikujete SIGKILL.
 Pochopitelne DB by mela rozdychat oboje i kdyz z ruznyma nasledkama.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/