Commit-Protokoll

Commit-Protokolle der Informatik regeln die Festschreibung (Commit) von Daten, die durch eine (verteilte) Transaktion beispielsweise in einem Datenbankmanagementsystem verändert werden sollen. Bekannte Commit-Protokolle für verteilte Systeme sind beispielsweise Paxos, Raft, Zwei- und Drei-Phasen-Commit.

Die wünschenswerten Eigenschaften (verteilter) Transaktionen werden durch ACID definiert. Das Commit-Protokoll ist für die Gewährleistung dieser Eigenschaften zuständig. Je nach Commit-Protokoll müssen nicht alle Eigenschaften verpflichtend erfüllt werden.

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).

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 und über X/Open XA standardisierte 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 dann, 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.

Während der beiden Phasen werden die folgenden Nachrichten zwischen den Teilnehmern ausgetauscht:^[1]

• Commit-request-Phase
  1. Der Koordinator sendet ein prepare an alle Teilnehmer und wartet auf Antworten aller Teilnehmer.
  2. Die Teilnehmer verarbeiten die Transaktion bis zu dem Punkt, wo die Transaktion entweder mit commit oder rollback abgeschlossen wird. Dabei schreiben sie Einträge in ihr undo log und in ihr redo log.
  3. Die Teilnehmer antworten mit ready, wenn die Transaktion erfolgreich war – oder sie antworten mit failed, wenn die Transaktion fehlgeschlagen ist.
• Commit-Phase:
  • Wenn der Koordinator von allen Teilnehmern eine ready-Meldung bekommen hat:
    1. Der Koordinator sendet commit an alle Teilnehmer.
    2. Die Teilnehmer schließen die Transaktion mit commit ab und geben alle Sperren und Ressourcen frei.
    3. Die Teilnehmer senden ein acknowledgment zurück.
    4. Der Koordinator beendet die Transaktion, wenn er von allen Teilnehmern die Bestätigung erhalten hat.
  • Wenn zumindest einer der Teilnehmer ein failed schickt:
    1. Der Koordinator sendet abort an alle Teilnehmer.
    2. Die Teilnehmer schließen die Transaktion mit rollback ab (mittels des undo logs) und geben alle Sperren und Ressourcen frei.
    3. Die Teilnehmer senden ein acknowledgment zurück.
    4. Der Koordinator beendet die Transaktion ebenso mit rollback, wenn er von allen Teilnehmern die Bestätigung erhalten hat.

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.

Das 2PC-Protokoll garantiert die Korrektheit auch dann, wenn einzelne oder mehrere Rechner ausfallen oder wenn Netzwerkpartitionierungen auftreten, so dass die Kommunikation zwischen lauffähigen Rechnern unterbunden wird. Korrektheit bedeutet dabei: Es kann nicht vorkommen, dass eine Transaktion bei verschiedenen Teilnehmern zu unterschiedlichen Ergebnissen kommt.

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.

• Datenqualität
• Netzprotokoll

1. ↑ Alfons Kemper, André Eickler: Datenbanksysteme. Eine Einführung. 6. Auflage. Oldenbourg, München 2006, ISBN 978-3-486-57690-0.