transazioni distribuite - Dipartimento di Ingegneria dell`Informazione

Transcript

TRANSAZIONI DISTRIBUITE
•
•
Transazioni distribuite
Atomicità di una transazione distribuita
•
Gestione dell’affidabilità
– Protocollo Two-Phase Commit
– 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
F.Cesarini - Basi Dati
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)
Distribuite
2
1
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
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
Distribuite
4
2
Modello del Distributed Execution Monitor
Begin_trans,
Risultati
Read, Write
Commit, Abort
Distributed Execution
Monitor
Transaction Manager
TM
Con altri SC
Con altri
Con altri
TM
data processor
Scheduler SC
verso data
processor
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
Distribuite
6
3
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 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
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
Distribuite
8
4
Esempio1 di transazione
•
Conto_corrente ( num_cc, nome, saldo) divisa in due frammenti
– Conto_corrente1
– Conto_corrente2
•
(num_cc <= 10000)
(num_cc > 10000)
Query che trasferisce 100 euro dal conto 3100 al conto 15000 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 + 100
where num_cc = 15000
End transaction
Distribuite
9
Esempio2 di transazione (1)
• Conto_corr (num, saldo) e
allocate in nodi diversi
• Transazione:
Conto_risp (num, saldo)
– 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]
Distribuite
10
5
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
Distribuite
11
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
Distribuite
12
6
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
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
Distribuite
14
7
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
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
Distribuite
16
8
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
Distribuite
17
Azioni del protocollo 2PC
coordinatore
partecipante
INITIAL
INITIAL
RE
PREPA
Write begin_commit
Write abort
BORT
VOTE-A
WAIT
no
si
VOTE-COMMIT
Any NO
?
si
Write ready
GLOBAL-
Write abort
ABORT
READY
OMMIT
GLOBAL-C
no
Write commit
ACK
Write abort
ABORT
COMMIT
abort
Type of msg?
commit
ACK
Write end_of_transaction
Distribuite
Ready to
commit?
Write commit
ABORT
COMMIT
18
9
Struttura del 2PC centralizzato
coordinatore
partecipanti
PREPARE
coordinatore
coordinatore
VOTE-ABORT /
GLOBAL-ABORT /
ABORT /
VOTE-COMMIT
GLOBAL-COMMIT
COMMIT
Fase 1
Distribuite
partecipanti
Fase 2
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
Distribuite
20
10
Protocollo 2PC – finestra di incertezza
Prepare
Global decision
Complete
TM
prepare
msg
ready
msg
decision
msg
Ready
Local
decision
ack msg
RM
Finestra di incertezza
Distribuite
21
Protocollo 2PC nel contesto di una
transazione
CLIENT
2PC
exec
done
done
TM
Begin
Update Update
RM
Distribuite
22
11
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
–
–
–
–
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
•
Motivi della ripetizione della seconda fase
– Il fallimento del TM non ha conseguenze sulla transazione
– È 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
Distribuite
24
12
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
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 T1 e T2 che
operano su due dati, x e y, allocati rispettivamente nei nodi 1 e 2.
Indichiamo con S1 e S2 le storie locali
T1 :
T2 :
r11(x) w11(x) r12(y) w12(y)
r22(y) w22(y) r21(x) w21(y)
S1 :
S2 :
r11(x) w11(x) r21(x) w21(x)
r22(y) w22(y) r12(y) w12(y)
S1 e S2 sono localmente serializzabili (sono seriali), ma nel grafo
dei conflitti globale c’è un ciclo:
– Nodo 1: T1 precede ed è in conflitto con T2
– Nodo 2: T2 precede ed è in conflitto con T1
Distribuite
26
13
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 (TwoPhase 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
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
Distribuite
28
14
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
T1: r1(x) w1(y) c1
inizia nel nodo N1
T2: r2(y) w2(x) c2
inizia nel nodo N2
Si consideri la storia seguente
– N1: il serializzatore riceve r1(x) e assegna il lock rl1(x)
– N2: il serializzatore riceve r2(y) e assegna il lock rl2(y)
– N1: il ser. riceve w2(x), mette T2 in attesa, aggiunge T2 → T1 al
proprio grafo di attesa
– N2: il ser. riceve w1(y), mette T1 in attesa, aggiunge T1 → T2 al
proprio grafo di attesa
•
Si ha un ciclo nel grafo di attesa globale
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]
Distribuite
30
15

transazioni distribuite - Dipartimento di Ingegneria dell`Informazione

Transcript

Documenti analoghi

Basi di dati e Web introduzione

INTRODUZIONE Motivazioni e Obbiettivi

Business Integrator - infinys systems de

Tecnologia di un Database Server - Dipartimento di Matematica e

Le transazioni

Nessuno andrà più allo stadio

FINALITA` E OBIETTIVI - Istituto Comprensivo "G.Taliercio"

Modulo FAST CLAIM - Deutsche Bank Easy

laboratorio di sand-art

CITTA` DI BASSANO DEL GRAPPA C. A. P. 36061 (VI)

Transazioni