Architetture distribuite

Transcript

1 Architetture distribuite Basi di dati: Architetture e linee di evoluzione - Seconda edizione Capitolo 6 Appunti dalle lezioni Sommario Architetture client-server Basi di dati distribuite Basi di dati parallele Basi di dati replicate Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 2

2 Paradigma client-server Tecnica per strutturare sistemi software Viene resa "pubblica" una "interfaccia di servizi" Due tipologie di sistemi: CLIENT richiedono i servizi SERVER forniscono i servizi servizi richiesti dal CLIENT svolti dai SERVER Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 3 Client-server nei sistemi informativi Separazione funzionale ideale CLIENT presentazione dell'informazione SERVER gestione dei dati SQL il linguaggio ideale per separare gli ambienti CLIENT formula query, elabora risultati SERVER esegue query RETE trasferisce i comandi di attivazione (es: di procedure SQL) e i risultati Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 4

3 Architettura client-server classica CLIENT compone richieste in SQL SERVER esegue richieste in SQL Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 5 Architettura con server applicativo CLIENT richiede applicazioni CLIENT CLIENT SERVER APPLICATIVO compone richieste in SQL DATABASE SERVER esegue richieste in SQL Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 6

4 Sommario Architetture client-server Basi di dati distribuite Basi di dati parallele Basi di dati replicate Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 7 DB Distribuiti Un DB distribuito è una collezione di dati: Logicamente appartenenti allo stesso sistema. I dati hanno cioè caratteristiche tali che li legano insieme cosicché un DB distribuito è diverso da un insieme di DB centralizzati. Sono distribuiti su più server collegati in rete. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 8

5 Motivazioni Natura intrinsecamente distribuita delle organizzazioni Evoluzione degli elaboratori Aumento della capacità' elaborativa Riduzione di prezzo Evoluzione della tecnologia dei DBMS Standard di interoperabilità Evoluzione delle reti Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 9 DB Distribuiti: Classificazione Se su tutti i server è usato lo stesso DBMS si parla di DB omogenei. Se i DBMS sono diversi si parla di DB eterogenei. E anche importante sapere se i vari server sono collegati da una LAN o da una WAN. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 10

6 Tipici esempi di applicazioni Omogeneo Eterogeneo LAN Applicazioni gestionali e finanziarie Applicazioni gestionali interfunzionali WAN Sistemi di prenotazione, applicazioni finanziarie Sistemi di prenotazione integrati, sistemi interbancari Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 11 Problemi delle basi di dati distribuite Autonomia e cooperazione Trasparenza Efficienza Affidabilità Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 12

7 Autonomia e cooperazione L'esigenza di autonomia: Una reazione ai ''Centri EDP'' Portare competenze e controllo laddove vengono gestiti i dati Rendere la maggior parte delle applicazioni NON distribuite (!) L'esigenza di cooperazione: Alcune applicazioni sono intrinsecamente distribuite e richiedono l'accesso a più basi di dati Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 13 Frammentazione dei dati Posso frammentare lo schema Vincoli di integrità referenziale non sono più esprimibili in maniera immediata Posso frammentare la tabella Frammentazione orizzontale I frammenti sono insiemi di tuple con lo stesso schema. La relazione originale si ottiene con l unione. Frammentazione verticale I vari frammenti hanno uno schema ottenuto come sottoinsieme dello schema della relazione di partenza. La relazione originale si ottiene con un join. La frammentazione deve essere garantire completezza e ricostruibilità. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 14

8 Frammentazione orizzontale: esempio CONTO-CORRENTE (NUM-CC, FILIALE, SALDO) TRANSAZIONE (NUM- CC,DATA,PROGR,AMMONTARE, CAUSALE) 3 filiali Frammentazione principale CONTO1 = σ Filiale=1 (CONTO-CORRENTE) CONTO2 = σ Filiale=2 (CONTO-CORRENTE) CONTO3 = σ Filiale=3 (CONTO-CORRENTE) Frammentazione derivata TR1 = Transazioni relative a conti di CONTO1 TR2 = Transazioni relative a conti di CONTO2 TR3 = Transazioni relative a conti di CONTO3 Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 15 Frammentazione verticale: esempio Impiegato(CF,Indirizzo, Dipartimento) Dipartimento(Nome,Città) AnagraficaImpiegato(CF,Indirizzo) DipartimentoImpiegato(CF,Dipartimento) La chiave è replicata ( la relazione è ricostruibile) Il vincolo di integrità referenziale si applica ad una sola relazione Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 16

