TRANSAZIONI DISTRIBUITE TRANSAZIONI

Transcript

1 TRANSAZIONI DISTRIBUITE Transazioni distribuite Atomicità di una transazione distribuita Protocollo Two-Phase Commit Gestione dell affidabilità Fallimenti durante il 2PC Gestione della concorrenza Serializzabilità locale e globale Protocollo 2PL (Two-Phase Locking) distribuito Situazioni di stallo Riferimenti [1] A.Albano Costruire sistemi per basi di dati, Addison Wesley, 2001 [4] P.Atzeni,S.Ceri,P.Fraternali,S.Paraboschi,R.Torlone Basi di dati architetture e linee di evoluzione, McGraw-Hill, 2003 [5] M.T.Ozsu,P.Valduriez Principles of Distributed Database Systems, 2nd edition, Prentice Hall, 1991 Transazioni distribuite 1 TRANSAZIONI Una transazione è una unità elementare di lavoro svolta da una applicazione; comandi di transazione: Start transaction / end transaction Commit / Rollback Se una transazione esegue un rollback oppure viene uccisa dal sistema si dice che la transazione va in abort Proprietà acide di una transazione (ACID) Atomicity, atomicità: una transazione è una unità indivisibile di esecuzione (tutta o niente, abort undo) Consistency, consistenza: non devono essere violati i vincoli di integrità della base di dati (verifica immediata o differita al momento del commit, es. cicli nei vincoli di integrità referenziali) Isolation, isolamento: l esito di una transazione è indipendente dall esecuzione concorrente di altre transazioni (2PL vs 2PL stretto) Durability, persistenza: le modifiche effettuate da una transazione andata in commit devono essere permanenti (guasti redo) Transazioni distribuite 2 1

2 Caratteristiche delle transazioni distribuite Una transazione distribuita è composta da più sottotransazioni eseguite in modo concorrente da processi diversi In un DBMS distribuito le sottotransazioni vengono eseguite su nodi diversi della rete Una transazione distribuita accede quindi a dati allocati su nodi diversi La transazione distribuita deve comunque essere indivisibile Le sottotransazioni devono essere opportunamente coordinate Transazioni distribuite 3 Distributed Execution Monitor Nel sistema c è un modulo che gestisce l esecuzione delle transazioni, in ambiente distribuito è chiamato Distributed Execution Monitor Il DEM passa opportuni comandi al Data Processor che invece ha la funzione di accedere ai dati All interno del DEM possiamo individuare due componenti Lo Scheduler che si occupa di alternare le operazioni delle varie transazioni in esecuzione Il Transaction Manager che gestisce le transazioni, accetta i comandi di transazione e fa in modo che vengano eseguiti Transazioni distribuite 4 2

3 Modello del Distributed Execution Monitor Begin_trans, Read, Write Commit, Abort Risultati Distributed Execution Monitor Transaction Manager TM Con altri SC Con altri TM Con altri data processor Scheduler SC verso data processor Transazioni distribuite 5 Operazioni e Transaction Manager Begin_transaction Sta per cominciare una nuova transazione Il TM registra il nome della transazione, l applicazione da cui ha origine,.. Read Se il dato x è memorizzato localmente, il suo valore viene letto e restituito Altrimenti il TM sceglie una copia di x e chiede che venga restituita Write Il TM coordina l aggiornamento del valore di x in tutti i siti dove è memorizzato Commit Il TM coordina l aggiornamento fisico di tutti i database che contengono copie di tutti i dati che erano stati scritti Abort Il TM fa in modo che le transazioni non abbiano effetto sul database Transazioni distribuite 6 3

4 Classificazione delle transazioni (1) Classificazione delle transazioni basata sulla natura dei comandi SQL che le compongono Richieste remote Transazioni di sola lettura verso un solo DBMS remoto (più comandi SELECT verso un unico DBMS remoto) Transazioni remote Transazioni costituite da più comandi (SELECT, INSERT, DELETE, UPDATE) diretti ad un unico DBMS remoto Transazioni distribuite Transazioni rivolte a più DBMS, ma un singolo comando SQL fa riferimento ai dati di un solo DBMS Richieste distribuite Transazioni arbitrarie, formate da più comandi SQL, e ciascuno di essi può far riferimento a dati distribuiti su qualunque DBMS Transazioni distribuite 7 Classificazione delle transazioni (2) Questa classificazione fa riferimento alla nozione di trasparenza a livello di linguaggio Ad esempio se abbiamo trasparenza a livello di frammentazione (l utente fa una query generica senza sapere se la relazione è frammentata e l eventuale allocazione dei frammenti) la query risultante è classificabile come richiesta distribuita La classificazione fa riferimento alle situazioni: Una transazione può solo leggere Una transazione può scrivere ma scrive su un solo DBMS Una transazione può scrivere su più nodi ma ogni comando, quindi anche ogni scrittura, è indirizzato ad un solo DBMS: necessità di un protocollo di commit a due fasi Una transazione può avere un comando (o più) che fa riferimento a più nodi (es. join): necessità di un ottimizzatore delle interrogazioni Transazioni distribuite 8 4

