Dosar - PC Report Nr 87 / Decembrie 1999

Originalul i copia
Replicarea n baze de date
Replicarea este o tehnologie destul de veche, care a cptat o popularitate nesperat
odat cu succesul lui Lotus Notes. Idea a fost preluat cu succes n domeniul bazelor de
date i, curnd, a devenit un loc comun n SGBD-urile de vrf.
Mircea Srbu

Un fenomen interesant n informatica actual - i cu precdere n domeniul bazelor de date - l

reprezint manifestarea pregnant a dou tendine contradictorii: centralizarea i distribuirea.
Ambele tendine sunt animate de intenia de a obine anumite avantaje i, desigur, preul acestor
avantaje l reprezint anumite dezavantaje. Dac ne referim la baze de date, avantajul
centralizrii const n posibilitile mult mai simple de a asigura integritatea datelor i consistena
prelucrrilor, n timp ce descentralizarea aduce un spor de disponibilitate. Performana de
ansamblu este un aspect care, n cele din urm, "arbitreaz" criteriile care se cer urmrite pentru
un echilibru ct mai apropiat de optim ntre centralizare i descentralizare. O discuie mai ampl
asupra bazelor de date distribuite a fost publicat n PC Report (iunie 1997).
Replicarea este o tehnologie care, n foarte multe situaii, reprezint un compromis acceptabil n
aceast direcie. Replicarea a devenit din ce n ce mai popular pe msur ce posibilitile de
comunicaii pentru date au devenit mai bogate, mai ales odat cu dezvoltarea Internet-ului. n
ciuda unor aspecte relativ intuitive, tehnologia replicrii este suficient de complex pentru a
invalida din start orice tentativ de a o explica n cteva pagini de revist. Articolul acesta
urmrete mai mult s sublinieze importana tehnologiei, s prezinte cteva domenii de
aplicabilitate i s schieze o taxonomie a metodelor i tehnicilor. Cu concursul partenerilor notri
din industrie, subiectul poate fi continuat n articole tehnice mai specifice.
Ce este replicarea?
La modul intuitiv, replicarea este un proces care const n realizarea i distribuirea unor copii ale
datelor. Distribuirea acestor copii (numite "replici") are ca scop procesarea datelor n mod local.
Dac vom analiza cteva scenarii, vom descoperi imediat cteva dintre tipurile posibile de
replicare i vom putea detalia puin definiia.
(a) S presupunem c o firm comercial din Bucureti are filiale judeene. Nomenclatorul de
produse pe care firma le vinde este administrat central. Pentru ca filialele locale s aib acces la
acest nomenclator exist, n principiu, varianta accesului la nomenclatorul stocat pe serverul
central al firmei. Aceasta ar nsemna ca, practic, fiecare tranzacie realizat local s acceseze
serverul central. Avantajul este c se garanteaz astfel actualitatea informaiei utilizate i se
asigur integritatea bazei de date, dar dezavantajele constau n costurile comunicaiei, n viteza
redus de rspuns i, mai ales, n dependena de accesul la server. O pan de comunicaii sau
indisponibilitatea temporar a serverului va pune filiala n imposibilitatea de a efectua orice
tranzacie. Alternativa o constituie distribuirea unor replici ale nomenclatorului la filialele judeene.
n acest caz, bazele de date locale vor lucra autonom, cu riscul de a nu dispune n orice moment
de varianta actual a informaiilor din nomenclator.
(b) O firm de asigurri utilizeaz ageni care cltoresc n teritoriu i ncheie asigurri. Agenii
dispun de un calculator portabil i de o baz de date autonom n care consemneaz fiecare
asigurare ncheiat. Din cnd n cnd, agenii trimit la sediul central replici ale bazelor de date
locale, pentru a fi centralizate i procesate. De asemenea, pot s primeasc actualizri ale
preurilor i clauzelor, noi oferte etc.
(c) S considerm o firm de software care dispune de echipe de dezvoltare n mai multe orae.
O baz de date n care sunt consemnate bug-urile semnalate de clieni este ntreinut la sediul

central, dar este replicat la toate punctele de lucru, pentru c o "scam" ntr-un subsistem poate
afecta (sau poate proveni din) alte subsisteme. Orice echip poate s fac actualizri, care
trebuie s poat fi vzute ct mai repede de celelalte echipe.
Pot fi imaginate numeroase alte scenarii, dar cele de mai sus reprezint cazuri clasice. n toate
cele trei cazuri se remarc faptul c replicarea este utilizat pentru a oferi un nivel ct mai ridicat
de autonomie bazelor de date locale. Pe de alt parte, se observ c acest nivel ridicat de
autonomie (i, implicit, de disponibilitate) implic anumite concesii n ceea ce privete
actualitatea informaiei utilizate. De asemenea, replicarea conduce la redundan, ceea ce atrage
dup sine pericolul apariiei unor stri inconsistente.
O definiie
Revenind acum la definiie, am putea s spunem c replicarea este o tehnologie care permite ca
informaiile provenind de la una sau mai multe surse s fie distribuite ctre una sau mai multe
inte i, n plus, ca modificrile intervenite n surse s fie propagate n mod consistent ctre intele
corespunztoare.
ntr-adevr, definiia a devenit acum prea general, dar putem s facem cteva precizri care s
o fac utilizabil.
n primul rnd, "sursele" i "intele" sunt, n cazul nostru, baze de date. Vom restrnge chiar mai
mult domeniul, referindu-ne n cele ce urmeaz doar la baze de date relaionale. Este ns bine
s reinem c replicarea este o noiune mai general, fiind prezent n domenii diverse, cum ar fi
administrarea documentelor, mesagerie electronic, Internet etc.
Faptul c att sursele ct i intele pot fi multiple permite stabilirea unor relaii diverse ntre
acestea, ansamblul acestor relaii definind ceea ce se numete de obicei "topologia replicrii". n
scenariile evocate mai sus, avem de-a face cu topologii ierarhice n primele dou scenarii ("oneto-many" n cazul (a), "many-to-one" n cel de-al doilea caz) i o topologie de tip reea ("many-tomany") n ultimul scenariu (c).
Un alt aspect important este faptul c replicarea nu implic, de obicei, ntreaga baz de date (caz
n care avem de-a face cu o replicare total). Cazul cel mai comun l reprezint replicarea unei
tabele, dar adesea se recurge la replicarea unor submulimi a datelor unei tabele sau a mai
multor tabele, ceea ce ridic i mai mult nivelul de complexitate a replicrii.
Procesul prin care se asigur capturarea, propagarea i reproducerea la inte a actualizrilor din
surse se numete sincronizare, fiind elementul central al ntregii tehnologii. Sincronizarea asigur
caracterul dinamic al ntregului proces. Un termen alternativ pentru sincronizare este
"remprosptare" (refresh), dei n anumite contexte sensul su este mai limitat (se refer doar la
anumite tipuri de sincronizare).
O ultim precizare se refer la obiectul sincronizrii. Din cele prezentate pn acum s-ar putea
deduce c sincronizarea se refer exclusiv la date. Cu toate acestea, expresia "propagarea
actualizrilor" sugereaz faptul c sincronizarea poate fi privit i dintr-o perspectiv procedural:
este posibil ca ceea ce se transmite de la surs ctre int s nu fie de fapt noile valori ce trebuie
memorate, ci chiar operaiile de actualizare aplicate asupra sursei, astfel nct acestea s fie
aplicate i asupra replicilor. Cu alte cuvinte, replicarea nu se refer doar la distribuirea datelor, ci
i la distribuirea prelucrrilor. Aa cum vom vedea n continuare, n practic se utilizeaz o
combinaie de tehnici.
Sincron i asincron
O prim diviziune a tehnicilor de replicare se bazeaz pe momentul n care se realizeaz
sincronizarea. Din acest punct de vedere, replicarea poate fi sincron sau asincron.
Replicarea sincron implic faptul c o actualizare n surs trebuie propagat i aplicat imediat
n toate replicile. Acest proces se realizeaz de obicei pe baza unui protocol numit "comitere n

