Verteiltes Sperren Verteilte Recovery

Verteiltes Sperren
Verteilte Recovery
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
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
SITE A
T1
T2
SITE B
T1
T2
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
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
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)
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.
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)
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
Failures Impact
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)
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)
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.
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.
Nachrichtenfluss in 2PC-Protokoll
prepare
yes / no
Globales Commit-Ergebnis
commit / abort
Ende (Sperrfreigabe)
ack
Teilnehmer
Koordinator
Lokales Commit-Ergebnis
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
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)
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
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
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
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 CommitProtokolls nicht benötigt
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?
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
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
Flüchtiger Speicher
Datenbank Puffer
Log Puffer
lri
Pi
lrj
WRITE
Logeinträge vor dem Commit
Log
Daten
Recovery
Pj
WRITE
geänderte Seiten nach dem Commit
Daten
Daten
Stabiler Speicher
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)
…
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 BeforeImage 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)
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
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