Wie verhindern zweiphasige Festschreibungen einen Ausfall in letzter Sekunde?

75

Ich untersuche, wie das Zwei-Phasen-Commit für eine verteilte Transaktion funktioniert. Nach meinem Verständnis fragt der Transaktionskoordinator im letzten Teil der Phase jeden Knoten, ob er zum Festschreiben bereit ist. Wenn alle einverstanden sind, werden sie aufgefordert, sich zu verpflichten.

Was verhindert den folgenden Fehler?

Alle Knoten antworten, dass sie zum Festschreiben bereit sind
Der Transaktionskoordinator fordert sie auf, "fortzufahren und festzuschreiben", aber einer der Knoten stürzt ab, bevor diese Nachricht empfangen wird
Alle anderen Knoten werden erfolgreich festgeschrieben, aber jetzt ist die verteilte Transaktion beschädigt
Nach meinem Verständnis wurde die Transaktion des abgestürzten Knotens zurückgesetzt, wenn er zurückkommt (da er nie die Festschreibungsnachricht erhalten hat).

Ich gehe davon aus, dass auf jedem Knoten eine normale Datenbank ausgeführt wird, die nichts über verteilte Transaktionen weiß. Was habe ich verpasst?

database distributed-transactions

— Gili
quelle

2

Ihre Annahme einer normalen Datenbank ist falsch. Jede Ressource (Nachrichtenwarteschlange, Datenbank usw.) unterstützt verteilte Transaktionen (durch Unterstützung eines Transaktionskoordinators) oder nicht. Wenn dies nicht der Fall ist, wird die Zuverlässigkeit beeinträchtigt, wenn Sie es in eine verteilte Transaktion aufnehmen.

— Erickson

Erickson, wenn Sie die Antworten anderer Leute mit Ihrem Kommentar einfügen, werde ich ihn als offizielle Antwort markieren.

— Gili

43

Nein, sie werden nicht angewiesen, ein Rollback durchzuführen, da im Szenario des Originalplakats einige der Knoten bereits festgeschrieben wurden. Wenn der abgestürzte Knoten verfügbar wird, weist der Transaktionskoordinator ihn an, erneut ein Commit durchzuführen.

Da der Knoten in der Vorbereitungsphase positiv reagiert hat, muss er in der Lage sein, "festzuschreiben", selbst wenn er von einem Absturz zurückkommt.

— Jason Kresowaty
quelle

Ich verstehe nicht, wie der abgestürzte Knoten die Transaktion bis zu der Position wiedergeben soll, an der sie aufgehört hat. Was verhindert, dass die Datenbank bei einem Absturz zurückgesetzt wird, wenn Sie eine verteilte Transaktionsbibliothek über eine normale Datenbank anpassen?

— Gili

8

Gili: Weil es versprochen hat, dass es in der Vorbereitungsphase von 2PC möglich sein wird.

— Thomas

3

@Gili Die abgestürzte Datenbank muss die Transaktion nicht erneut abspielen. Bei herkömmlichen DB-Transaktionen werden diese Änderungen aktiv im Transaktionsprotokoll vorgenommen. Dies geschieht nur, wenn die erforderlichen Zeilen-, Tabellen- und Seitensperren abgerufen werden können. Im Wesentlichen hat die Transaktion nach der ersten Phase die Datenbank bereits geändert, aber andere Abfragen können diese Änderungen erst sehen, wenn sie als festgeschrieben markiert sind. Sie müssen sie nur noch als verpflichtet markieren.

— AaronLS

26

Alle Antworten zusammenfassen:

Bei verteilten Transaktionen kann man keine normalen Datenbanken verwenden. Die Datenbank muss explizit einen Transaktionskoordinator unterstützen.
Die Knoten werden nicht zum Zurücksetzen angewiesen, da einige der Knoten bereits festgeschrieben haben. Wenn der abgestürzte Knoten zurückkommt, weist der Transaktionskoordinator ihn an, das Festschreiben zu beenden.

— Gili
quelle

3

Was passiert, wenn der Koordinator abstürzt, während der Knoten ausgefallen ist, und der Knoten aufwacht, während der Koordinator noch ausgefallen ist? Was macht der Knoten dann?

— Aviad P.

3

Ich schlage vor, eine separate Frage zu diesem Thema zu stellen. Ich kenne die Antwort selbst nicht, aber ich vermute, dass der Knoten darauf wartet, dass der Koordinator zurückkommt, bevor er Clientverbindungen akzeptiert.

— Gili

2

Ohne den Koordinator kommt natürlich alles zum Stillstand.

— Jaco Van Niekerk

21

Punkt 4 ist falsch. Jeder Knoten zeichnet in einem stabilen Speicher auf, dass er die Transaktion festschreiben oder zurücksetzen konnte, sodass er auch bei Abstürzen die Anweisungen ausführen kann. Wenn der abgestürzte Knoten wieder hochgefahren wird, muss er erkennen, dass sich eine Transaktion im Status vor dem Festschreiben befindet, relevante Sperren oder andere Steuerelemente wiederherstellen und dann versuchen, die Koordinator-Site zu kontaktieren, um den Status der Transaktion zu erfassen.