dou faze" (two-phase commit) i se refer la tranzacia care realizeaz actualizarea. n prima
faz, sursa (un server de baze de date) va solicita intelor (alte sisteme de baze de date) s se
pregteasc pentru efectuarea tranzaciei i va atepta confirmrile din partea acestora. Cnd
toate intele sunt pregtite, sursa le va solicita comiterea tranzaciei i va atepta ca fiecare int
s raporteze succesul. Cnd toate intele au comis cu succes tranzacia, sursa declar tranzacia
ncheiat i consemneaz acest lucru n jurnal (log). n cazul n care ntr-una dintre faze cel puin
o int nu poate comite tranzacia, orice modificri produse deja sunt anulate (rollback).
Este evident c replicarea sincron impune un dou cerine eseniale: reeaua (fie ea LAN sau
WAN) trebuie s funcioneze i fiecare baz de date int s poat s comit tranzacia care
realizeaz actualizarea. Aceste cerine pot fi ndeplinite doar n anumite medii, cu anumite costuri,
iar balana este nclinat n favoarea integritii procesrii i n defavoarea disponibilitii. Anumite
aplicaii, cum ar fi de exemplu cele financiare sau cele de rezervare a locurilor, sunt bine
deservite de aceast tehnic.
Care este diferena ntre replicarea sincron i tranzaciile distribuite? Este greu de trasat o linie
de demarcaie clar. n principiu, o tranzacie distribuit nu lucreaz (n mod deliberat) cu copii
ale datelor, ci cu date care sunt distribuite n mai multe locaii. Astfel, este posibil ca prelucrarea
unei comenzi de la un client s implice att date ale serviciului de vnzri (situat la o anumit
locaie) ct i date ale serviciului financiar (situat ntr-o alt locaie). Din punctul de vedere al
aplicaiei, localizarea datelor este un proces transparent.
n cazul replicrii sincrone, un scenariu tipic este urmtorul: O tranzacie T ncearc s
actualizeze (printre altele) nite date care reprezint sursa unei replicri. Pentru ca aceast
actualizare s se propage imediat, sistemul genereaz o tranzacie special P, care s
actualizeze (independent de T) replicile datelor respective. Comiterea cu succes a tranzaciei T
este condiionat de comiterea tranzaciei P. S remarcm c T poate fi tranzacie simpl
(local), n timp ce P este o tranzacie distribuit (care este ns transparent din perspectiva
aplicaiei).
Replicarea asincron se bazeaz pe un mecanism de tip store and forward (adesea se folosete
i termenul message based replication). Informaiile despre actualizrile produse n sursa
replicrii sunt stocate ntr-o coad de ateptare, de unde sunt apoi trimise ctre locaiile intelor,
care se sincronizeaz pentru a reflecta starea sursei. Acest proces implic o anumit ntrziere,
care poate fi de cteva secunde sau de cteva zile, n funcie de configurarea sistemului i de
disponibilitatea sistemelor implicate. n schimb, avantajele pot fi considerabile din punct de
vedere al disponibilitii (operarea ntr-o locaie nu este afectat de indisponibilitatea unei alte
locaii) i a costurilor legate de transferul informaiilor (nu este nevoie de o conexiune
permanent).
Deoarece replicarea sincron este adesea asimilat cu bazele de date distribuite i implic un
nivel de complexitate foarte ridicat, ceea ce se traduce n costuri adesea foarte mari (att pentru
comunicaii ct i pentru proiectare i exploatare), replicarea asincron - mult mai practic i mai
ieftin - a devenit alternativa cea mai popular n ultima vreme. n plus, replicarea sincron este
inaplicabil ntr-o ntreag clas de aplicaii, din ce n ce mai rspndit, care implic utilizatori
mobili (ca n cazul celui de-al doilea scenariu evocat). Din aceste motive, n foarte multe lucrri i
articole, termenul "replicare" se refer implicit la replicarea asincron. n cele ce urmeaz m voi
referi n mod preponderent la replicarea asincron.
Tranzacional sau nu
nainte de a detalia mai departe mecanismele care stau la baza replicrii, merit s insistm puin
asupra unor aspecte legate de consistena de ansamblu a unei baze de date distribuite prin
replicare. Pentru aceasta, trebuie s revenim puin la noiunea de tranzacie, tratat pe larg n
mai multe articole aprute de-a lungul timpului n PC Report. (O excelent prezentare a
subiectului a fost fcut de Mihai Budiu n PC Report 67 - aprilie 1998, http://www.
pcreport.ro/pcrep67/023.htm)

Proprietile ACID (vezi caseta "Tranzacii") sunt interdependente. Implementarea acestora se

face n majoritatea sistemelor comerciale prin mecanisme de blocare (lock - ncuietoare, zvor)
care, pe baza unui protocol bine stabilit, interzic accesul altor tranzacii la datele asupra crora
acioneaz deja o tranzacie. Blocarea este ns un mecanism care funcioneaz n mod sincron,
deci este inaplicabil n cazul replicrii asincrone. Aceasta nseamn c exist oricnd posibilitatea
ca efectele unei tranzacii s nu fie vizibile ntr-una sau mai multe replici, ceea ce conduce la
faptul c, cel puin ntre dou sincronizri consecutive, ansamblul bazei de date (considernd aici
i replicile) s fie inconsistent.
S considerm scenariul (a) i s ne imaginm c se produce o tranzacie care modific preul
produsului P de la p1 la p2. Teoretic, tranzacia poate fi considerat ncheiat abia atunci cnd
modificarea a fost efectuat n tabela "printe" (de la sediul central) i n toate replicile sale.
Replicarea fiind asincron, filialele vor continua s lucreze cu preul p1 pn la sincronizare. Mai
mult, replicile nu se sincronizeaz simultan, deci este posibil ca anumite filiale s lucreze cu un
pre n timp ce altele lucreaz cu alt pre. Iar dac aceast inconsisten nu pare suficient de
"flagrant", s ne imaginm ce se ntmpl n situaia n care produsul P nu mai este disponibil
pentru vnzare i este ters din baza de date central.
Exist mai multe variante de a trata astfel de situaii, n funcie de posibilitile tehnice i, mai
ales, de activitatea modelat (business rules).
O prim posibilitate este de a accepta posibilitatea de a avea stri inconsistente. Dac firma
consider c nu-i grav ca ntr-un interval rezonabil de timp (s zicem, 2-3 ore) produsul s fie
vndut cu preuri diferite de diverse filiale, e OK. n acest caz, o replicare non-tranzacional este
acceptabil. Aceasta nseamn c modificrile sunt transmise ctre replici fr nici o informaie
despre tranzaciile care le-au produs (se folosete i termenul de replicare linie cu linie - row by
row replication).
O variant "forte" este de a combina replicarea asincron cu replicarea sincron. Anumite operaii
critice (n cazul crora compromisul este inacceptabil) ar putea fi forate la o replicare sincron.
De pild, la tergerea unui produs din nomenclatorul central, baza de date va ncerca s utilizeze
canalele de comunicaie disponibile pentru a lua legtura cu toate filialele i a aplica protocolul
two phase commit, chiar dac n acest fel tranzacia n cauz va dura cteva minute (sau chiar
ore). Desigur, trebuie s existe posibilitile tehnice (mcar conexiuni dial-up) i s fie acceptabil
din perspectiva activitii respective. Dac, de exemplu, se tranzacioneaz intens iar baza de
date nu permite blocarea la nivel de linie ci doar la nivel de tabel, s-ar putea ca o astfel de
tranzacie lung s opreasc toat activitatea firmei.
n fine, o alt variant o reprezint "tranzaciile ntrziate". Aceasta nseamn c replicarea va
ine seama nu doar de modificrile n surs, ci i de tranzaciile care le-au produs. Deocamdat,
este suficient de menionat c se transmit ctre inte doar modificrile produse de tranzacii deja
comise n surs i c aceste modificri sunt trimise n ordinea n care s-au produs, nsoite de
mrci de timp (timestamps). Este vorba, n principiu, de un fel de replicare a tranzaciilor. E
importat de notat faptul c se recurge la o serializare a actualizrilor. Dac, de pild, n surs o
tranzacie T1 a modificat preul produsului P de la p la p+1, dup care o tranzacie T2 a modificat
preul aceluiai produs la p*2, este esenial ca aceste modificri s fie efectuate n int n
aceeai ordine.
Exist i alte modaliti de tratare a acestor probleme, dar nu exist nici o garanie c ansamblul
de date va fi n permanen consistent. Este un compromis obligatoriu pe care replicarea
asincron l impune. Vom vedea pe parcurs i care sunt tehnicile prin care se pot obine variante
ct mai avantajoase.
Unidirecional sau bidirecional
Cea mai simpl form de replicare o reprezint replicarea unidirecional. Altfel spus, replica este
disponibil doar pentru citire. Deoarece o astfel de replic read-only reprezint doar o imagine a
datelor din surs aa cum se prezentau ele la un anumit moment (un instantaneu), se folosete
adesea termenul snapshot.

