Atomare Commit-Protokolle. Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 1

Transkript

1 Atomare Commit-Protokolle Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 1

2 Atomares Commit-Protokoll Bisher: Protokolle zur lokalen Transaktionsverwaltung / Sperrverwaltung Atomzität auf lokalen Daten Logbuch Redo / Undo Before-image / After-image Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 2

3 Atomares Commit-Protokoll Heute: Protokolle zur verteilten Transaktionsverwaltung Verteilte Transaktion: Wird auf mehreren verteilten Datenbanken ausgeführt Beibehaltung der Atomizität bei verteilten Transaktionen Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 3

4 Atomares Commit-Protokoll Transaktion / Koordinator : T Write(1,..) Write(3,..) Datenbanken / Teilnehmer : Read(2,..) Atomizität : Änderung auf allen Datenbanken oder auf keiner Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 4

5 Atomares Commit-Protokoll Algorithmus, der Prozesse zu einer gemeinsamen Entscheidung führt: 1. Alle Prozesse fällen dieselbe Entscheidung (Commit oder Abort) 2. kein Prozess kann seine Entscheidung revidieren 3. Commit kann nur entschieden werden, wenn alle für Commit votieren 4. Wenn keine Fehler auftreten und alle für Commit votieren, gilt Commit 5. Sind alle Fehler behoben und treten genügend lange keine neuen auf, kommt jeder Prozess zu einer Entscheidung Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 5

6 2-Phasen-Commit-Protokoll (2PC - Zentralisiert) Algorithmus, der Prozesse zu einer gemeinsamen Entscheidung führt: 1. Koordinator schickt Vote-Request an alle Prozesse 2. Teilnehmer-Prozess votiert (für Commit oder Abort), notiert das Votum im Logbuch und informiert den Koordinator. Bei Vote-Abort : lokal Abort ausführen 3. Koordinator sammelt Voten und fällt die Entscheidung Commit genau dann, wenn alle Teilnehmer für Commit votieren, Sonst Abort. Koordinator benachrichtigt die Teilnehmer, die für Commit votierten 4. Teilnehmer, die für Commit votierten, warten auf die Entscheidung des Koordinators und setzen sie um. Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 6

7 2-Phasen-Commit-Protokoll (2PC - Linear) Prepare VC/VA VC/VA VC/VA N GC/GA GC/GA GC/GA GC/GA + weniger Nachrichten - keine Parallelität Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 7

8 2-Phasen-Commit-Protokoll (2PC - Verteilt) 1C C Prepare vote-abort/ vote-commit + keine 2. Phase - Teilnehmer müssen bekannt sein global-commit/ global-abort Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 8

9 Fehlerbehandlung (2PC Zentralisiert) Timeouts Nachrichten werden nicht empfangen Terminierungs-Protokoll Teilnehmer/Koordinatorfehler (z.b. Stromausfall) Teilnehmer/Koordinator können abstürzen Recovery-Protokoll Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 9

10 Terminierungs-Protokoll (2PC Zentralisiert) 1. Koordinator Timeouts WAIT (Koordinator erhält von Teilnehmer kein Votum) Global Abort COMMIT/ABORT (Koordinator erhält kein ACK von einem Teilnehmer) Wiederholtes Senden von Global Abort / Global Commit bis Teilnehmer antwortet Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 10

11 Terminierungs-Protokoll (2PC Zentralisiert) 2. Teilnehmer Timeouts INITIAL(Keine Prepare-Nachricht erhalten) Local Abort (Trifft Prepare später ein, Vote-Abort oder Nachricht ignorieren) READY (Global Commit / Global Abort nach Vote-Commit nicht erhalten) Blockieren und Warten Entscheidung kann ohne Kenntnis der globalen Entscheidung nicht getroffen werden (ggf. andere Teilnehmer konsultieren) Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 11

12 Terminierungs-Protokoll (2PC Zentralisiert) 2. Teilnehmer Timeouts READY (Global Commit / Global Abort nach Vote-Commit nicht erhalten) Blockieren und Warten Entscheidung kann ohne Kenntnis der globalen Entscheidung nicht getroffen werden (ggf. andere Teilnehmer konsultieren) (1) Anderer Teilnehmer kennt Entscheidung Entscheidung übernehmen (2) Anderer Teilnehmer votierte mit Abort lokal Abort ausführen (3) Erreichbare Teilnehmer votierten Commit weiter Blockieren Annahme: Irgendwann sind andere wieder erreichbar Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 12

