Transaktionen Anforderungen an Transaktionen

© H.-U. Hei§, Uni-Paderborn
6 Transaktionen in Verteilten Systemen
© H.-U. Hei§, Uni-Paderborn
Anforderungen an Transaktionen (ACID - Principle):
6.1 Grundlagen (Wiederholung aus KMS)
Atomicity
AtomaritŠt
Alles-oder-Nichts-Eigenschaft: Die Transaktion wird
entweder vollstŠndig ausgefŸhrt oder hinterlŠ§t keinerlei
Wirkung.
Kritische Abschnitte
¥
elementares Mittel zur Konsistenzwahrung bei nebenlŠufigen Zugriffen
¥
Programmierer selbst fŸr korrektes Setzen der Sperren verantwortlich
Consistency
Konsistenz
Eine Transaktion fŸhrt einen konsistenten Datenzustand
wieder in einen solchen Ÿber.
Anforderungen an ãhšheresÒ Konzept
¥
Automatisches Erzwingen der Konsistenzwahrung
¥
Umgang mit verschiedenen kritischen Abschnitten
¥
Konsistenzwahrung auch bei Fehlern und AusfŠllen
Isolation
Isolation
Zwischenergebnisse einer Transaktion sind fŸr andere
Transaktionen nicht sichtbar.
Durability
→ Transaktionen
Dauerhaftigkeit:
Die €nderungen einer beendeten und bestŠtigten
(committed) Transaktion kšnnen weder verloren gehen
noch rŸckgŠngig gemacht werden.
Eine Transaktion ist eine Folge von Operationen, die in ihrer Wirkung atomar sein soll.
6-1
6-2
© H.-U. Hei§, Uni-Paderborn
© H.-U. Hei§, Uni-Paderborn
Zustände von Transaktionen
T1
T2
T3
Tn
start, read, write, abort, commit
Beendet
(partially
committed)
Bestätigt
(committed)
M
IT
Transaktionsverwalter
(transaction manager)
TV_COMMIT
Architektur
eines
Transaktionssystems
CO
M
Planer (scheduler)
Undefiniert
(undefined)
read, write, abort, commit
T
Gescheitert
(failed)
TV_ROLLBACK
Daten
6-3
Undefiniert
(undefined)
TV_ABORT
OR
read, write
Rücksetzer
(recovery manager)
Aktiv
(active)
AB
Pufferverwalter
(cache manager)
START
6-4
Zurückgesetzt
(aborted)
© H.-U. Hei§, Uni-Paderborn
Einige Definitionen (Wiederholung)
Def.:
Def.:
Def.:
Def.:
Transaktion Ti liest von Transaktion Tj, wenn Ti Datenelemente liest, die vorher
von Tj geschrieben wurden.
Ein Plan S hei§t rŸcksetzbar (recoverable, S ∈RC), wenn jede Transaktion T ∈S
erst dann bestŠtigt wird, wenn alle Transaktionen, von denen sie gelesen hat,
bereits bestŠtigt sind oder abgebrochen wurden
Zwei PlŠne S und SÕ hei§en Šquivalent, wenn sie dieselben Ausgabewerte liefern
und denselben Datenzustand zurŸcklassen.
Def.
Zwei PlŠne S und SÕ hei§en konfliktŠquivalent, wenn sie aus denselben
Operationen bestehen und Konflikte in gleicher Weise auflšsen
(∀p ↔ q: p < S q ⇔ p < S' q)
Ein Plan S hei§t (konflikt)serialisierbar (S ∈SR), wenn er (genauer: seine
bestŠtigte Projektion C(S)) zu einem seriellen Plan (konflikt)Šquivalent ist.
Def.:
Zusammenhang der
Eigenschaften
(Mengendiagramm)
Konfliktserialisierbare Pläne
SR
Rücksetzbare Pläne
RC
Ein Plan S hei§t strikt ( S ∈ST ), wenn von keiner Transaktion aus S unbestŠtigte
Daten gelesen oder Ÿberschrieben werden.
Ein Plan S hei§t seriell, wenn fŸr jedes Paar von Transaktionen alle Operationen
der einen vor jeder Operation der anderen ausgefŸhrt werden.
Def.:
Def.:
© H.-U. Hei§, Uni-Paderborn
kaskadierenden Abbruch
vermeidende Pläne
ACA
Strikte Pläne
ST
Serielle Pläne
Korrekte Pläne
Ein Plan S hei§t korrekt, wenn er konfliktserialisierbar und rŸcksetzbar ist.
6-5
6-6
© H.-U. Hei§, Uni-Paderborn
Koordination von Transaktionen
Vorgehensweisen von Planern
Da die Konsistenzwahrung automatisch geschehen soll, mu§ von einer beliebig verzahnten
Folge von Operationen der nebenlŠufigen Transaktionen ausgegangen werden.
Die Transaktionsverwaltung (bzw. der Planer als Teil der TV) hat dann die Aufgabe, aus
dieser Aufruffolge einen Plan mit den gewŸnschten Eigenschaften (z.B. Serialisierbarkeit)
zu schaffen.
Da er die Operationen nicht verŠndern kann, bleiben nur die folgenden Optionen:
1.
2.
3.
Sofortige AusfŸhrung der Operation
Verzšgerung der AusfŸhrung der Operation (um eine Umordnung zu bewirken)
Abweisen der Operation (fŸhrt zum Abbruch der Transaktion)
T1
T2
© H.-U. Hei§, Uni-Paderborn
Tn
BezŸglich der Wahl der Optionen kann man Planer mit unterschiedlichem Verhalten
unterscheiden
Konservatives Vorgehen
¥
¥
¥
Aggressives Vorgehen
¥
Folge F von Operationen
¥
Planer
(scheduler)
Konservative Planer gehen von hŠufigen Konflikten aus und sind daher sehr vorsichtig.
Sie verzšgern Operationen so lange, bis kaum noch etwas schiefgehen kann.
Den Extremfall bildet der serielle Planer, der alle Transaktionen zwangsserialisert.
Aggressive Planer neigen dazu, Operationen sofort auszufŸhren,
weil sie davon ausgehen, da§ Konflikte ohnehin selten sind.
Sollte sich doch ein Konflikt ergeben, so nimmt man in Kauf, Operationen
zurŸckzuweisen, d.h. Transaktionen abzubrechen und zurŸckzusetzen.
konservativ
Folge F‘ von Operationen
Daten
6-7
aggressiv
keine Abbrüche
lange Verzögerungen
viele Abbrüche
keine Verzögerungen
6-8
© H.-U. Hei§, Uni-Paderborn
© H.-U. Hei§, Uni-Paderborn
Das Zweiphasen-Sperrprotokoll (ZPP) (Two-Phase-Locking (2PL))
Modifikation: Striktes Zweiphasensperren
Mithilfe von Lese- und Scheibsperren lŠ§t sich ein Protokoll angeben, das die Forderung
nach Serialisierbarkeit erfŸllt.
Das normale Zweiphasensperren erzeugt serialisierbare PlŠne, jedoch nicht unbedingt
rŸcksetzbare:
1.
Eine Transaktion mu§ jedes Datenelement vor dem ersten Zugriff mit einer dem Zugriff
entsprechenden Sperre belegen.
2.
Kein Datenelement darf mit unvertrŠglichen Sperren belegt werden.
3.
Eine Transaktion darf nach der ersten Freigabe einer Sperre keine weitere Sperre
setzen.
4.
Am Ende der Transaktion mŸssen alle von ihr gehaltenen Sperren freigegeben sein.
T1
write_lock(x)
write(x)
write_unlock(x)
T2
read_lock(x)
read(x)
read_unlock(x)
commit
abort
Daher zusŠtzliche Forderung:
Forderung 3 gibt dem Sperrprotokoll seinen Namen, da durch sie die Transaktion in zwei
Phasen zerlegt wird, eine, in der Sperren sukzessive erworben werden und eine, in der die
Sperren wieder freigegeben werden.
5
Alle jemals erworbenen Sperren werden bis zum Ende der Transaktion gehalten.
Dadurch werden strikte PlŠne erzeugt, die nicht nur rŸcksetzbar sind, sondern auch
kaskadierendes RŸcksetzen vermeiden.
6-9
6-10
© H.-U. Hei§, Uni-Paderborn
© H.-U. Hei§, Uni-Paderborn
Komponenten und ihr Zusammenspiel
Anzahl Sperren
T1
Normales 2PL
T2
T3
Zeit
start, read, write, abort, commit
Architektur
eines
Transaktionssystems
c
Anzahl Sperren
recovery manager
(RM)
Zeit
Stabiler
Speicher
Konservatives 2PL
read, write
fetch
flush
c
Anzahl Sperren
Transaktionsverwalter
(transaction manager)
Planer (scheduler)
read, write, abort, commit
Striktes 2PL
read
write
Pufferverwalter
(cache manager)
Log
Zeit
c
6-11
Tn
6-12
read
write
Instabiler
Speicher
(Puffer)
© H.-U. Hei§, Uni-Paderborn
6.2 Validierer (Optimistische Synchronisation)
¥
¥
RŸckwŠrtsorientierte Validierung
Sind Konflikte eher selten, so kann man die Transaktionen ohne Verzšgerung bis zu
ihrem Ende durchlaufen lassen und erst dann prŸfen, ob Konflikte stattgefunden
haben.
In diesem (hoffentlich seltenen) Konfliktfall ist die Transaktion abzubrechen
(zurŸckzusetzen) und erneut zu starten.
Die Validierung, d.h. PrŸfung auf Konfliktfreiheit (zum Commit-Zeitpunkt von Ti) kann auf
zwei Arten erfolgen:
¥
¥
© H.-U. Hei§, Uni-Paderborn
VorwŠrtsorientiert
†berprŸfen aller aktiven Transaktionen, ob ein Konflikt mit Ti vorliegt.
RŸckwŠrtsorientiert
†berprŸfen aller abgeschlossenen Transaktionen, ob ein Konflikt mit Ti vorliegt.
r(a) w(x) w(b)
T2
w(y) r(z) c
Konflikt
r(x) c
T3
Validierung von T2
r(y)
T5
w(y) c
T1
w(x)
T4
GeprŸft wird auf Konflikte mit Ÿberlappenden, aber bereits bestŠtigten Transaktionen
An die Stelle des Planers tritt der Validierer (certifier), der die PrŸfungen vornimmt und ggf.
eine Transaktion abbricht.
6-13
6-14
© H.-U. Hei§, Uni-Paderborn
VorwŠrtsorientierte Validierung
T2
r(a) w(x) w(b)
Ablauf der Validierung (VorwŠrtsvalidierung)
Der Validierer unterhŠlt die folgenden Datenstrukturen
w(y) r(z) c
Konflikt
r(x) c
T3
Validierung von T2
T5
active_set
Menge der aktiven Transaktionen
r_set(Ti)
Menge der von Ti gelesenen Datenelemente (fŸr alle Ti )
w_set(Ti)
r(y)
Menge der von Ti gelesenen Datenelemente (fŸr alle Ti )
validate_forward(Ti)
begin
conflict := false
for all Tj ∈ active _ set ∧ i ≠ j do
w(y) c
T1
T4
© H.-U. Hei§, Uni-Paderborn
w(x)
(
( )
) (
( )
) (
( )
if r _ set Tj ∩ w _ set (Ti ) ≠ ∅ ∨ w _ set Tj ∩ r _ set (Ti ) ≠ ∅ ∨ w _ set Tj ∩ w _ set (Ti ) ≠ ∅
GeprŸft wird auf Konflikte mit aktiven Transaktionen
6-15
then conflict := true
end do;
if conflict then abort(Ti) else commit(Ti)
end validate
6-16
)
© H.-U. Hei§, Uni-Paderborn
© H.-U. Hei§, Uni-Paderborn
Struktur strikter optimistischer Koordination
Strikter VorwŠrtsvalidierer
Ein solcher Validierer erzeugt serialisierbare PlŠne.
Die erzeugten PlŠne sind jedoch nicht notwendigerweise strikt.
Der erzeugte serialisierbare Plan mu§ ja einem seriellen Plan (konflikt-)Šquivalent sein.
Daher folgende €nderung:
Sei nun Ti < Tj bezŸglich der seriellen Ordnung.
¥ Zur Vermeidung des Lesens oder Schreibens unbestŠtigter Daten greift jede Transaktion
auf eine private Kopie des Datenemelents zu.
Dann mu§ gelten:
¥ Nach erfolgreicher Validierung (Commit) werden die Kopien zurŸckgeschrieben und
dadurch sichtbar gemacht.
1. Alle €nderungen von Ti mŸssen fŸr Tj sichtbar sein
Dies fŸhrt zur sogenannten Dreiphasenstruktur der optimistischen (validierenden)
Verfahren:
Validierungsphase
Lesephase
START
2. Keine €nderungen von Tj dŸrfen fŸr Ti sichtbar sein
3. Bei Schreibzugriffen mu§ wi(x) vor wj(x) ausgefŸhrt werden
Schreibphase
COMMIT
Entscheidung Ende
6-17
6-18
© H.-U. Hei§, Uni-Paderborn
© H.-U. Hei§, Uni-Paderborn
Realisierung der VorwŠrtsvalidierung
Strikte Vorwärtsvalidierung von Ti
1. Die Bearbeitung der Commit-Operation (Validierungs- und Schreibphase) wird als
kritischer Abschnitt durchgefŸhrt.
Krit. Abschnitt und Sperrung des Write-Sets
2. In der Schreibphase werden die Datenelemente mit Sperren versehen, um einen Zugriff
anderer Transaktionen zu verhindern.
3. Als Validierung bleibt dann nur noch folgendes
validate_forward(Ti)
begin
conflict := false
for all Tj ∈ active _ set ∧ i ≠ j do
(
( )
if r _ set Tj ∩ w _ set (Ti ) ≠ ∅
r
v
r
r
)
then conflict := true
end do;
if conflict then abort(Ti) else commit(Ti)
end validate
6-19
w
Ti
warten
v
w
warten
r
v
Tj nicht in Konflikt mit Ti
w
Tk in Konflikt mit Ti
Damit wird der Šquivalente serielle Plan durch die COMMIT-Reihenfolge festgelegt.
6-20
© H.-U. Hei§, Uni-Paderborn
Variante der VorwŠrtsvalidierung:
© H.-U. Hei§, Uni-Paderborn
6.3 Architektur verteilter Transaktionssysteme
T11 T12
Idee:
Im Falle eines Konflikts wird nicht die validierende Transaktion Ti,
sondern die in Konflikt stehende aktive Transaktion Tj abgebrochen,
weil ihr Abbruch (im Mittel) einen geringeren Aufwand (Neustart) bedeutet (Kill-Strategie).
r
v
w
r
T1k1
TM
T21 T22
T2k2
Tm1 Tm2
TM
Tmkm
TM
Kommunikationsnetz
Sched.
Sched.
Sched.
RM
RM
RM
Daten
Daten
Daten
Ti
Tj in Konflikt mit Ti
umsonst geleistete Arbeit
6-21
6-22
© H.-U. Hei§, Uni-Paderborn
Annahmen
© H.-U. Hei§, Uni-Paderborn
Fehlerarten
Knotenfehler
¥
¥
Wir nehmen eine homogene Umgebung an:
Jeder Knoten besteht aus einem lokalen Transaktionsverwaltungssystem
Jeder Knoten verwaltet einen Teil der Daten.
Jedes Datum befindet sich auf genau einem Knoten (keine Replikate)
¥
Eine Transaktion sendet ihre Operationen an den lokalen Transaktionsverwalter TM.
¥
Falls das Datum lokal nicht verfŸgbar ist, wird eine Anforderung an den TM geschickt,
bei dem das Datum sich befindet.
¥
Bei Commit oder Abort mu§ der TM alle Knoten verstŠndigen,
die von der Transaktion betroffen waren.
¥
¥
¥
Bei Knotenausfall nehmen wir an, da§ der Knoten sofort stoppt,
d.h. keinerlei Operationen mehr durchfŸhrt.
Der Inhalt des flŸchtigen Speichers geht verloren und
der Knoten mu§ eine Restart-Operation durchfŸhren.
Ein Knoten ist daher entweder aktiv (und arbeitet korrekt) oder
er ist ausgefallen (und rŸhrt sich nicht)
Netzfehler
6-23
¥
¥
¥
Ausfall der Verbindung
Fehler in Kommunikationssoftware
Ausfall eines Zwischenknoten
¥
¥
¥
Nachrichtenverlust
NachrichtenverfŠlschung
Netzpartitionierung
6-24
© H.-U. Hei§, Uni-Paderborn
© H.-U. Hei§, Uni-Paderborn
Fehlerbehandlung
6.4 Koordination verteilter Transaktionen
Viele dieser Fehler werden von unteren Schichten der Kommunikationsoftware behandelt.
6.4.1 Zentrale Koordination
Auch in einem verteilten System kann ein zentraler Planer eingesetzt werden:
Kšnnen sie jedoch dort nicht behoben werden, so sind sie auch fŸr das
Transaktionsverwaltungssystem auf Schicht 7 sichtbar.
T11 T12
T 1k1
Tc1 Tc2
TM
Tckc
Tm1Tm2
TM
Tmkm
TM
Erkennung von Fehlern
Sched.
Die GrŸnde fŸr die Nichterreichbarkeit eines anderen Knotens kšnnen auf dieser Ebene
meist nicht
herausgefunden werden.
RM
RM
RM
Daten
Daten
Daten
In der Regel ist man auf Fristablauf-Mechanismen (Time out) angewiesen
6-25
6-26
© H.-U. Hei§, Uni-Paderborn
Implikationen
¥
¥
6.4.2 Dezentrale Koordination
Sperrprotokoll (2PL)
Globale Sicht auf die Sperrsituation. Wie im lokalen Fall
Optimistische Verfahren
Nach Abschlu§ mu§ jede Transaktion ihren Read- und Write-Set an die zentrale
Validierungsstelle schicken. Nur sinnvoll bei RŸckwŠrtsvalidierung.
Bei VorwŠrtsvalidierung mŸ§ten die Read- und Write-Sets aller im Netz aktiven
Transaktionen bestimmt werden
Nachteile
¥
¥
¥
¥
© H.-U. Hei§, Uni-Paderborn
Zentrale darf nicht ausfallen ( keine Ausfalltoleranz)
Zentrale wird leicht zum Engpa§ (keine Skalierbarkeit)
Die Autonomie der Knoten ist stark eingeschrŠnkt
Auch rein lokale Transaktionen mŸssen sich an den zentralen Planer wenden (unnšt.
Aufwand)
6-27
T11 T12
T1k1
Tc1 Tc2
Tckc
Tm1Tm2
TM
TM
TM
Sched.
Sched.
Sched.
RM
RM
RM
Daten
Daten
Daten
6-28
Tmkm
© H.-U. Hei§, Uni-Paderborn
Zwei-Phasen-Sperrprotokoll bei dezentraler Koordinierung
© H.-U. Hei§, Uni-Paderborn
6.5 Verteilte Verklemmungen
Bei Verwendung von Sperren kšnnen Verklemmungen (deadlocks) entstehen.
¥
ZugriffswŸnsche werden an den Knoten gesendet, der das Datum verwaltet
Die Sperren fŸr jedes Datum werden daher lokal und zentral am jeweiligen Ort gefŸhrt.
¥
Der lokale Scheduler kann jedoch nicht feststellen, ob eine Transaktion an einem
anderen Ort schon Sperren freigegeben hat.
¥
Ohne weitere Ma§nahmen kommt es daher zu einer Verletzung der Zweiphasen-Regel.
¥
Die Zweiphasen-Eigenschaft kann jedoch durch striktes Sperren erzwungen werden:
Sperren werden solange gehalten, bis fŸr die Transaktion die Commit-Anforderung
eintrifft
T1
T2
lock (x)
lock (y)
wartet auf
T1 besitzt x
T2 besitzt y
lock (y)
lock (x)
wartet auf
Verklemmungen sind gekennzeichnet durch eine zyklische Wartesituation:
Zur Darstellung kann man den sogenannten Wartegraphen verwenden:
Die Transaktionen sind die Knoten, und es fŸhrt ein Pfeil von Knoten i nach Knoten j, wenn
Ti eine Sperre benštigt, die Tj besitzt.
Eine Verklemmung liegt vor, wenn der Graph Zyklen besitzt.
6-29
6-30
© H.-U. Hei§, Uni-Paderborn
Beispiel fŸr das Entstehen einer verteilten Verklemmung
T2 = r2 (y ) w2 ( x ) c2
T1 = r1 ( x ) w1 (y ) c1
x liegt auf Knoten A
Planer A
© H.-U. Hei§, Uni-Paderborn
Zentrale Zyklenentdeckung
Ein globaler Verklemmungsentdecker (global deadlock detector, GDD)
¥
existiert zentral an einem Knoten
¥
sammelt periodisch lokale Wartegraphen und vereinigt sie zu einem globalen
Wartegraphen
empfange r2 (y )
¥
prŸft den Wartegraphen auf Zyklen
setze rl2 ( y )
¥
wŠhlt bei Verklemmung ein ãOpferÒ (abzubrechende Transaktion) aus.
y liegt auf Knoten B
Planer B
empfange r1 ( x )
setze rl1( x )
empfange w1 (y )
empfange w2 ( x )
füge w2 ( x ) in Warteschlange
füge w1 (y ) in Warteschlange
füge neue Kante T2 → T1
füge neue Kante T1 → T2
in Wartegraph
in Wartegraph
6-31
Wegen der nicht ganz aktuellen Information Ÿber die globale Wartesituation
kšnnen sogenannte Phantom-Verklemmungen auftreten,
d.h. Verklemmungen, die gar nicht existieren
6-32
© H.-U. Hei§, Uni-Paderborn
Verteilte Zyklenentdeckung (Path Pushing)
© H.-U. Hei§, Uni-Paderborn
Beispiel
Das Zusammensetzen des globalen Wartegraphen kann auch dezentral erfolgen:
T1
T2
T5
T3
Tex
T2
T4
(1) Jeder Knoten unterhŠlt seinen lokalen Wartegraphen als Teil des globalen
Wartegraphen
(2) Der restliche, unbekannte Teil des Wartegraphen wird durch einen Knoten T ex
reprŠsentiert:
- Wartet eine lokale Transaktion Ti auf eine Sperre an einem anderen Knoten,
so gibt es eine Kante von Ti nach Tex.
- Wartet eine entfernte Transaktion Tk auf eine lokale Sperre,
so wird eine Kante von Tex nach Tk eingefŸgt.
(3) Bei jedem EinfŸgen einer Kante wird eine ZyklenprŸfung durchgefŸhrt:
- Wird ein Zyklus gefunden, der Tex nicht enthŠlt, so liegt eine lokale Verklemmung vor.
- Wird ein Zyklus gefunden, der Tex enthŠlt, so liegt eine potentielle verteilte
Verklemmung vor.
(4) Bei potentieller Verklemmung wird der zyklische Pfad als deadlock detection message
(DDM) an einen der betroffenen Knoten geschickt.
(5) Beim Empfang einer DDM fŸgt der Knoten den Pfad (ohne Tex ) in den lokalen Graphen
ein und fŸhrt wiederum eine ZyklenprŸfung durch (3)
(6) Nach endlich vielen Schritten wird eine Verklemmung erkannt oder der Algorithmus hŠlt
an.
Knoten 2 erkennt einen Zyklus, der Tex nicht enthŠlt: Daher liegt eine verteilte Verklemmung
vor.
6-33
6-34
Tex
T3
Knoten 1
Knoten 2
Da Knoten 1 einen Zyklus entdeckt, der Tex enthŠlt, schickt er die Nachricht (Tex, T2, T3,
Tex) an Knoten 2, der seinen Wartegraphen entsprechend aktualisiert:
Tex
T2
T4
T3
© H.-U. Hei§, Uni-Paderborn
© H.-U. Hei§, Uni-Paderborn
Verteilte Zyklenentdeckung (Chandy-Misra-Haas)
Kriterien fŸr die Auswahl der abzubrechenden Transaktion
Ein weiterer verteilter Algorithmus kommt mit weniger Nachrichten aus und produziert auch
keine Phantom-Verklemmungen (Chandy-Misra-Haas-Algorithmus):
Wird ein Zyklus entdeckt, so mu§ eine der beteiligten Transaktionen abgebrochen werden.
¥
Mu§ ein Proze§ warten, so schickt er eine Nachricht an den Proze§, der das
angeforderte BM besitzt.
Mšgliche Kriterien:
¥
Die Nachricht enthŠlt: Die ID des wartenden Prozesses, die ID des Senders, die ID des
EmpfŠngers
¥
bereits geleistete Arbeit der Transaktion
¥
RŸcksetzkosten der Transaktion
¥
Der EmpfŠnger prŸft, ob er selbst wartet. Wenn ja, modifiziert er die Nachricht:
¥
die erwarteten Restkosten (Zeit) zur vollstŠndigen Bearbeitung der Transaktion
Die erste Komponente bleibt, die zweite wird durch seine ID ersetzt, die dritte ist die ID
des Prozesses, auf den er wartet (und an den diese Nachricht geht)
¥
die Anzahl der Zyklen in der sich eine Transaktion befindet
¥
die Anzahl der AbbrŸche, die eine Transaktion schon erlebt hat
¥
Kommt die Nachricht beim ursprŸnglichen Sender an, so liegt ein Zyklus vor
(0,8,0)
P4
P0
P1
P2
(0,4,6)
(0,2,3)
P6
P8
P3
P5
(0,5,7)
6-35
P7
6-36
© H.-U. Hei§, Uni-Paderborn
© H.-U. Hei§, Uni-Paderborn
Zeitstempel-Verfahren (Verklemmungsvermeidung)
Beispiel fŸr Livelock
¥
In einer Verklemmungssituation wartet eine Transaktion auf sich selbst.
¥
Existiert eine globale Ordnung der Transaktionen (Zeitstempel) und erzwingt man,
da§ diese Ordnung im Wartegraph berŸcksichtigt wird (topologische Sortierung),
so kann man Zyklen verhindern:
Ti: w(x) w(y)
TSC := TSC + 1;
ts(Ti) := TSC;
set wli(x);
¥
Tk: w(y) w(x)
/* Ti started
TSC := TSC + 1;
ts(Tk) := TSC;
/* Tk started
set wlk(y);
Praktisch bedeutet das:
set wli(y);
/* aborted since ts(Ti)< ts(Tk)
TSC := TSC + 1;
ts(Ti) := TSC
/* Ti restarted
set wli(x);
Ti darf nur dann auf Tk warten, wenn ts(Ti) < ts(Tk)
oder
Ti darf nur dann auf Tk warten, wenn ts(Tk) < ts(Ti)
set wlk(x);
/* aborted since ts(Tk)< ts(Ti)
TSC := TSC + 1;
ts(Tk) := TSC;
/* Tk restarted
set wlk(y);
Andernfalls findet ein Abbruch statt.
¥
Dabei kšnnen zyklische AbbrŸche stattfinden (sogenannte Livelocks)
set wli(y);
/* aborted since ts(Ti)< ts(Tk)
6-37
6-38
© H.-U. Hei§, Uni-Paderborn
Varianten
© H.-U. Hei§, Uni-Paderborn
Beispiel
Fordert Ti eine Sperre, die Tk besitzt, so hat der Planer mehrere Optionen:
wait-die
Die bekanntesten:
ãwait-dieÒ
ãwound-waitÒ
if ts(Ti) < ts(Tk)
then Ti waits
else abort Ti
/* Ti ist Šlter als Tk
/* Ti ist jŸnger als Tk
if ts(Ti) < ts(Tk)
then abort Tk
else Ti waits
/* Ti ist Šlter als Tk
/* Ti ist jŸnger als Tk
6-39
besitzt
Sperre
fordert
Sperre
besitzt
Sperre
alter
Prozeß
ts = 10
junger
Prozeß
ts = 20
junger
Prozeß
ts = 20
alter
Prozeß
ts = 10
abbrechen
warten
wound-wait
In beiden FŠllen wird die jŸngere Transaktion abgebrochen, also die Šltere Transaktion
bevorzugt,
wobei wound-wait Šltere Transaktionen noch stŠrker favorisiert als wait-die
fordert
Sperre
fordert
Sperre
besitzt
Sperre
fordert
Sperre
besitzt
Sperre
alter
Prozeß
ts = 10
junger
Prozeß
ts = 20
junger
Prozeß
ts = 20
alter
Prozeß
ts = 10
abbrechen
warten
6-40
© H.-U. Hei§, Uni-Paderborn
6.6 BestŠtigung verteilter Transaktionen
© H.-U. Hei§, Uni-Paderborn
6.6.1 Das Zwei-Phasen-Commit-Protokoll (2PC)
Die Korrektheit eines Transaktionskonzepts baut auf der AtomaritŠt der Commit-Operation.
Ihre GewŠhrleistung im verteilten Fall, wo es einer Abstimmung der Knoten bedarf und
AusfŠlle nicht ausgeschlossen werden kšnnen, ist schwierig
Einer der involvierten Knoten (Ÿblicherweise der ãHeimatknotenÒ der Transaktion)
Ÿbernimmt die Rolle des Koordinators, alle anderen sind Teilnehmer (participants)
Jeder Knoten unterhŠlt eine spezielle Log-Datei, in die alle relevanten Ereignisse
geschrieben werden.
Ein atomares Commit-Protokoll (ACP) hat den folgenden Anforderungen zu genŸgen:
(1) Alle Knoten, die eine Entscheidung treffen, treffen dieselbe Entscheidung.
Das Protokoll besteht aus vier Schritten:
(2) Ein Knoten kann seine Entscheidung nicht nachtrŠglich Šndern.
(1) Aufforderung zur Stimmabgabe (vote request)
(3) Die Entscheidung, eine Transaktion zu bestŠtigen, kann nur von allen Knoten
einstimmig getroffen werden.
(2) Stimmabgabe (vote)
(4) Falls keine AusfŠlle vorliegen und alle Knoten zugestimmt haben, wird die Transaktion
bestŠtigt.
(3) Mitteilung Ÿber die Entscheidung (decision)
(4) BestŠtigung der Entscheidung (acknowledge)
(5) Nach Behebung eventueller AusfŠlle mu§ eine Entscheidung getroffen werden
6-41
6-42
© H.-U. Hei§, Uni-Paderborn
Struktur des Zwei-Phasen-Commit-Protokolls
© H.-U. Hei§, Uni-Paderborn
Verhalten im Fehlerfall (erkennbar durch Fristablauf)
(1) Teilnehmer wartet auf vote-request:
Koordinator
Teilnehmer
Teilnehmer
Falls keine Nachricht eintrifft, entscheidet der Teilnehmer ãAbortÒ und stoppt.
(2) Koordinator wartet auf vote-messages:
Phase 1
Phase 2
vote mess
st
age (yes/n
(3) Teilnehmer wartet auf Entscheidung
no)
age (yes/
o)
vote mess
)
decision
ess. (C/A
decision m
Falls nicht alle Stimmabgaben eingetroffen sind, entscheidet der Koordinator ãAbortÒ,
sendet die entsprechenden decision-messages und stoppt.
vote reque
est
vote requ
ack
mess. (C
/A)
Ungewißheitsperiode der
Teilnehmer
ack
Da die Entscheidung zu diesem Zeitpunkt vielleicht bereits getroffen ist, ist eine
einseitige Entscheidung wie in (1) nicht mehr mšglich. Um die Ungewi§heit zu
beenden, mu§ Teilnehmer p einen anderen Teilnehmer q nach dem Ergebnis fragen
(Terminierungsprotokoll).
Drei Mšglichkeiten:
(a) q hat die Entscheidung erhalten und gibt sie an p weiter
Warten auf Nachricht
(b) q hat noch nicht abgestimmt. q kann einseitig ãAbortÒ entscheiden und eine
entsprechende Nachricht an p senden
(c) q ist selbst in der Ungewi§heitsphase und kann p nicht helfen.
6-43
6-44
© H.-U. Hei§, Uni-Paderborn
Verhalten der Knoten bei Neustart (Recovery)
© H.-U. Hei§, Uni-Paderborn
Eigenschaften des 2PC-Protokolls
Fehlertoleranz:
Toleriert KnotenausfŠlle und Kommunikationsfehler (durch Fristablauf)
(1) Log enthŠlt keinen ãStart 2PCÒ-Eintrag (d.h. Knoten ist Teilnehmer)
Blockierung:
(a) Log enthŠlt ãCommitÒ: Verhalten gemŠ§ Recovery-Verfahren (redo)
(b) Log enthŠlt ãAbortÒ: Verhalten gemŠ§ Recovery-Verfahren (undo)
(c) Log enthŠlt ãYesÒ, aber weder ãAbortÒ noch ãCommitÒ: Terminierungsprotokoll
starten
(d) Alle anderen FŠlle:
verfahren
ãAbortÒ entscheiden, ãAbortÒ ins Log schreiben und wie (b)
ZeitkomplexitŠt:
Das 2PC-Protokoll benštigt drei Runden.
Im Fehlerfall kommen zwei Runden fŸr das Terminierungsprotokoll hinzu.
(2) Log enthŠlt ãStart 2PCÒ-Eintrag (d.h. Knoten ist Koordinator)
NachrichtenkomplexitŠt:
(a) Log enthŠlt ãCommitÒ: Verhalten gemŠ§ Recovery-Verfahren (redo)
Bei n Teilnehmern und 1 Koordinator: 3n Nachrichten
(b) Log enthŠlt ãAbortÒ: Verhalten gemŠ§ Recovery-Verfahren (undo)
(d) Alle anderen FŠlle:
verfahren
2PC blockiert, wenn bei einem Teilnehmer ein Fristablauf wŠhrend seiner
Ungewi§heitsperiode entsteht und nur Knoten erreicht werden kšnnen, die sich
ebenfalls in Ungewi§heit befinden.
ãAbortÒ entscheiden, ãAbortÒ ins Log schreiben und wie (b)
Im Fehlerfall weitere O(n2) Nachrichten (worst case)
6-45
6-46
© H.-U. Hei§, Uni-Paderborn
6.6.2 Das Drei-Phasen-Commit-Protokoll (3PC)
Das 3PC-Protokoll ist eine nichtblockierende Verbesserung des 2PC-Protokolls.
© H.-U. Hei§, Uni-Paderborn
Struktur des Drei-Phasen-Commit-Protokolls (3PC)
Koordinator
Teilnehmer
vote reque
est
6-47
Phase 2
3PC verhindert diese Situation, indem es sicherstellt,
da§ kein Knoten ãCommitÒ entschieden haben kann,
solange noch ein nicht ausgefallener Knoten ungewi§ ist.
Phase 3
Blockieren im 2PC resultiert aus einer Situation,
in der alle nicht ausgefallenen Knoten ungewi§ sind
und nicht einseitig ãAbortÒ entscheiden kšnnen,
weil einige Knoten vielleicht schon ãCommitÒ entschieden haben.
Phase 1
Idee:
vote requ
vote mess
o)
vote mess
decision
/A)
no)
age (yes/
2
ss. (pre-C
ack
1
st
age (yes/n
e
decision m
Teilnehmer
4
mess. (p
re-C/A) 3
ack
Commit
Commit
6-48
5
© H.-U. Hei§, Uni-Paderborn
© H.-U. Hei§, Uni-Paderborn
ZustandsŸbergŠnge beim 3PC-Protokoll
Koexistenz von ZustŠnden
No
Finished
Aborted
Finished
Aborted
Uncertain
PreCommitted
Committed
Finished
+
+
+
-
-
Aborted
+
+
+
-
-
Uncertain
+
+
+
+
-
PreCommitted
-
-
+
+
+
Committed
-
-
-
+
+
rt
bo
A
Yes
:
t3
Timeout 5: TP: Abort
Timeout 1,2
rt
:
TP
o
Ab
ou
me
Ti
Commit
Uncertain
Pre-Commit
Timeout 3: TP: Pre-Commit
Precommitted
Timeout 5: TP: Commit
Timeout 4
Committed
(TP: Terminierungsprotokoll)
6-49
6-50
© H.-U. Hei§, Uni-Paderborn
Das 3PC-Terminierungsprotokoll
© H.-U. Hei§, Uni-Paderborn
Beispiel
(initiiert bei Timeout 3 und 5 (Koordinator-Ausfall)
Alle Teilnehmer haben ãYesÒ gestimmt.
¥
ZunŠchst wŠhlen alle aktiven Teilnehmer einen neuen Koordinator
¥
Der neue Koordinator sammelt die Zustandsinformation aller Teilnehmer und verfŠhrt
nach den folgenden Regeln:
Der Koordinator beginnt, ãpre-commitÒ zu verschicken und fŠllt aus,
so da§ nur ein Teil der Knoten die Nachricht erhalten hat.
Einige Knoten sind im Zustand ãpre-commitÒ, die anderen im Zustand ãuncertainÒ
R1: Falls ein Knoten im Zustand ãfinishedÒ oder ãabortedÒ ist, lautet die Entscheidung
ãAbortÒ
R2: Falls irgendein Knoten im Zustand ãcommitÒ ist, lautet die Entscheidung ãCommitÒ
Die Knoten im Zustand ãpre-commitÒ fallen ebenfalls aus.
Die restlichen Knoten starten das Terminierungsprotokoll:
R3: Sind alle Knoten im Zustand ãuncertainÒ, lautet die Entscheidung ãAbortÒ
R4: Sind einige Knoten im Zustand ãpre-committedÒ, aber keiner im Zustand ãcommitÒ,
sendet er ãPre-CommitÒ an alle Knoten.
Nach Eingang der Quittungen (Ack) kann ãCommitÒ entschieden werden
¥
Teilnehmer, die ihren Zustand nicht melden, werden ignoriert
Der (gewŠhlte) neue Koordinator sammelt die ZustŠnde der operationalen Knoten
(alle ãuncertainÒ) und beschlie§t gemŠ§ Regel R3: ãAbortÒ
Ausgefallene Knoten verhalten sich nach Wiederanlauf wie in 6-25, Fall 1-c:
Sie starten das Terminierungsprotokoll und erfahren die Entscheidung ãAbortÒ.
Obwohl sie bereits ãpre-commitÒ erhalten hatten, entscheiden sie ãAbortÒ.
6-51
6-52
© H.-U. Hei§, Uni-Paderborn
© H.-U. Hei§, Uni-Paderborn
6.7 Replikation
Forderung:
6.7.1 Grundlagen
In verteilten Systemen kšnnen Zugriffe auf Daten
Replikationstransparenz (replication transparency)
¥
¥
¥
¥
ist
¥
Dem Benutzer sollte die Existenz von Replikationen verborgen bleiben
¥
Er sollte seine Ÿbliche Sicht auf die Daten haben.
¥
BezŸglich Korrektheit (ACID-Eigenschaften) sollte sich das Transaktionssystem
verhalten wie im replikationsfreien Fall
zu lange Zeit in Anspruch nehmen, weil sie von weit her geholt werden mŸssen
kurzfristig nicht mšglich sein, weil sie exklusiv gesperrt sind
kurzfristig nicht mšglich sein, weil Kommunikationsfehler auftreten
lŠngerfristig nicht mšglich sein, weil der Knoten, auf dem die Daten liegen, ausgefallen
Dagegen kann Abhilfe geschaffen werden, wenn man die Daten
¥
in mehreren Kopien auf unterschiedlichen Rechnern bereitstellt
Dies nennt man Replikation
Wir wollen die Replikation von Daten im Kontext der Transaktionen behandeln,
weil dafŸr ein einfacher, aber mŠchtiger Formalismus zur VerfŸgung steht
6-53
6-54
© H.-U. Hei§, Uni-Paderborn
Annahmen
¥
¥
¥
¥
Am Heimatknoten einer Transaktion Ti mu§ der Transaktionsverwalter eine Operation
pi(x) umsetzen in eine oder mehrere Operationen der Art pi(xA), wobei xA eine Kopie
von x ist, die auf Knoten A gespeichert ist.
Um herauszufinden, welche Kopien von x verfŸgbar sind,
unterhŠlt der Transaktionsverwalter ein Verzeichnis,
in dem alle Kopien aller Datenelemente verzeichnet sind.
(Das Verzeichnis wiederum kann zentral oder dezentral, mit oder ohne Replikation
realisiert sein)
Der Planer (scheduler) am Ort A wei§ nichts von der Existenz weiterer Kopien.
Er behandelt pi(xA), als ob nur dieses eine Exemplar existiert,
d.h. er koordiniert nur Zugriffe auf dieses eine Exemplar.
Bei AusfŠllen kšnnen einige Kopien nicht verfŸgbar sein.
Wir nehmen an, da§ eine Kopie xA an Knoten A fŸr Ort B verfŸgbar ist,
wenn A die Operation an xA
korrekt ausfŸhrt und B eine entsprechende Quittung
erhŠlt.
6-55
© H.-U. Hei§, Uni-Paderborn
6.7.2 Schreiben aller verfŸgbarer Kopien
(Write-All-Available-Algorithmus)
¥
Leseoperationen kšnnen auf jeder beliebigen Kopie durchgefŸhrt werden
(diejenige, die zu den geringsten Kosten erreichbar ist)
¥
Schreiboperationen mŸssen auf allen Kopien durchgefŸhrt werden.
¥
Ist ein Knoten A ausgefallen, so kann eine Schreiboperation an einem xA nicht
durchgefŸhrt werden, d.h. die Operation ist solange zu verzšgern, bis A wieder
betriebsbereit ist. (Write-All-Algorithmus)
Dies ist in der Regel nicht tolerabel.
¥
Man vermeidet eine solche lange Verzšgerung,
indem man die Schreiboperation nur an den aktuell erreichbaren Kopien durchfŸhrt.
(Write-All-Available-Algorithmus)
Damit handelt man sich jedoch neue Probleme ein.
6-56
© H.-U. Hei§, Uni-Paderborn
Beispiel:
Write-All-Available-Algorithmus
w0 (x A )
w0 (x B )
© H.-U. Hei§, Uni-Paderborn
B fällt aus
c0
B
B ist wieder operabel
r1 (yC )w1 (x A )c1
B
r2 (x B )w2 (yC ) c2
w0 (yC )
T2 liest veraltete Daten
Wegen der Unerreichbarkeit einiger Kopien kšnnen globale Konflikte zwischen
Operationen gelegentlich unerkannt bleiben.
Daher ist eine zusŠtzliche Validierung erforderlich.
Ein Teil der fŸr die Validierung notwendigen Kommunikation kann in das Commit-Protokoll
integriert werden.
Der ãWrite-all-Available-Algorithmus ermšglicht
ãbilligeÒ Leseoperationen auf Kosten ãteurerÒ Schreiboperationen.
Sei listx die Liste aller Knoten, die eine Kopie von x besitzen.
Transaktionsverwalter empfŠngt Read(x) von Ti
failed := false;
availx := listx;
start:A:= nearest(availx);
send (Read(xA)) to A;
wait (response);
on timeout
begin
availx := availx \ { A};
if (availx - ∅ )
then goto start;
else failed := true;
end;
if (failed or response = ÔrejectedÕ)
then abort(Ti);
else
begin
send (xA) to Ti;
access(Ti) := access(Ti) ∪ {xA};
end;
6-57
6-58
© H.-U. Hei§, Uni-Paderborn
Transaktionsverwalter empfŠngt Write(x) von Ti
abort := false;
missingx := ∅ ;
send (Write(xA)) to all A ∈ listx;;
wait (responses);
on timeout of response(A)
begin
missingx := missingx ∪ {xA};
for each response Aj received
do;
if (response = ÔrejectedÕ)
then abort := true;
else access(Ti) := access(Ti) ∪ {xA};
end do;
if (missingx = listx) then abort := true;
if (abort)
then Abort(Ti);
else
begin
missing(Ti) := missing(Ti) ∪ missingx;
send ack to Ti
end;
6-59
© H.-U. Hei§, Uni-Paderborn
Validierung von Ti
abort := true;
send (UNAVAILABLE(xA)) to all sites A with xA ∈ missing (Ti);
wait (responses);
on timeout of all abort :=false;
if (abort)
then
begin
Abort (Ti);
return;
end;
send (AVAILABLE(xA)) to all sites A with xA ∈ access (Ti);
wait (responses)
on timeout of any
begin
Abort (Ti);
return;
end;
Commit (Ti);
return;
6-60
© H.-U. Hei§, Uni-Paderborn
© H.-U. Hei§, Uni-Paderborn
6.7.3 Der PrimŠrkopie-Algorithmus
6.7.4 Der Quorum-Algorithmus
Um die Kosten fŸr eine Schreiboperation zu reduzieren, erfordert der Primary-CopyAlgorithmus lediglich die €nderung einer Kopie, der PrimŠrkopie (primary copy oder master
copy)
Das Schreiben der anderen Kopien wird erst nach der BestŠtigung der Transaktion
vollzogen.
Der Quorum-Algorithmus liegt gewisserma§en ãzwischenÒ dem Primary-Copy-Verfahren
(ãnur eine Kopie wird geschriebenÒ) und dem ãWrite-all-Available-Verfahren (ãalle Kopien
werden geschriebenÒ).
Die Grundidee besteht darin, da§ es genŸgt, eine qualifizierte Mehrheit (Quorum) der
Kopien zu aktualisieren.
In Kombination mit dem Zwei-Phasen-Sperren gibt es zwei Alternativen
Jede Kopie xA von x erhŠlt ein nichtnegatives Gewicht (Anzahl der Stimmen).
a)
Eine Schreiboperation erfordert Sperren auf allen (verfŸgbaren) Kopien.
Dadurch wird eine konsistente Sicht gewŠhrleistet.
Leseoperation werden verzšgert, da sie auf Freigabe der Sperren warten mŸssen.
Eine Leseschwelle RT (read threshold) und eine Schreibschwelle WT (write threshold) sind
so definiert, da§ gilt:
b)
Eine Schreiboperation erfordert eine Sperre lediglich auf der PrimŠrkopie.
Lesetransaktionen, die nicht unbedingt die jŸngste Version benštigen,
kšnnen irgendeine
Kopie lesen.
Lesetransaktionen, die die jŸngste Version brauchen,
mŸssen eine Lesesperre aus die PrimŠrkopie anfordern.
(i)
WT > TW / 2
(ii) RT + WT > TW
Dabei ist TW die Summe aller Gewichte (total weight), die den Kopien von x zugewiesen
wurden.
6-61
6-62
© H.-U. Hei§, Uni-Paderborn
Der Quorum-Algorithmus
© H.-U. Hei§, Uni-Paderborn
Beispiele für Quoren
Eine Menge von Kopien von x hei§t Lese-Quorum (bzw. Schreib-Quorum), wenn ihr
akkumuliertes Gewicht grš§er ist als die Leseschwelle (bzw. Schreibschwelle)
RT = 2
Der Transaktionsverwalter, der eine Leseoperation (bzw. Schreiboperation) empfŠngt,
erzeugt daraus Leseoperationen (bzw. Schreiboperationen) fŸr jede Kopie eines LeseQuorums (bzw. Schreib-Quorums).
WT=8
A
B
C
Die Schwellenbedingung (i) bewirkt,
da§ nicht mehr als eine Schreiboperation zu einem Zeitpunkt stattfinden kann.
D
E
F
Die Schwellenbedingung (ii) bewirkt,
da§ nicht auf dasselbe Datenelement nebenlŠufig gelesen und geschrieben werden kann.
G
H
I
RT = 5
Lesequorum
Schreibquorum
Es ist au§erdem sichergestellt, da§ jedes Lese-Quorum mindestens einen aktuellen Wert
enthŠlt.
6-63
6-64
WT = 5
A
B
C
D
E
F
G
H
I
© H.-U. Hei§, Uni-Paderborn
Der Quorum-Algorithmus
© H.-U. Hei§, Uni-Paderborn
Versionssteuerung bei Quoren
Transaktionsverwalter empfŠngt Write(x) von Ti
RT = 5
WQ := find_write_quorum;
send (Write(xA)) to all A WQ;
wait (responses);
vmax := max {vn(xA)| A ∈ WQ}
for each A ∈ WQ
do vn(xA) := vmax+1; end do;
send (vn(xA)) to all A ∈ WQ;
send (ack) to Ti;
WT = 5
Versionsnummern
5
5
3
5
5
3
5
5
3
6
5
3
6
7
7
6
7
7
4
6
4
7
7
7
7
7
7
Transaktionsverwalter empfŠngt Read(x) von Ti
RQ := find_read_quorum;
send (Read(xA)) to all A ∈ RQ;
wait (responses);
youngest := xAj where vn(xAj) = max { vn(xA)| A ∈ RQ}
send (youngest) to Ti;
6-65
Vor Schreiboperation
Nach Schreiboperation
6-66
Nächste Leseoperation