4 - Datenbanken

wwwdb.inf.tu.dresden.de
  • Keine Tags gefunden...

4 - Datenbanken

Webscale Data Management 4 Verteilte Transak9onsverarbeitung © Prof. Dr.-­‐Ing. Wolfgang Lehner |


Mo)va)on Dresden DB2 -­‐70 DB1 Konto Haben 4711 2500 4711 10 Konto Haben 4711 2500 4711 10 DB3 -­‐2490 Um strenge Konsistenz in verteilten Systemen zu gewährleisten bedarf es der synchronen, verteilten Transak)onsverarbeitung. Paris © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 2


Gliederung Wiederholungen Transak1onsverarbeitung Besonderheiten im Verteilten Fall Two-­‐Phase Commit (2PC) § 2PC-­‐Protokoll § Fehlerszenarien und Recovery-­‐Fall Op1mierungen des 2PC § Freigabetopologien § 1PC, 3PC Ausblick Replika1on © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 3


Wiederholungen Transak1onsverarbeitung © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 4


Wiederholung Transak)onsverarbeitung Prinzip einer Transak1on § Folge von aufeinanderfolgenden DB-­‐Opera9onen, die eine Datenbank von einem konsistenten Zustand wieder in einen konsistenten Zustand überführt geklammert durch: BOT ........ EOT (Commit / Abort) § Eigenscha_en: Wahrung der ACID-­‐Eigenscha_en Atomicity, Consistency, Isola9on, Durability © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 5


Wiederholung 2-­‐Phasen-­‐Sperrprotokoll Phase 1: Wachstumsphase (mit/ohne Pre-­‐Claiming) Phase 2: Schrumpfphase (strict or dynamic) # Sperren 2PL # Sperren 2PL mit Pre-­‐Claiming BOT EOT Zeit BOT EOT Zeit # Sperren striktes 2PL # Sperren striktes 2PL mit Pre-­‐Claiming BOT EOT Zeit BOT EOT Zeit © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 6


Besonderheiten im Verteilten Fall © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 7


Transak)onsverarbeitung in VDBMS Aufgabe § Gewährleistung der ACID-­‐Eigenscha_en bei verteilter Ausführung (über mehrere Knoten hinweg) von Transak9onen T1 T2 VDBMS (Verteiltes Datenbankmanagementsystem) Knoten 1 Knoten 2 Knoten 3 Knoten 4 © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 8


Besonderheiten in VDBMS Fehlermöglichkeiten im verteilten Fall § Knotenfehler: Totalausfall / Par9eller Ausfall § Kommunika9onsfehler § Nachrichtenverlust, Nachrichtenverfälschung, Doppelte Nachrichten § Netzwerkpar99onierung: Au_eilung betriebsbereiter Rechner in disjunkte Par99onen § Gefährdung der Atomarität von Transak9onen (Consistency nach CAP) § Verteilte Commit-­‐Protokolle T1 VDBMS Knoten 1 Knoten 2 Anforderungen § Verteilte Synchronisa9on zur Gewährleistung der Konsistenz bei verschränkter Ausführung § Commit als atomares Ereignis! Gleichzei9gkeit bei verteilten Knoten § Deadlock-­‐Erkennung © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 9


Struktur verteilter Transak)onen Transak1onale Strukturen über mehrere Knoten § Heimat-­‐ oder Koordinatorknoten: Knoten, an dem die Transak9on gestartet wird § Lokale Transak3on: Transak9on, die vollständig am Heimat-­‐ knoten ausgeführt wird § Globale Transak3on: können sich bei VDBMS über mehrere Knoten erstrecken § Ablaufstruktur: bildet gerichteten Graphen (Transak9onsbaum) © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 10


Two-­‐Phase Commit (2PC) © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 11


Commit-­‐Behandlung in VDBMS Die EOT (End-­‐of-­‐Transac1on)-­‐Behandlung von globalen Transak1onen stellt in VDBMS eine Herausforderung dar Eine globale Transak1on muss atomar beendet werden, d.h. entweder § COMMIT à globale Transak9on wird an allen (relevanten) lokalen Knoten festgeschrieben § ABORT à globale Transak9on wird an allen (relevanten) Knoten nicht festgeschrieben Problem in verteilter Umgebung § die Sta9onen eines VDBMS können unabhängig voneinander "abstürzen" Two-­‐Phase-­‐Commit sichert die Integrität bei verteilten Aktualisierungen § Aktualisierung von logisch zusammen gehörenden, aber physisch verteilten Datenbeständen § Aktualisierung von Kopien (gleiche Datenbestände auf verschiedenen Knoten) à Replika9on © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 12


