Verteiltes Sperren Verteilte Recovery

Transkript

1 Verteiltes Sperren Verteilte Recovery

2 Verteiltes Sperren (Distributed Locking) Wie werden Sperren für Objekte über mehrere Knoten hinweg verwaltet? Zentralisiert: Ein Knoten für Sperren verantwortlich Zentraler Knoten stellt Engpass für Leistung und Verfügbarkeit dar (anfällig gegenüber Single Site Failure) Primärkopie: Alle Sperren für ein Objekt auf dem Primärkopie-Knoten für dieses Objekt verwaltet Lesen erfordert Zugriff auf den sperrenden Knoten und ebenso auf den Knoten, wo das Objekt gespeichert ist Voll Verteilt: Sperren für eine Kopie werden auf dem Knoten verwaltet, wo die Kopie gespeichert ist Sperren auf allen Knoten beim Schreiben eines Objekts

3 Verteilte Deadlock-Erkennung Jeder Knoten unterhält einen lokalen Wartegraph Ein globaler Deadlock könnte existieren, selbst wenn die lokalen Graphen keine Zyklen enthalten: T1 T2 T1 T2 T1 T2 SITE A SITE B GLOBAL Drei Lösungen: Zentralisiert: sende alle lokalen Graphen zu einem Knoten Hierarchisch: organisiere Knoten in einer Hierarchie und sende lokale Graphen zum Vorgänger (parent) in dieser Hierarchie Timeout: Abbruch der Transaktion, wenn sie zu lange wartet

4 Recovery und die ACID Eigenschaften ACID-Prinzip: Atomarität: alle Aktionen einer Transaktion sind erfolgreich oder gar keine Consistency (Konsistenz): eine Transaktion garantiert den Übergang von einem konsistenten DB-Zustand zu einem anderen konsistenten DB-Zustand Isolation: die Ausführung einer Transaktion ist isoliert von der Ausführung parallel ablaufender anderer Transaktionen Dauerhaftigkeit: wenn eine Transaktion Commit macht, ist ihre Wirkung persistent Recovery-Manager: Garantiert Atomarität und Dauerhaftigkeit Atomarität wird garantiert indem Operationen einer Transaktionen, die nicht mit Commit endet, zurückgesetzt werden Dauerhaftigkeit wird garantiert indem commited Transaktionen ein Crash oder ein Fehler überleben

5 Motivation Atomarität gescheiterte Transaktionen können zurückgesetzt werden (Rollback) Dauerhaftigkeit Was geschieht beim Absturz des DBMS (betrifft auch Puffer)? Welche sind die Ursachen? Gewünschtes Verhalten nach einem Restart des Systems: T1, T2 und T3 müssen dauerhaft sein T4 und T5 sollten zurückgesetzt werden (keine sichtbaren Effekte hinterlassen)

6 Fehlerklassifikation 1. Transaktionsfehler Abbruch der Transaktion (freiwillig oder systemseitig) 3% der Transaktionen werden abnormal aborted (Adressierungsfehler, falsches Input, Overflow, res. Limit exceeded, usw.) 2. Systemfehler (Crash) Fehler der Hardware, Fehler der Software, Stromausfall Verlust bzw. Verfälschung von Hauptspeicherinhalten, aber Datenbank auf Externspeicher unzerstört 3. Geräte- bzw. Externspeicherfehler Head Crash, Fehler in Systemprogrammen, usw.

7 Fehlerarten Transaktionsfehler Freiwilliger Transaktionsfehler durch eine ROLLBACK-Anweisung Unzulässige Dateneingabe Nicht erfolgreiche DB-Operation Fehler im Transaktionsprogramm Division durch Null Adressierungsfehler Systemseitiger Abbruch einer Transaktion Verletzung von Integritätsbedingungen Verletzung von Zugriffsbeschränkungen Systemseitiger Abbruch einer oder mehrerer Transaktionen Auflösung von Deadlocks (Select a Victim) Behandlung von Systemüberlast (z.b. Sperr- oder Speicher-engpässe)