9 Allocazione dei dati Ogni frammento è realizzato tramite una o più tabella in un db allocato su un certo server. Allocazione non ridondante ogni frammento o relazione viene allocato su un solo server. ridondante alcuni frammenti o relazioni sono allocati su più server. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 17 Interazione con un DB distribuito Livello di trasparenza Trasparenza di Frammentazione Interagiamo con il db distribuito come se fosse centralizzato. Non ci dobbiamo preoccupare né della eventuale frammentazione né delle allocazioni. Trasparenza di Allocazione Dobbiamo conoscere come sono frammentati i dati ma dobbiamo indicarne la allocazione. Se il sistema è ad allocazione ridondante non dobbiamo indicare a quale replica ci riferiamo per l accesso (trasparenza di replicazione) Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 18

10 Livelli di Trasparenza Trasparenza di Linguaggio Dobbiamo indicare sia i frammenti sia la loro allocazione ma non dobbiamo preoccuparci dei vari dialetti SQL usati dai vari sistemi. Assenza di trasparenza Il sistema è eterogeneo e i dialetti SQL sono diversi e noi dobbiamo specificare le varie query opportunamente. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 19 Livelli di Trasparenza: Esempio Fornitore Fornitore1 Fornitore2 [email protected] (Oracle) [email protected] (SQLServer) [email protected] (SQLServer) Problema: Selezionare il nome di un fornitore dato il suo numero Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 20

11 Livelli di Trasparenza: Esempio Trasparenza di frammentazione select nome from fornitore where numero = 125 Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 21 Livelli di Trasparenza: Esempio Trasparenza di allocazione select nome from fornitore1 where numero = 125 Se non lo trovo select nome from fornitore2 where numero = 125 Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 22

12 Livelli di Trasparenza: Esempio Trasparenza di linguaggio select nome into from where numero = 125 Se non lo trovo select nome from [email protected] where numero = 123 Assenza di trasparenza Bisogna tenere conto dei dialetti SQL nella formulazione delle query Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 23 Transazioni e DB Distribuiti Richieste remote Operazioni di sola lettura indirizzate ad un solo DBMS Transazioni remote Insieme arbitrario di comandi SQL indirizzate ad un solo DBMS Transazioni distribuite (2PC) Indirizzate a più DBMS, ma ogni comando SQL fa riferimento a dati gestiti da un solo DBMS. Richieste distribuite (2PC + Ottimizzazione Distribuita) Transazioni arbitrarie, in cui il singolo comando SQL può fare riferimento anche a dati gestiti da più DBMS Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 24

13 Acidità delle transazioni distribuite Ragioneremo sulle transazioni distribuite Consistenza Limiti tecnologici impongono che i vincoli imposti siano solo locali. Consistenza globale consistenza locale Persistenza I meccanismi utilizzati per il caso centralizzato restano validi La gestione corretta dei log a livello locale persistenza globale Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 25 Acidità delle transazioni distribuite Isolation Se ogni sistema usa il 2PL stretto la scheduling globale è serializzabile Problema del deadlock distribuito Se ogni sistema usa il metodo dei timestamps, ed essi sono assegnati in maniera globale alle sottotransazioni,lo scheduling globale è serializzabile. Atomicity È il problema che bisogna affrontare e la cui soluzione richiede l introduzione di nuovi record nel file di log. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 26

14 Commit a 2 fasi (2PC) I server vengono denominati: Resource Manager (RM); Transaction Manager (TM). L analogia più calzante è quella di un matrimonio con i promessi sposi (i RMs) ed un celebrante (TM). Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 27 Commit a 2 fasi (2PC) Il celebrante chiede ai partecipanti se vogliono sposarsi (cioè se vogliono concludere positivamente la transazione). Se tutti i partecipanti sono d accordo, il matrimonio si fa. Se almeno uno dei partecipanti non è d accordo il matrimonio si annulla. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 28