5 Esempio1 di transazione Conto_corrente ( num_cc, nome, saldo) divisa in due frammenti Conto_corrente1 (num_cc <= 10000) Conto_corrente2 (num_cc > 10000) Query che trasferisce 100 euro dal conto 3100 al conto con trasparenza a livello di allocazione (l utente è a conoscenza dei frammenti ma non dei nodi su cui sono allocati) Begin transaction update Conto_corrente1 set saldo = saldo 100 where num_cc = 3100; update Conto_corrente2 set saldo = saldo where num_cc = End transaction Transazioni distribuite 9 Esempio2 di transazione (1) Conto_corr (num, saldo) e Conto_risp (num, saldo) allocate in nodi diversi Transazione: sposta un ammontare da Conto_risp a Conto_corr viene eseguita come due processi diversi che si scambiano messaggi la transazione inizia nel nodo dove si trova Conto_risp la transazione effettua alcune operazioni, poi attiva la sottotransazione partecipante e le manda un messaggio Riferimento [1] Transazioni distribuite 10 5

6 Esempio2 di transazione (2) PROCESS Coordinatore; VAR EXEC SQL BEGIN DECLARE SECTION x_amm, amm, x_saldo: INTEGER; numero, da_conto, a_conto: ARRAY [1 6] OF CHAR; EXEC SQL END DECLARE SECTION BEGIN TRANSACTION WRITELN ( Scrivi Ammontare, da quale conto, a quale conto ); READ (amm, da_conto, a_conto); EXEC SQL SELECT saldo INTO :x_saldo FROM Conto_risp WHERE num = :da_conto IF x_saldo < amm THEN BEGIN WRITELN ( saldo insufficiente ); ROLLBACK; END ELSE BEGIN EXEC SQL UPDATE Conto_risp SET saldo = :saldo - :amm WHERE num = :da_conto; CREATE Partecipante; SEND (amm, a_conto) TO Partecipante; COMMIT; END END TRANSACTION; END Coordinatore Transazioni distribuite 11 Esempio2 di transazione (3) PROCESS Partecipante VAR EXEC SQL BEGIN DECLARE SECTION amm, x_saldo: INTEGER; a_conto: ARRAY [1 6] OF CHAR; EXEC SQL END DECLARE SECTION BEGIN RECEIVE ( amm, a_conto) FROM Coordinatore; EXEC SQL UPDATE Conto_corr SET saldo=saldo + :amm WHERE num = :a_conto; IF SQLCODE = 0 THEN COMMIT ELSE ROLLBACK END Partecipante Transazioni distribuite 12 6

7 Atomicità di una transazione Una transazione distribuita è composta da più sottotransazioni eseguite su nodi diversi Ogni sottotransazione può andare in commit o in abort indipendentemente dalle altre La transazione distribuita può andare in commit solo se tutte le sottotransazioni terminano correttamente Deve quindi essere seguito un protocollo particolare per arrivare alla decisione di commit o abort per la transazione Protocollo di commit a due fasi (Two-Phase Commit Protocol, 2PC) Tutti i server su cui sono eseguite le sottotransazioni sono detti partecipanti ; esiste un processo detto coordinatore Vengono scritti nuovi tipi di record nel log per rendere il protocollo resistente ai guasti Transazioni distribuite 13 2PC / Two-Phase Commit Protocol Abbiamo un numero arbitrario di partecipanti e un coordinatore Partecipanti: RM, Resource Manager (sono le sottotransazioni) Coordinatore: TM, Transaction Manager Un RM viene eseguito sotto il controllo del Transaction Manager locale ed esegue quanto localmente necessario: scrittura sul Log di Begin, Insert, regola WAL (Write Ahead Log), commit precedenza, Il TM spesso è eseguito sul nodo che ha attivato la transazione Fase uno Vengono interrogate le sottotransazioni, raccolte le loro decisioni e deciso un commit globale (se tutte hanno comunicato una terminazione positiva) o un abort globale Fase due La decisione globale viene comunicata alle sottotransazioni che effettuano le relative operazioni Transazioni distribuite 14 7

