Transaction Management in the R* Distributed Database Management System C. Mohan, Bruce Lindsay and...

Transaction Management in the R* Distributed Database Management System

C. Mohan, Bruce Lindsay and R. Obermarck

16.05.2009 Seminar Datenbanken SS09 Hendrik Wolf, MNR: 25202540

16.05.2009 Seminar Datenbanken SS-09 2

Inhalt

• Introduction• Guaranteeing Uniformity• Synchrone / Asynchrone Logs• 2 Phase Locking• 2 Phase Commit• Hierachical 2P• Presumed Abort• Presumed Commit• Fazit


R* Protocol

• Transaktionsmanagement im R* verteilten Datenbankmanagementsystemen

• R* ist ein experimentelles Datenbank Protokoll für Transaktion in verteilten Datenbanken

• Erlaubt multiple Datenänderung auf mehreren Seiten über eine einzelne Transaktion


R* Protocol

• R* beinhaltet Presumed Abort und Presumed Commit Protokoll

• PA, PC sollen Traffic minimieren und Performance steigern

• PA ist für read-only Transaktionen optimiert

• R* verfügt über eigenes Deadlockmanagement

• Entwickelt in IBM Almaden Research Center


Guaranteeing Uniformity

• Transaktionen in einer Datenbank entweder ganz oder gar nicht ausführen.

• Auch bei Verbindungsfehlern

• Transaktion müssen test weise durchgeführt werden

• Widerrufbarkeit durch UNDO/REDO Logs garantieren


Log Schreibarten

Synchron• Log erzwungen • Für alle Transaktion• Log vor der T. von VM

auf Festspeicher sichern -> Force writes

• Nach Fehlern Transaktion widerrufbar

Asynchron• Log im VM, bei Bedarf

auslagern• Transaktionen auch ohne

gesicherten Log• Nach Fehlern mögl. Kein

Log vorhanden


2 Phase Locking

• 2PL ermöglicht Serialisierbarkeit von parallelen Transaktionen.

• Wachstumsphase: Sperren werden gesetzt,

aber nicht freigegeben. • Schrumpfungsphase: Sperren werden freigegeben,

aber nicht angefordert.

Quelle: http://de.wikipedia.org/wiki/Sperrverfahren#Zwei-Phasen-Sperrprotokoll


2 Phase Locking

• R* implementiert 2PL

• Durch die Nutzung von 2PL entstehen Deadlocks

• Deadlocks werden von R* nicht verhindert sondern durch „victim Transaction abort“ aufgelöst

• Victim: Bei globalen Deadlocks wird eine Transaktion auf der Seite des Deadlocks ausgewählt und beendet.


2 Phase Commit

• In vert. Datenbanken teilen sich Transaktionen meist in mehrere Prozesse auf

• 2P besteht aus einem Koordinator und mehreren Subordinatoren

• Ko. übergibt Transaktion an die Subs

• Die Subs führen die Transaktion aus

• Subs kommunizieren nur mit dem Ko. nicht untereinander

Ko

Sub1 Sub2 Subn


Kriterien eines 2PC

• Garantierte atomare Transaktionen

• Transaktionen nach dem ausführen „vergessen“

• Minimaler Überhang (Log-writes, message traffic)

• Optimierte Performance im fehlerfreien Fall

• Optimierung von read-only Transaktion


2P Ablauf

Koordinator Subordinate

PREPARE

prepare* / abort*

YES / NO VOTE

commit* / abort*

COMMIT / ABORT

commit* / abort*

ACK

end

-Prepare S

tate- -Com

mit S

tate-

Zeit


2P im fehlerfreien Ablauf (1/3)

• Nutzerapplikation übergibt Transaktion an den Koordinator -> 1. Phase

• Ko. Sendet PREPARE an alle Subordinates• Wenn der Sub. bereit ist wird ein prepare Log (force write)

und YES VOTE an Ko. gesendet.• Wenn alle Subs YES VOTE gesendet haben ist die

Transaktion im –PREPARED STATE- und es beginnt die 2te Phase



• 2te Phase:• Ko. schreibt einen Commit Log (forced) und sendet

COMMIT an alle Subs• -COMMITING POINT-• Wenn alle Subs ein COMMIT erhalten haben schreiben

diese ebenfalls einen Commit Log (forced) und senden ACK an denn Ko.

• Daraufhin führen die Subs die Transaktion aus• Ko. Schreibt END in das Log



• Sollte einer der Subs NO VOTE senden wird die Transaktion abgebrochen

• Transaktion geht in den -ABORT STATE-• Ko. sendet ABORT an all die Subs die YES VOTE

gesendet haben und schreibt einen ABORT LOG (forced)


Zusammenfassung 2P

Koordinator Subordinator

Nachrichten

PREPARE

COMMIT/ABORT

YES/NO VOTE

ACK

Logs

commit* (forced)