8 Fehlerarten Systemfehler (Crash) Weiterer Betrieb des DBS nicht mehr möglich Fehler der Hardware (z.b. Rechnerausfall) Fehler der Software (z.b. Datenbank- oder Betriebssystem) Umgebungsfehler (z.b. Stromausfall) Geräte- bzw. Externspeicherfehler Ausfall von Magnetplatten (Head Crash) Rekonstruktion der durch den Ausfall verlorengegangenen Änderungen mittels Archivkopien Katastrophen-Recovery Zerstörung eines ganzen Rechenzentrums (Verarbeitungsrechner und Externspeicher) aufgrund von Naturkatastrophen oder Anschlägen Verhinderung eines Datenverlustes über verteilten Systemansatz

9 Failures Impact

10 Recovery Nicht-katastrophale Fehler (1. und 2. Kategorie) Man benutzt die Log-Datei um die Datenbank in einem konsistenten Zustand zu bringen (wie vor dem Auftreten des Fehlers) Transaktionen, die noch nicht den Commit durchgeführt haben, zurücksetzen Log-Einträge in chronologisch umgekehrter Reihenfolge bearbeiten (undo) Sicherstellen, dass alle protokollierte Änderungen in die Datenbank eingebracht werden Die Log-Datei in Vorwärtsrichtung bearbeiten (redo) Katastrophale Fehler (3. Kategorie) Bei Zerstörung der Datenbank oder der Log-Datei kann man aus einer Archivkopie und dem Log-Archiv, den jüngsten konsistenten Zustand wiederherstellen (restore)

11 Verteilte Recovery Zwei mögliche neue Probleme: Neue Fehlerarten: z.b. Fehler in der Kommunikations-Verbindung, Fehler auf einem entfernten Knoten, wo eine Subtransaktion läuft Wenn Sub-Transaktionen einer Transaktion auf verschiedenen Knoten laufen, müssen alle oder keine ein Commit machen. Erfordert ein Commit-Protokoll, um dies zu erreichen. Ein Log wird auf jedem Knoten unterhalten wie in einem zentralisierten DBMS, und Aktionen des Commit-Protokolls werden zusätzlich protokolliert. Meistverbreitetes Protokoll in kommerziellen DBMS: 2-Phase-Commit (2PC)

12 Two-Phase Commit (2PC) Knoten, von dem aus die Transaktion beginnt, ist Koordinator; andere Knoten, wo sie ausgeführt wird, sind Teilnehmer Wenn eine Transaktion ein Commit machen möchte: 1. Koordinator sendet eine prepare Message an jeden Teilnehmer, um deren lokales Commit-Ergebnis in Erfahrung zu bringen 2. Nach Empfang der prepare-nachricht sichert der Teilnehmer bei einer erfolgreich zu Ende gekommenen Subtransaktion durch das Ausschreiben von noch ungesicherten Log-Daten eines prepare Satzes. Anschließend sendet der Teilnehmer eine yes Nachricht an den Koordinator und wartet auf den Ausgang der globalen Transaktion. Für eine gescheiterte (nicht erfolgreiche) Subtransaktion wird ein abort Satz in den lokalen Log geschrieben und eine no Message zum Koordinator geschickt. Die Subtransaktion wird vom Teilnehmer zurückgesetzt.

13 Two-Phase Commit (2PC) (Fortsetzung) 3. Haben alle Teilnehmer mit yes geantwortet, schreibt der Koordinator einen commit Satz in die lokale Log-Datei, woraufhin die globale Transaktion als erfolgreich beendet gilt. Danach wird eine commit Message gleichzeitig an alle Agenten verschickt. Stimmte mindestens ein Agent mit no, so ist auch die globale Transaktion gescheitert. Der Koordinator schreibt einen abort Satz in seinen Log und sendet eine abort Message an alle Teilnehmer, die mit yes gestimmt haben. 4. Teilnehmer schreiben einen abort oder commit Satz in die Log-Datei, abhängig von der Antwort des Koordinators. Gehaltene Sperren werden freigegeben. Anschließend sendet der Teilnehmer noch eine Quittung (ack Message) an den Koordinator. 5. Nach Eintreffen aller ack Nachrichten schreibt der Koordinator einen end Satz in seine Log-Datei.