8 Protocollo 2PC - Log TM e RM hanno ognuno un proprio Log Record particolari scritti da TM nel suo Log PREPARE contiene l identificativo dei processi RM (nodo e processo) GLOBAL COMMIT esprime la decisione atomica e persistente di terminare con successo l intera trasmissione GLOBAL ABORT COMPLETE viene scritto al termine del 2PC Record particolari scritti da ogni RM nel suo Log READY contiene l identificativo (nodo e processo) di TM, esprime la volontà irrevocabile di partecipare al 2PC per contribuire ad un commit Transazioni distribuite 15 Protocollo 2PC in assenza di guasti prima fase TM Registra Prepare nel proprio Log Imposta un tempo massimo di attesa, timeout Invia un messaggio Prepare a tutti gli RM RM Un RM in stato affidabile scrive Ready nel proprio Log e trasmette a TM un messaggio di Ready (vote-commit) Un RM non in stato affidabile (fallimento di transazione) invia un messaggio di not-ready (vote-abort) e termina il protocollo TM Colleziona tutte le risposte Se riceve da tutti gli RM un messaggio di Ready scrive Global Commit nel proprio Log Se non riceve tutte risposte positive, o se allo scadere del timeout non ha ancora ricevuto risposta da tutti gli RM, scrive Global Abort sul proprio Log Es. di risposta mancante: RM ha deciso autonomamente un abort Transazioni distribuite 16 8

9 Protocollo 2PC in assenza di guasti seconda fase TM Trasmette la sua decisione agli RM Imposta un timeout RM in stato ready Riceve da TM la decisione globale Scrive Commit o Abort sul proprio Log Invia un messaggio di Ack (Acknowledge) al TM L esecuzione del Commit o Abort procede localmente TM Colleziona tutti gli Ack Se riceve tutti gli Ack scrive Complete nel proprio Log Se scatta il timeout senza aver ricevuto tutte le risposte, imposta un nuovo timeout e ripete la trasmissione verso gli RM che non hanno risposto, e così via finché non arrivano tutti gli Ack Transazioni distribuite 17 Azioni del protocollo 2PC coordinatore INITIAL PREPARE partecipante INITIAL Write begin_commit WAIT VOTE-ABORT Write abort no Ready to commit? si VOTE-COMMIT Write ready Any NO? no si Write abort GLOBAL-COMMIT GLOBAL-ABORT READY Write commit COMMIT ABORT ACK ACK Write abort abort Type of msg? commit Write commit Write end_of_transaction ABORT COMMIT Transazioni distribuite 18 9

10 Struttura del 2PC centralizzato coordinatore partecipanti coordinatore partecipanti coordinatore PREPARE VOTE-ABORT / VOTE-COMMIT GLOBAL-ABORT / GLOBAL-COMMIT ABORT / COMMIT Fase 1 Fase 2 Transazioni distribuite 19 Protocollo 2PC - osservazioni Assenza di comunicazione fra TM e RM Durante la prima fase: Abort globale Durante la seconda fase: ripetizione della trasmissione da parte di TM Un RM ready perde la propria autonomia rispetto a TM e rimane in attesa di quanto deciderà TM Intervallo di incertezza: intervallo fra la scrittura sul Log di Ready e la scrittura di Commit o Abort Durante l intervallo di incertezza i lock acquisiti permangono, non vengono ancora rilasciati (se si ha un fallimento di TM o della rete si deve aspettare il ripristino dal fallimento): protocollo blocca nte Le prossime figure sono riprese da [4] Nella seconda viene visualizzato un client che lancia il processo applicativo RM ( e poi altri ) e ne attende la terminazione; una volta che gli RM comunicano di aver terminato, lancia il 2PC interagendo con il TM In questo modello è il client a coordinare un esecuzione distribuita Transazioni distribuite 20 10

11 Protocollo 2PC finestra di incertezza Prepare Global decision Complete TM prepare msg ready msg Ready decision msg Local decision ack msg RM Finestra di incertezza Transazioni distribuite 21 Protocollo 2PC nel contesto di una transazione CLIENT exec done 2PC done TM Begin Update Update RM Transazioni distribuite 22 11

12 Protocollo 2PC guasti caduta di un partecipante Ricordiamo che la caduta di un partecipante comporta la perdita dei buffer Nel protocollo di ripresa a caldo, viene esaminato il Log Se l ultimo record scritto dal partecipante è Una azione: le azioni devono essere disfatte Abort: le azioni devono essere disfatte Commit: le azioni devono essere rifatte Se, in questi ultimi due casi, non è stato inviato ack, si noti che il TM continua a ripetere la seconda fase finché non ottiene risposta (a seguito del recovery di RM) Ready: l esito globale è in dubbio; vengono chieste informazioni al TM Transazioni distribuite 23 Protocollo 2PC guasti caduta del coordinatore Ultimo record nel Log: Prepare Il TM ripete la prima fase del protocollo (se gli RM sono ancora pronti, si potrà avere un Commit) Ultimo record nel Log: Global Decision Ad alcuni RM potrebbe non essere ancora stata comunicata la decisione globale La seconda fase viene riiniziata inviando a tutti la decisione globale Ultimo record nel Log: Complete Il fallimento del TM non ha conseguenze sulla transazione Motivi della ripetizione della seconda fase È scaduto il timeout nel funzionamento normale Recovery di RM o TM Ripetizione seconda fase: RM può ricevere più volte la stessa decisione, questa può essere ignorata ma deve essere risposto ack Transazioni distribuite 24 12