Beispiel Hochzeit DB2 DB1 READY READY (1b) PREPARE: Nun frage ich Sie, Frau KNOTEN 2, ist es auch Ihr freier Wille, mit dem hier anwesenden Herrn KNOTEN 1 die Ehe einzugehen, so beantworten auch Sie diese Frage mit einem "Ja". ACK ACK (1a) PREPARE: Ich frage Sie, Herr KNOTEN 1, ist es Ihr freier Wille, mit der hier anwesenden Frau KNOTEN 2 die Ehe einzugehen, so beantworten Sie diese Frage mit einem "Ja". (2b) COMMIT: Nachdem Sie beide meine Fragen übereins9mmend mit einem "Ja" beantwortet haben, erkläre ich Sie kra_ Gesetzes zu rechtmäßig verbundenen Eheleuten. DB3 (2a) COMMIT: Nachdem Sie beide meine Fragen übereins9mmend mit einem "Ja" beantwortet haben, erkläre ich Sie kra_ Gesetzes zu rechtmäßig verbundenen Eheleuten. © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 15


Zustandsübergänge – Agenten Timeout oder lokaler Fehler entdeckt: § abort ins Log § sende FAILED ABORT empfangen: § abort ins Log § sende ACK Wartend Bereit PREPARE empfangen und lokal alles okay: § Log-­‐Einträge ausschreiben § ready ins Log § sende READY COMMIT empfangen: § commit ins Log § sende ACK Abgebrochen Festgeschrieben PREPARE empfangen: § sende FAILED © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 18


Fehlerszenario Verlorene Nachricht Situa1on 1 § PREPARE-­‐Nachricht des Koordinators an einen Knoten geht verloren oder § READY-­‐ (oder FAILED-­‐)Nachricht eines Knotens geht verloren à nach TIMEOUT-­‐Intervall geht Koordinator davon aus, dass betreffender Knoten nicht funk9onsfähig ist und sendet ABORT-­‐Nachricht an alle Knoten (Transak9on gescheitert) Situa1on 2 § Knoten erhält im Zustand READY keine Nachricht vom Koordinator à Knoten ist blockiert, bis COMMIT-­‐ oder ABORT-­‐Nachricht vom Koordinator kommt, da Knoten nicht selbst entscheiden kann à Knoten schickt eine „Erinnerung“ an den Koordinator Situa1onen ähnlich zum Ausfall des Koordinators / eines Knotens © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 22


Op1mierungen des 2PC © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 23


Charakteris)sche Eigenscha]en 2PC Fehlertoleranz § Netzwerkfehler und Knotenfehler werden toleriert, sofern keine Protokollinforma9on verloren geht § Beim Wiederanlauf ausgefallener Knoten muss der Zustand unterbrochener Transak9onen der Protokollinforma9on entnommen werden Problem Blockierung § Ein Teilnehmer der mit ready ges9mmt hat und das globale Ergebnis noch nicht kennt, befindet sich in der Unsicherheitsphase § Ressourcen werden von Teiltransak9onen in der Unsicherheitsphase ggf. unnö9g lange gesperrt § Lösung: 3PC Problem Hohes NachrichtenauFommen (Komplexität) § Bei n Teilnehmern 4(n-­‐1) Nachrichten im fehlerfreien Fall § Im Fehlerfall kommen weitere Nachrichtenrunden hinzu! § Lösung: 1PC (aber auch andere) © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 24


Freigabetopologien Aufgabe § Legt fest, welcher Knoten mit welchen anderen Knoten Nachrichten auszutauschen hat Bisher: Implizit Baum der Höhe 1 Hierarchische Zwei-­‐Phasen-­‐Freigabe © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 25