14 Koordinator Teilnehmer Nachrichtenfluss in 2PC-Protokoll prepare Lokales Commit-Ergebnis yes / no Globales Commit-Ergebnis commit / abort Ende (Sperrfreigabe) ack

15 Anmerkungen zum 2PC Zwei Kommunikationsphasen, jeweils durch den Koordinator initiiert: Erst Abstimmung (Voting) Dann Beendigung (Termination) Jeder Knoten darf über einen Abbruch der Transaktionen entscheiden Jede Message reflektiert eine Entscheidung des Absenders; das Überleben dieser Entscheidung ist dadurch gesichert, dass die Nachricht zunächst in lokale Log-Datei geschrieben wird Offizielles Commit der globalen Transaktion: Koordinator schreibt Commit-Satz ins Log All Log-Sätze für Aktionen des Commit-Protokolls für eine Transaktion enthalten: Transaktions-ID und Koordinator-ID Abort/Commit-Satz des Koordinators enthält auch die IDs aller Teilnehmer

16 Restart nach dem Ausfall eines Knotens Wiederanlauf (restart) auf einem Knoten (kann vorher Teilnehmer oder Koordinator gewesen sein) Wenn es einen commit oder abort Log-Satz für eine Transaktion T gibt, aber keinen end-satz, muss ein Undo/Redo für die Transaktion durchgeführt werden Wenn dieser Knoten Koordinator für T ist: Erneutes (periodisches) Senden von commit/abort Messages bis alle Quittungen (acks) eingetroffen sind Wenn es einen prepare Log-Satz für Transaktion T gibt, aber kein commit/abort, ist dieser Knoten ein Teilnehmer für T Wiederholtes Anrufen des Koordinators, um den Status von T zu bestimmen dann Schreiben eines commit/abort Logsatzes Durchführung von Redo/Undo von T Schreiben des end Log-Satzes Wenn es nicht mal einen prepare Log-Satz für T gibt, einseitiger Abort und Rückgängigmachen von T Dieser Knoten kann Koordinator gewesen sein (hat vielleicht eine prepare-message vor dem Crash noch abgeschickt) Falls Koordinator gewesen, kommen noch Messages von den Teilnehmern an (Notwendige Antwort: Abort T)

17 Blockieren Wenn der Koordinator einer Transaktion T scheitert, können Teilnehmer die mit yes votiert haben, nicht über Commit oder Abort von T entscheiden, bis der Koordinator wiederhergestellt ist: T ist blockiert Selbst wenn alle Teilnehmer einander kennen (zusätzlicher Mehraufwand in prepare Message), sind sie blockiert, sofern nicht einer von ihnen mit no votiert hat

18 Fehler in Verbindungen und auf entfernten Knoten Wenn ein entfernter Knoten während des Commit-Protokolls für eine Transaktion T nicht antwortet, hat das 2 Gründe: Fehler auf diesem Knoten Verbindungsfehler Regeln: Wenn der aktuelle Knoten der Koordinator für T ist, sollte T abgebrochen werden. Wenn der aktuelle Knoten ein Teilnehmer ist, der mit no votiert hat, sollte er T abbrechen. Wenn der aktuelle Knoten ein Teilnehmer ist und mit yes votiert hat, ist er blockiert, solange der Koordinator nicht antwortet

19 Beobachtungen beim 2PC Ack Messages (Quittungen) um den Koordinator zu informieren, wann er eine Transaktion T vergessen kann bis zum Erhalt aller Quittungen muss Koordinator T in der Transaktionstabelle halten Wenn der Koordinator scheitert nach dem Senden von prepare Nachrichten, aber vor dem Schreiben von commit/abort Log-Sätzen, bricht er beim Wiederanlauf die Transaktion ab Wenn eine Subtransaktion keine Updates macht, ist sein Commit-oder Abort-Status irrelevant