13 Recovery-Protokoll (2PC Zentralisiert) Annahme: Die aufeinanderfolgenden Operationen Eintrag ins Logbuch schreiben Entsprechende Nachricht versenden werden atomar ausgeführt. Unrealistisch, aber erstmal ok! Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 13

14 Recovery-Protokoll (2PC Zentralisiert) 1. Koordinator Fehler INITIAL(Bevor Koordinator die Commit-Prozedur gestartet hat) Starte Commit-Prozess WAIT(Prepare-Message bereits versendet) Starte Commit-Prozess erneut. Prepare-Message nochmal senden. COMMIT/ABORT(Globale Entscheidung bereits verschickt) Nichts tun, falls alle ACKs angekommen sind. Sonst: Terminierungs-Protokoll! Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 14

15 Recovery-Protokoll (2PC Zentralisiert) 2. Teilnehmer Fehler INITIAL Transaktion einseitig aborten READY(Vote-Commit wurde bereits verschickt) Wie Timeout der Global-Message behandeln (Blockieren!) ABORT/COMMIT(Alle Nachrichten vom Koordinator erhalten) Terminierungs-Bedingung klar, keine spezielle Aktion erforderlich Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 15

16 Recovery-Protokoll (2PC Zentralisiert) Annahme: Die aufeinanderfolgenden Operationen Eintrag ins Logbuch schreiben Entsprechende Nachricht versenden werden atomar ausgeführt. Unrealistisch, aber erstmal ok! Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 16

17 Recovery-Protokoll (2PC Zentralisiert) Koordinator Fehler 1. Nach begin_commit, vor PREPARE wie Fehler in WAIT behandeln 2. Nach commit/abort, vor GLOBAL COMMIT/GLOBAL ABORT wie Fehler in COMMIT/ABORT, Teilnehmer durch Terminierungsprotokoll (Timeout) Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 17

18 Recovery-Protokoll (2PC Zentralisiert) Teilnehmer Fehler 1. Nach ready, vor VOTE-COMMIT wie Fehler in READY behandeln 2. Nach abort/commit, vor ACK wie Fehler in COMMIT/ABORT behandeln, Koordinator wird dies durch Timeout behandeln Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 18

19 Recovery-Protokoll (2PC Zentralisiert) Teilnehmer Fehler 3. Nach abort, vor VOTE-ABORT Koordinator ist in WAIT Timeout! Nach Terminierungsprotokoll wird Koordinator Transaktion global Aborten Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 19

20 2-Phasen-Commit-Protokoll (2PC - Zentralisiert) Zusammenfassung: Protokoll zur atomaren Ausführung verteilter Transaktionen (atomares Commit-Protokoll) Kann umgehen mit Fehlern auf Seiten von Koordinator / Teilnehmer Nachrichtenverlust Blockierend! Erinnerung Terminierungs-Protokoll: 2. Teilnehmer Timeouts READY (Global Commit / Global Abort nach Vote-Commit nicht erhalten) Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 20

21 Bi-State-Termination (bei 2PC - Zentralisiert) Koordinator INITIAL WAIT COMMIT Teilnehmer INITIAL READY? Koordinator Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 21

22 Bi-State-Termination (bei 2PC - Zentralisiert) Koordinator INITIAL WAIT COMMIT Teilnehmer INITIAL READY? Koordinator Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 22

23 Bi-State-Termination (bei 2PC - Zentralisiert) Tabelle: Kunden ID Name Ort 5 Meyer Paderborn 7 Müller Paderborn T1 : UPDATE Kunden SET Name = Mueller AND Ort = Paderborn WHERE ID=7 T2 : DELETE * FROM Kunden WHERE ID = 7 T3 : UPDATE Kunden SET Ort = PB WHERE Ort = Paderborn T4 : SELECT * FROM Kunden WHERE Ort = Paderborn Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 23

