[linux-l] Transaktionen für alle (was: Re: [linux-l] Dateien mit '/' im Dateinamen)

Dani Oderbolz oderbolz at ecologic.de
Mi Aug 20 12:55:51 CEST 2003


Steffen Dettmer wrote:

>* Jan Krueger wrote on Tue, Aug 19, 2003 at 20:40 +0200:
>  
>
> ...
>
>>>>Hihi, Und was machst Du, wenn die Anforderung 24/7 ist? sql
>>>>stop ist dann verboten und ein snap inkonsistent, also?
>>>>        
>>>>
>>>Dann ist die Anforderung falsch.
>>>      
>>>
>
>  
>
>>Offensichtlich. Was sagt Dein Chef dazu?
>>    
>>
>
>Er formuliert sie auf 99.9% von 24/7 um. Bleibt über eine Minute
>am Tag. Verfügbarkeiten von 99.9% sind meist ausreichend,
>zumindestens für das, was ich mache, in jedem Fall.
>
>  
>
>>>Kann mir nicht vorstellen, daß das funktioniert, ohne
>>>Transaktionen abzubrechen *oder* zu verzögern, denn man braucht
>>>ja einen Zeitpunkt, in dem es keine offenen Transaktionen gibt,
>>>um umschalten zu können. Den gleichen Zeitpunkt, wie für das
>>>Ziehen eines Snaps.
>>>      
>>>
>>Da der eine und der andere letztendlich parallel die dinge
>>ausführen, also exakt das gleiche tun (beide haben die gleichen
>>offenen transaktionen laufen) muß lediglich die Anwendung ihre
>>verbindung zum anderen umschalten.  klitzekleine verzögerung.
>>der andere kann, da er ja alles bisherige auch ausgeführt hat,
>>nahtlos übernehmen.
>>    
>>
>
>? Nee... Wenn jemand eine Datei liest, schreibt und nach 3
>Stunden nochmal einen Block davon neu schreibt (also einen
>exklusiven Lock hat), kann logischerweise 3 Stunden niemand
>anders die Datei lesen, weil er ja nicht wissen kann, ob der
>erste geschriebene Block commitet wird oder nicht. Man könnte
>natürlich noch "views" dazunehmen, daß der andere dann die Daten
>sieht, die es mal waren. Wird natürlich auch wieder teuer, weil
>man dann alle View-Daten speichern muß (was natürlich jede
>Datenbank  - außer vielleicht mySQL und "kleine" - kann, wo wir
>wieder beim Thema wären ;)). Wenn beide schreiben wollen, muß auf
>jeden Fall sequentialisiert werden, einer kann ja nur. Wenn nur
>einer liest, und später seine Transaktion beenden (positiv,
>commit) will, die gelesenen Daten aber doch geändert wurden (weil
>die erste Transaktion auch positiv war), muß hier ein Rollback
>gemacht werden (bei Datenbanken bekommt man dann ein Transaction
>abort, sowas müßte man dann hier auch machen). Ist schon
>schwierig.
>  
>
Also wenn ihr euch schon für so ein sauteures System wie Oracle entscheidet,
dan vergesst doch bitte diese Snap Klimmzüge.
Oracle unterstützt so gennantes Hot Backup, dh. du kannst im laufenden 
Betrieb
unter voller Last ein Backup ziehen.
Ich kenne ein Projekt, die machen dass so, dass sie ihre Disks 3 Fach 
spiegeln,
dann sagen sie der DB "Hallo, ich will ein Backup dieses Tablespaces 
machen",
dann brechen sie den Spiegel, und weiter gehts.
Solche Backups sind natürlich inkonsistent, aber da man parallel noch 
das Transaktionslog hat,
kann man sie nach einem Crash wieder konsistent machen.
Dabei werden Transaktionen weder abgebrochen, oder verzögert, die werden 
einfach woanders hingeschrieben
(Genauser ins Rollback Segment und ins Red Log).

Gruss,
Dani





Mehr Informationen über die Mailingliste linux-l