20 Verbessertes 2PC mit Presumed Abort Two-Phase-Commit mit Presumed Abort Wenn der Koordinator ein Abort einer Transaktion durchführt, wird T rückgängig gemacht (undo) und unmittelbar aus der Transaktionstabelle entfernt. Wartet nicht auf Quittungen; vermutet Abbruch, wenn Transaktion nicht in Transaktionstabelle Namen der Subtransaktionen nicht aufgezeichnet in abort Log-Satz Teilnehmer brauchen keine Quittungen bei Abort Messages zurückschicken (Koordinator wartet nach Absender der Abort Message nicht auf Teilnehmer) Wenn eine Subtransaktion keine Updates macht, antwortet sie auf die prepare Message mit reader Message anstelle von yes/no (keine Log-Sätze schreiben) Koordinator ignoriert nachfolgend die Leser-Subtransaktion (deren Status für den Ausgang der globalen Transaktion irrelevant ist) Wenn alle Subtransaktionen Leser sind, wird die 2. Phase des Commit- Protokolls nicht benötigt

21 Daten Recovery für eine locale Datenbank Annahmen: Nebenläufigkeitskontrolle wird benutzt: Striktes Zwei-Phasen-Sperrprotokoll (striktes 2PL) Änderungen werden lokal (auf die Platte) geschrieben Gibt es einen einfachen Plan, der die Atomarität und Dauerhaftigkeit garantiert?

22 Recovery Manager Flüchtiger Speicher: DB Puffer Inhalt des Speichers steht nur zur Laufzeit des Systems zur Verfügung Stabiler Speicher: DB und Logs Platte oder andere Speichermedien Ausfallsicherheit

23 Action Logging Alle Änderungsoperationen einer Transaktion müssen in das Log geschrieben werden (die Reihenfolge der Operationen wird in dem Log aufbewahrt) Kein Logeintrag für Leseoperationen nötig Die Log-Datei wird normalerweise auf anderen Speichermedien als die Datenbank gespeichert

24 Flüchtiger Speicher Datenbank Puffer Log Puffer lri lrj Pi Pj WRITE Logeinträge vor dem Commit WRITE geänderte Seiten nach dem Commit Log Daten Daten Daten Recovery Stabiler Speicher

25 Datenbank Log Zur Durchführung der Recovery werden im Log die Änderungen von Transaktionen protokolliert DO-REDO-UNDO-Prinzip Einträge im Log enthalten: Log-Sequence-Number eindeutige Durchnummerierung der Log-Einträge Transaktionskennung Typ der Operation Objekte, die geändert werden Altes Objekt-Wert (Before-Image des Datenobjekts) Neues Objekt-Wert (After-Image des Datenobjekts)

26 Prokollierung von Änderungen Für jede Änderungsoperation einer Transaktion werden zwei Protokollinformationen benötigt: Redo-Information Gibt an wie die Änderungen nachvollzogen werden können (wie man aus dem Before- Image das After-Image erzeugen kann) Undo-Information Gibt an wie die Änderungen rückgängig gemacht werden können (wie man aus dem After-Image das Before-Image erzeugen kann)

27 Andere Logeinträge Die Log-Datei enthält auch Informationen wie begin-transaction, commit-transaction, abort-transaction Wenn eine Transaktion mit Abort beendet wird, dann muss diese zurürckgesetzt werden Log rückwärts scannen um T s Änderungsoperationen zu finden man schreibt das Before-Image um die Änderungen zurückzusetzen Aber wie lange muss man suchen um alle Änderungsoperationen zu finden? bis zum begin-transaction Bei einem Rollback wegen einem Crash muss das System Transaktionen, die beendet wurden von denen die noch alive waren unterscheiden darum die commit und abort Logeinträge

28 Log-Datei - Probleme Garantiert ein Commit-Request die Dauerhaftigkeit? Wenn ein Systemfehler (Crash) auftritt, nachdem die Transaktion die Änderungen gemacht hat und dem Commit-Request geschickt hat, aber bevor der Commit-Logeintrag in die Log-Datei geschrieben wurde dann wird die Transaktion in dem Recovery Phase aborted Die Änderungen sind nicht unbedingt dauerhaftig