end

prepare*

commit*

beide forced


2P Ablauf mit Fehlern

• Jede Seite verfügt über einen Recovery Prozess• RP bezieht Information aus den gesicherten Logs



• Absturz im PREPARED STATE • RP spricht Ko. an um zu erfahren wie die T. beendet

wird• Wenn Ko. mit COMMIT/ABORT antworten verhält sich

RP wie ein Sub und führt die T. durch



• Absturz im COMMIT STATE der Transaktion• RP sendet solange COMMIT / ABORT an die Subs bis

ein ACK zurückgesendet wird.• Wenn ACK erhalten wird END in das Log geschreiben



• Absturz bei der Ausführung der Transaktion• RP widerruft die Transaktion mit Hilfe des UNDO/REDO

Logs


Hierachical 2P

• Bisherige Beschreibung von 2P reicht nicht aus wenn eine Transaktion aus mehren Ebenen / Prozessen besteht.

• Lösung: Hierachical 2P

Ko

Sub1 Sub2 Subn


Hierachical 2P

Root

Non-LeafNon-Root

Leaf Leaf Leaf

• Prozesse werden Baumförmig angeordnet mit Parent / Child Abhängigkeit

• Root: Prozess arbeitet als Ko

• Non-Root,Non-Leaf: arbeitet als Ko für Leaf und als Sub für Root

• Leaf: Pozess arbeitet als Sub


Presumed Abort Protocol

• Transaktion ist komplett oder teilweise read-only• Komplett read-only: keine updates• Teilweise read-only: Ein Teil der T. bewirkt updates• Art der T. muss nicht vorher bekannt sein.

• Für read-only gilt:– Root sendet kein COMMIT / ABORT– Kein UNDO/REDO Log– Keine 2te Phase für das Protokoll


PA Protocol - Ablauf

ROOT Non-Root,Non-LeafLeaf

PREPARE

PREPARE

VOTE READ

prepare*

VOTE YES

commit*

COMMIT

commit*

ACK

end


PA Protocol - Ablauf• Vollständig read-only

– Kein Prozess schreibt Logs– Root sendet PREPARE an dessen Leaf-Prozesse– Leaf-Prozesse senden READ-VOTE an den Root

• Teilweise read-only– Root sendet PREPARE und COMMIT / ABORT an die Leaf-

Prozesse die ein update durchführen– Und PREPARE an alle read-only Leafs

• Ist der Root ein Non-root,Non-Leaf Prozess sendet dieser YES-VOTE und ACK an dessen parent-root


Presumed Commit Protocol

• Mehrheit der T. werden mit COMMIT beendet und nicht mit ABORT

Logs forced-write nur für abort Performance

• Problem: Root stürzt ab während einige Leafs im PREPARED STATE sind also YES VOTE gesendet haben

• Nach Recovery vergisst Root die T. ohne die Leafs darüber zu informieren, da kein commit Log

• Die Leafs die YES-VOTE gesendet haben fragen beim Root nach, dieser antwortet mit COMMIT Inkonsistenz


Presumed Commit Protocol

• Lösung: • Root forced einen collect Log • In dem der Status der Leafs festgehalten wird PC

• Wenn Recovery Prozess nach Fehlern einen collect log findet werden damit alle beteiligten Leafs ABORTED

• Wenn kein Log vorhanden ist wird auf Anfragen der Leaf-Prozesse immer mit COMMIT geantwortet.


PC Protocol - Ablauf

ROOT Non-Root,Non-LeafLeaf

collecting*PREPARE

collecting* PREPARE

VOTE READprepare*

VOTE YEScommit*

COMMITcommit


PC Protocol - Ablauf

• Vollständig read-only– Root schreibt zwei Logs: collecting (forced) und commit– Und sendet PREPARE an die Leaf-Prozesse– Leaf-Prozesse senden READ-VOTE und schreiben keine Logs

• Teilweise read-only– Root schreibt zwei Logs: collecting und commit beide forced– sendet PREPARE und COMMIT an update-Leaf

und PREPARE an read-only-Leaf– Leaf schreibt drei Logs:

collecting, prepare beide forced und commit nicht forced


Fazit

• PA ist effizienter als 2P– durch die read-only Optimierung von PA – 2P behandelt alles als update Transaktion

• PC bietet Performancevorteil gegenüber 2P– Durch die Einsparung von zwei Logs und ACK


Quellen

• Joseph M. Hellerstein and Michael Stonebraker (Eds.): Readings in Database Systems, 4th Edition Paper

• http://de.wikipedia.org/wiki/Sperrverfahren#Zwei-Phasen-Sperrprotokoll

Date post:	05-Apr-2015
Category:	Documents
Upload:	hludowig-schmall
View:	102 times
Download:	0 times

Transaction Management in the R* Distributed Database Management System C. Mohan, Bruce Lindsay and...

Documents