13 Protocollo 2PC - guasti perdita di messaggi / partizionamento rete Perdita di Prepare o di Ready ( o Not-ready) Scade il timeout senza risposta e si ha un Global Abort Perdita di Decision o di Ack: Scade il timeout della seconda fase che viene ripetuta Partizionamento della rete Per il TM è come se tutti i partecipanti sconnessi dalla sottorete cui appartiene il coordinatore fossero falliti Per un RM sconnesso dalla sottorete cui appartiene il coordinatore è come se fosse fallito il coordinatore La transazione avrà successo solo se TM e tutti gli RM appartengono ad una sottorete Transazioni distribuite 25 Concorrenza Correttezza di una esecuzione concorrente distribuita: concetto di serializzabilità La serializzabilità locale delle varie sottotransazioni non garantisce la serializzabilità delle transazioni globali Esempio [4] supponiamo di avere due transazioni T 1 e T 2 che operano su due dati, x e y, allocati rispettivamente nei nodi 1 e 2. Indichiamo con S1 e S2 le storie locali T 1 : r 11 (x) w 11 (x) r 12 (y) w 12 (y) T 2 : r 22 (y) w 22 (y) r 21 (x) w 21 (y) S1 : r 11 (x) w 11 (x) r 21 (x) w 21 (x) S2 : r 22 (y) w 22 (y) r 12 (y) w 12 (y) S1 e S2 sono localmente serializzabili (sono seriali), ma nel grafo dei conflitti globale c è un ciclo: Nodo 1: T 1 precede ed è in conflitto con T 2 Nodo 2: T 2 precede ed è in conflitto con T 1 Transazioni distribuite 26 13

14 Serializzatore distribuito Ambiente distribuito: metodi che sono una generalizzazione di quelli utilizzabili sui sistemi centralizzati Serializzatore distribuito: Ogni sistema locale ha il proprio serializzatore che garantisce la serializzabilità della storia locale I serializzatori locali cooperano tra loro scambiandosi messaggi in modo da ottenere una storia globale serializzabile Consideriamo una generalizzazione del protocollo 2PL (Two- Phase Locking) Protocollo 2PL I dati vengono bloccati e rilasciati con primitive di tipo lock/unlock Dopo un unlock non possono più essere effettuati lock Protocollo 2PL stretto (garantisce l isolamento ) Gli unlock vengono effettuati tutti insieme al momento del Commit Transazioni distribuite 27 Protocollo 2PL distribuito Ogni scheduler esegue localmente un 2PL stretto Quando viene ricevuta una richiesta di blocco per un dato x, viene controllato se il dato è già bloccato, ed eventualmente la transazione viene sospesa Viene seguito un protocollo 2PC per il Commit globale La sottotransazione rilascia tutti i suoi blocchi quando riceve dal coordinatore il messaggio abort o commit Transazioni distribuite 28 14

15 Situazioni di stallo Il protocollo 2PL può portare a situazioni di stallo Una situazione di stallo globale (su più nodi) può verificarsi anche in assenza di stalli locali Esempio [1] - x, y siano dati memorizzati in N1 e N2 T 1 : r 1 (x) w 1 (y) c 1 inizia nel nodo N1 T 2 : r 2 (y) w 2 (x) c 2 inizia nel nodo N2 Si consideri la storia seguente N1: il serializzatore riceve r 1 (x) e assegna il lock rl 1 (x) N2: il serializzatore riceve r 2 (y) e assegna il lock rl 2 (y) N1: il ser. riceve w 2 (x), mette T 2 in attesa, aggiunge T 2 T 1 al proprio grafo di attesa N2: il ser. riceve w 1 (y), mette T 1 in attesa, aggiunge T 1 T 2 al proprio grafo di attesa Si ha un ciclo nel grafo di attesa globale Transazioni distribuite 29 Rilevazione delle situazioni di stallo Uso di timeout Rilevazione centralizzata: costruzione del grafo di attesa globale da parte di un controllore [1] [5] Su un nodo particolare è attivato il controllore (rilevatore globale) I serializzatori locali comunicano via via al controllore le modifiche al grafo di attesa locale Periodicamente il controllore effettua l unione dei grafi locali, se rileva un ciclo sceglie la transazione da interrompere stallo fantasma : una situazione di stallo che appare nel grafo globale, ma dovuta a ritardi nella trasmissione di modifiche del grafo locale Proposto per INGRES distribuito Algoritmo IBM DB2 distribuito: cfr. [3] Transazioni distribuite 30 15