Die Probleme treten nur auf, wenn der abgestürzte Knoten nie wieder hochgefahren wird (dann denkt alles andere, dass die Transaktion in Ordnung war oder wenn der abgestürzte Knoten zurückkommt).

— Jonathan Leffler
quelle

Geht dies nicht davon aus, dass der Datenbank verteilte Transaktionen bekannt sind? Ich dachte, Sie sollten in der Lage sein, verteilte Transaktionen auf normale Datenbanken zu setzen, die nichts davon wissen ...

— Gili

6

Nein; Das DBMS muss sich seiner Verantwortlichkeiten im 2PC-Protokoll bewusst sein. Die Hauptverantwortung besteht darin, eine Transaktion in einem Go / No-Go-Status zu halten, bis der Koordinator den Befehl erteilt. Sie verlieren (Autonomie) an diesem Punkt. Informix implementiert ein heuristisches Rollback, um verschwundene Systeme zu behandeln.

— Jonathan Leffler

12

Das Zwei-Phasen-Commit ist nicht kinderleicht und wurde nur für 99% der Fälle entwickelt.

"Das Protokoll geht davon aus, dass auf jedem Knoten mit einem Write-Ahead-Protokoll ein stabiler Speicher vorhanden ist, dass kein Knoten für immer abstürzt, dass die Daten im Write-Ahead-Protokoll bei einem Absturz niemals verloren gehen oder beschädigt werden und dass zwei beliebige Knoten kommunizieren können miteinander."

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

— Reno
quelle

Selbst wenn die von Ihnen genannten Annahmen erfüllt sind, sehe ich nicht, wie der Knoten wissen soll, dass er die Transaktion wiedergibt (anstatt sie zurückzusetzen), wenn sie von einem Absturz zurückkommt. Soweit ich weiß, ist der Datenbank die verteilte Transaktion nicht bekannt. etwas darüber tut es.

— Gili

@Gili: Die Datenbank muss über die verteilte Transaktion Bescheid wissen, um 2PC korrekt zu unterstützen. Wenn Sie etwas darauf aufbauen, haben Sie keine zuverlässige 2PC-Implementierung.

— Jonathan Leffler

Dies ist nicht richtig gesagt. 2PC ist unter bestimmten Voraussetzungen zu 100% korrekt. Bei dieser Frage muss der Teilnehmer die Daten aus dem Pre-Commit dauerhaft speichern und das Commit nach einem Neustart beenden können, wenn der Koordinator dies anweist. Der Koordinator muss auch die endgültige Entscheidung zum Zurücksetzen oder Festschreiben dauerhaft speichern, falls dies fehlschlägt. Außerdem dürfen nicht alle Teilnehmer für immer abstürzen, sie müssen schließlich neu starten und die dauerhaft gespeicherten Daten haben. Wenn diese erfüllt sind, ist 2PC 100% korrekt. Wenn nicht, kann es falsch sein.

— Oliv

7

Es gibt viele Möglichkeiten, die Probleme mit einem Zwei-Phasen-Commit anzugreifen. Fast alle von ihnen werden als eine Variante des dreiphasigen Paxos-Festschreibungsalgorithmus angezeigt. Mike Burrows, der den auf Paxos basierenden Chubby Lock-Dienst bei Google entwickelt hat, sagte in einem Vortrag, den ich gesehen habe, dass es zwei Arten von verteilten Festschreibungsalgorithmen gibt - "Paxos und falsche".

Eine Sache, die der abgestürzte Knoten tun könnte, wenn er wieder aufwacht, ist zu sagen: "Ich habe noch nie von dieser Transaktion gehört, sollte sie festgeschrieben worden sein?" an den Koordinator, der ihm mitteilen wird, wie die Abstimmung war.

Beachten Sie, dass dies ein Beispiel für ein allgemeineres Problem ist: Der abgestürzte Knoten kann viele Transaktionen verpassen, bevor er wiederhergestellt wird. Daher ist es fürchterlich wichtig, dass es nach der Wiederherstellung entweder mit dem Koordinator oder einem anderen Replikat spricht, bevor es sich zur Verfügung stellt. Wenn der Knoten selbst nicht erkennen kann, ob er abgestürzt ist oder nicht, werden die Dinge komplizierter, aber dennoch nachvollziehbar.

Wenn Sie ein Quorum-System für Datenbanklesevorgänge verwenden, wird die Inkonsistenz maskiert (und der Datenbank selbst bekannt gemacht).

— HenryR
quelle

Wie spielt der Knoten die Transaktion wieder ab, wenn sie erneut aktiviert wird? Soweit ich weiß, werden normale Datenbanken bei einem Absturz immer zurückgesetzt, und sie kennen verteilte Transaktionen nicht (Sie passen eine Bibliothek darüber). Als solches sehe ich nicht, wie Sie diese Arbeit machen können.

— Gili