In che modo i commit a due fasi impediscono il fallimento dell'ultimo secondo?

Question

Sto studiando come funziona il commit in due fasi in una transazione distribuita. Comprendo che nell'ultima parte della fase il coordinatore delle transazioni chiede a ciascun nodo se è pronto per il commit. Se tutti sono d'accordo, allora dice loro di andare avanti e impegnarsi.

Cosa impedisce il seguente errore?

1. Tutti i nodi rispondono che lo sono pronto a impegnare
2. La transazione il coordinatore dice loro di " andare avanti e impegna " ma uno dei nodi si blocca prima di ricevere questo il messaggio
3. Tutti gli altri nodi si impegnano correttamente, ma ora la transazione distribuita è danneggiata
4. Sono consapevole del fatto che quando il nodo in crash ritorna, la sua transazione sarà stata ripristinata (poiché non ha mai ricevuto il messaggio di commit)

Suppongo che ogni nodo stia eseguendo un normale database che non sa nulla delle transazioni distribuite. Cosa mi sono perso?

Answer 1

Riassumendo le risposte di tutti:

1. Non è possibile utilizzare normali database con transazioni distribuite. Il database deve supportare esplicitamente un coordinatore delle transazioni.

2. Ai nodi non viene richiesto di eseguire il rollback perché alcuni nodi hanno già eseguito il commit. Quello che succede è che quando il nodo in crash ritorna, il coordinatore delle transazioni gli dice di terminare il commit.

Answer 2

No, non viene loro richiesto di eseguire il rollback perché nello scenario del poster originale, alcuni dei nodi hanno già eseguito il commit. Quello che succede è quando il nodo bloccato diventa disponibile, il coordinatore delle transazioni gli dice di impegnarsi di nuovo.

Perché il nodo ha risposto positivamente nella sezione "preparare" fase, è necessario essere in grado di " commit " ;, anche quando ritorna da un arresto anomalo.

Answer 3

No. Il punto 4 non è corretto. Ogni nodo registra in un archivio stabile che è stato in grado di eseguire il commit o il rollback della transazione, in modo che possa fare come comandato anche in caso di crash. Quando viene ripristinato il nodo in crash, deve rendersi conto che ha una transazione in stato pre-commit, ripristinare eventuali blocchi o altri controlli rilevanti e quindi tentare di contattare il sito del coordinatore per raccogliere lo stato della transazione.

I problemi si verificano solo se il nodo in crash non torna mai (quindi tutto il resto pensa che la transazione sia stata OK, o lo sarà quando il nodo in crash ritorna).

Answer 4

Il commit in due fasi non è infallibile ed è progettato per funzionare nel 99% dei casi.

" Il protocollo presuppone che ci sia una memoria stabile su ciascun nodo con un registro write-ahead, che nessun nodo si blocchi per sempre, che i dati nel registro write-ahead non vengano mai persi o danneggiati in un crash e che due nodi possono comunicare tra loro. "

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

Answer 5

Esistono molti modi per attaccare i problemi con il commit in due fasi. Quasi tutti finiscono come una variante dell'algoritmo di commit trifase di Paxos. Mike Burrows, che ha progettato il servizio di blocco Chubby su Google basato su Paxos, ha affermato che esistono due tipi di algoritmi di commit distribuiti: "Paxos, e quelli errati". - in una lezione che ho visto.

Una cosa che il nodo in crash potrebbe fare, quando si risveglia, è dire "non ho mai sentito parlare di questa transazione, avrebbe dovuto essere commesso?" al coordinatore, che gli dirà quale è stato il voto.

Ricorda che questo è un esempio di un problema più generale: il nodo in crash potrebbe perdere molte transazioni prima di recuperare. Pertanto è estremamente importante che, al momento del recupero, debba parlare con il coordinatore o con un'altra replica prima di rendersi disponibile. Se il nodo stesso non è in grado di dire se si è bloccato o meno, le cose diventano più coinvolte ma ancora tracciabili.

Se si utilizza un sistema quorum per le letture del database, l'incongruenza verrà mascherata (e resa nota al database stesso).