7.2 Commit-Behandlung
7.2.5 Drei-Phasen-Commit
Ein (potentieller) Schwachpunkt der Zwei-Phasen-Commit-Protokolle liegt in der Abhängigkeit zum Koordinator, dessen Ausfall während des Prepared-Zustandes der Agenten zu langen Blockierungen führen kann[30]. Als Abhilfe wurden daher sogenannte "nicht-blockierende" Commit-Protokolle vorgeschlagen, die das Blockierungsproblem unter Inkaufnahme eines erhöhten Aufwandes abschwächen. Ein solches Verfahren ist das Drei-Phasen-Commit-Protokoll [Sk81, BHG87], das nachfolgend beschrieben wird. Es kann jedoch Blockierungen nur unter der Voraussetzung verhindern, daß keine Netzwerk-Partitionierungen vorkommen und höchstens K < N Rechner gleichzeitig ausfallen, wobei K ein Verfahrensparameter ist.
Wir beschreiben das 3PC-Protokoll für eine zentralisierte Kommunikationsstruktur zwischen Koordinator und Agenten. Die dabei anfallenden Nachrichten sind in Abb. 7-8 gezeigt. Man erkennt, daß die erste Phase mit der des 2PC-Protokolls übereinstimmt. Der (nicht gezeigte) Abort-Fall, wenn also wenigstens ein Agent mit FAILED stimmt, wird wie im 2PC-Protokoll behandelt. Eine zusätzliche Phase wird also nur notwendig, wenn alle Agenten mit READY stimmen. In dieser Situation nimmt der Koordinator jetzt zunächst einen Zwischenzustand (Precommit) ein, der mit einem entsprechenden Log-Satz protokolliert wird. Der Koordinator teilt das Precommit allen Agenten mit, die dieses Zwischenergebnis ebenfalls protokollieren und mit einer PC-ACK-Nachricht quittieren. Nachdem die PC-ACK-Nachrichten von K der N-1 Agenten eingetroffen sind, entscheidet der Koordinator auf Commit und schreibt den entsprechenden Log-Satz. Die letzte Phase (Mitteilung und Quittierung des Commit-Resultats) stimmt wiederum mit der des 2PC-Protokolls überein. Mit dem Precommit sichert der Koordinator zu, daß er von sich aus die Transaktion nicht mehr zurücksetzt. Allerdings ist es im Gegensatz zum Commit nach einem Precommit des Koordinators nach dessen Ausfall noch möglich, die Transaktion abzubrechen.
Wird während der Commit-Behandlung ein Koordinatorausfall erkannt (durch Timeout), so erfolgt die Wahl eines neuen Koordinators. Damit der neue Koordinator die Commit-Behandlung fortführen kann, erfrägt er zunächst von den überlebenden Rechnern den Commit-Zustand bezüglich der betroffenen Transaktion. Wenn einer der Agenten einen Commit-Satz oder Abort-Satz für die Transaktion protokolliert hat, wird das entsprechende Ergebnis global gültig gemacht. Wenn keiner der Agenten einen Abort- oder Commit-Satz, jedoch wenigstens einer einen Precommit-Zustand vorliegen hat, dann wird das 3PC-Protokoll mit dem Verschicken der PRECOMMIT-Nachrichten fortgesetzt. Anderenfalls wird auf Abbruch der Transaktion entschieden.
Abb. 7-8: Nachrichtenfluß beim Drei-Phasen-Commit
Das im 2PC-Protokoll bestehende Blockierungsproblem im Prepared-Zustand eines Agenten ist mit diesem Ansatz gelöst. Denn wenn der Koordinator auf Abort entschieden hat, dies jedoch nicht mehr propagiert wurde, dann kann keiner der Agenten im Precommit-Zustand sein. Der neue Koordinator entscheidet daher richtigerweise auf Transaktionsabbruch. Hatte der ausgefallene Koordinator auf Commit entschieden, so findet der neue Koordinator bei wenigstens einem der überlebenden Agenten einen Precommit-Zustand vor (da nach Voraussetzung neben dem Koordinator höchstens K-1 weitere Rechner ausfallen dürfen und vor dem Commit K Agenten das Precommit quittierten). Allerdings entscheidet der neue Koordinator in dieser Situation nicht unmittelbar auf Commit, da dann der Ausfall des neuen Koordinators auf dasselbe Blockierungsproblem wie beim 2PC führen würde. Stattdessen wird das 3PC-Protokoll mit dem Verschicken der PRECOMMIT-Nachrichten fortgesetzt. Ist der ursprüngliche Koordinator im Precommit-Zustand ausgefallen, so kann die globale Transaktion sowohl abgebrochen als auch erfolgreich beendet werden. Welche Entscheidung vom neuen Koordinator gefällt wird, hängt davon ab, ob noch einer der Agenten den Precommit-Zustand erreicht hat.
Der Preis für diese höhere Robustheit liegt in der signifikanten Zunahme an Nachrichten und Log-Zugriffen. Insgesamt fallen jetzt 6*(N-1) Nachrichten sowie 3N Log-Vorgänge an. Die Voraussetzung, daß keine Netzwerk-Partitionierungen auftreten, ist notwendig, da ansonsten in mehreren Partitionen ein neuer Koordinator gewählt werden könnte. Die einzelnen Koordinatoren könnten dann zu unterschiedlichen Commit-Ergebnissen kommen.
Abschließender Vergleich
In Abb. 7-9 zeigen wir abschließend noch einmal den Nachrichtenbedarf für einige der vorgestellten Commit-Protokolle (mit optimierter Behandlung lesender Sub-Transaktionen). Es wird dabei wie bisher angenommen, daß die Transaktion an N Knoten ausgeführt wurde (N>1), wobei an M (< N) Knoten keine Änderungen erfolgten. Für das Ein-Phasen-Commit sowie das lineare 2PC ergeben sich für lesende Sub-Transaktionen keine Einsparungen. Denn bei langen Lesesperren sind auch für diese Protokolle 2 Nachrichten pro Agent zur Sperrfreigabe erforderlich.
Abb. 7-9: Nachrichtenbedarf verteilter Commit-Protokolle
[30] Zur praktischen Relevanz des Blockierungsproblems gibt es keine Untersuchungen, obwohl nahezu ausschließlich Zwei-Phasen-Commit-Protokolle zur verteilten Commit-Behandlung im Einsatz sind. Allerdings werden in existierenden Systemen z.T. "heuristische" Commit-Entscheidungen zur Auflösung von Blockierungen vorgesehen [GR93, SBCM93]. Dabei entscheidet nach einem Koordinatorausfall der Operateur über das Commit-Ergebnis für eine blockierte Sub-Transaktion, oder es werden Default-Entscheidungen getroffen, um die Blockierung aufzulösen. Für derart "behandelte" Transaktionen kann allerdings keine Atomarität mehr garantiert werden. Wird später festgestellt, daß die heuristische Commit-Entscheidung von der des Koordinators abweicht, so kann der Schaden (Inkonsistenz der Datenbank) nur noch durch manuelle Recovery-Maßnahmen behoben bzw. begrenzt werden.