Lineare Zwei-­‐Phasen-­‐Freigabe Idee § Commit Behandlung sequen9ell durch die beteiligten Transak9onsmanager § Phase 1: Vorwärts-­‐Kommunika9on (READY / FAILED) § Phase 2: Umgekehrte Reihenfolge (COMMIT / ABORT) Ansatz § Koordinator bringt sich selbst in PREPARED Zustand und gibt die lokale Entscheidung (READY / FAILED) an den Nachfolger in der Kexe weiter § Ein Mitglied der Kexe gibt die Nachricht READY an den Nachfolger weiter falls der Vorgänger mit READY ges9mmt hat und die lokale Entscheidung auch READY lautet. § Falls der Vorgänger mit FAILED ges9mmt hat oder die lokale Entscheidung FAILED heißt, erhält der Nachfolger die Nachricht FAILED § Der letzte in der Kexe übernimmt die Koordinatorrolle und protokolliert das globale Commit-­‐Ergebnis § Commit-­‐Ergebnis wird in umgekehrter Reihenfolge bis zum Ini9ator weitergereicht. Dieser bestä9gt den Erhalt des Ergebnisses beim letzten TM Vorteil: Geringe Anzahl von Nachrichten: nur 2n-­‐1 Nachrichten! Nachteil: Bei großem n signifikante Erhöhung der Antwortzeiten! © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 26


Op)mierung von 2PC-­‐Verfahren Presumed Abort § Bei späteren Anfragen wird aus dem Nichtvorhandensein eines Abort-­‐Eintrages in der Logdatei des Koordinatorknotens auf das Commit dieser Transak9on geschlossen Vorteile § Koordinator braucht Abort-­‐Satz nicht mehr synchron zu schreiben § ACK-­‐Nachrichten für gescheiterte Transak9on überflüssig § Schreiben der Ende-­‐Sätze bei Koordinator und Zwischenknoten enzällt § Allerdings keine Einsparungen für erfolgreiche globale Transak9onen Ähnlich: Presumed Commit § Wenn kein Abort-­‐Eintrag gefunden wird auf Commit geschlossen © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 27


Op)mierung von 2PC-­‐Verfahren (2) Op1mierung nur-­‐lesender Sub-­‐Transak1onen § Weder Logging noch Recovery, nur Sperren freigeben § Kann bereits in Phase 1 des 2PC-­‐Protokolls geschehen, unabhängig davon, ob globale Transak9on erfolgreich; zweite Commit-­‐Phase ganz einsparen Bewertung § m der n-­‐1 Sub-­‐Transak9onen sind Leser (m < n) § Reduk9on der Zahl der Nachrichten im Basisverfahren um 2m auf 4(n -­‐ 1) -­‐ 2m § Reduk9on der Zahl der Log-­‐Schreibvorgänge auf 2n-­‐m Sonderfall § Reine Lese-­‐Transak9onen (m = n) nur 2*(n-­‐1) Nachrichten und keine Log-­‐Zugriffe Bei kurzen Lesesperren (Konsistenzebene 2, “Cursor Stability“) § Commit-­‐Behandlung enzällt bei lesenden Sub-­‐Transak9onen vollständig, nur noch 4*(n-­‐m-­‐1) Nachrichten © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 28


1PC (One-­‐Phase-­‐Commit) Mo1va1on § 2PC: verrichtete Arbeit getrennt vom Commit-­‐Protokoll § Bei kurzen (verteilten) Transak9onen mit nur einer externen DB-­‐Opera9on ist die Commit-­‐Behandlung aufwändiger als die eigentliche Transak9on Work & Prepare Konzept Primär Sub § PREPARE-­‐Aufforderung bereits mit Work-­‐Aufruf verbinden § Sub-­‐Transak9on geht unmixelbar nach Ausführung der Opera9on und vor Done & Ready Commit Ack Rückmeldung an die Sub-­‐Transak9on in PREPARED-­‐Zustand § Erste Commit-­‐Phase kann eingespart werden, eigentliche Commit-­‐Bearbeitung nur noch eine Phase zur Mixeilung des Ergebnisses (daher „1-­‐Phasen-­‐Freigabe“) à Pro Teilnehmer 2 Nachrichten weniger © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 29