24 Bi-State-Termination (bei 2PC - Zentralisiert) Idee: Modifizierte/Gelesene Tupel einer Transaktion nicht bis zum Abschluss der Transaktion sperren. Zwei Versionen der Daten für jede Transaktion 1. Eine Version, die gültig wird, wenn die Transaktion mit Commit abschließt. 2. Eine Version, die gültig wird, wenn die Transaktion mit Abort abschließt. Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 24

25 Bi-State-Termination (bei 2PC - Zentralisiert) Commit Abort T1 T T Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 25

26 Bi-State-Termination (bei 2PC - Zentralisiert) Umsetzung: Atomic-Commit-Protokoll : 2PC Concurrency-Control : modifiziertes striktes 2PL Mögliche Freigabe der Sperren einer Transaktion nach Abgabe des Vote der Datenbank. Werden die Sperren freigegeben, müssen Sie zum Auflösen der Versionen wieder aufgebaut werden. Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 26

27 Bi-State-Termination (bei 2PC - Zentralisiert) 2PC + 2PL Phase 1 Phase 2 Sperren von Transaktion x gesetzt Aufbau der Sperren für Transaktion x Aufforderung zum Vote durch den Koordinator Parallele, in Konflikt stehende Transaktion y muss warten y kann ausgeführt werden Abgabe des Vote Erhalt der globalen Commit-Entscheidung und Freigabe der Sperren Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 27

28 Bi-State-Termination (bei 2PC - Zentralisiert) 2PC + BST Phase 1 Phase 2 Sperren von Transaktion x gesetzt Aufbau der Sperren und Versionen für Transaktion x Aufforderung zum Vote durch den Koordinator Abgabe des Vote Parallele, in Konflikt stehende Transaktion y. Freigabe der Sperren von x und Aufbau der Sperren von y Aufbau der Sperren und Entfernen der Versionen Erhalt der globalen Commit-Entscheidung für Transaktion x. Warten bis durch y gesperrte Tupel freigegeben sind Freigabe der Sperren Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 28

29 Bi-State-Termination (bei 2PC - Zentralisiert) Änderungen in der Datenbank : ID Name Ort Inserted Deleted 5 Meyer Paderborn 2 7 Müller Paderborn 1 Einträge in Inserted: Bezeichner der Transaktionen, die das Tupel eingefügt haben Einträge in Deleted: Bezeichner der Transaktionen, die das Tupel gelöscht haben Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 29

30 Bi-State-Termination (bei 2PC - Zentralisiert) Anforderungen an die Versionsspalten : 1.) Einträge in Inserted sind mit einem logischen UND verknüpft. ID Name Ort Inserted Deleted 5 Meyer Paderborn Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 30

31 Bi-State-Termination (bei 2PC - Zentralisiert) Anforderungen an die Versionsspalten : 1.) Einträge in Inserted sind mit einem logischen UND verknüpft. 2.) Einträge in Deleted sind mit einem logischen ODER verknüpft. ID Name Ort Inserted Deleted 5 Meyer Paderborn Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 31

32 Bi-State-Termination (bei 2PC - Zentralisiert) Anforderungen an die Versionsspalten : 1.) Einträge in Inserted sind mit einem logischen UND verknüpft. 2.) Einträge in Deleted sind mit einem logischen ODER verknüpft. 3.) Enthält ein Tupel weder in Inserted noch in Deleted Einträge, so ist es in dieser Version gültig. Es darf keine weitere Version existieren. ID Name Ort Inserted Deleted 5 Meyer Paderborn 5 Meyer Münster 2 Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 32

33 Bi-State-Termination (bei 2PC - Zentralisiert) Auflösen der Versionen: Transaktion T schließe mit Commit ab Lösche Tupel mit Bezeichner T in Deleted Entferne alle Vorkommen von T aus Inserted Transaktion T schließe mit Abort ab Lösche Tupel mit Bezeichner T in Inserted Entferne alle Vorkommen von T aus Deleted Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 33

34 Bi-State-Termination (bei 2PC - Zentralisiert) Insert Queries : T3 : INSERT INTO Kunden VALUES(8, Riegel, Mainz ) ID Name Ort Inserted Deleted 5 Meyer Paderborn 2 7 Müller Paderborn 1 8 Riegel Mainz 3 Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 34

35 Bi-State-Termination (bei 2PC - Zentralisiert) Delete Queries : T4 : DELETE * FROM Personen WHERE ID = 7 ID Name Ort Inserted Deleted 5 Meyer Paderborn 2 7 Müller Paderborn 1 4 Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 35

