Basi di dati distribuite: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
+client-server
+2PC
Riga 81:
 
Un metodo per passare a nuovi sistemi è la creazione di un gateway, cioè un sistema che si interpone tra il nuovo e il vecchio, permettendo l'intercomunicazione finchè il passaggio non sarà avvenuta completamente. Questi trasferimenti durano parecchi anni, con costi molto elevati e tempi molto lunghi, soprattutto per garantire l'affidabilità del trasferimento e del nuovo sistema.
 
== Controllo di concorrenza distributo ==
Si rende necessario adottare tecniche per garantire il controllo di concorrenza anche in ambito distribuito. Fortunatamente le proprietà CID rimangono valide anche in ambito distribuito:
* Consistenza: se ogni sottotransazione preserva l'integrità locale, anche i dati globali saranno coerenti e consistenti;
* Isolamento: se ogni sottotransazione è ''2PL'' o ''TS'' allora la transazione è globalmente serializzabile;
* Persistenza (Durability): se ogni sottotransazione utilizza il log in formato corretto, la persistenza dei dati globali è garantito.
 
E l'atomicità? Per garantire l'atomicità tutti i nodi devono decidere ugualmente se effettuare un ''commit'' o un ''abort'', tenendo anche conto dei possibili errori di comunicazione che possono avvenire (caduta di un nodo, downlink, ack mancante, ecc.). Per questo si rendono necessari i cosiddetti '''protocolli di commit'''.
 
=== Protocollo di commit 2PC ==
I server della rete vengono classificati in:
* '''Transaction Manager (TM)''', un solo server che si occupa di coordinare il protocollo. L'estensione dei record di log per questo server comprende:
** ''prepare'': indica quali nodi della rete partecipano al protocollo
** ''global commit/abort'': indica a tutti i nodi della rete in modo atomico e persistente l'azione da eseguire
** ''complete'': indica la conclusione del protocollo di commit
* '''Resource Manager (RM)''', tutti gli altri server, che possiedono i seguenti messaggi/record di log:
** ''ready'': indica la disponibilità a partecipare alla procedura del protocollo
** ''local commit/abort'': indica nel log l'operazione indicata dal TM
 
Esempio di comunicazione avvenuta con successo:
# ''TM''->''RMs'': ''prepare''
# ''RMs''->''TM'': ''ready''
# ''TM''->''RMs'': ''global commit/abort''
# ''RMs''->''TM'': ''ack''
# ''TM'' solo log: ''complete''
 
==== Reazione ai guasti ====
Il protocollo deve essere in grado di rispondere a diversi guasti, tra cui:
* '''Perdita di un RM''': protocollo di ripresa a caldo, dipende dall'ultimo stato presente nel log degli RM (se è abort, sarà effettuata un'operazione di UNDO, altrimenti se è commit REDO). Se il log di un RM non contiene informazioni (è nello stato di ready) dovrà chiedere al TM cosa fare;
* '''Perdita del TM''': se il TM non ha ancora inviato le azioni globali, un ''global abort'' viene effettuato. Altrimenti il ''TM'' reinvierà tutti i messaggi globali.
* '''Problemi di rete''': se un messaggio viene perso o vi è una separazione della rete, si esauriranno i timeout in attesa dei riscontri e dei ''ready'' e un ''global abort'' sarà inviato dal TM. Il sistema è comunque in grado di eseguire transazioni che facciano parte della partizione del TM.
 
== Note ==