1PC (One-­‐Phase-­‐Commit) Klassisches 2PC 1PC Grundsätzliches Problem bei 1PC § Frühzei9ger Übergang in PREPARE-­‐Zustand erhöht Wahrscheinlichkeit einer Blockierung; hängt davon ab, wie viel weitere Arbeit globale Transak9on noch auszuführen hat © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 30


3PC (Three-­‐Phase-­‐Commit) Mo1va1on § 2PC: ggf. lange Blockierung (Abhängigkeit vom Koordinator) § Ausfall des Koordinators bevor Teilnehmer Global-­‐Commit / Global-­‐Abort erhalten § Ausfall eines Teilnehmers während PREPARED kann zu langen Blockierungen führen § Performance-­‐Erhöhung durch „nicht-­‐blockierende“ Commit-­‐Protokoll (maximal k


3PC (Three-­‐Phase-­‐Commit) Zustandsübergänge © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 32


3PC (Three-­‐Phase-­‐Commit) Skizze des Algorithmus § Zwischenzustand PRECOMMIT für Koordinator, mit Log-­‐Satz protokolliert § Teilt es allen Teilnehmern mit; ebenfalls protokollieren und bestä9gen § Wenn k von n-­‐1 PC-­‐ACK-­‐Nachrichten eingegangen sind, entscheidet der Koordinator auf Commit und schreibt Log-­‐Satz § Letzte Phase dann wieder wie bei 2PC § Pre-­‐Commit des Koordinators: Zusicherung, dass er von sich aus Transak9on nicht mehr zurücksetzt § Abbruch allerdings immer noch möglich, wenn Koordinator-­‐Knoten ausfällt § durch Timeout erkannt § Wahl eines neuen Koordinators § Neuer Koordinator erfragt von anderen (überlebenden) Teilnehmern den Commit-­‐Zustand der Transak9on § Einer der Teilnehmer hat Commit-­‐ oder Abort-­‐Satz protokolliert: Ergebnis global gül9g machen § Nur Pre-­‐Commit bei wenigstens einem Teilnehmer: 3PC mit Verschicken der PRECOMMIT-­‐Nachrichten fortsetzen § Andernfalls Transak9on abbrechen © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 33


3PC (Three-­‐Phase-­‐Commit) Charakteris1sche EigenschaXen des 3PC Lösung des Blockierungsproblems § Koordinator entscheidet auf Abort à Es wird kein Pre-­‐Commit vom Nachfolger gefunden § Bei Entscheidung auf Commit (Koordinator hat Pre-­‐Commit verschickt und mindestens k Bestä9gungen erhalten) à Es wird ein Pre-­‐Commit gefunden falls nicht mehr als k Knoten ausfallen Problem § Bei Netzwerkpar99onierungen funk9oniert das Protokoll nicht! § In einer Par99on wird ein neuer Koordinator gewählt, obwohl in einer anderen Par99on noch ein betriebsbereiter Koordinator exis9ert à Lösungsansatz: Enhanced Three Phase Commit (E3PC) § Signifikante Zunahme an Systemaufwand § Nachrichten: 6*(n-­‐1) § Log-­‐Vorgänge: 3n © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 34


Vergleich Nachrichtenau`ommen Szenario § Transak9on an n Knoten ausgeführt (n > 1), davon an m Knoten keine Änderungen (Lese-­‐Transak9onen) Allgemein Beispiel 1 (n=2, m=0) 1PC 2(n-­‐1) 2 18 Lineares 2PC 2n -­‐ 1 3 19 2PC 4(n-­‐1) -­‐ 2m 4 26 3PC 6(n-­‐1) -­‐ 4m 6 34 Beispiel 2 (n=10, m=5) § Für 1PC und lineares 2PC keine Einsparung für lesende Sub-­‐Transak9onen: bei langen Lesesperren auch für diese Protokolle 2 Nachrichten pro Teilnehmer für Freigabe © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 35


Zusammenfassung Wiederholungen Transak1onsverarbeitung Besonderheiten im Verteilten Fall Two-­‐Phase Commit (2PC) § 2PC-­‐Protokoll § Fehlerszenarien und Recovery-­‐Fall Op1mierungen des 2PC § Freigabetopologien § 1PC, 3PC © Prof. Dr.-­‐Ing. Wolfgang Lehner | Webscale Data Management | 36

Weitere Magazine dieses Users
Ähnliche Magazine