36 Bi-State-Termination (bei 2PC - Zentralisiert) Update Queries : T5 : UPDATE Personen SET Ort = PB WHERE Ort = Paderborn ID Name Ort Inserted Deleted 5 Meyer PB Müller PB Meyer Paderborn Müller Paderborn Betroffene Tupel kopieren und als gelöscht markieren. 2. Update auf den betroffenen Tupel ausführen, die den Bezeichner nicht in Deleted stehen haben Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 36

37 Bi-State-Termination (bei 2PC - Zentralisiert) Select Queries : T6 : SELECT * FROM Personen WHERE Ort = Paderborn ID Name Ort Inserted Deleted 5 Meyer Paderborn 2 7 Müller Paderborn 1 ID Name Ort ID Name Ort 5 Meyer Paderborn 5 Meyer Paderborn T1 Commit, T2 Commit 7 Müller Paderborn T1 Abort, T2 Commit ID Name Ort 7 Müller Paderborn ID Name Ort T1 Abort, T2 Abort T1 Commit, T2 Abort Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 37

38 Bi-State-Termination (bei 2PC - Zentralisiert) Fazit: Deutlicher Vorteil bei der Ausführung von Transaktionen in mobilen verteilten Datenbanksystemen. Engpass - bis zu 81% mehr Transaktionen konnten abschließen Streuung - bis zu 25% mehr Transaktionen konnten abschließen Eine maximale Anzahl an Versionen eines Tupels sollte festgelegt werden, um keine Explosion der Datenbankgröße zu erhalten. (~ 14 hängende Transaktionen auf einem Tupel) Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 38

39 Bi-State-Termination (bei 2PC - Zentralisiert) Die BST lässt sich bei einer großen Anzahl an Transaktionen (~ 1 Transaktion/Sekunde) über eine längere Zeit ohne signifikanten Performanceverlust durchführen. Die BST ist gut geeignet für mobile verteilte Datenbanken, eine Blockierung im Falle eines Verbindungsausfalls wird aufgehoben. Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 39

40 Nicht-blockierendes Commit-Protokoll Wie muss ein nicht-blockierendes synchrones Commit-Protokoll aussehen? Das Zustandsübergangsdiagramm darf keine der folgenden Eigenschaften erfüllen: 1. Kein Zustand ist gleichzeitig adjazent zu COMMIT und zu ABORT 2. Kein nicht-commitbarer Zustand ist adjazent zu COMMIT adjazent : Von einem Zustand zu einem anderen mit einer Transition Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 40

41 3-Phasen-Commit-Protokoll (3PC Zentralisiert) Änderungen zu 2PC: Koordinator Neuer Zustand PRECOMMIT hinter WAIT Teilnehmer Neuer Zustand PRECOMMIT hinter READY PRECOMMIT: Puffer-Status der gilt, falls der Koordinator/Teilnehmer bereit ist, in den Status COMMIT zu wechseln Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 41

42 3-Phase-Commit (Commit-Fall) Phase 1 Phase 2 Phase 3 Co T 1 : cancommit? T 1 : Yes T 1 : precommit? T 1 : Okay T 1 : docommit T 1 : done DB Phase 1: Co fragt DBs jede DBs gibt ihr Votum zurück Phase 2: Co sammelt Voten der DBs Co berechnet globales Votum Co gibt globales Votum an DBs DBs bereiten globales Votum vor DBs bestätigen Vorbereitung Phase 3: Co sammelt Bestätigungen der DBs wenn alle Bestätigungen gesammelt commit DBs führen Entscheidung durch Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 42

43 Fehlerbehandlung (3PC Zentralisiert) Timeouts Nachrichten werden nicht empfangen Terminierungs-Protokoll Teilnehmer/Koordinatorfehler (z.b. Stromausfall) Teilnehmer/Koordinator können abstürzen Recovery-Protokoll Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 43