Este interesant istoria acestui termen. Iniial, el a fost utilizat n unele baze de date relaionale
centralizate (Oracle), pentru a "nghea" anumite seturi de date. Un snapshot se definete exact
ca un view (deci prin intermediul unei selecii) dar, spre deosebire de acesta, este o tabela
stocat - nu virtual, ca n cazul unui view. Un snapshot este accesibil doar pentru citire i este
"remprosptat" la anumite intervale de timp. Rolul unui snapshot ntr-o baz centralizat era (i
nc este) de a permite efectuarea unor operaii de analiz bazate pe interogri complexe, fr
ca acestea s interfereze (prin blocri) cu procesrile "pe viu", rezultnd astfel performane
superioare att pentru procesrile tranzacionale (OLTP) ct i pentru cele de analiz (OLAP).
Cnd a pit n lumea procesrii distribuite, Oracle s-a folosit de acest mecanism, furniznd astfel
"prima generaie" de instrumente de replicare. Termenul s-a impus, aa c atunci cnd Oracle a
introdus o tehnologie de replicare bidirecional ("simetric") a pstrat termenul, introducnd
noiunea de "updatable snapshot", dei este o flagrant contradicie de termeni.
Atenie deci la terminologie: Oracle folosete termenul snapshot ca sinonim pentru replic, n
timp ce restul lumii nelege prin snapshot doar "replic read-only" (mai mult, Sybase numete
snapshot o replic read-only non-tranzacional).
Replicarea bidirecional implic faptul c replica este la rndul ei actualizabil i c modificrile
din replic vor fi reflectate n surs. Observai c n acest caz noiunile de "surs" i "replic" i
cam pierd sensul: o surs poate fi considerat replic i invers, motiv pentru care se folosete
adesea termenul de "replicare simetric" (introdus tot de Oracle). De altfel, trebuie spus c atunci
cnd vom lua n considerare diferitele topologii posibile pentru replicare, nici termenul
"bidirecional" nu este foarte corect (de fapt, procesul este multidirecional) i nici "simetric"
(cteodat una dintre locaii este "mai simetric" dect celelalte).
Totui, cine-i "eful"? Cum se definete i se iniiaz replicare? Ajungem astfel la cteva noiuni
importante legate de metodologia replicrii.
Configuraii
n discuia care urmeaz voi ncerca s prezint, pe baza scenariilor de la nceputul articolului,
principalele tipuri de aplicaii n care se utilizeaz replicarea asincron. Voi introduce totodat, la
modul intuitiv, cteva noiuni care vor fi explicitate n continuarea articolului.
O prim aplicaie tipic o constituie distribuirea (sau diseminarea) informaiilor. n scenariul (a)
firma de comer utilizeaz mecanismele replicrii pentru a distribui ctre filiale nomenclatorul de
produse pe care filialele judeene le vnd. Deoarece filialele judeene nu au voie s actualizeze
nomenclatorul, replicarea este unidirecional, deci copiile sunt disponibile doar pentru citire.
Replicarea poate fi tranzacional sau la nivel de linie, n funcie de volumul i frecvena
modificrilor (altfel spus: de volatilitatea datelor). Tot acest factor este cel care determin
frecvena sincronizrilor. O situaie tipic este cea n care replicarea se produce n fiecare noapte,
astfel nct modificrile s nu interfereze cu activitatea cotidian. Avantajul este sporit i de costul
(de obicei) mai mic al liniilor de telecomunicaii (dac e cazul).
O chestiune extrem de important n acest context o reprezint relaia de proprietate asupra
datelor. n acest caz, nomenclatorul de produse aparine locaiei centrale, care este singura
abilitat s efectueze actualizri. Termenul generic pentru aceast configuraie este master/slave,
unde locaia central este nodul master (numit uneori nodul "primar") iar locaiile slave (numite
uneori "secundare") sunt bazele de date locale.
n privina topologiei, se observ c este vorba de o structur arborescent cu dou niveluri. Este
ns posibil i o structur pe mai multe niveluri. S ne imaginm c n fiecare jude pot exista
mai multe magazine, fiecare cu o baz de date local. n acest caz, replicarea se poate face n
continuare, de la filiale ctre magazine, ierarhia fiind pe trei niveluri. Este de notat ns c
nomenclatorul este n continuare deinut doar de ctre locaia central.
Scenariul (b) pune n eviden tot o structur arborescent, de tip master/slave, cu diferena c
datele aparin n acest caz utilizatorilor mobili, fiind replicate la locaia central doar pentru

