Wie verhindern zweiphasige Commits im zweiten Sekunde ein Fehler?

Question

Ich untersuche, wie zweiphasige Commit in einer verteilten Transaktion funktioniert. Nach meinem Verständnis fragt der Transaktionskoordinator im letzten Teil der Phase jeden Knoten, ob er bereit ist, sich zu engagieren. Wenn sich alle einig waren, dann fordert es ihnen auf, weiterzumachen und sich zu verpflichten.

Was verhindert das folgende Fehler?

1. Alle Knoten antworten, dass sie bereit sind zu verpflichten
2. Der Transaktionskoordinator fordert ihnen auf
3. Alle anderen Knoten verpflichten sich erfolgreich, aber jetzt ist die verteilte Transaktion korrupt
4. Nach meinem Verständnis, wenn der abgestürzte Knoten zurückkommt, wurde seine Transaktion zurückgerollt (da er nie die Commit -Nachricht erhalten hat)

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

Answer 1

Zusammenfassung aller Antworten:

1. Man kann keine normalen Datenbanken mit verteilten Transaktionen verwenden. Die Datenbank muss einen Transaktionskoordinator explizit unterstützen.

2. Die Knoten werden nicht angewiesen, sich zurückzusetzen, da einige der Knoten bereits begangen wurden. Was passiert, ist, dass der Transaktionskoordinator, wenn der abgestürzte Knoten zurückkommt, ihm teilt, das Commit zu beenden.

Answer 2

Nein, sie werden nicht angewiesen, sich zurückzuziehen, da im Szenario des Originalplakers einige der Knoten bereits begangen wurden. Wenn der abgestürzte Knoten verfügbar ist, fordert der Transaktionskoordinator ihn erneut an.

Da der Knoten in der Phase "vorbereiten" positiv reagierte, muss er in der Lage sein, "zu verpflichten", auch wenn er von einem Absturz zurückkommt.

Answer 3

Punkt 4 ist falsch. Jeder Knoten zeichnet im stabilen Speicher auf, dass er die Transaktion begehen oder rollen konnte, damit er auch über Abstürze befohlen wird. Wenn der abgestürzte Knoten zurückkommt, muss er erkennen, dass er über eine Transaktion im Zustand vor dem Kommunikation verfügt, relevante Schlösser oder andere Steuerelemente wiederherstellt und dann versucht, den Koordinator-Standort zu kontaktieren, um den Status der Transaktion zu sammeln.

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

Answer 4

Das Two -Phase -Commit ist nicht narrensicher und ist nur für die Arbeit in den 99% der Fälle ausgelegt.

"Das Protokoll geht davon aus miteinander."

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

Answer 5

Es gibt viele Möglichkeiten, die Probleme mit dem Zweiphasen-Commit anzugreifen. Fast alle von ihnen landen als eine Variante des Paxos-Dreiphasen-Commit-Algorithmus. Mike Burrows, der den molligen Lock -Service bei Google entworfen hat, der auf Paxos basiert, sagte, dass es zwei Arten von verteilten Commit -Algorithmen gibt - "Paxos und falsche" - in einem Vortrag, den ich gesehen habe.

Eine Sache, die der abgestürzte Knoten tun könnte, wenn er wieder aufnimmt, ist zu sagen: "Ich habe nie von dieser Transaktion gehört, sollte er begangen werden?" dem Koordinator, der ihm sagen wird, was die Abstimmung war.

Denken Sie daran, dass dies ein Beispiel für ein allgemeineres Problem ist: Der abgestürzte Knoten könnte viele Transaktionen verpassen, bevor er sich erholt. Daher ist es furchtbar wichtig, dass es bei Genesung entweder mit dem Koordinator oder einer anderen Replik spricht, bevor es sich selbst zur Verfügung stellt. Wenn der Knoten selbst nicht feststellen kann, ob er abgestürzt ist oder nicht, werden die Dinge mehr involviert, aber dennoch flehbar.

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