15 Durability Ogni DBMS ha ovviamente la capacità di gestire applicazioni in modo autonomo. Un progetto accurato della distribuzione dovrebbe garantire che la maggior parte possibile delle applicazioni operino localmente. Nel caso di transazioni distribuite sono possibili diversi malfunzionamenti; Caduta del TM; Caduta di uno di RM; Caduta della Rete. Nuovi record nei log. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 29 2PC in assenza di guasti Rapide scritture su log e scambi di messaggi prepare global decision complete TM prepare msg ready ready msg decision msg finestra di incertezza local decision ack msg RM Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 30

16 Nuovi record nel log del TM Ai record classici si aggiunge: Record di prepare Il TM scrive sul proprio log l identificativo dei processi RM partecipanti. Record global commit / global abort Si riporta la decisione presa relativamente alla transazione in esame. Record di complete Il protocollo è stato portato a termine. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 31 Nuovi record nel log del RM Ai record classici si aggiunge il record di ready: Se accetto: Indica l irrevocabile decisione di partecipare al commit globale. Deve essere scritto quando si è in uno stato stabile (risorse bloccate) e rispettando la WAL e la commit precedenza per il proprio log. Una volta scritto questo record, l RM perde ogni autonomia decisionale. Se rifiuto: Poi vediamo Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 32

17 To be noted Un RM dopo essersi dichiarato ready perde la sua autonomia e attende la decisione del TM. Un guasto del TM lascia l RM in uno stato di incertezza, in cui tutte le risorse acquisite con lock sono bloccate. L intervallo tra la scrittura dei record ready e commit o abort è chiamato finestra di incertezza. Il protocollo è progettato per minimizzare la sua durata. I protocolly di recovery sono svolti dai TM o RM dopo i guasti; ristabiliscono uno stato finale corretto che dipende dalla decisione globale del TM Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 33 Cosa accade se. Qualche RM non manda la decisione locale Allo scadere del time-out si opta per global abort Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 34

18 Cosa accade se. Qualche RM decide l abort della transazione Anziché mandare un messaggio di ready, manda un messaggio di not-ready. Il processo che gestisce l RM termina dopo l abort Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 35 Cosa accade se. Cade il TM e l ultimo record è prepare Problema: il messaggio di prepare è arrivato a tutti, a nessuno o a qualcuno? Alla ripresa del TM si può decidere per un global abort e svolgendo la seconda parte del protocollo. E anche possibile cercare di ripetere la prima fase. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 36

19 Cosa accade se. Cade il TM e l ultimo record è global decision Quanti RM siano stati avvertiti della decisione? Bisogna ripetere la seconda riavvertendo tutti gli RM. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 37 Cosa accade se. Un partecipante cade prima del record ready Non ci sono modifiche sostanziali rispetto al caso centralizzato. La transazione va disfatta perché la transazione globale è andata in global abort. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 38

20 Cosa accade se. Un partecipante cade dopo il record ready L RM deve conoscere la decisione globale. L RM interroga il TM oppure il TM reinvia la decisione ad intervalli regolari Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 39 Cosa accade se. Si perde il prepare msg o qualche ready msg Situazioni indistinguibili (dal punto di vista del TM) Scatta il timeout sulla prima fase e si decide un global abort. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 40

21 Cosa accade se. Si perde il global decision msg o qualche ack Situazioni indistinguibili (dal punto di vista del TM) Scatta il timeout sulla seconda fase e questa viene ripetuta. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 41 Osservazione La possibile ripetizione della seconda fase (scadenza del timeout normalmente o recovery del TM o dell RM) fa sì che che l RM possa ricevere il messaggio di global decision più volte. L RM ignora i messaggi successivi ma deve sempre mandare l ack per consentire la chiusura del protocollo. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 42