44 Terminerungs-Protokoll (3PC Zentralisiert) 1. Koordinator Timeouts WAIT (Koordinator erhält von Teilnehmer kein Votum) Global Abort (wie bei 2PC) PRECOMMIT(Alle Teilnehmer wenigstens in READY Vote-Commit) Wiederholtes Senden von PREPARE-TO-COMMIT mit anschließendem GLOBAL-COMMIT an alle erreichbaren Teilnehmer COMMIT/ABORT(Teilnehmer wenigstens in PRECOMMIT) keine spezielle Aktion notwendig. Wird von Terminierungsprotokoll der Teilnehmer geregelt Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 44

45 Terminerungs-Protokoll (3PC Zentralisiert) 2. Teilnehmer Timeouts INITIAL(Keine PREPARE-Message erhalten) Einseitiges ABORT (wie 2PC) PRECOMMIT(PREPARE-TO-COMMIT erhalten, warten auf GLOBAL- COMMIT) siehe READY READY(Votiert für COMMIT, aber globale Entscheidung nicht bekannt) Neuen Koordinator aus erreichbaren Teilnehmern wählen! Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 45

46 Terminerungs-Protokoll (3PC Zentralisiert) 2. Teilnehmer Timeouts READY(Votiert für COMMIT, aber globale Entscheidung nicht bekannt) Neuen Koordinator aus erreichbaren Teilnehmern wählen! Neuer Koordinator kann in folgenden Zuständen sein: WAIT(READY), PRECOMMIT, COMMIT, ABORT Sendet eigenen Zustand an alle erreichbaren Teilnehmer 1. Teilnehmer ist in späterem Zustand? Neuen Koordinator ignorieren 2. Andere führen Transition aus und senden entsprechende Nachricht an neuen Koordinator Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 46

47 Terminerungs-Protokoll (3PC Zentralisiert) Sobald neuer Koordinator Nachrichten von Teilnehmer erhält, setzt er die Terminierung je nach Zustand wie folgt fort: 1. WAIT global Abort Teilnehmer können in INITIAL, READY, ABORT, PRECOMMIT sein. Problem: PRECOMMIT erwartet keinen Abbruch. Hinzufügen! 2. PRECOMMIT global Commit Teilnehmer können nur in READY, PRECOMMIT, COMMIT sein. 3. ABORT Alle anderen Teilnehmer müssen auch in ABORT sein abort Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 47

48 Terminierungs-Protokoll (3PC Zentralisiert) Wenn Co abstürzt, wird NewCo als neuer Koordinator gewählt und startet Terminierungsprotokoll NewCo DB run subtrans run subtrans Wait Abort Wait Abort Prepare C Prepare C Commit Commit Ist NewCo in PrepareC oder in Commit, führt er DBs zu Commit, sonst zu Abort Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 48

49 Recovery-Protokoll (3PC Zentralisiert) 1. Koordinator Fehler WAIT (PREPARE-Message bereits verschickt, Teilnehmer haben Transaktion möglicherweise bereits beendet) Schicksal der Transaktion bei anderen erfragen PRECOMMIT (Teilnehmer haben Transaktion möglicherweise bereits beendet) Da es durch die neuen Terminierungsprotokolle möglich ist, vom PRECOMMIT-Zustand zu ABORT zu kommen, Schicksal der Transaktion bei anderen erfragen Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 49

50 Recovery-Protokoll (3PC Zentralisiert) 2. Teilnehmer Fehler PRECOMMIT Bei anderen Teilnehmern erfragen, wie sie die Transaktion beendet haben Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 50

51 3-Phasen-Commit-Protokoll - Diskussion Verglichen mit 2 PC: - mehr Nachrichten - weniger Fälle der unabhängigen Wiederherstellung bei Fehlern + nicht-blockierend Jedoch: - kann bei Netzwerkpartitionierung zu Fehlern führen: NewCo1 Co Wait NewCo2 Prepare C Abort Commit Netzwerkpatitionierung Ist NewCo in Precomit oder in Commit, führt er DBs zu Commit, sonst zu Abort Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 51

52 Wahlaufruf Heute Uhr am Service Center Möglichkeit zur Wahl: Fachschaftsrat Mitglieder der Fachschaftsvertretung EIM studentische Fakultätsratsmitglieder studentische Mitglieder des Senats Mitglieder des Studierendenparlaments Morgen (Mittwoch) Uhr Service Center Grundlagen von Datenbanken - SS Prof. Dr. Stefan Böttcher Atomare Commit-Protokolle Folie 52