7. Verteilte Transaktionen 7.1 Verteilte Datenbanksysteme
Werbung
7. Verteilte Transaktionen • Überblick 7.1 7.2 7.3 7.4 Verteilte Datenbanksysteme Verteilte Transaktionen Dezentrale Koordination Replikation O. Kao Systemaspekte Verteilter Systeme 7-1 7.1 Verteilte Datenbanksysteme • Definition: Verteiltes Datenbanksystem (VDBS) Unter VDBS wird eine logisch integrierte Sammlung gemeinsam genutzter Daten verstanden, die physikalisch auf einer Anzahl von Knoten in einem Rechnernetzwerk verteilt ist • „Natürliche“ Datenverteilung: mehrere unabhängige Systeme mit ihren lokalen Datenmengen werden zu einer Einheit kombiniert 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 O. Kao Systemaspekte Verteilter Systeme 7-2 Klassifikation Verteilter Datenbanksysteme DBMS = Datenbankmanagementsystem O. Kao Systemaspekte Verteilter Systeme 7-3 Homogene VDBS • Homogene VDBS leiten sich aus konventionellen DBS durch Partitionierung der Daten auf mehrere Knoten ab 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, …. O. Kao Systemaspekte Verteilter Systeme 7-4 Heterogene VDBS • Verschiedene DBS auf den Knoten erlaubt ⇒ Vorteil der einheitlichen Verteilung/Ausführung der Operationen existiert nicht mehr • Die einzelnen Systeme verfügen über 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 • Vollintegrierte DBS: bereits vorhandene Datenbanken werden über Konvertierungssubsysteme in ein neues globales System gekoppelt • Partiell integrierte DBS Zentrale Schnittstelle zur Abfrage / Kombination der Ergebnisse Lokaler Zugriff ohne Nutzung globaler Schnittstellen und -mechanismen erlaubt ⇒ Mitgliedschaft im globalen System bleibt unsichtbar O. Kao Systemaspekte Verteilter Systeme 7-5 Föderierte Datenbanksysteme • Eng verbundene (Tightly coupled) DBS verfügen über ein globales konzeptionelles Schema als Vereinigung von Teilen der lokalen Schemata 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 O. Kao Systemaspekte Verteilter Systeme 7-6 Datenmanagement in verteilten Datenbanksystemen • Wesentliche Bedingungen aus Verteilung der Daten über die Knoten • Kompromiss zwischen Datenlokalität (Benötigte Daten auf einem Knoten) und Nebenläufigkeit (Daten gleichmäßig über alle Knoten verteilt) • 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 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 O. Kao 7-7 Systemaspekte Verteilter Systeme 7.2 Verteilte Transaktionen • Verteilte Transaktion greifen auf Objekte zu, die auf mehreren räumlich getrennten Servern verteilt sind Atomarität: Transaktion ist entweder bei allen Servern festgeschrieben oder wird von allen Servern abgebrochen ⇒ Koordination durch einen/mehrere Server erforderlich • Transaktionsarten 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 X T11 Client T T Y X T1 T 12 N T21 T T2 Client Y Z O. Kao M T22 Systemaspekte Verteilter Systeme P 7-10 Architektur verteilter Transaktionssysteme T11 T12 T1m Transaktionsmanager T21 T22 T2m Transaktionsmanager Tn1 Tn2 Tnm Transaktionsmanager Kommunikationsnetz Scheduler Scheduler Scheduler Ressourcenmanager Ressourcenmanager Ressourcenmanager Daten Daten Daten O. Kao Systemaspekte Verteilter Systeme 7-11 Architektur verteilter Transaktionssysteme (2) • Annahmen 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 • Fehlerarten 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 O. Kao Systemaspekte Verteilter Systeme 7-12 Koordinator einer Verteilten Transaktion • Client startet eine verteilte Transaktion durch eine openTransaction Anforderung an einen Transaktionsverwalter auf beliebigem Server 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 join openTransaction closeTransaction . T Client join Teilnehmer A Filiale X a.withdraw(4); Teilnehmer b.withdraw(T, 3); T =openTransaction a.withdraw(4); c.deposit(4); b.withdraw(3); d.deposit(3); closeTransaction join Koordinator ist einer der Server, z.B. Filiale X O. Kao B Filiale Y b.withdraw(3); Teilnehmer C c.deposit(4); D d.deposit(3); Filiale Z Systemaspekte Verteilter Systeme 7-13 Koordinator einer Verteilten Transaktion (2) • Während der Ausführung der verteilten Transaktion 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 • Bei Aufruf von closeTransaction besitzt der Koordinator Verweise auf alle Teilnehmer • Sicherstellung der Atomaritätseigenschaft mit sog. CommitProtokollen O. Kao Systemaspekte Verteilter Systeme 7-14 Koordination durch zentralen Planer • Zentraler Planer verwaltet alle Transaktionen 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 T11 T12 T1m T21 T22 T 2m TM • Nachteile TM Tn1 Tn2 Tnm TM Sch. 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 O. Kao RM RM RM Daten Daten Daten Systemaspekte Verteilter Systeme 7-15 7.3 Dezentrale Koordination • 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 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 • Einfachste Realisierung: Koordinator fordert alle Teilnehmer solange auf, die aktuelle Transaktion zu bestätigen/abbrechen, bis alle geantwortet haben (Ein-Phasen-Commit-Protokoll, 1PC) O. Kao Systemaspekte Verteilter Systeme 7-16 Zwei-Phasen-Commit-Protokoll (2PC) • 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 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: Sicherstellung, dass alle Teilnehmer abstimmen und die getroffene Entscheidung tatsächlich umsetzen O. Kao Systemaspekte Verteilter Systeme 7-17 Zwei-Phasen-Commit-Protokoll (2) • • 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, 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 O. Kao Systemaspekte Verteilter Systeme 7-18 Ablauf bei 2PC • 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 Koordinator Schritt 1 3 Teilnehmer Status Schritt Vorbereitet auf Festschreiben (Wartet auf Stimmen) festgeschrieben fertig Yes 2 Vorbereitet auf Festschreiben (unsicher) 4 Festgeschrieben doCommit haveCommitted O. Kao Status canCommit? Systemaspekte Verteilter Systeme 7-19 Leistung des 2PC • 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 Organisation der Koordinatoraktivitäten notwendig sind • Ausfall- und Fehleranfälligkeit 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 O. Kao Systemaspekte Verteilter Systeme 7-20 Drei-Phasen-Commit-Protokoll (3PC) • 3PC-Protokoll: nicht-blockierende Verbesserung des 2PC-Protokolls • Voraussetzung Höchstens K<N Rechner fallen aus, K Verfahrensparameter • Idee 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 • 3PC verhindert diese Situation, indem es sicherstellt, dass kein Knoten Commit entschieden haben kann, solange noch ein nicht ausgefallener Knoten ungewiss ist • Allerdings Der Verwaltungsaufwand ist deutlich höher, insgesamt werden 6N Nachrichten und 3(N+1) Log-Vorgänge notwendig O. Kao Systemaspekte Verteilter Systeme 7-21 Ablauf bei 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 ⇒ Behandlung des Abort-Falls (mind. 1 Knoten stimmt mit Abort) wie 2PC Yes: alle Knoten antworten mit Yes ⇒ zusätzliche Phase ⇒ Einsatz 3PC • 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 preCommitAnforderungen an die Teilnehmer Teilnehmer protokollieren und bestätigen die preCommit-Anforderungen • Phase 3: Koordinator sammelt alle Bestätigungen Wurden alle empfangen, wird commit ausgeführt und doCommit an alle Teilnehmer gesendet ⇒ Teilnehmer schreiben die Daten fest O. Kao Systemaspekte Verteilter Systeme 7-22 Ablauf bei 3PC (2) Koordinator Schritt 1 3 5 Teilnehmer Status Schritt Vorbereitet auf Festschreiben (Wartet auf Stimmen) Logging preCommit fertig Yes 2 Vorbereitet auf Festschreiben (ungewiss) 4 Logging preCommit 6 Logging Commit Sperrfreigabe preCommit preCommit ack Commit Logging preCommit fertig Status canCommit? acknowledge • Ein Koordinatorausfall wird durch Time-Outs erkannt Alle aktiven Teilnehmer wählen einen neuen Koordinator Damit der neue Koordinator die commit-Behandlung fortführen kann, wird ein Terminierungsprotokoll gestartet O. Kao Systemaspekte Verteilter Systeme 7-23 3PC-Terminierungsprotokoll • 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 O. Kao Systemaspekte Verteilter Systeme 7-24 Beispiel zu 3PC • 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 uncertain • Angenommen, die Knoten im Zustand preCommit fallen ebenfalls aus 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 O. Kao 7-25 Systemaspekte Verteilter Systeme 7.4 Replikation • Ziele der Replikation 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 • Beispiel: Replizierte Kontodaten A R1 (Paderborn) R3 (Frankfurt) B O. Kao A B R2 (Kassel) Systemaspekte Verteilter Systeme 7-26 Probleme mit replizierten Daten • 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 Automatische, transparente Aktualisierung aller Repliken, sobald ein Datum verändert wird Aufrechterhaltung der Datenkonsistenz unter Berücksichtigung aller Repliken • Anforderungen für Synchronisationsprotokolle, die das Korrektheitskriterium der 1-Kopie-Serializierbarkeit unterstützen 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 O. Kao Systemaspekte Verteilter Systeme 7-27 Ansätze • Drei wichtigste Verfahrensklassen für die Aktualisierung und Synchronisation auf replizierten Datenbanken 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 O. Kao Systemaspekte Verteilter Systeme 7-28 Varianten des Write-AllAnsatzes • Bekanntestes Variante: Write-All-Read-Any oder auch Read-OnceWrite-All (ROWA) Strategie genannt 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 • Beispiel zu ROWA-Strategie (siehe Skizze auf Folie 7-33) 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 O. Kao Systemaspekte Verteilter Systeme 7-29 Nachteile der ROWA-Strategie • Änderung der Sperrprotokolle erforderlich 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 • Entscheidender Nachteil: Ausfallsicherheit schlechter als bei nichtredundanten Datenbanken 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 • Abgeschwächte Forderung Write-All-Available-Read-Any 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 O. Kao Systemaspekte Verteilter Systeme 7-30 Primary-Copy-Verfahren • Ziel 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 • Effizienzvorteil Aktualisierungsnachrichten werden gebündelt und zusammen zum Zielknoten übertragen Primärkopien werden auf unterschiedlichen Knoten gespeichert, um Engpässe zu vermeiden • Nachteil: Verzögerte Anpassung der Replikate • Realisierung des Primary-Copy-Protokolls 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 O. Kao Systemaspekte Verteilter Systeme 7-31 Alternativen zum Primary-CopyProtokoll • Schreibsperren werden nur noch zentral auf der Primärkopie angefordert ⇒ Anzahl von Sperrkonflikte wird reduziert • Behandlung der Lesezugriffe wegen eventuell veralteter, inkonsistenter Daten erforderlich 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 O. Kao Systemaspekte Verteilter Systeme 7-32 Beispiel zu Primary-CopyVerfahren • Annahmen 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 • Was passiert, wenn der Knoten mit der Primärkopie ausfällt? 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 O. Kao Systemaspekte Verteilter Systeme 7-33 Voting-Verfahren • Vor jedem Zugriff auf ein repliziertes Datum müssen ausreichend viele Stimmen (votes) gesammelt werden • Mehrheits-Votum 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 • Vorteil: Objekte auch bei mehreren Knotenausfällen referenzierbar • Nachteil: Jede Zugriff verlangt mehrere Nachrichten zur Sicherstellung der Mehrheit O. Kao Systemaspekte Verteilter Systeme 7-34 Gewichtetes Voting (Quorum Consensus) • 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 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 • Durch die Gewichte können sowohl die Kosten für Schreib/LeseZugriffe als auch die Verfügbarkeit bestimmt werden 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 O. Kao Systemaspekte Verteilter Systeme 7-35 Beispiel zu Quorum-Verfahren • 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 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 • Lesezugriffe werden gegenüber von Schreibzugriffen bevorzugt, wenn z.B. r=2 und w=4 gilt 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 O. Kao Systemaspekte Verteilter Systeme 7-36 Vor- und Nachteile des Quorum-Verfahrens • Durch spezielle Parameterwahl lassen sich das Mehrheits- und das ROWA-Verfahren sowie eines der Primary-Copy-Protokolle nachbilden 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 • Hauptnachteil der Voting-Verfahren ist die geeignete Wahl der Parameter, insbesondere wenn diese ohne oder mit geringer Beteiligung des Systemverwalters erfolgen sollen O. Kao Systemaspekte Verteilter Systeme 7-37 Schnappschuss-Replikation • 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 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 • Beispieldefinition CREATE SNAPSHOT underflow AS SELECT KNR, KTONR, KTOSTAND FROM KONTO WHERE KTOSTAND <0 REFRESH EVERY DAY O. Kao Systemaspekte Verteilter Systeme 7-38 Eigenschaften des Schnappschusses • Im Beispiel Schnappschuss entspricht einer Kopie der Teilmenge aller überzogenen Konten Schnappschuss wird in explizit angegebenen Abschnitten aktualisiert (REFRESH – Angabe) • Vorteile 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 • Nachteile Qualität geringer als bei „echter“ Replikation ⇒ Daten im kontrollierten Maß veraltet Veraltete Daten reduzieren den Wert des Schnappschusses im Fehlerfall O. Kao Systemaspekte Verteilter Systeme 7-39 Anwendungen für Schnappschuss-Replikation • Die schwache Form der Replikation wird z.B. angewendet bei 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) • Varianten Quasi-Kopien: Verwendung von anwendungsbezogenem Wissen, um die Aktualisierungen bei bedeutender Veränderung weiterzugeben O. Kao Systemaspekte Verteilter Systeme 7-40