22 Ottimizzazione read-only Quando un RM ha svolto solo operazioni di lettura, Risponde read-only al messaggio di prepare message e esce dal protocollo. Il TM ignora tutti gli RM read-only nella seconda fase del protocollo. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 43 Protocollo di abort presunto (cenni) E una ottimizzazione, usata da quasi tutti i sistemi commerciali: Se un TM riceve una richiesta di remote recovery da una transazione in dubbio che non gli è nota, risponde per default che la transazione ha fatto un global abort Come conseguenza, se vengono persi prepare e global abort si ottiene comunque un comportamento corretto => non è necessario scriverli in modo sincrono sul log. Inoltre, il record complete non può essere omesso. In conclusione, gli unici record che devono essere scritti in modo sincrono sono: Ready(RM), global commit e commit locale (TM). Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 44

23 Protocollo di commit a quattro fasi Il processo TM viene replicato tramite un processo di backup collocato su un nodo differente. Il TM informa il backup delle sue decisioni prima di comunicarle agli RM. Se il TM ha un guasto, il backup può intervenire: Come prima cosa attiva un altro backup. Successivamente continua la esecuzione del protocollo di commit. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 45 Protocollo di commit a 4 fasi Prepare Global Commit coordinatore (TM) P GC backup Complete 2 fasi aggiunte partecipante (RM) Ready Commit Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 46

24 Protocollo di commit a tre fasi (cenni) Idea: grazie ad una terza fase, ogni partecipante può diventare un TM. Il partecipante eletto TM guarda il suo log: Se l ultimo record è ready può imporre un global abort. Se l ultimo ready e pre-commit può imporre un global commit. Difetto: il protocollo allunga la finestra di incertezza e può essere scorretto in presenza di partizioni di rete. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 47 Protocollo di commit a 3 fasi (cenni) Prepare Pre-commit Global Commit Complete Ready Pre Commit Local Commit Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 48

25 Standardizzazione del protocollo (cenni) Standard X-open DTP interfaccia TM: definisce i servizi del coordinatore offerti ad un client per eseguire il commit di partecipanti eterogenei interfaccia XA: definisce i servizi di partecipanti passivi che rispondono a chiamate del coordinatore (offerta da molti DBMS sul mercato) Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 49 Caratteristiche X-Open DTP (cenni) Gli RM sono passivi: rispondono a remote procedure calls dei TM Protocollo: commit a due fasi con ottimizzazioni (abort presunto e read-only) Previste decisioni euristiche: dopo un guasto, gli operatori possono forzare abort o commit, se le decisioni forzate sono inconsistenti ciò viene riportato al client. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 50

26 Interfaccia TM (cenni) tm_init e tm_exit iniziano e terminano un dialogo client -TM tm_open e tm_term aprono e chiudono una sessione col TM tm_begin inizia una transazione tm_commit richiede un commit globale tm_abort richiede un abort globale Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 51 Interfaccia XA (cenni) xa_open e xa_close: iniziano e terminano un dialogo TM - RM xa_start e xa_end attivano e completano una transazione xa_precomm richiede all RM di svolgere la prima fase del protocollo xa_commit e xa_abort comunicano la global decision all RM xa_recover inizia una recovery dell RM; ogni RM risponde alla richiesta con tre insiemi di transazioni: in dubbio, decise con commit euristico, decise con abort euristico. Il TM termina le transazioni in dubbio e indica (xa_forget) all RM di dimenticare transazioni decise in modo euristico. Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 52

27 Sommario Architetture client-server Basi di dati distribuite Basi di dati parallele Basi di dati replicate Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 53 Obiettivo: Efficienza Ottimizzazione delle query Modalità di esecuzione seriale parallela Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 54

28 Esecuzione seriale CENTRO CONTO2 CONTO3 CLIENT CONTO1 FILIALE1 Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 55 Esecuzione parallela CLIENT CONTO1 CONTO2 CONTO3 FILIALE1 FILIALE2 FILIALE3 Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 56

29 Scalabilità delle applicazioni Carico: insieme di tutte le applicazioni (query) Scalabilità: abilità di conservare prestazioni elevate al crescere del carico Dimensioni di crescita : numero delle query complessità delle query Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 57 Due tipologie di carico Transazionale carico: transazioni brevi misura: tps (transazioni per secondo) tempo di risposta: pochi secondi Analisi dei dati carico: query SQL complessa tempo di risposta: variabile Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 58

