7 . V e rte ilte T ra n s a k tio n e n

7.1
7.2
7.3
7.4
O. Kao
Systemaspekte Verteilter Systeme
Verteilte Datenbanksysteme
Verteilte Transaktionen
Dezentrale Koordination
Replikation
• Überblick
7. Verteilte Transaktionen
7-1
O. Kao
Systemaspekte Verteilter Systeme
7-2
Beispiel: multimediale Datenbank über Filme kann auf zwei Arten aus
mehreren lokalen Datenbanken aufgebaut werden
Lokale Datenbanken speichern Medien und Metainformationen, z.B.
Bilddatenbank mit Fotos von Schauspielern, Bilddatenbank mit
Keyframes aus verschiedenen Filmen, Videoserver sowie relationale
Datenbanken mit bibliografischen und Filmangaben
Jede lokale Datenbank enthält eine Teilmenge des Filmmaterials,
z.B. nach Herstellerland geordnet
In beiden Fällen ermöglicht eine zentrale Schnittstelle den Zugriff auf die
Daten in allen lokalen Datenbanken
• „Natürliche“ Datenverteilung: mehrere unabhängige Systeme mit
ihren lokalen Datenmengen werden zu einer Einheit kombiniert
Unter VDBS wird eine logisch integrierte Sammlung gemeinsam
genutzter Daten verstanden, die physikalisch auf einer Anzahl von
Knoten in einem Rechnernetzwerk verteilt ist
• Definition: Verteiltes Datenbanksystem (VDBS)
7.1 Verteilte
Datenbanksysteme
O. Kao
Systemaspekte Verteilter Systeme
DBMS = Datenbankmanagementsystem
Klassifikation Verteilter
Datenbanksysteme
7-3
O. Kao
Systemaspekte Verteilter Systeme
Zugriff auf alle Teile der
lokalen Datenbanken zentral über
ein einheitliches Schema
Fragmentierungsschicht:
Unterteilung der globalen
Operationen in Segmente für
einzelne Knoten ⇒ notwendige
Einschränkungen zur sinnvollen
Vereinigung der Teilergebnisse
Allokationsschicht: Zuordnung von
Fragmenten zu Knoten, besonders
wichtig in Kombination mit
Replikation, Scheduling, ….
• Homogene VDBS leiten sich aus
konventionellen DBS durch
Partitionierung der Daten auf
mehrere Knoten ab
Homogene VDBS
7-4
O. Kao
Systemaspekte Verteilter Systeme
7-5
Zentrale Schnittstelle zur Abfrage / Kombination der Ergebnisse
Lokaler Zugriff ohne Nutzung globaler Schnittstellen und -mechanismen
erlaubt ⇒ Mitgliedschaft im globalen System bleibt unsichtbar
• Vollintegrierte DBS: bereits vorhandene Datenbanken werden über
Konvertierungssubsysteme in ein neues globales System gekoppelt
• Partiell integrierte DBS
Umsetzungsschemata zur vollständigen Integration im globalen DBS
Schnittstellen (Gateways) für den Zugriff auf die lokalen Daten
Beispiel: Metasuchmaschinen geben Stichwörter nach syntaktischer
Anpassung in mehrere Suchmaschinen ein ⇒ Parallele Bearbeitung
Syntaktische Umwandlung betrifft die Formulierung der logischen
Ausdrücke, z.B. Wort1 AND Wort2 wird zu +Wort1+Wort2
• Verschiedene DBS auf den Knoten erlaubt ⇒ Vorteil der einheitlichen
Verteilung/Ausführung der Operationen existiert nicht mehr
• Die einzelnen Systeme verfügen über
Heterogene VDBS
O. Kao
Systemaspekte Verteilter Systeme
Lokale DBS erlauben – je nach
Autonomiegrad – die
Aufnahme von Teilen der
Daten im globalen Schema
Auf die anderen Daten kann
nur lokal zugegriffen werden
Hilfsschema legt die Regel für
die Datenkonvertierung fest,
z.B. 13. November 2000 in
2000/11/13
• Eng verbundene (Tightly
coupled) DBS verfügen über
ein globales konzeptionelles
Schema als Vereinigung von
Teilen der lokalen Schemata
Föderierte Datenbanksysteme
7-6
O. Kao
Systemaspekte Verteilter Systeme
Transaktionskontrolle muss auf alle beteiligten Knoten verteilt werden
⇒ Anpassung der bestehenden Verfahren notwendig
Berücksichtigung der Replikation
Alle Knoten müssen stets die aktuelle Version der Daten haben
• Dieses Allokationsproblem ist NP-vollständig ⇒ Einsatz von
Heuristiken
• Bei VDBS wird eine Transaktion in mehrere Subtransaktionen –
Agenten – unterteilt und an die entsprechenden Knoten versendet
Datenlokalität (Benötigte Daten auf einem Knoten) und
Nebenläufigkeit (Daten gleichmäßig über alle Knoten verteilt)
7-7
• Wesentliche Bedingungen aus Verteilung der Daten über die Knoten
• Kompromiss zwischen
Datenmanagement in verteilten
Datenbanksystemen
T
Client
T
O. Kao
Z
Y
X
T2
T1
Y
X
Systemaspekte Verteilter Systeme
T
Client
M
T22
P
T 12
N
T21
T11
7-10
Flache Transaktion: Die aktuelle Anforderung der Transaktion wird
abgeschlossen, bevor die nächste Anforderung abgesetzt wird
Verschachtelte Transaktion: Top-Level-Transaktion öffnet untergeordnete
Transaktionen, die wieder weitere Anforderungen absetzen können
• Transaktionsarten
Atomarität: Transaktion ist entweder bei allen Servern festgeschrieben
oder wird von allen Servern abgebrochen
⇒ Koordination durch einen/mehrere Server erforderlich
• Verteilte Transaktion greifen auf Objekte zu, die auf mehreren räumlich
getrennten Servern verteilt sind
7.2 Verteilte Transaktionen
T12
T1m
T22
T2m
Daten
Daten
Systemaspekte Verteilter Systeme
Ressourcenmanager
Ressourcenmanager
O. Kao
Scheduler
Tn2
Tnm
Daten
7-11
Ressourcenmanager
Scheduler
Transaktionsmanager
Tn1
Kommunikationsnetz
Transaktionsmanager
T21
Scheduler
Transaktionsmanager
T11
Architektur verteilter
Transaktionssysteme
O. Kao
Systemaspekte Verteilter Systeme
7-12
Knotenfehler: Der Knoten stoppt sofort und führt keinerlei Operationen
mehr durch ⇒ Der Inhalt des flüchtigen Speichers geht verloren und der
Knoten muss eine Restart-Operation durchführen
Netzfehler: Ausfall der Verbindung, Fehler in Kommunikationssoftware,
Ausfall eines Zwischenknoten, Nachrichtenverlust und -verfälschung
• Fehlerarten
Homogene Umgebung existiert ⇒ Jeder Knoten besteht aus einem lokalen
Transaktionsverwaltungssystem
Jeder Knoten verwaltet einen Teil der Daten
Jedes Datum befindet sich auf genau einem Knoten (keine Redundanz)
Eine Transaktion sendet Operationen an lokalen Transaktionsmanager 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 muss der TM alle Knoten verständigen, die von der
Transaktion betroffen waren
• Annahmen
Architektur verteilter
Transaktionssysteme (2)
O. Kao
join
join
b.withdraw(3);
a.withdraw(4);
7-13
Teilnehmer
c.deposit(4);
C
D
d.deposit(3);
Filiale Z
B
Filiale Y
Teilnehmer
A
Filiale X
Teilnehmer
Systemaspekte Verteilter Systeme
join
b.withdraw(T, 3);
.
Koordinator ist einer der Server, z.B. Filiale X
T =openTransaction
a.withdraw(4);
c.deposit(4);
b.withdraw(3);
d.deposit(3);
closeTransaction
T
Client
openTransaction
closeTransaction
Verwalter öffnet die Transaktion, vergibt systemweit-eindeutige ID
Verwalter wird zur Koordinator für die gesamte Transaktion ⇒
Verantwortung für Annahme/Abbruch der Transaktion
Teilnehmer = Server, die benötigte Objekte bereitstellen
• Client startet eine verteilte Transaktion durch eine openTransaction
Anforderung an einen Transaktionsverwalter auf beliebigem Server
Koordinator einer Verteilten
Transaktion
O. Kao
Systemaspekte Verteilter Systeme
• Bei Aufruf von closeTransaction besitzt der Koordinator Verweise
auf alle Teilnehmer
• Sicherstellung der Atomaritätseigenschaft mit sog. CommitProtokollen
7-14
Koordinator erstellt Liste mit Verweisen auf alle Teilnehmer
Teilnehmer notieren den Koordinator
Hinzufügen von weiteren Teilnehmern mit der Funktion join(Trans-ID,
Verweis auf neuen Teilnehmer)
⇒ Koordinator wird über die Neuzugänge informiert
• Während der Ausführung der verteilten Transaktion
Koordinator einer Verteilten
Transaktion (2)
O. Kao
RM
Daten
Daten
Sch.
TM
RM
TM
T11 T12 T1m T21 T22 T
2m
Systemaspekte Verteilter Systeme
Zentrale darf nicht ausfallen
Eingeschränkte Skalierbarkeit
Eingeschränkte Knotenautonomie
Auch ausschließlich lokale
Transaktionen müssen sich an den
zentralen Planer wenden ⇒ unnötiger
Aufwand
• Nachteile
2PL-Sperrprotokoll: Globale Sicht auf
die Sperrsituation, wie im lokalen Fall
Optimistische Verfahren: Nach
Abschluss muss jede Transaktion
ihren r/w-Set an die zentrale
Validierungsstelle senden
• Zentraler Planer verwaltet alle
Transaktionen
Koordination durch zentralen
Planer
7-15
Daten
RM
TM
Tn1 Tn2 Tnm
O. Kao
Systemaspekte Verteilter Systeme
7-16
• Einfachste Realisierung: Koordinator fordert alle Teilnehmer solange
auf, die aktuelle Transaktion zu bestätigen/abbrechen, bis alle
geantwortet haben (Ein-Phasen-Commit-Protokoll, 1PC)
1. Alle Knoten, die eine Entscheidung treffen, treffen dieselbe Entscheidung
2. Ein Knoten kann seine Entscheidung nicht nachträglich ändern
3. Die Entscheidung, eine Transaktion zu bestätigen, kann nur von allen
Knoten einstimmig getroffen werden
4. Falls keine Ausfälle vorliegen und alle Knoten zugestimmt haben, wird
die Transaktion bestätigt
5. Nach Behebung von Ausfällen muss eine Entscheidung getroffen werden
• Gewährleistung der Korrektheit eines Transaktionskonzepts ist
schwierig, da es im verteilten Fall einer Abstimmung der Knoten
bedarf und Ausfälle nicht ausgeschlossen werden können
• Anforderung an ein atomares Commit-Protokoll (ACP) für verteilte
Transaktionen
7.3 Dezentrale Koordination
O. Kao
Systemaspekte Verteilter Systeme
• Probleme: Sicherstellung, dass alle Teilnehmer abstimmen und die
getroffene Entscheidung tatsächlich umsetzen
7-17
Jeder Knoten unterhält eine spezielle Log-Datei mit relevanten Ereignissen
In der ersten Vorbereitungsphase (Abstimmphase) wird abgestimmt, ob
die Transaktion festgeschrieben oder abgebrochen wird
Ist einmal ein Votum abgegeben, so darf das Votum nicht geändert
werden auch wenn das System ausfällt ⇒ alle relevanten Daten müssen
im stabilen Speicher zusammen mit dem Status prepared sein
In der zweiten Phase (Abschlussphase) wird die getroffene Entscheidung
von jedem Teilnehmer durchgeführt
• Probleme bei 1PC: Ein Server kann die Transaktion nicht einseitig
abbrechen, z.B. wenn Konflikte oder Deadlocks aufgetreten sind
• Bei 2PC kann jeder Teilnehmer seinen Transaktionsteil abbrechen und
somit den Abbruch der gesamten Transaktion herbeiführen
• Grundidee
Zwei-Phasen-Commit-Protokoll
(2PC)
•
•
O. Kao
Systemaspekte Verteilter Systeme
7-18
ob er eine Transaktion festschreiben kann. Teilnehmer stimmt ab
doCommit(trans): Koordinator->Teilnehmer: Festschreiben der Transaktion
doAbort(trans) : Analog zu doCommit(), jetzt aber mit Abort
haveCommitted(trans, participant) : Teilnehmer->Koordinator: Transaktion
festgeschrieben
getDecision(trans) -> Yes / No: Teilnehmer->Koordinator mit Frage nach
Entscheidung über Transaktion, für die er mit Yes gestimmt hat aber noch
keine Antwort kam ⇒ Timeout zur Erkennung von Serverabstürzen
Das 2PC-Protokoll besteht aus vier Schritten
1. Aufforderung zur Stimmabgabe (vote request)
2. Stimmabgabe (vote)
3. Mitteilung über die Entscheidung (decision)
4. Bestätigung der Entscheidung (acknowledge)
Einzelne Operationen
canCommit?(trans)-> Yes / No: Aufruf vom Koordinator an den Teilnehmer,
Zwei-Phasen-Commit-Protokoll (2)
festgeschrieben
fertig
3
O. Kao
Vorbereitet auf
Festschreiben
(Wartet auf Stimmen)
1
Vorbereitet auf
Festschreiben
(unsicher)
Festgeschrieben
2
4
Systemaspekte Verteilter Systeme
haveCommitted
doCommit
Yes
canCommit?
Status
Schritt
Status
Schritt
Teilnehmer
Koordinator
• Koordinator fragt alle Teilnehmer canCommit() und sammelt die
Antworten
• Koordinator wertet alle Stimmen (auch die eigene) aus
Falls alle mit Yes gestimmt haben, so wird die Anweisung zum
Festschreiben doCommit() verteilt
Andernfalls wird die Transaktion abgebrochen doAbort()
• Alle Teilnehmer warten auf den Befehl, bestätigen die Ausführung
• Falls Bestätigung ⇒ haveCommited Nachricht an den Koordinator
Ablauf bei 2PC
7-19
O. Kao
Systemaspekte Verteilter Systeme
7-20
2PC kann mehrere Server-/Kommunikationsfehler tolerieren und wird
garantiert irgendwann abgeschlossen. Die Vorgabe einer Zeitgrenze ist
allerdings nicht möglich
Die Verzögerung bei der Ausführung von 2PC kann dazu führen, dass
einige Teilnehmer in einen unsicheren (ungewissen) Zustand geraten
Besonders kompliziert, wenn der Koordinator ausgefallen ist und auf
keine getDecision() Anforderung reagiert
⇒ Drei-Phasen-Commit-Protokolle (3PC) zur Reduktion der
Verzögerungen
• Ausfall- und Fehleranfälligkeit
Organisation der Koordinatoraktivitäten notwendig sind
• Kosten für das 2PC im fehlerfreien Fall sind bei N Teilnehmern
proportional zu 3N Nachrichten
Je N Nachrichten für canCommit, Yes/No und doCommit
haveCommited-Nachrichten werden nicht mitgezählt, da diese für die
Leistung des 2PC
O. Kao
Systemaspekte Verteilter Systeme
Der Verwaltungsaufwand ist deutlich höher, insgesamt werden 6N
Nachrichten und 3(N+1) Log-Vorgänge notwendig
• 3PC verhindert diese Situation, indem es sicherstellt, dass kein
Knoten Commit entschieden haben kann, solange noch ein nicht
ausgefallener Knoten ungewiss ist
• Allerdings
7-21
Blockieren im 2PC resultiert aus einer Situation, in der alle nicht
ausgefallenen Knoten im Zustand uncertain (ungewiss) sind und nicht
einseitig Abort entscheiden können, weil einige Knoten vielleicht schon
Commit entschieden haben
• Idee
Höchstens K<N Rechner fallen aus, K Verfahrensparameter
• 3PC-Protokoll: nicht-blockierende Verbesserung des 2PC-Protokolls
• Voraussetzung
Drei-Phasen-Commit-Protokoll (3PC)
O. Kao
Systemaspekte Verteilter Systeme
Teilnehmer gesendet ⇒ Teilnehmer schreiben die Daten fest
7-22
• Phase 3: Koordinator sammelt alle Bestätigungen
Wurden alle empfangen, wird commit ausgeführt und doCommit an alle
Anforderungen an die Teilnehmer
Teilnehmer protokollieren und bestätigen die preCommit-Anforderungen
• Phase 2: Koordinator nimmt Zwischenzustand (preCommit) ein ⇒
der Koordinator sichert zu, dass er von sich aus die Transaktion nicht
mehr abbrechen wird. Allerdings, falls er ausfällt ist ein Zurücksetzen
immer noch möglich
Koordinator protokolliert den Zustand und sendet preCommit-
Behandlung des Abort-Falls (mind. 1 Knoten stimmt mit Abort) wie 2PC
Yes: alle Knoten antworten mit Yes ⇒ zusätzliche Phase ⇒ Einsatz 3PC
• Phase 1: Analog zur ersten Phase von 2PC
• Der Koordinator sammelt die Stimmen und trifft eine Entscheidung
No: Abbruch und Information der mit Yes abgestimmten Teilnehmer ⇒
Ablauf bei 3PC
Logging preCommit
fertig
Logging preCommit
fertig
3
5
acknowledge
preCommit ack
Commit
preCommit
Yes
6
4
2
Logging Commit
Sperrfreigabe
Logging preCommit
Vorbereitet auf
Festschreiben
(ungewiss)
O. Kao
Systemaspekte Verteilter Systeme
7-23
Alle aktiven Teilnehmer wählen einen neuen Koordinator
Damit der neue Koordinator die commit-Behandlung fortführen kann,
wird ein Terminierungsprotokoll gestartet
• Ein Koordinatorausfall wird durch Time-Outs erkannt
Vorbereitet auf
Festschreiben
(Wartet auf Stimmen)
1
canCommit?
Status
Schritt
Status
Schritt
Teilnehmer
Koordinator
Ablauf bei 3PC (2)
O. Kao
Systemaspekte Verteilter Systeme
7-24
• Der neue Koordinator sammelt die Zustandsinformation aller
Teilnehmer und verfährt nach den folgenden Regeln
R1: Falls ein Knoten im Zustand finished oder aborted ist, so lautet die
Entscheidung abort
R2: Falls irgendein Knoten im Zustand commit ist, lautet die Entscheidung
commit
R3: Sind alle Knoten im Zustand uncertain, lautet die Entscheidung abort
R4: Sind einige Knoten im Zustand preCommit, aber keiner im Zustand
commit, sendet er preCommit an alle Knoten
• Nach Eingang der Quittungen (Ack) kann commit entschieden
werden
• Teilnehmer, die ihren Zustand nicht melden, werden ignoriert
3PC-Terminierungsprotokoll
O. Kao
Systemaspekte Verteilter Systeme
7-25
Die restlichen Knoten starten das Terminierungsprotokoll
Der (gewählte) neue Koordinator sammelt die Zustände der
operationalen Knoten (alle uncertain) und beschließt gemäß Regel
R3 abort
Ausgefallene Knoten starten nach dem Restart das
Terminierungsprotokoll und erfahren die Entscheidung abort
Obwohl sie bereits preCommit erhalten hatten, entscheiden sie Abort
• Angenommen, die Knoten im Zustand preCommit fallen ebenfalls
aus
uncertain
• Alle Teilnehmer haben mit Yes gestimmt
• Der Koordinator beginnt, preCommit zu verschicken, fällt aber aus,
so dass nur ein Teil der Knoten die Nachricht erhält
• Einige Knoten sind im Zustand preCommit, die anderen im Zustand
Beispiel zu 3PC
A
R1
(Paderborn)
O. Kao
R2
(Kassel)
Systemaspekte Verteilter Systeme
B
• Beispiel: Replizierte Kontodaten
R3
(Frankfurt)
Steigerung der Verfügbarkeit
Daten werden auf k Knoten kopiert ⇒ Daten bleiben auch beim
Ausfall von k-1 Knoten erhalten
Leistungssteigerung
Parallele Ausführung der Lesezugriffe für die gleichen Daten
Verringerung der Anzahl notwendiger Kommunikationsvorgänge
durch Unterstützung der Datenlokalität
• Ziele der Replikation
7.4 Replikation
7-26
A
B
O. Kao
Systemaspekte Verteilter Systeme
Es werden nur solche Schedules zugelassen, die zu serialisierbaren
Schedules auf einer nicht-redundanten Datenbank äquivalent sind
Insbesondere muss dies auch für mögliche Fehlerfälle gelten
• Anforderungen für Synchronisationsprotokolle, die das
Korrektheitskriterium der 1-Kopie-Serializierbarkeit unterstützen
Automatische, transparente Aktualisierung aller Repliken, sobald ein
Datum verändert wird
Aufrechterhaltung der Datenkonsistenz unter Berücksichtigung aller
Repliken
• Verwaltung replizierter Daten erhöht den Speicherbedarf und die
Kommunikationsleistung bei Schreibzugriffen
• Hoher Implementierungsaufwand, da ein verteiltes DBS die
Existenz der replizierten Daten für den Benutzer transparent sein
soll
Probleme mit replizierten
Daten
7-27
O. Kao
Systemaspekte Verteilter Systeme
7-28
Write-All-Ansatz: Synchrone Aktualisierung aller replizierten Kopien
Primary-Copy-Verfahren: Sofortige Aktualisierung einer Masterkopie,
die Veränderungen werden mit etwas Verspätung weitergegeben
Voting-Verfahren: Jede der Repliken bekommt eine oder mehrere
Stimmen zugeordnet. Bei jedem Schreib- oder Lesezugriff muss die
Mehrheit dieser Stimmen durch Sperren der entsprechenden Objekte
gewonnen werden
• Drei wichtigste Verfahrensklassen für die Aktualisierung und
Synchronisation auf replizierten Datenbanken
Ansätze
O. Kao
Systemaspekte Verteilter Systeme
7-29
Alle Lesezugriffe der Zentrale (R2) werden auf replizierten Daten und
ohne Verzögerung ausgeführt
Zugriff auf alle Daten trotz Ausfalls von einem der Rechner möglich
Allerdings erfordert die Aktualisierung der Kontodaten das Sperren
und die synchrone Aktualisierung beider Kopien
• Beispiel zu ROWA-Strategie (siehe Skizze auf Folie 7-33)
Synchrone Änderung aller Replikate vor Abschluss der
Änderungstransaktion
⇒ Jedes Replikat ist auf dem aktuellen Stand und kann für die
Lesezugriffe verwendet werden
⇒ Auswahl beim Lesen erfolgt basierend auf minimaler Kommunikation
oder Auslastung der einzelnen Knoten
⇒ Einzelne Knotenausfälle können problemlos kompensiert werden
• Bekanntestes Variante: Write-All-Read-Any oder auch Read-OnceWrite-All (ROWA) Strategie genannt
Varianten des Write-AllAnsatzes
O. Kao
Systemaspekte Verteilter Systeme
7-30
Die replizierten Datensätze werden nur auf den verfügbaren Rechnern
aktualisiert
Bei ausgefallenen Rechnern werden alle Aktualisierungen protokolliert
und beim nächsten Start nachgeholt
Probleme entstehen, wenn sich die Knoten in unterschiedlichen
Netzwerkpartitionen befinden
• Abgeschwächte Forderung Write-All-Available-Read-Any
Fällt nur einer der replizierten Knoten aus, so ist die gesamte
Datenbank nicht mehr funktionsfähig, da alle Knoten mit Replikaten
berücksichtigt werden müssen
• Entscheidender Nachteil: Ausfallsicherheit schlechter als bei nichtredundanten Datenbanken
Vor dem Zugriff muss eine Schreibsperre auf allen replizierten
Datensätzen – auf unterschiedlichen Knoten – erworben werden
Alle Knoten müssen an dem Commit-Protokoll beteiligt werden
• Änderung der Sperrprotokolle erforderlich
Nachteile der ROWA-Strategie
O. Kao
Systemaspekte Verteilter Systeme
7-31
Anforderung von Schreibsperren für alle Replikate (wie bei ROWA),
allerdings wird nur die primäre Kopie synchron aktualisiert
Die Sperre geht in Besitz des Primary-Copy-Rechners über, der dann
nach und nach die Replikate aktualisiert und erst nach Abschluss alle
Sperren wieder frei gibt
• Nachteil: Verzögerte Anpassung der Replikate
• Realisierung des Primary-Copy-Protokolls
Aktualisierungsnachrichten werden gebündelt und zusammen zum
Zielknoten übertragen
Primärkopien werden auf unterschiedlichen Knoten gespeichert, um
Engpässe zu vermeiden
• Effizienzvorteil
Effiziente Bearbeitung von Änderungen, indem nur ein Replikat – so
genannte Primärkopie – sofort aktualisiert wird
Die anderen Kopien werden asynchron vom Primary-Copy-Rechner aus
und sobald möglich (as soon as possible) aktualisiert
• Ziel
Primary-Copy-Verfahren
O. Kao
Systemaspekte Verteilter Systeme
7-32
Lesezugriff auf Primärkopie: Alle Lesetransaktion referenzieren nur die
primäre Kopie ⇒ keine Lokalität/Parallelität, lediglich Ausfallsicherheit
Lesezugriff auf lokale Kopien, Sperranforderung beim Primary-CopyRechner: Nur die Sperren werden beim primären Rechner positioniert,
die Zugriffe selbst können auf einem anderen Rechner erfolgen
Beim Sperren wird überprüft, ob das Datum aktualisiert werden
muss und ggf. die Aktualisierung bevorzugt behandelt
Entlastung des Primary-Copy-Rechners
Lokale Abwicklung von Lesezugriffen: Inkonsistenzen – in praktischen
Anwendungen von wenigen Sekunden – werden in Kauf genommen
und auf die Daten ohne vorherige Überprüfung der Primärkopie
zugegriffen ⇒ Anwendung nur in speziellen Fällen tolerierbar
• Schreibsperren werden nur noch zentral auf der Primärkopie
angefordert ⇒ Anzahl von Sperrkonflikte wird reduziert
• Behandlung der Lesezugriffe wegen eventuell veralteter,
inkonsistenter Daten erforderlich
Alternativen zum Primary-CopyProtokoll
O. Kao
Systemaspekte Verteilter Systeme
7-33
Primärkopie nicht erreichbar ⇒ keine Transaktion kann ausgeführt
werden, wenn sie diese Daten benötigt
Ausweg: Wahlalgorithmen zur Bestimmung einer neuen Primärkopie.
Vorraussetzung ist allerdings, dass die Repliken auf dem aktuellen Stand
sind bzw. gebracht werden können
• Was passiert, wenn der Knoten mit der Primärkopie ausfällt?
Die Primärkopien der Kontodatensätze liegen auf den Filialrechnern (R1
hält Primärkopie von A und R3 von B)
Sämtliche Lese- und Schreibzugriffe können lokal durchgeführt werden,
Kommunikation nur bei Kontenzugriffe der Zentrale (R2), d.h. Sperren
und Aktualisieren der Primärkopien
Strategie 1 verlangt Sperren und Lesen der Primärkopie ⇒
Nachrichten für Objektzugriff und Commit
Strategie 2 erfordert Nachrichten für Sperranforderung und –freigabe
Strategie 3 ist z.B. für globale Auswertungen ausreichend
• Annahmen
Beispiel zu Primary-CopyVerfahren
O. Kao
Systemaspekte Verteilter Systeme
7-34
• Vorteil: Objekte auch bei mehreren Knotenausfällen referenzierbar
• Nachteil: Jede Zugriff verlangt mehrere Nachrichten zur
Sicherstellung der Mehrheit
Die Transaktion muss die Mehrheit der Repliken des benötigten
Objekts sperren (Sperre = Stimme)
Beim Lesen wird analog eine Mehrheit der Repliken mit Lesesperren
belegt und ein Element referenziert
Somit ist es sichergestellt, dass das Objekt nicht von einer anderen
Transaktion zwischenzeitlich verändert werden kann
Mindestens ein der Replikate befindet sich auf dem aktuellen Stand
⇒ Aktualität der Replikate wird durch einen Änderungszähler festgestellt
• Vor jedem Zugriff auf ein repliziertes Datum müssen ausreichend
viele Stimmen (votes) gesammelt werden
• Mehrheits-Votum
Voting-Verfahren
O. Kao
Systemaspekte Verteilter Systeme
7-35
Je kleiner r bzw. w, desto schneller sind die Lese- bzw. Schreibzugriffe
Erhöhte Verfügbarkeit, da einige Rechner ausfallen dürfen
Lesebevorzugung geht auf Kosten der Schreiboperationen und umgekehrt
• Durch die Gewichte können sowohl die Kosten für Schreib/LeseZugriffe als auch die Verfügbarkeit bestimmt werden
Bedingung w>v/2 garantiert, dass kein Objekt gleichzeitig von mehr als 1
Transaktion geändert wird
Bedingung r+w>v verhindert, dass ein Objekt gleichzeitig gelesen und
geschrieben wird. Ferner wird sichergestellt, dass mindestens ein Objekt
zum letzten Schreib-Quorum gehörte
• Jedem Replikat eines Objektes wird ein bestimmtes Gewicht
(Stimmenanzahl) zugeordnet
• Zum Lesen bzw. Schreiben eines Datums wird eine bestimmte Anzahl
von Stimmen (Lese-Quorum bzw. Schreib-Quorum) gesammelt
• Es seien insgesamt v Stimmen möglich und r/w Lese/Schreib-Quorum
Gewichtetes Voting
(Quorum Consensus)
O. Kao
Systemaspekte Verteilter Systeme
Lesezugriffe können auf R1 lokal ausgeführt werden
Bei Schreibzugriffen sind allerdings mindestens 3 Rechner beteiligt.
Nach Ausfall von R1 ist das Objekt nicht mehr modifizierbar
• Lesezugriffe werden gegenüber von Schreibzugriffen bevorzugt,
wenn z.B. r=2 und w=4 gilt
7-36
Durch Bevorzugung von R1 ist ein schnellerer Zugriff auf die Daten
von R1 gewährleistet
Zugriff ist auch nach Ausfall von jedem der Rechner möglich. Wenn R1
intakt bleibt, dürfen auch zwei Rechner ausfallen
• Objekt A sei an vier Rechnern R1 bis R4 repliziert
• Stimmenverteilung <2,1,1,1>, d.h. R1 hat 2 Stimmen
• Wählt man r = 3 und w = 3, so sind 2 oder 3 Rechner bei jeder
Transaktion involviert
Beispiel zu Quorum-Verfahren
O. Kao
Systemaspekte Verteilter Systeme
• Hauptnachteil der Voting-Verfahren ist die geeignete Wahl der
Parameter, insbesondere wenn diese ohne oder mit geringer
Beteiligung des Systemverwalters erfolgen sollen
7-37
Mehrheitsverfahren: Jedes Replikat hat das gleiche Gewicht (1
Stimme)
ROWA-Verfahren: Jedes Replikat hat eine Stimme. Ferner ist r=1 und
w=v=Anzahl Replikate
Primary-Copy: Primärkopie bekommt 1 Stimme, alle anderen Replikate
bekommen keine Stimme und r=w=1 ⇒ Lesezugriffe müssen an
Primärkopie gerichtet werden, Repliken ohne Stimme werden ohne
Konsistenzzusicherung genutzt
• Durch spezielle Parameterwahl lassen sich das Mehrheits- und
das ROWA-Verfahren sowie eines der Primary-Copy-Protokolle
nachbilden
Vor- und Nachteile des
Quorum-Verfahrens
O. Kao
Systemaspekte Verteilter Systeme
CREATE SNAPSHOT underflow AS
SELECT KNR, KTONR, KTOSTAND
FROM KONTO WHERE KTOSTAND <0
REFRESH EVERY DAY
• Beispieldefinition
7-38
Entspricht materialisierten durch eine DB-Anfrage spezifizierten Sicht
Ergebnis der Anfrage wird als eigenständiges DB-Objekt unter einem
benutzerspezifizierten Namen abgelegt
Zugriff auf einen Schnappschuss erfolgt mit der jeweiligen DBAnfragesprache, nur Lesezugriffe zulässig
• Replikationsaufwand erhöht sich deutlich, wenn die Komponenten
geographisch weit verteilt sind und die Aktualisierungskosten
aufgrund der langsamen Netze noch höher sind
• Verringerung der Aktualisierungskosten durch Einführung von
Schnappschüssen (snapshots)
• Definition Schnappschuss
Schnappschuss-Replikation
O. Kao
Systemaspekte Verteilter Systeme
7-39
Qualität geringer als bei „echter“ Replikation ⇒ Daten im kontrollierten
Maß veraltet
Veraltete Daten reduzieren den Wert des Schnappschusses im Fehlerfall
• Nachteile
Durch Bindung an DB-Sprachen können beliebige Informationen (auch
aggregierte Informationen, Verknüpfungen, … ) zusammengefasst werden
Entlastung des Primary-Copy-Rechners, da alle Zugriffe lokal und ohne
Kommunikation erfolgen
Kein Synchronisationsproblem, da lediglich Leseoperationen zulässig
• Vorteile
Schnappschuss entspricht einer Kopie der Teilmenge aller überzogenen
Konten
Schnappschuss wird in explizit angegebenen Abschnitten aktualisiert
(REFRESH – Angabe)
• Im Beispiel
Eigenschaften des
Schnappschusses
O. Kao
Systemaspekte Verteilter Systeme
7-40
Quasi-Kopien: Verwendung von anwendungsbezogenem Wissen, um
die Aktualisierungen bei bedeutender Veränderung weiterzugeben
• Varianten
Ersatzteillisten bei KFZ-Betrieben
Buchkataloge in Bibliotheken
Telefonbücher
Andere Verzeichnisse, auf die vorwiegend lesend zugegriffen wird
⇒ Reduzierter Kommunikationsaufwand ist an dieser Stelle wichtiger als
die 100% Aktualität (auf Sekunde/Minute/Stunde genau)
• Die schwache Form der Replikation wird z.B. angewendet bei
Anwendungen für
Schnappschuss-Replikation