DBMS distribuito: protocolli di commit

In un sistema di database locale, per eseguire il commit di una transazione, il gestore delle transazioni deve trasmettere solo la decisione di eseguire il commit al gestore del recupero. Tuttavia, in un sistema distribuito, il gestore delle transazioni dovrebbe trasmettere la decisione di impegnarsi a tutti i server nei vari siti in cui viene eseguita la transazione e applicare la decisione in modo uniforme. Quando l'elaborazione è completa in ogni sito, raggiunge lo stato della transazione parzialmente confermata e attende che tutte le altre transazioni raggiungano lo stato parzialmente confermato. Quando riceve il messaggio che tutti i siti sono pronti per il commit, inizia a eseguire il commit. In un sistema distribuito, tutti i siti eseguono il commit o nessuno di essi lo fa.

I diversi protocolli di commit distribuiti sono:

  • Impegno in una fase
  • Commit in due fasi
  • Impegno in tre fasi

Commit distribuito in una fase

Il commit distribuito in una fase è il protocollo di commit più semplice. Si consideri che esiste un sito di controllo e una serie di siti slave in cui viene eseguita la transazione. I passaggi nel commit distribuito sono:

  • Dopo che ogni slave ha completato localmente la propria transazione, invia un messaggio "FATTO" al sito di controllo.

  • Gli slave attendono il messaggio "Commit" o "Abort" dal sito di controllo. Questo tempo di attesa è chiamatowindow of vulnerability.

  • Quando il sito di controllo riceve il messaggio "FATTO" da ogni slave, decide se eseguire il commit o l'interruzione. Questo è chiamato il punto di commit. Quindi, invia questo messaggio a tutti gli schiavi.

  • Alla ricezione di questo messaggio, uno slave esegue il commit o interrompe e quindi invia un messaggio di riconoscimento al sito di controllo.

Commit distribuito in due fasi

Il commit a due fasi distribuito riduce la vulnerabilità dei protocolli di commit a una fase. I passaggi eseguiti nelle due fasi sono i seguenti:

Phase 1: Prepare Phase

  • Dopo che ogni slave ha completato localmente la propria transazione, invia un messaggio "FATTO" al sito di controllo. Quando il sito di controllo ha ricevuto il messaggio "FATTO" da tutti gli slave, invia un messaggio "Prepara" agli slave.

  • Gli schiavi votano se vogliono ancora impegnarsi o meno. Se uno slave desidera eseguire il commit, invia un messaggio "Pronto".

  • Uno slave che non desidera eseguire il commit invia un messaggio "Non pronto". Ciò può accadere quando lo slave ha transazioni concorrenti in conflitto o si verifica un timeout.

Phase 2: Commit/Abort Phase

  • Dopo che il sito di controllo ha ricevuto il messaggio "Pronto" da tutti gli slave:

    • Il sito di controllo invia un messaggio "Global Commit" agli slave.

    • Gli slave applicano la transazione e inviano un messaggio "Conferma ACK" al sito di controllo.

    • Quando il sito di controllo riceve il messaggio "Commit ACK" da tutti gli slave, considera la transazione come confermata.

  • Dopo che il sito di controllo ha ricevuto il primo messaggio "Non pronto" da qualsiasi slave -

    • Il sito di controllo invia un messaggio "Global Abort" agli slave.

    • Gli schiavi interrompono la transazione e inviano un messaggio "Abort ACK" al sito di controllo.

    • Quando il sito di controllo riceve il messaggio "Abort ACK" da tutti gli slave, considera la transazione come interrotta.

Commit trifase distribuito

I passaggi nel commit trifase distribuito sono i seguenti:

Phase 1: Prepare Phase

I passaggi sono gli stessi del commit distribuito in due fasi.

Phase 2: Prepare to Commit Phase

  • Il sito di controllo emette un messaggio di trasmissione "Enter Prepared State".
  • I siti schiavi votano "OK" in risposta.

Phase 3: Commit / Abort Phase

I passaggi sono gli stessi del commit in due fasi tranne per il fatto che il messaggio "Conferma ACK" / "Interrompi ACK" non è richiesto.