30 Parallelismo Ottenuto tramite molti processori che cooperano in una unica architettura informatica Due tipi di parallelismo inter-query ciascuna query affidata ad un solo processore intra-query per carichi transazionali ciascuna query affidata a molti processori per carichi di analisi dei dati Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 59 Architetture a confronto SHARED-NOTHING rete veloce PROCESSORE PROCESSORE MEMORIA DISCO MEMORIA DISCO Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 60

31 Architetture a confronto SHARED-MEMORY DISCO. DISCO MEMORIA PROCESSORE PROCESSORE Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 61 Architetture a confronto SHARED-DISKS DISKS DISCO. DISCO PROCESSORE PROCESSORE MEMORIA MEMORIA Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 62

32 Benchmark Metodi per confrontare le prestazioni di sistemi diversi (in competizione) varie tipologie di carico transazionale analisi dei dati Misto standardizzazione: del database del carico codice transazioni modalità di invio frequenza di arrivo della modalità di misurazione Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 63 Curva di speed-up Misura il crescere di efficienza al crescere del numero di processori tps... curva reale numero di processori Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 64

33 Curva di scale-up Misura il crescere di costo unitario complessivo per transazione al crescere del numero di processori costo unitario... curva reale numero di processori Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 65 Join distribuito E' l'operazione di analisi dei dati più onerosa consideriamo: conto corrente transazione JOIN Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 66

34 Join distribuito UNIONE CONTO1 JOIN TRANS1 CONTO2 JOIN TRANS2 CONTO3 JOIN TRANS3 Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 67 Requisiti per il join distribuito I domini degli attributi di join devono essere partizionati e ogni partizione assegnata ad una coppia di frammenti ad esempio su valori numerici tra 1 e : da 1 a da a da a In molti sistemi paralleli i dati vengono inizialmente ridistribuiti sui dischi per ottenere questa distribuzione Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 68

35 Sommario Architetture client-server Basi di dati distribuite Basi di dati parallele Basi di dati replicate Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 69 Replicazione dei dati E' un ingrediente fondamentale dei sistemi informativi per garantire: efficienza affidabilità autonomia Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 70

36 Replicazione Asimmetrica Copia Primaria propagazione Copia Secondaria modifiche Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 71 Replicazione Simmetrica Copia 1 propagazione Copia 2 modifiche modifiche Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 72

37 Trasmissione sincrona delle variazioni COPIA 1 COPIA 2 transazione master Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 73 Trasmissione asincrona delle variazioni COPIA 1 COPIA 2 propagazione transazione master transazione di allineamento Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 74

38 Modalità di allineamento COPIA 1 COPIA 2 Refresh INTERO CONTENUTO DELLA COPIA 1 periodico a comando ad accumulo di variazione Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 75 Modalità di allineamento Incrementale Periodico a comando ad accumulo di variazione COPIA 1 COPIA 2 DELTA-PLUS DELTA-MINUS Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 76

39 Trigger di replicazione CREATE TRIGGER CAPTURE-INS AFTER INSERT ON PRIMARY FOR EACH ROW INSERT INTO DELTA-PLUS VALUES (NEW.*) CREATE TRIGGER CAPTURE-DEL AFTER DELETE ON PRIMARY FOR EACH ROW INSERT INTO DELTA-MINUS VALUES (OLD.*) CREATE TRIGGER CAPTURE-UPD AFTER UPDATE ON PRIMARY FOR EACH ROW BEGIN INSERT INTO DELTA-PLUS VALUES (NEW.*) INSERT INTO DELTA-MINUS VALUES (OLD.*) END Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 77 Esempio: replicazione in computer mobili Computer mobili: saltuariamente collegati ad una rete Copie disconnesse per ore o giorni intere, poi riconnesse (riconciliazione) Applicazione: agenti di vendita mobili Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 78

40 Allineamento di copie disconnesse Richiede spesso la replicazione simmetrica COPIA DEL VENDITORE COPIA CENTRALE (con riconciliazione) modifiche modifiche Basi di Dati 2 Prof. Antonio d Acierno Architetture distribuite 79