Commit-Protokoll
aus Wikipedia, der freien Enzyklopädie
Commit-Protokolle regeln die Festschreibung (Commit) von Daten, die durch eine (verteilte) Transaktion beispielsweise in einem Datenbankmanagementsystem verändert werden sollen.
Inhaltsverzeichnis |
[Bearbeiten] Notwendigkeit und Anforderungen
Die wünschenswerten Eigenschaften (verteilter) Transaktionen werden i.A. durch das Akronym ACID abgekürzt: Atomicity oder „Atomarität“, Consistency oder „Konsistenz“, Isolation und Durability oder „Dauerhaftigkeit“. Das Commit-Protokoll ist für die Gewährleistung dieser Eigenschaften zuständig.
Je nach Commit-Protokoll müssen nicht alle der o.g. Eigenschaften verpflichtend erfüllt werden. Die Gewährleistung der „Atomarität“ der Transaktion hat normalerweise den höchsten Stellenwert. Das bedeutet, es muss sichergestellt werden, dass entweder alle oder keine der in einer Transaktion angeforderten Modifikationen durchgeführt werden.
[Bearbeiten] Grundprinzip
Zur Erfüllung ihrer jeweiligen Anforderungen beschreiben Commit-Protokolle, wie die an einer Transaktion teilnehmenden Prozesse über einen Koordinator miteinander kommunizieren müssen, wie Informationen protokolliert (geloggt) werden und wie schließlich die betroffenen Daten festgeschrieben werden. Dabei werden verschiedene Fehlersituationen durch das Protokoll abgefangen, wie z. B. ein Absturz des Koordinators während einer Phase (abhängig vom Protokoll).
[Bearbeiten] Varianten
[Bearbeiten] Zwei-Phasen-Commit-Protokolle
In verteilten Systemen erstreckt sich eine Transaktion häufig über mehrere Prozesse (im Englischen in diesem Zusammenhang auch als agents bezeichnet), die gemeinsam und voneinander abhängig Daten verändern. Zur Gewährleistung der Atomarität ist hier ein verteiltes Commit-Protokoll erforderlich.
Das bekannteste Verfahren ist das sogenannte „Two-Phase-Commit“ oder Zwei-Phasen-Commit (2PC). Dabei holt ein Koordinator (meist der Prozess, der die Festschreibung einleitet) in der ersten Phase des Protokolls die Zustimmung oder Ablehnung zur Festschreibung der Datenveränderungen aller beteiligten Prozesse ein (auch „Abstimmungsphase“). Nur, wenn alle Teilnehmer zustimmen, entscheidet der Koordinator auf „Commit“, ansonsten lautet die Entscheidung „Rollback“ (Zurücksetzen). Ist die Entscheidung gefallen, unterrichtet der Koordinator in der zweiten Phase („Commit Phase“) des Protokolls die Teilnehmer über das Ergebnis. Gemäß diesem gemeinsamen Ergebnis wird entweder die gesamte Transaktion zurückgesetzt, oder alle Teiltransaktionen werden zum erfolgreichen Ende geführt indem die zwischenzeitlich gesperrten Ressourcen wieder freigegeben werden.
Beim Zwei-Phasen-Commit besteht das grundsätzliche Problem, dass Teilnehmer zwischenzeitlich blockiert werden. Das passiert, sobald ein Teilnehmer seine lokale „Commit“-Entscheidung dem Koordinator mitgeteilt hat. Danach wartet der Teilnehmer auf die globale (gemeinsame) Entscheidung. Das wird vor allem dann problematisch, wenn der Koordinator zwischenzeitlich ausgefallen ist. In dieser Situation kann der Teilnehmer weder die gesperrten Ressourcen freigeben, noch die lokale Transaktion zurücksetzen. Allenfalls kann der Teilnehmer die globale Commit-Entscheidung von einem anderen Teilnehmer in Erfahrung bringen.
[Bearbeiten] Drei-Phasen-Commit-Protokolle
Zur Reduzierung der Zahl der notwendigen Protokollierungsvorgänge, der Zahl der erforderlichen Nachrichten sowie zur Steigerung der Robustheit werden in der Fachliteratur zahlreiche Varianten des 2PC-Protokolls diskutiert. So zielt etwa das sogenannte Drei-Phasen-Commit-Protokoll (3PC) darauf ab, das Risiko der Blockierung zu vermeiden. Dazu ist eine Erhöhung der Zahl der Nachrichtenrunden erforderlich, damit bei einem zwischenzeitlichen Ausfall des Koordinators das Protokoll durch einen neuen Koordinator zu Ende geführt werden kann. Auch hier besteht allerdings die Gefahr, dass eine inkonsistente Entscheidung aufgrund einer Netzpartitionierung getroffen wird. Eine Lösung für das Partitionierungsproblem stellt der Paxos-Consensus-Algorithmus dar.