centralizare i analiz, n regim read-only. n acest caz avem mai multe noduri primare i un
singur nod secundar, o situaie tipic pentru aplicaiile de centralizare (sau consolidare) a
informaiilor. Acest gen de replicare este frecvent utilizat i n depozitele de date, astfel nct
locaia central s fie alimentat automat, la intervale regulate cu informaii extrase din sistemele
operative (n acest caz apare i o faz de "curire" i transformare a datelor, dar replicarea
rmne n esen unidirecional). Chiar dac nu se lucreaz cu un depozit de date, acest tip de
replicare poate fi utilizat pentru a izola aplicaiile de analiz (care pot lucra pe o copie read-only)
de cele tranzacionale.
Rmnnd n sfera configuraiilor master/slave, s simplificm puin scenariul (a), considernd c
firma este compus doar din trei sucursale: una la Bucureti (acionnd n Muntenia, Oltenia i
Dobrogea), una la Cluj (acionnd n Transilvania) i un la Iai (acionnd n Moldova). Dac vom
considera informaiile despre clienii companiei, alegerea cea mai corect este ca fiecare
sucursal s aib la dispoziie informaii despre toi clienii companiei. Pe de alt parte, este
normal ca fiecare client s "aparin" unei singure sucursale, pentru a evita actualizrile multiple,
care pot crea probleme de consisten. n aceast situaie se poate recurge la o partiionare a
informaiilor despre clieni, astfel nct actualizrile privind un anumit client pot fi fcute de o
singur sucursal, modificrile fiind replicate apoi ctre celelalte dou (care vor avea acces doar
pentru citire). Configuraia este tot de tip master/slave, n acest caz fiecare nod fiind master
pentru anumite informaii i slave pentru altele.
Scenariul (c) este tipic pentru configuraiile reea, numite "peer to peer" sau "update anywhere"
(Oracle numete aceast configuraie "multiple master"). Fiecare locaie poate s fac actualizri
asupra datelor, iar modificrile sunt replicate la toate celelalte noduri. Este evident c aceast
configuraie este cea mai expus la pericolul pierderii integritii, datorit unor actualizri
contradictorii, numite n continuare "conflicte". Pentru a detecta i rezolva aceste conflicte se
folosesc diverse tehnici automate (replicarea tranzacional este obligatorie n aceste
configuraii), dar nu se exclude nici posibilitatea unor soluii "manuale".
Exist i cteva versiuni ale acestei variante de replicare, care au darul de a simplifica oarecum
administrarea. Una dintre ele este "proprietatea dinamic" asupra datelor. Ideea de baz este c
procesarea datelor se constituie ntr-un proces format din etape, proprietatea asupra datelor
schimbndu-se de la o etap la alta (motiv pentru care configuraia mai este numit "workflow
ownership"). n exemplul (c), ne-am putea imagina c bug-urile detectate ar putea avea un traiect
prestabilit, pornind de la echipa care se ocup de interfaa cu utilizatorul, trecnd apoi la echipa
care dezvolt logica aplicativ i, n cele din urm, la echipa care proiecteaz bazele de date. n
fiecare pas al procesului, informaiile asupra respectivului bug aparin echipei respective, care
este sigura care poate face actualizri, actualizri care vor fi replicate ctre celelalte locaii. n
felul acesta, problema se reduce la una de tip master/slave. Poate exemplul nu este cel mai
sugestiv. Aplicarea tipic a acestei tehnici gsim n cazul procesrilor comenzilor de la clieni.
O alt variant (promovat de IBM) este folosirea unui aa-numit "nod de referin", astfel nct
configuraia va fi transformat din reea ntr-o ierarhie, avnd ca rdcin nodul de referin.
Toate actualizrile realizate de noduri vor fi replicate ctre nodul de referin, care apoi le va
replica la rndul su ctre celelalte noduri. Desigur, n acest fel nu se mpiedic apariia
conflictelor (modificrile pot fi efectuate n continuare de ctre oricare nod), dar se pot
implementa mai simplu metode tranzacionale de depistare i rezolvare.
Combinaii
n lumea real situaiile nu sunt att de "pure" cum apar prezentate n seciunea precedent. n
cele mai multe cazuri, avem de-a face cu configuraii combinate sau cu configuraii paralele n
cadrul aceleiai aplicaii. n scenariul (a) nomenclatorul central aparine locaiei centrale, dar
datele despre clieni pot aparine filialelor (replicate apoi la celelalte filiale, eventual prin
intermediul unui nod de referin situat la nivel central), n timp ce procesarea comenzilor se
poate face n regim de workflow ownership. De pild, preluarea comenzilor se face la nivelul
magazinelor, livrarea se face la nivelul filialei, facturarea se efectueaz la nivelul central etc.

n plus, mecanismul relativ simplu de tip publish and subscribe pe care se bazeaz administrarea
replicrii se complic i mai mult cnd lum n considerare faptul c nu ntotdeauna replicarea
implic doar tabele ntregi (aa cum, oarecum implicit, am considerat pn acum), cu att mai
puin baze de date ntregi. n multe cazuri, datele care trebuie replicate constituie o submulime a
liniilor i/sau a coloanelor unei tabele, dar pot fi i date compuse printr-o definiie de tipul celor
folosite pentru crearea unui view, implicnd mai multe tabele legate prin asocieri complexe.
Uneori trebuie replicat un grup de obiecte ale bazei de date.
Dac la aceasta mai adugm faptul c exist ansa ca sistemul de baze de date s nu fie
omogen, implicnd diverse SGBD-uri (de pild, utilizatorii mobili nu vor putea purta ntr-un
notebook un server SQL complet), uneori de la productori diferii, obinem un tablou destul de
bogat al nivelului de complexitate la care se poate ajunge.
Cu toate acestea, replicarea poate fi stpnit. Exist astzi o pleiad de produse dedicate
configurrii, administrrii i monitorizrii procesului de administrare. Pentru a putea evalua
avantajele i dezavantajele acestora n funcie de problema pe care o avei de rezolvat, este
necesar s cunoatei la modul general etapele procesului de replicare i cteva dintre variantele
tehnologice ale fiecrei etape. n cele ce urmeaz voi ncerca s schiez principalele elementele
ale acestei problematici.
nainte de a ncepe, iat etapele procesului:
Stabilirea surselor i a intelor;
Capturarea actualizrilor i evaluarea acestora n vederea propagrii;
Propagarea actualizrilor de la surs la int;
Aplicarea actualizrilor la baza de date int (cu detectarea i rezolvarea eventualelor conflicte).
Configuraii, topologii, proprietate
Diverse produse utilizeaz diverse terminologii pentru a descrie modul de configurare a replicrii,
oferind desigur i posibiliti diferite. Una dintre cele mai simple i evocatoare terminologii este
cea bazat pe metafora publish and subscribe (publicare i abonare). Dei utilizat ca atare doar
de Microsoft, cu anumite adaptri este valabil la majoritatea produselor.
Pe scurt, baza de date (serverul) care va servi ca surs pentru replicare va fi numit "editor"
(publisher). n cadrul acestei baze de date se definesc aa-numite "publicaii" (publications), care
sunt de fapt seturile de date disponibile pentru replicare. Alte baze de date se pot "abona"
(subscribe) la aceste publicaii. Pentru a defini procesul de replicare se specific editorul,
publicaia i abonatul, precum i nite informaii adiionale, cum ar fi tipul replicrii (unidirecional
sau bidirecional), intervalul de timp ntre sincronizri, modul de rezolvare a conflictelor etc. n
principiu, orice server poate s fie editor al anumitor publicaii i totodat abonat la publicaii
editate de alte servere. Mai mult, se poate ajunge la situaii n care aceeai tabel poat s
conin date surs i date replicate (prin partiionare).
O problem ceva mai delicat apare atunci cnd replicarea este selectiv, n sensul c
"publicaia" nu este o tabel ntreag. n acest caz se recurge la un procedeu numit data
subsetting. Replicarea selectiv este important din cel puin dou motive. n primul rnd, astfel
se poate minimiza traficul n reea (s ne imaginm c fiecare produs din nomenclator este nsoit
de scheme, desene sau chiar videoclipuri de prezentare - replicarea acestora poate fi extrem de
costisitoare). n al doilea rnd, este foarte posibil ca drepturile de acces la anumite date s fie
rezervate proprietarului, caz n care replicarea acestora afecteaz securitatea sau
confidenialitatea informaiilor.
De regul, indiferent de modul de specificare a sursei, se ajunge la o instruciune SELECT prin
care se definete subsetul dorit. Restriciile impuse asupra acestei selecii depind de posibilitile
fiecrui produs n parte, dar cteva sunt n general valabile. Cel mai important aspect este c

fiecare linie selectat trebuie s corespund unei linii din tabela surs. Aceasta nseamn, la
modul minimal, c subsetul de coloane selectat trebuie s cuprind toate coloanele care
formeaz cheia primar a tabelei surs. n majoritatea produselor de replicare, n selecia datelor
pentru replicare nu se pot folosi funcii de agregare sau distinct, nu se admit clauze GROUP BY
sau CONNECT BY, asocieri (join), operaii cu seturi (de pild UNION) i anumite forme de
interogri nglobate.
Pentru exemplificare, m voi referi la Oracle8 Replication, unde definirea "publicaiei" se face
printr-o instruciune de tipul
CREATE SNAPSHOT nume
AS selecie.
Oracle se refer la dou niveluri de complexitate pentru replicare: nivelul de baz (lucreaz doar
unidirecional) i nivelul avansat (poate lucra i bidirecional). Replicile pot fi la rndul lor simple
sau complexe. Ambele categorii pot fi folosite n replicarea de baz, ns numai replicile simple
pot fi actualizabile.
O replic simpl se bazeaz pe o singur tabel surs iar selecia pe care se bazeaz se supune
tuturor restriciilor amintite mai sus. Dac vom considera c n scenariul (a) avem n baza de date
central o tabel Produse avnd coloanele cod, den, pre, comandat i disponibil, atunci o replic
se poate crea astfel:
CREATE SNAPSHOT produse AS
SELECT cod, den, pret FROM produse@centru.ro
n acest caz, replica preia doar o submulime a coloanelor tabelei surs. Actualizrile care
afecteaz n surs doar coloanele excluse din replic nu vor fi propagate. Prin folosirea unei
clauze WHERE se pot selecta pentru replicare doar anumite linii.
CREATE SNAPSHOT produse AS
SELECT * FROM produse@centru.ro p
WHERE p.disponibil > 100
O caracteristic interesant n tehnologia de replicare de la Oracle este c selecia liniilor se
poate baza i pe parcurgerea referinelor many-to-one n tabele asociate. n exemplul care
urmeaz, locaia central va prelua de la locaia local Mure doar comenzile care corespund
unor clieni din judeul Mure:
CREATE SNAPSHOT comenzi AS
SELECT * FROM comenzi@mures.ro a
WHERE EXISTS
(SELECT cod
FROM clienti@mures.ro b
WHERE a.cod_client = b.cod
AND b.jud = 'MS');
Replicile complexe nu au limitrile replicilor simple, n schimb nu pot fi actualizabile iar
sincronizarea nu se poate face incremental.

Este util o analogie ntre definirea unei replici i definirea unui view. Restriciile privind
actualizarea unui view sunt de obicei aceleai n cazul unei replici. Este interesant de remarcat
c instrumentele de replicare de la IBM permit (e drept, printr-o configurare special) replicarea
unui view. O alt remarc este c Oracle face o important distincie ntre replicile actualizabile
(updatable snapshots) i replicarea simetric ntre servere (multimaster replication). n acest ultim
caz nu se admite replicarea selectiv.
n fine, trebuie spus c la configurarea replicrii, sistemele genereaz diverse obiecte specifice n
bazele de date, obiecte care vor fi apoi utilizate pentru replicare. De exemplu, Oracle genereaz
automat pentru fiecare snapshot un index bazat pe cheia primar i un view. Pentru fiecare surs
de replicare, Oracle construiete un jurnal (snapshot log), materializat ntr-o tabel care cuprinde,
pentru fiecare linie actualizat cheia primar, marca de timp i, eventual identificatorul unic de
linie (ROWID). Informix folosete un catalog global al replicrii (cu meta-date despre fiecare
surse, participani, definiii, opiuni etc.), care este la rndul su replicat n toate serverele
implicate n replicare. Alte sisteme folosesc tabele adiionale pentru modificri, tabele "umbr"
(shadow), jurnale specializate etc.
Capturarea modificrilor
Odat ce sursele i intele au fost stabilite, urmtoarea problem o reprezent mecanismele prin
care programele (sau procesele, n cazul implementrilor n SGBD) de replicare s sesizeze
comiterea unei modificri n surs i s poat identifica elementele acestei actualizri.
Exist dou mari categorii de mecanisme de replicare: bazate pe "declanatoare" (triggers) i
bazate pe jurnal (log).
Capturarea actualizrilor prin "declanatoare" este cea mai veche. Un trigger este o procedur
stocat ceva mai special, deoarece nu este apelat explicit, ci se execut automat ca rspuns la
tentativa de a actualiza (prin INSERT, DELETE sau UPDATE) tabela creia i este ataat triggerul. Unele sisteme permit specificarea unor anumite coloane din tabel a cror modificare
declaneaz trigger-ul (desigur, pentru UPDATE).
Un trigger se definete ntr-un limbaj procedural, care variaz de la server la server (n ultima
vreme mai muli productori au introdus n produsele lor posibilitatea de a scrie proceduri stocate
n Java). Iat un exemplu, n care voi folosi (destul de liber) limbajul procedural din PostgreSQL:
CREATE TRIGGER produse_up
BEFORE UPDATE ON prod
FOR EACH ROW
BEGIN
IF OLD.cod != NEW.cod THEN
DELETE prod
WHERE cod = ODL.cod;
INSERT INTO prod VALUES
(NEW.cod, NEW.den, NEW.pret);
END IF;
END;
Exemplul este sugestiv pentru posibilitile unui trigger. n primul rnd, declanatorul este legat de
o tabel (n cazul nostru prod) i de o anume actualizare (aici UPDATE, dar se pot meniona mai

multe, conectate prin OR). Se remarc faptul c acest trigger se declaneaz nainte de
efectuarea actualizrii (opiunea AFTER ar lansa trigger-ul dup ce s-a realizat actualizarea). n
fine, constatm c trigger-ul are acces att la valorile dinainte de actualizare (OLD) ct i la cele
de dup actualizare (NEW). Codul n sine nu este grozav: n cazul n care se ncearc
modificarea cheii primare, comanda UPDATE este nlocuit de o tergere urmat de o nserare.
Este posibil ca inserarea s fie i ea "pzit" de un trigger, ilustrnd astfel declanarea n
cascad. Nu voi intra n detalii legate de valoarea de retur, de parametrizare etc.
Acest mecanism a fost introdus de productorii de baze de date mai ales pentru a permite
controlul procedural al integritii datelor, dar a fost utilizat i pentru a implementa o prim
generaie de aplicaii de replicare. Este uor de imaginat un set de trigger-e care adaug ntr-o
coad mesaje privind actualizrile efectuate ntr-o tabel.
Dezavantajul major al acestei abordri este c trigger-ele se execut n baza de date, fiind
procese destul de consumatoare de resurse, fapt care afecteaz performanele. Pe de alt parte,
trigger-ele utilizator nu au acces la informaii despre tranzacia n cadrul crei se execut, deci nu
permit dect replicarea la nivel de linie. n fine, apar i problemele de interferen cu trigger-e
destinate unor alte scopuri (de pild validri complexe de consisten).
Capturarea modificrilor din jurnal este o metod oarecum mai simpl. Orice server de baze de
date serios jurnalizeaz ntr-un fel sau altul tranzaciile, n scopul de a oferi o posibilitate de
refacere a bazei de date n cazul unui incident. Sistemele de jurnalizare sunt diverse, dar n
general se consemneaz un identificator al tranzaciei, utilizatorul care a comis tranzacia,
actualizrile realizate, valorile intermediare (dinainte i de dup fiecare actualizare) i momentul
comiterii. Numrul mare de informaii jurnalizate se explic prin faptul c anularea unei tranzacii
(rollback) se face tot pe baza acestor informaii.
Mecanismul de capturare poate fi integrat n mecanismul de jurnalizare, caz n care identificarea
tranzaciilor care trebuie replicate se poate face dinamic, sau poate fi exterior, caz n care jurnalul
este examinat periodic, ntr-o ordine strict. Deoarece unele sisteme scriu n jurnal ntr-o manier
circular (cele mai noi intrri le suprascriu pe cele mai vechi intrri), procesele de jurnalizare i
capturare trebuie corelate astfel nct capturarea s nu rmn n urm i s rateze anumite
tranzacii (n astfel de situaii, toate tranzaciile n curs de desfurare sunt blocate pn cnd
programul de capturare avanseaz suficient - situaia poate apare la o defectuoas configurare a
spaiului rezervat fiierelor log). Dei unele sisteme marcheaz chiar n jurnal tranzaciile care
trebuie replicate, majoritatea recurg la structuri de stocare specializate (de genul unui "jurnal
consolidat" sau a unor tabele care consemneaz schimbrile).
Avantajul capturrii bazate pe jurnal const n faptul c se pot identifica tranzaciile i c nu se
produc interferene cu procesrile curente (exceptnd situaii de genul celei descrise mai sus). Pe
de alt parte, programul sau procesul care realizeaz capturarea implic procesri destul de
complexe i, mai ales, multe operaii de transfer de date, ceea ce conduce la o ncrcare mai
mare a serverului i/sau a reelei.
Ambele tehnici sunt folosite i fiecare productor insist pe avantajele soluiei pe care a ales-o.
Oracle merge pe soluia trigger, dar ntr-o variant optimizat. Trigger-ele pentru replicare sunt
standardizate i, mai ales, internalizate. Aceasta nseamn c sunt compilate i incluse chiar n
motorul bazei de date, ceea ce conduce la performane foarte bune, plus posibilitatea de a avea
acces la toate informaii relative la tranzaciile utilizatorilor care realizeaz actualizri. Sybase se
bazeaz pe un software specializat (Replication Server) care se ocup numai de replicare. O
component specializat a acestuia (Log Transfer Manager) ruleaz alturi de fiecare server
surs i alimenteaz serverul de replicare cu actualizrile capturate din jurnal. Informix i IBM
folosesc de asemenea mecanisme bazate pe jurnal.
Evaluarea datelor pentru replicare
Toate sistemele de replicare ncearc s minimizeze volumul informaiilor care trebuie propagate.
n acest sens, se recurge adesea la o evaluare a informaiilor capturate despre modificri.
Aceast etap se desfoar de regul la momentul compunerii mesajelor care vor fi depuse n

coad. n cazul sistemelor bazate pe trigger-e, este posibil ca o parte din aceste procesri s fie
realizate chiar de trigger-ul de capturare. Pe de alt parte, este posibil ca trigger-ele s nu scrie
direct n coada de mesaje ci ntr-un jurnal propriu, de unde informaiile pot fi evaluate n vederea
replicrii (aa proceseaz Oracle cu replicile actualizabile).
Pentru exemplificare, m voi referi la Informix Enterprise Replication. O prim evaluare se refer
la momentul comiterii tranzaciei i este necesar pentru a plasa n coad doar tranzacii deja
comise. Important este ns evaluarea imaginii liniilor care trebuie replicate. Aceast evaluare
are ca scop determinarea efectului net al unui serii de actualizri care se realizeaz asupra unei
linii n cadrul unei singure tranzacii. n felul acesta se evit propagarea fiecrei operaii i se
trimite doar o singur actualizare (sau poate nici att), ceea ce minimizeaz att traficul ct i
volumul actualizrilor la nodul int.
Deoarece n cadrul unei tranzacii operaiile sunt strict secveniale, este suficient s analizm
modul cum se evalueaz grupuri de dou actualizri (actualizarea rezultant este apoi evaluat
mpreun cu urmtoarea i aa mai departe).
Cazul cel mai simplu este cel n care inserarea unei linii este urmat de tergerea liniei, caz n
care efectul este nul. Dac ns inserarea este urmat de o modificare (UPDATE) atunci se
verific dac imaginea final a liniei corespunde criteriului de selecie n vederea replicrii. Dac
nu, efectul este iari nul. Dac da, atunci efectul net este inserarea unei linii cu imaginea final
rezultat.
Dac o modificare a unei linii este urmat de tergerea linei, atunci trebuie aplicat criteriul de
selecie asupra rezultatului modificrii. Dac linia rezultat nu trebuie replicat atunci rezultatul
net este nul. Dac ns linia modificat corespunde criteriului, atunci rezultatul este tergerea
imaginii iniiale a liniei.
De exemplu, dac replicarea se refer doar la clienii din judeul Mure, atunci tranzacia
urmtoare:
BEGIN WORK;
INSERT INTO pers
VALUES (1325, 'Ion', 'MS');
UPDATE pers SET nume = 'Vasile'
WHERE marca = 1325;
COMMIT WORK;
va avea ca efect net trimiterea ctre int a operaiei:
INSERT INTO pers
VALUES (1325, 'Vasile', 'MS');
Dac mai apoi se execut urmtoarea tranzacie:
BEGIN WORK;
UPDATE pers SET jud = 'CJ'
WHERE marca = 1325;
DELETE FROM pers
WHERE nume = 'Vasile';

COMMIT WORK;
efectul net va fi replicarea operaiei:
DELETE FROM pers
WHERE marca = 1325
AND nume = 'Vasile'
AND jud = 'MS';
Observaie: Desigur, ar fi suficient s se specifice cheia primar pentru tergere. Condiiile
suplimentare sunt ns utile pentru detectarea unor eventuale conflicte.
Dac o linie care nu corespundea criteriului va fi actualizat astfel nct s corespund criteriului,
rezultatul net este inserarea n replic a unei linii cu imaginea final. O situaie invers conduce la
o tergere. Este, cred suficient de clar, modul n care se trateaz alte combinaii.
Un caz particular l reprezint grupurile de modificri care schimb cheia primar a unei linii. n
acest caz, dac att imaginea iniial ct i imaginea final corespund criteriului de selecie
pentru replicare, se procedeaz la tergerea liniei iniiale i inserarea liniei finale.
O precizare: cmpurile de tip blob sau text sunt tratate oarecum diferit.
Mecanisme de propagare
Propagarea modificrilor se realizeaz printr-un mecanism bazat pe cozi de mesaje (message
queuing). Aceast tehnologie este suficient de complex pentru a merita o tratare separat dar,
n acest context, este suficient dac menionez c aceste mecanisme (fie integrate n baza de
date, fie implementate ca middleware) garanteaz stocarea sigur a mesajelor att la surs ct i
la destinaie, garanteaz livrarea fiecrui mesaj i permit urmrirea fiecrui mesaj n parte.
Deocamdat, o analogie cu sistemele de pot electronic este suficient (unele sisteme
folosesc chiar MAPI), dei produsele de tip MOM (Message Oriented Middleware) sunt adesea
mult mai complexe.
n principiu, actualizrile capturate se consemneaz n nite mesaje stocate ntr-o "coad stabil"
(care nu poate fi afectat de incidente soft sau hard) pe sistemul surs. Mesajele sunt preluate
de mecanismul de transport asincron i sunt expediate ctre inte, unde sunt stocate tot n cozi
stabile. Prin acelai mecanism de mesagerie, intele rspund cu mesaje de confirmare pentru
fiecare mesaj primit. Odat de recepia a fost confirmat de toi destinatarii, mesajul poate fi ters
din coada de plecare. Protocolul poate fi destul de complex, implicnd retransmiterea mesajelor,
mecanisme de verificare etc. Este important ca mesajele s poat fi serializate nainte de
aplicare, s nu se piard i s nu fie dublate.
n general, replicarea se face incremental: fie se trimit operaiile care au fost efectuate asupra
sursei de la ultima sincronizare (eventual evaluate ca efect net al tranzaciilor care le-au realizat),
fie se trimit aa-numite "fiiere delta", care cuprind diferenele intervenite n imaginile liniilor ntre
dou sincronizri succesive (n cazul replicrii non-tranzacionale). Exist ns situaii n care se
recurge la replicarea total a unei surse. Un caz tipic este cel n care un server int este
indisponibil o perioad mai lung de timp. n aceast situaie, mesajele din coad care-i sunt
adresate nu vor putea fi terse iar spaiul ocupat va deveni foarte mare. Soluia este ndeprtarea
intei respective din configuraia de replicare. De ndat ce serverul este din nou disponibil, este
reintrodus n configuraie, ceea ce va conduce la o replicare total a sursei (echivalent cu
tergerea tuturor liniilor i inserarea tuturor liniilor din surs).
Aplicarea actualizrilor
Dup ce mesajele cuprinznd actualizrile sosesc la serverul int, ele trebuie aplicate (de
preferin ct mai repede) asupra bazei de date int. Procesul n sine nu este interesant.

Eventual se poate meniona faptul c exist posibilitatea ca regulile de integritate din baza de
date int s fie diferite de cele din surs i c ele vor superviza actualizrile. Aceasta nseamn
c dei la surs actualizrile au fost acceptate, ele pot fi respinse la baza de date int. Situaiile
de acest gen nu sunt tipice, ci fiind mai degrab rezultatul unor erori de proiectare sau
configurare.
Ca regul general, n cadrul configuraiilor de tip master/slave regulile de integritate din baza de
date slave sunt mai relaxate dect cele din master, iar n cadrul configuraiilor peer-to-peer
regulile de integritate sunt echivalente n toate locaiile. n aceste condiii se poate presupune c
nu vor fi replicate dect actualizri realizate de tranzacii valide la surs.
Chiar i n aceste condiii, caracterul asincron al replicrii poate conduce la situaii de conflict.
Ajungem astfel la subiectul cel mai interesant din cadrul acestei seciuni: detectarea i rezolvarea
conflictelor.
n primul rnd, nu orice anomalie este un conflict. Considernd scenariul (a), o actualizare a
preului unui produs P la sediul central efectuat la momentul T1 va fi replicat la filiala Mure la
momentul T2. ntre momentele T1 i T2, filiala Mure va vinde produsul P cu un pre incorect. E o
anomalie, dar nu e un conflict. O astfel de anomalie nu poate fi detectat de mecanismul de
replicare, deci rmne pe seama aplicaiei. O posibil variant ar fi ca (n locaia replicat) un
trigger de actualizare s caute n tabela de vnzri toate nregistrrile introduse dup momentul
actualizrii linei respective n locaia primar i s le listeze (urmnd ca rezolvarea situaiei s fie
fcut manual).
Conflictele sunt caracteristice configuraiilor cu replici actualizabile i apar la momentul n care
aplicarea actualizrilor n baza de date replicat nu este posibil datorit unor actualizrii
contradictorii realizate de diverse locaii. Cele mai comune conflicte (numite uneori coliziuni) sunt
cele datorate unor erori n ordinea replicrii. Iat cteva exemple:
Replicarea unei operaii DELETE nu gsete linia care trebuie tears (conflict de tergere).
Explicaia poate fi faptul c n timpul propagrii, o alt operaie a actualizat linia.
O operaie UPDATE replicat nu gsete linia care trebuie actualizat (conflict de modificare).
Explicaia este aceeai ca n cazul tergerii.
O operaie INSERT replicat gsete deja n replic o linie avnd aceeai cheie primar
(conflict de unicitate). Explicaia poate fi faptul c n timpul propagrii, a intervenit o operaie de
inserare sau o operaie de modificare asupra cheii primare a unei linii existente.
Multe sisteme permit aplicarea unor reguli prestabilite pentru rezolvarea automat a unor astfel
de conflicte. Cele mai comune sunt regulile bazate pe mrci de timp (timestamps). Exist i
metode de rezolvare a conflictelor bazate pe un sistem de prioriti acordate locaiilor i/sau
utilizatorilor. O alt variant de rezolvare o constituie construirea unor proceduri stocate care s
fie executate atunci cnd este detectat un conflict. Acestea au acces la toate informaiile
referitoare la actualizrile conflictuale, prin urmare pot combina metode bazate pe mrci de timp,
prioriti sau alte reguli specifice aplicaiei.
Informix, de exemplu, permite rezolvarea automat a conflictelor prin mrci de timp (ultima
actualizare nvinge), prin proceduri stocate (logica acesteia determin actualizarea care nvinge)
sau prin... ignorarea conflictului. Dac pentru o anumit replic se alege regula mrcilor de timp,
se poate aduga ca regul secundar lansarea unei proceduri stocate (pentru cazul n care
actualizrile n conflict au aceeai marc de timp). Un detaliu: pentru ca regulile bazate pe mrci
de timp s poat funciona corect, sistemele participante trebuie s aib ceasurile sincronizate i
s in seama de eventualele diferene de fus orar.
S considerm un exemplu, n versiune Informix. Fie trei locaii (A, B i C) n configuraie peer-topeer i o tabel Pers n care a fost inserat o linie prin instruciunea:
INSERT INTO pers

VALUES (1325, 'Vasile', 'MS');

Regula de rezolvare a conflictelor este cea bazat pe mrci de timp. Considerm ca la momentul
T0 (s zicem, ora 12:00), linia exist n toate replicile.
La momentul T1 (12:05), la locaia B se execut instruciunea:
UPDATE pers SET jud = 'CJ'
WHERE marca = 1325;
La momentul T2 (12:10), la locaia C se execut instruciunea:
DELETE FROM pers
WHERE marca = 1325
AND nume = 'Vasile'
AND jud = 'MS'
La momentul T3 (13:00), actualizrile de la locaia C sosesc la locaia A i sunt aplicate n tabela
Pers. Linia cu cheia primar 1325 este tears din tabel Pers. Sistemul pstreaz ns linia ntro "umbr" (shadow) a tabelei.
La momentul T4 (13:15), sosesc la locaia A actualizrile de la B. Se ncearc aplicarea
modificrii, care ns nu gsete linia. Sistemul detecteaz astfel apariia unui conflict.
Deoarece linia cu cheia primar cutat lipsete din tabela Pers, se scaneaz "umbra". Este
gsit linia n cauz i se compar marca de timp aplicat de ultima actualizare (n cazul nostru
T2, adic 12:10) cu marca de timp a noii actualizri (T1, adic 12:05). Este considerat
nvingtoare actualizarea cu marca de timp mai mare (n cazul nostru, tergerea), deci
modificarea nu se mai aplic i linia rmne tears.
Faptul c actualizarea de la C au sosit mai repede dect cele de la B este ntmpltor. Ce s-ar fi
ntmplat dac ordinea ar fi fost inversat? S-ar fi aplicat nti modificarea (jud ar fi devenit 'CJ')
dup care tergerea n-ar fi gsit linia (observai importana condiiilor suplimentare pentru
tergere). S-ar fi cutat linia cu cheia primar 1325 i s-ar fi comparat mrcile de timp. tergerea
ar fi fost declarat nvingtoare, deci s-ar fi anulat modificarea i s-ar fi ters linia.
Este de remarcat faptul c n ambele cazuri s-ar fi ajuns la acelai rezultat, care ar fi fost apoi
replicat ctre celelalte locaii. S observm c dac instruciunea UPDATE ar fi modificat cheia
primar, putem presupune c tergerea n-ar mai fi putut gsi linia dinainte de modificare. Nu este
aa, deoarece la evaluarea lui UPDATE, aceasta ar fi fost nlocuit cu o tergere urmat de o
nserare, deci linia ar fi fost gsit n tabela "umbr".
S-ar putea ns ca aceast rezolvare s nu fie ceea ce ne-am dorit. Poate am fi dorit ca prima
actualizare s nving. Unele sisteme permit stabilirea unei astfel de reguli, dar n Informix va
trebui s scriem o procedur stocat n acest scop. (Dac am fi ales varianta "ignore" am fi
obinut rezultate diferite n funcie de momentul replicrii.)
O ultim precizare: Informix permite i stabilirea aplicabilitii regulii de rezolvare la nivel de linie
sau la nivel de tranzacie. n primul caz, este posibil ca dintre actualizrile realizate n cadrul unei
tranzacii unele s fie aplicate i altele nu. Dac rezolvarea se face la nivel de tranzacie, atunci
fie ntreaga tranzacie este aplicat, fie este anulat (rollback). Aceast ultim variant este
menit s pstreze integritatea referenial.
Prevenirea conflictelor

Conflictele reprezint partea cea mai sensibil a sistemelor distribuite pe baz de replicare. O
regul de bun sim spune c este preferabil ca acestea s fie prevenite dect s se mizeze pe
rezolvarea lor automat. n scopul prevenirii conflictelor, varianta cea mai bun este stabilirea
strict a apartenenei datelor i evitarea pe ct posibil a configuraiilor peer-to-peer. n exemplul
precedent, datele despre personalul unei companii se preteaz cel mai bine la partajare, astfel
nct drepturile de actualizare s fie deinute de fiecare filial doar pentru angajaii proprii. n
aceste condiii, transferul unui angajat de la filiala Mure la filiala Cluj (operaie care a fost
simulat n exemplu) s-ar petrece puin mai complicat (persoana ar tears din baza de date la
Mure i ar fi inserat din nou la Cluj) dar de bun seam mai sigur.
Tot o metod de prevenire a conflictelor poate fi considerat tehnologia promovat de IBM, care
propune nlocuirea configuraiilor peer-to-peer cu configuraii ierarhice cu un nod de referin. n
aceast configuraie, toate actualizrile sunt replicate nti spre nodul de referin (rdcina
ierarhiei), de unde sunt apoi replicate ctre celelalte noduri. Eventualele conflicte sunt rezolvate
la nodul de referin, printr-o metod bazat pe aa-numitele "tranzacii de compensare". Atunci
cnd dou tranzacii ncearc s realizeze actualizri contradictorii, una dintre ele este aleas ca
"victim". Aceasta va fi anulat la nivelul nodului de referin, dup care sistemul va genera o
"tranzacie de compensare", care va fi propagat n scopul de a anula efectele tranzaciei
"victim" la nivele inferioare ale ierarhiei. Este interesant de notat c aceast metod
funcioneaz i n cazul conflictelor mai complexe, implicnd date din mai multe tabele.
S considerm, ca exemplu, o configuraie peer-to-peer cu trei noduri (A i B), n care avem
definite tabelele F (furnizori) i P (produse), asociate printr-o cheie strin (f_id) n tabela P (orice
produs trebuie s aparin unui furnizor). Regula pentru tergere n restricia referenial pentru
cheia strin este ON DELETE RESTRICT (un furnizor nu poate fi ters dect dac nu are nici
un produs care s-i fie asociat).
S considerm c la locaia A s-a fcut inserarea:
INSERT INTO F VALUES (12, ...);
S mai presupunem c nu exist nici un produs de la furnizorul 12 i c aceast inserare a fost
replicat cu succes, astfel nct la momentul T0 (ora 12:00) starea este consistent.
La momentul T1 (12:05), la locaia A se execut instruciunea:
DELETE FROM F WHERE id = 12;
La momentul T2 (12:07), la locaia B se execut instruciunea:
INSERT INTO P
VALUES (1023, 12, "Ciocan");
La momentul T3 (12:10), la locaia A sosete mesajul cu actualizarea produs la momentul T2 la
B. Inserarea nu se poate face deoarece nu exist furnizorul referit (id = 12).
La momentul T4 (12:15), la locaia B este replicat tergerea efectuat la momentul T1 la locaia
A. Furnizorul cu codul 12 nu poate fi ters deoarece exist un produs care-l refer.
Observm c s-a ajuns la o stare inconsistent: la nodul A nu mai exist nici furnizorul 12 nici
produsul 1023, n timp ce la nodul B ambele exist.
n varianta propus de IBM, vom considera c un nod (C) ca fiind nod de referin. Considernd
momentele aceleai operaii n nodurile A i B, la aceleai momente (T1 i T2), scenariul poate fi
continuat astfel:
La momentul T3 (12:10), inserarea de la momentul T2 din nodul B este replicat n nodul C. Este
aplicat cu succes, dup care este trimis spre replicare nodului A.

La momentul T4 (12:15), tergerea de la momentul T1 din nodul A este replicat n nodul C.

Deoarece furnizorul 12 are un produs care-l refer, nu poate fi ters. Se aplic o metod de
rezolvare a conflictului, de pild last timpstamp wins. Conform acesteia, tranzacia care a comis
inserarea nvinge, iar cea care a comis tergerea este considerat "victim". Prin urmare,
tergerea nu este replicat ctre B i se genereaz o tranzacie de compensare care este trimis
ctre A. Aceasta ar putea fi de forma:
BEGIN WORK;
DELETE FROM P
WHERE cod = 1023
AND f_id = 12
AND den = 'Ciocan';
INSERT INTO F
VALUES (12, ...);
INSERT INTO P
VALUES (1023, 12, 'Ciocan');
COMMIT WORK;
Chiar dac nu s-au evitat astfel conflictele, prin centralizare numrul lor s-a redus iar posibilitile
de rezolvare au sporit. Cu toate c nodurile sunt consistente, problema nu poate fi considerat
complet rezolvat. Considernd c tranzacia de compensare a fost comis n nodul A la
momentul T5 (s zicem 12:17), orice tranzacie care a citit tabela F de la nodul A, a avut ocazia
s ia o decizie greit bazat pe faptul c furnizorul cu codul 12 a lipsit din tabel.
Concluzia final este c nici una dintre tehnicile de rezolvare a conflictelor nu este infailibil i c
vor exista mereu situaii n care se impun intervenii manuale. Este un pre care trebuie pltit n
schimbul avantajelor pe care replicarea asincron le ofer. Corolarul acestei concluzii este c
pentru anumite probleme replicarea asincron este aplicabil i pentru altele nu.
Ce-a mai rmas?
Nu am detaliat n aceast prezentare subiecte extrem de interesante cum ar replicarea
actualizrilor n schema bazelor de date sau replicarea prin apeluri asincrone de proceduri la
distan (asynchronous RPC). Nu am vorbit despre mecanismele de replicare la nivel de cmp i
de rezolvrile conflictelor prin versiuni multiple din Lotus Notes.
Nu am vorbit despre replicarea procedural practicat de Oracle i nici despre modelele de
propagare pull i push utilizate de IBM i de ali productori. Am amintit doar de problemele
speciale pe care le ridic replicarea pentru lucrtorii mobili.
O problematic larg este replicarea n medii eterogene, cuprinznd baze de date de la
productori diferii. n fine, nu am amintit despre produsele independente de la teri productori,
cum ar fi PeerDirect sau ThinkNet. i ar mai fi multe altele.
Sperana mea este c noiunile pe care am ncercat s le prezint n aceste (poate prea multe)
pagini v vor fi de folos atunci cnd v vei confrunta direct cu problematica replicrii.
Sau mcar c v-am strnit curiozitatea.