UTILIZAREA REPLICARII INTR-O APLICATIE DE BAZE DE DATE

 

 

CAPITOLUL I
INTRODUCERE

1.1. Bazele de date distribuite si procesele distribuite.

Termenii da baze de date distribuite si procesele distribuite sunt foarte apropiati, dar au intelesuri diferite. O baza de date distribuita este un set de baze de date stocate pe mai multe calculatoare care apar in aplicatie ca o singura baza de date.
Procesele distribuite apar atunci cand aplicatia unui sistem distribuie task-urile la diferite calculatoare intr-o retea. Procesarea unui sistem cu baze de date distribuite este vazuta mai mult ca o aplicatie sistem de baze de date client-server. Un sistem cu baze de date distribuite necesita functionarea unei aplicatii de procese distribuite.

1.2. Baze de date distribuite si replicarea lor.

Intr-o baza de date distribuita simplu, sistemul administreaza o singura copie a tuturor datelor si obiectelor de baze de date sustinute. Aplicatiile de baze de date distribuite folosesc tipic tranzactii distribuite pentru a accesa ambele locuri si datele indepartate si pentru a modifica bazele de date globale in timp real.

1.3. Ce este replicarea.

Replicarea este procesul de copiere si pastrare a schemelor obiectelor in multiple baze de date distribuite. Replicarea poate sa imbunatateasca performantele si sa protejeze disponibilitatea aplicatiilor fiindca exista o alternativa de acces la date. De exemplu, o aplicatie poate normal sa acceseze o baza de date locala mai repede decat a unui server indepartat, poate sa minimizeze traficul intr-o retea si sa obtina cele mai bune performante. In afara de aceasta aplicatia poate sa functioneze chiar daca va cadea un server local, dar alte servere cu baze de date replicate raman accesibile. Exista mai multe forme de replicare: replicarea de baza si replicarea avansata .
Folosind replicarea putem distribui datele intre diferite locuri, la utilizatorii indepartati sau mobili, intr-o arie locala folosind o retea cu conexiune dial-up si prin Internet. Replicarea de asemenea ne permite sa imbunatatim performantele aplicatiilor, sa separam datele fizice si modul cum sunt folosite procesele de baze de date distribuite intre mai multe servere.
Replicarea ofera diferite beneficii depinzand de tipul replicarii si de optiunile pe care le alegem, dar cel mai comun beneficiu este valabilitatea datelor cand si cum este nevoie.
Alte beneficii includ:
- permite mai multor locuri sa pastreze copii ale acelorasi date. Aceasta este util cand mai multe locuri au nevoie sa citeasca aceleasi date sau au nevoie de servere diferite pentru a rula aplicatiile;
- separarea aplicatiilor read-intensive cum ar fi procesele analitice de baze de date online sau depozitele de date;
- permite o mare autonomie. Utilizatorii pot lucra cu copii ale datelor in timp ce sunt deconectati si apoi, dupa ce fac modificari asupra bazelor de date le pot propaga atunci cand sunt reconectati;
- creste performantele de citire;
- aduce datele mai aproape de grupurile individuale. Aceasta ne ajuta sa reducem conflictele bazate pe mai multi utilizatori care modifica datele si cerintele din cauza carora datele pot fi distribuite in retea si putem partitiona datele pe baza nevoilor diferitor tranzactii sau utilizatori;
- replicarea este o alegere pentru strategia server standby.
Tot mai nou este nevoia de a fi necesar ca datele sa fie stocate redundant. Diferite aplicatii au nevoi diferite pentru autonomie si consistenta datelor.
Replicarea este o solutie pentru un mediu cu date distribuite cand avem nevoie
- sa copiem si sa distribuim datele spre unul sau mai multe locuri;
- pentru distribuirea copiilor datelor spre baze programate;
- sa distribuim modificarile datelor spre alte servere;
- atunci cand este nevoie sa permitem mai multor utilizatori si locuri sa faca schimbarile, apoi sa trimita modificarile de date impreuna si chiar potential sa rezolve conflictele;
- de a construi aplicatii de date care trebuie folosite in medii online sau offline;
- sa construim aplicatii Web in care utilizatorii pot accesa un mare volum de date;
- optional sa facem modificari la semnatarii care au un control transparent pentru editor.

CAPITOLUL II

Replicarea in Microsoft Sql Server

2.1. Tipuri de replicare.

In cercetarea mea asupra acestui subiect am intalnit urmatoarele tipuri de replicare pe care le putem folosi in aplicatiile distribuite:
- replicarea snapshot;
- replicarea tranzactionala; folosite in SQL Server;
- replicarea merge;
- replicare mastre-slave -; folosit in MySQl Server
Fiecare dintre aceste tipuri furnizeaza capabilitati diferite, depinzand de aplicatie si de diferite niveluri de proprietati (consistenta, izolare, durabilitate) ale tranzactiilor si autonomiei locurilor de replicare. De exemplu replicarea merge permite utilizatorilor sa lucreze si sa actualizeze datele autonom, in schimb cand serverele sunt reconectate, toate locurile cu topologie de replicare converg la aceeasi valoare de date.
Replicarea tranzactionala mentine consistenta tranzactiilor, dar locurile semnatare (subscriber) nu sunt asa de autonome cum sunt la replicarea merge din cauza ca editorii (Publisher) si semnatarii, in general ar trebui sa fie conectati continuu pentru ca actualizarile sa fie propagate la semnatari (subscribers).
Este imposibil ca pentru o aplicatie sa se foloseasca mai multe tipuri de replicare si optiuni. Unele din datele unei aplicatii s-ar putea sa nu necesite nici o actualizare la semnatari (subscriber), unele seturi de date necesita actualizari ocazionale facute la unul sau mai multe servere, in timp ce alte seturi de date necesita sa fie actualizate zilnic la mai multe servere.
Atunci cand se creeaza o aplicatie, pentru aceasta este aleasa un anumit tip de replicare, depinde de cerintele bazate pe factorii de date distribuiti, daca sau nu datele vor trebui actualizate la semnatari (subscribers), mediul de replicare, de nevoile si cerintele datelor care vor fi replicate.
Atunci cand planificam replicarea trebuie sa punem urmatoarele cerinte:
- daca datele replicate au nevoie de actualizare si de la cine;
- daca datele trebuie sa priveasca consistenta, autonomia si latenta;
- daca mediul replicarii include utilizatori business, infrastructura tehnica, retele si securitate si caracteristicile datelor.;
- tipul de replicare si optiunile;
- topologia replicarii si cum se aliniaza cu tipul replicarii.
Fiecare tip de replicare incepe cu generarea si aplicarea snapshoturilor la semnatar (subscriber), asa ca este important sa intelegem replicarea snapshot.

2.2. Replicarea snapshot (SQL Server).

Replicarea snapshot distribuie datele exact asa cum apar intr-un moment specific in timp si nu monitorizeaza actualizarile de date. Este cel mai bine folosita ca o metoda pentru replicarea datelor care se modifica ocazional sau unde cele mai multe actualizari ale valorilor de date nu sunt necesare. Cand are loc sincronizarea intregul snapshot este generat si trimis la semnatar (subscriber).
Replicarea snapshot va fi preferabila in locul replicarii tranzactionale cand schimbarile de date sunt substantiale, dar ocazionale. Daca o organizatie de vanzari mentine o lista cu pretul produselor si pretul este actualizat o data sau de doua ori in acelasi an, este recomandat replicarea intregului snapshot de date dupa ce a fost modificat. Crearea unor snapshoturi noi este o optiune daca editam tabele relativ mari, care sunt actualizate doar de editori (publishers).
Replicarea snapshot este adesea folosita atunci cand e nevoie de a rasfoi o lista de preturi, cataloguri, sau date pentru suport de decizii unde cele mai multe date nu sunt esentiale si datele sunt folosite ca read-only.
Aceasta replicare este utila atunci cand:
- datele sunt in special statice si nu se modifica des. Atunci cand se modifica este util sa editam o noua copie pentru semnatar;
- este acceptabil sa avem copii ale datelor care sunt expirate de o perioada de timp.
Replicarea snapshot este utila atunci cand avem nevoie sa distribuim o copie de date read-only, dar deasemenea ofera posibilitatea de a actualiza datele la semnatar (subscriber). Cand semnatarul doar citeste datele, consistenta tranzactiilor este mentinuta intre editor si semnatar din cauza ca datele sunt propagate folosind doua faze, protocolul de incredintare (intre doua PC), o trasatura a optiunii de actualizare imediate. Replicarea snapshot necesita o procesare constanta mai mica decat replicarea tranzactionala din cauza ca nu necesita o monitorizare continua a modificarilor de date de la sursele server. Daca setul de date care trebuie replicat este foarte mare, poate avea nevoie de o sursa substantiala de retea pentru a fi transmis.

2.3. Cum functioneaza replicarea snapshot.(SQL)

Replicarea snapshot este implementata de agentul snapshot si agentul de distributie. Agentul snapshot pregateste fisierele continand schemele si datele tabelelor si obiectelor de baze de date editate, stocheaza fisierele in foldere snapshot si inregistreaza sincronizarea functiilor in bazele de date distribuite la distribuitor. Implicit folderele snapshot sunt amplasate in distribuitor, dar se poate specifica o locatie alternativa (care poate fi un alt server, Cd-rom, disc, etc.).
Agentul de distributie muta snapshoturile tinute in tabelele de baze de date spre tabelele de destinatie ale semnatarului. Bazele de date distribuite sunt utilizate doar de replicare si nu contin nici o alta tabela utilizator.
Agentul snapshot de fiecare data cand este activat, el verifica daca a mai fost adaugata vreo noua semnatura. Daca nu este nici o noua semnatura, nu este creata nici o noua scriere de fisiere de date. Daca publicatia este creata cu optiunea de a crea primul snapshot imediat activat, noua schema si fisierele de date sunt create de fiecare date cand agentul snapshot este activat. Toate schemele si fisierele de date sunt stocate in folderul snapshot, agentul de distributie sau agentul merge le transfera la semnatari (vezi fig.2 si fig. 3, paginile 10 respectiv 15).

Fig. 1 Functionarea replicarii snapshot.

Agentul de distributie de fiecare data cand este activat pentru o publicatie snapshot, el muta schema si datele la semnatar(subscriber).

2.4. Replicarea tranzactionala.

Un snapshot initial de date este aplicat la semnatar, iar apoi cand modificarile de date sunt facute la editor, tranzactia individuala este capturata si propagata la semnatar.
Replicarea tranzactionala foloseste conectarea tranzactiei pentru a capta modificarile de incrementare care au fost facute asupra datelor din tabelele publicate. Microsoft SQL server 2000 monitorizeaza declaratiile de inserare, actualizare si stergere, sau alte modificari facute datelor si stocheaza aceste modificari in baze de date distribuite, care de fapt stau in coada. Modificarile sunt apoi propagate la semnatari si aplicate in aceeasi ordine in care au aparut.
Daca semnatarii au nevoie sa primeasca modificarile de date aproape in timp real, ei au nevoie de o retea conectata la editor. Replicarea tranzactionala poate oferi semnatarilor o latenta foarte mica. Semnatarii primesc de obicei datele folosind “push subscription” si de obicei primesc modificarile de la editor intr-un minut sau chiar mai putin, aceasta depinzand de retea, distanta si traficul de informatii.

2.5. Cum functioneaza replicarea tranzactionala.

Replicarea tranzactionala este implementata de agentul snapshot, agentul log reader si agentul de distributie. Agentul snapshot pregateste fisierele snapshot care contin scheme si date ale obiectelor de baze de date si tabelelor editate, stocarile de fisiere in folderul snapshot, inregistreaza sincronizarile de functii ale bazelor de date distribuite la distribuitor.
Agentul “log reader” monitorizeaza conectarea tranzactiilor a fiecarei baze de date configurata pentru replicarea tranzactionala si copiaza tranzactiile facute pentru replicare de la conectare in baze de date distribuite.
Agentul de distributie muta functiile initiale snapshot si tranzactiile tinute in tabele de baze de date distribuite.

2.6. Snapshotul initial.

Inainte ca o noua replicare tranzactionala spre un semnatar sa poata primi modificarile de la un editor , semnatarul trebuie sa contina tabele cu aceleasi scheme si date ca si tabelele editorului.
Copierea completa a publicatiei curente de la editor la semnatar este efectuata in snapshotul initial.
Dupa ce o publicatie si o semnatura au fost create, este nevoie sa se creeze si transfere un snapshot initial pentru semnatar. Schema transferului snapshot si datelor spre semnatar contine constrangeri, proprietati extinse, indexi, mecanisme si tabele sistem necesare pentru replicare. Snapshotul contine diferite tipuri de fisiere depinzand de tipul replicarii si articolele din publicatie:

Tipul replicarii Fisiere comune snapshot
Replicare snapshot si replicare tranzactionala Scheme (.sch); date (.bcp); constrangeri si indexi (.dri); constrangeri (.idx)
Replicare merge Scheme (.sch); date (.bcp);constrangeri si indexi (.dri); mecanisme (.trg); tabele de date sistem (.sys); tabele in conflict (.cft).

Cand snapshoturile sunt distribuite si aplicate asupra semnatarului, doar semnatarul care asteapta snapshotul initial este afectat, ceilalti semnatari la acea
Fig 2 Functionarea replicarii tranzactionale.

publicatie (care au primit adaugarile, actualizarile, stergerile sau alte modifiari asupra publicatiei) nu sunt afectati.

2.7. Procesele snapshot concurente.

Tipic prin generarea snapshotului, SQL Server va pune parti de chei (blocheaza accesul temporar) in toate tabelele publicate pe toata durata generarii snapshotului. Aceasta previne actualizarile nedorite care pot fi facute tabelelor publicate. Procesele snapshot concurente, valabile doar pentru replicarea tranzactionala nu tin aceste chei in timpul generarii snapshotului si permit utilizatorului sa poata sa lucreze, in timp ce SQL Server creeaza fisierele snapshotului initial. Dupa inceperea replicarii, agentul snapshot plaseaza cheile in tabelele publicatiei, iar dupa ce tranzactia este primita de semnatar cheile sunt retrase si modificarile in bazele de date pot continua.

Procedurile prin care agentul snapshot implementeaza snapshotul initial sunt aceleasi ca procedurile folosite in replicarea snapshot (vezi pagina 6 ).
Durata tinerii cheilor este foarte mica (cateva secunde), chiar daca este copiata o mare cantitate de date. Din acest punct agentul snapshot incepe sa genereze fisierele snapshot. Cand snapshotul este complet, o inregistrare secundara care indica sfarsitul snapshotului este scrisa la conectare. Orice tranzactie care apare pana ce snapshotul este generat este capturata intre cele doua indicii, de inceput si de sfarsit si trimisa mai departe la bazele de date distribuite de catre agentul log reader. Atunci cand snapshotul este aplicat semnatarului, agentul de distributie aplica in primul rand fisierele snapshot (schemele si fisierele .bcp), apoi revizuieste fiecare tranzactie capturata pentru a vedea daca a fost deja trimisa la semnatarul careia ii era destinata. In timpul procesului de revizuire, tabelele semnatarului sunt blocate.
Depinzand de numarul tranzactiilor capturate la editor in timp ce snapshotul a fost creat, ne putem astepta la o crestere a timpului necesar pentru aplicarea snapshotului asupra semnatarului.
Declaratiile de actualizare text (UPDATETEXT) nu pot fi efectuate asupra datelor marcate pentru replicare, in timp ce ele sunt extrase, in timpul proceselor snapshot concurente. Daca vom initia o declaratie UPDATETEXT vom primi un mesaj de eroare, care indica ca aceasta operatie nu este posibila din cauza ca se desfasoara procese snapshot concurente. Dupa ce snapshotul e complet, declaratiile UPDATETEXT pot fi efectuate din nou.
Procesele snapshot concurente folosesc un volum mare de tabele inserate, urmate de o serie de declaratii speciale INSERT si DELETE care aduc tabelele intr-o stare consistenta. Aceste operatii sunt efectuate ca o singura tranzactie, astfel incat utilizatorii bazelor de date nu vad datele ca fiind intr-o stare inconsistenta. Pentru a preveni modificarea datelor cu identitate proprie ale semnatarului, este indicat sa folosim optiunea NOT FOR REPLICATION. Procesele concurente snapshot sunt valabile doar la replicarea tranzactionala, atunci cand se ruleaza instante ale SQL Server.
Procedurile prin care agentul snapshot implementeaza snapshotul initial in replicarea tranzactionala sunt aceleasi proceduri cu cele folosite in replicarea snapshot. Dupa ce fisierele snapshot au fost generate le putem vedea in folderele snapshot folosind Snapshot Explorer. In SQL Server extindem folderele de replicare si publicari (Publisher), facem clic dreapta pe publicatie (publication_name) si alegem “Explore the Latest Snapshot Folder”.

2.8. Modificarea datelor si agentul log reader.

Agentul log reader functioneaza continuu, sau cu acordul unui program stabilit atunci cand a fost creata publicatia. Cand se executa, in primul rand citeste conectarea tranzactiilor publicate si identifica orice declaratie de inserare, actualizare si stergere, sau modificarile facute tranzactiilor de date care au fost marcate pentru replicare, apoi agentul trimite intreaga copie a tranzactiilor de la bazele de date distribuite spre distribuitor. Agentul log reader foloseste proceduri stocate intern sp_replcmds pentru a da urmatorul set de comenzi. Baza de date devine o cerinta store-and-forward (stocheaza si mai departe) in asteptare, ale carei modificari sunt trimise semnatarului. Doar tranzactiile care au consimtamant sunt trimise bazelor de date distribuite.
Agentul log reader apeleaza sp_repldone pentru a marca replicarea acolo unde s-a terminat. In final agentul marcheaza randurile din tranzactie care sunt gata pentru terminare si care au fost replicate deja. Randurile care asteapta sa fie replicate spre semnatar nu sunt terminate.
Modificarile de date facute semnatarului, vor fi propagate intotdeauna ca o singura declaratie de randuri. Daca o actualizare vrea sa modifice doar o singura coloana dintr-o tabela de date, actualizarea va fi propagata ca o serie de declaratii de stergere urmata de o serie de declaratii de inserare. Actualizarile facute vederilor indexate sau tabelelor de baza in care vederile indexate sunt stabilite, vor fi propagate ca o pereche DELETE/INSERT.
Agentul log reader functioneaza in agentul SQL server, la distribuitor si poate fi administrat direct accesand SQL Entreprise Manager, in monitorul de replicare si in folderele agentului.

2.9. Agentul de distributie.

Comenzile tranzactiilor sunt stocate in baze de date distribuite pana ce agentul de distributie le propaga tuturor semnatarilor. Bazele de date distribuite sunt folosite doar de replicare si nu contin alte tabele utilizator. Semnatarii vor primi tranzactiile in aceeasi ordine in care sunt aplicate la editor.
SQL Server poate valida datele actualizate la semnatar de catre procesele replicate si ne putem asigura ca datele de la editor sunt aceleasi si la semnatar. Validarea datelor de catre SQL Server se face calculand numarul de randuri si/sau verificarea sumei de la editor si apoi prin compararea acestor valori cu numarul de randuri si/sau verificarea sumei calculate la semnatar. O singura valoare este calculata pentru tabelele intregii publicatii si una pentru tabelele semnatarului, dar datele din coloanele cu text sau imagini nu sunt incluse in calcul. In timpul efectuarii verificarii, cheile (blocheaza temporar accesul la tabele) sunt plasate temporar in tabelele a caror randuri sau sume sunt efectuate, dar calculul se efectueaza repede (cateva secunde) si cheile sunt retrase.
Saltul erorilor in replicarea tranzactionala. Agentul skiperrors ne permite sa specificam care erori pot fi sarite in timpul proceselor distribuite. Tipic, atunci cand agentul log reader si agentul de distributie functioneaza in mod continuu, si unul dintre ei intalneste o eroare, agentul si procesele de distributie se opresc. Prin specificarea erorilor asteptate sau erorile care nu vrem sa intervina in replicare, cu parametrul skiperrors agentul de distributie va incarca informatiile despre erori si apoi va continua sa functioneze.

2.10. Replicarea merge (merge replication).

Replicarea merge este procesul de distribuire al datelor de la editor la semnatar, permitand editorului si semnatarului sa faca modificari si actualizari in timp ce conexiunea intre ei este deconectata, iar apoi se transmit actualizarile intre locuri (editor-semnatar) atunci cand se conecteaza. Replicarea merge permite diferitor locuri sa faca actualizari merge ca un rezultat uniform.
Snapshotul initial este aplicat semnatarilor si apoi SQL Server colecteaza modificarile de date de la editor la semnatari. Datele sunt sincronizate intre servere printr-un ceas programat, sau la cerere. Din cauza ca actualizarile sunt facute la mai mult decat un server, datele asemanatoare trebuie actualizate de editor, sau mai mult decat un semnatar. Replicarea merge contine optiuni care sunt implicite si unele setate pentru conflictele de rezolutie pe care le putem defini pentru a configura publicatiile merge. Cand apare un conflict, este solicitata o hotarare de catre agentul merge si determinate ce date vor fi acceptate si propagate spre alte locuri.
Replicarea merge este utila cand:
• mai multi semnatari au nevoie sa actualizeze datele in diferite momente si sa propage modificarile editorului spre alti semnatari;
• semnatarii au nevoie sa primeasca date, sa faca modificari indirect si mai tarziu sa sincronizeze modificarile intre editor si alti semnatari;
• cand nu se asteapta multe conflicte cand datele sunt actualizate in mai multe locuri.
Atunci cand datele trebuie sa fie actualizate de semnatari, se poate folosi replicarea snapshot sau replicarea tranzactionala cu optiunile de actualizare a subscriptiei, sau se poate folosi replicarea merge.
Metoda pe care o alegem depinde de topologia replicarii, de nevoile aplicatiei si a celor care o folosesc si carora le este destinata:

Folosim replicarea merge atunci cand… Folosim replicarea snapshot sau replicarea tranzactionala cu actualizare imediata sau actualizare in asteptare atunci cand…
• datele replicate sunt citite si actualizate de semnatari; • datele sunt mai mult read-only la semnatar;
• semnatarii si editorii sunt conectati doar ocazional; • semnatarul, distribuitorul si editorul sunt conectati cea mai mare parte a timpului;
• avem nevoie ca actualizarile sa fie propagate pe baza rand-cu-rand si conflictele sa fie evaluate si rezolvate la nivel de randuri; • conflictele cauzate de actualizarile multiple ale acelorasi date sunt ocazionale;
• conflictele cauzate de actualizarile multiple ale acelorasi date sunt manipulate si rezolvate. • Avem nevoie ca actualizarile sa fie propagate intr-o tranzactie de baza si conflictele sa fie evaluate si rezolvate.

2.11. Functionarea replicarii merge (merge replication).

Replicarea merge este implementata de agentul snapshot si agentul merge. Agentul snapshot pregateste fisierele continand scheme si date ale tabelelor publicate, stocheaza fisierele in folderul snapshot si insereaza functii de sincronizare in publicatiile de baze de date. Deasemenea agentul snapshot creeaza replicarea -; procedurile specificate si tabelele sistem.
Agentul merge aplica functiile snapshotului initial tinute in tabelele de baze de date publicate, asupra semnatarului. Totodata incrementeaza modificarile de date care apar la editor sau la semnatar, dupa ce a fost creat snapshotul initial.
Rolul distribuitorului este foarte limitat in replicarea merge, astfel incat implementarea distribuitorului este locala (pe acelasi server cu editorul). Agentul merge aplica functiile snapshotului initial tinute in tabelele de baze de date publicate, asupra semnatarului. Totodata incrementeaza modificarile de date care apar la editor sau la semnatar, dupa ce a fost creat snapshotul initial. lul distribuitorului este foarte limitat in replicarea merge, astfel incat implementarea distribuitorului este locala (pe acelasi server cu editorul). Agentul de distributie nu este folosit pe toata durata replicarii merge, iar bazele de date distribuite din distribuitor stocheaza “istoricul “ informatiilor despre replicarea merge.
Fig.3 Functionarea replicarii merge (merge replication).

2.12. Identificatorul unic de coloana.

SQL Server identifica o coloana unica pentru fiecare rand (row) in tabelele care sunt replicate. Aceasta permite randurilor sa fie identificate unic atunci cand exista mai multe copii de tabele. Daca tabela contine deja o coloana cu prioritatea ROWGUIDCOL, care este un index unic, sau o constrangere a unei chei primare, SQL Server va folosi automat acea coloana ca fiind identificator de rand pentru tabela publicata.
Astfel SQL server adauga uniqueidentifier (identificator unic) de coloana numit rowguid, care are proprietatea ROWGUIDCOL si un index a tabelelor publicate. Adaugarea coloanei ROWGUIDCOL creste marimea (size) tabelelor publicate. Coloana rowguid si indexul sunt adaugate tabelelor publicate atunci cand agentul snapshot se executa pentru prima data pentru o publicatie.

2.13. Mecanismele replicarii merge.

SQL Server instaleaza mecanismele care urmaresc modificarile datelor in fiecare rand sau coloana. Mecanismele captureaza modificarile facute tabelelor publicate si le inregistreaza in tabelele sistem merge. Urmarirea mecanismelor in tabelele publicate se face in timp ce agentul snapshot ruleaza prima data. Mecanismele sunt create pentru semnatar cand ii este aplicat snapshotul. Mecanisme diferite sunt generate pentru articole care urmaresc modificarile la nivel de rand si coloana. Din cauza ca SQL Server suporta mecanisme multiple de acelasi tip in tabelele publicate, mecanismele replicarii merge nu se interfereaza cu aplicatiile.

2.14. Procedurile stocate.

Agentul snapshot creeaza deasemenea proceduri stocate optionale care actualizeaza bazele de date subscrise. Cand datele sunt actualizate si noile inregistrari au nevoie sa intre in bazele de date subscrise, optiunile de proceduri stocate sunt folosite mai mult ca declaratii individuale de inserare, actualizare si stergere.
Cand agentul log reader intalneste declaratii de inserare, actualizare sau stergere marcate pentru replicare in conectarea tranzactiilor a unei publicatii de baze de date, el reconstruieste un rand din declaratia tranzactiei SQL din inregistrarea modificarilor de date. Apoi agentul log reader trimite declaratia tranzactiei SQL reconstruita la fiecare semnatar si aplica declaratiile tabelelor destinatie in fiecare baza de date destinatara. Acesta este un mecanism implicit folosit de SQL Server acolo unde sunt unul sau mai multi semnatari diferiti.
Daca toti semnatarii au instante ale SQL Server se pot inlocui declaratiile de inserare, actualizare si stergere din conectarea tranzactiilor cu optiuni de proceduri stocate pentru fiecare semnatar. Pentru fiecare tabela publicata exista trei cai prin care se pot manevra declaratiile (inserare, actualizare si stergere) detectate de agentul log reader in timpul procesului:
• Sa lasam mecanismele implicite ale replicarii sa lucreze;
• Specificarea ca nici o actiune nu va fi facuta la nici un semnatar. Tranzactiile de acest tip nu sunt replicate. De exemplu daca selectam inlocuirea declaratiilor de stergere cu proceduri stocate si nu introducem in loc nici o declaratie, declaratiile de stergere nu sunt replicate pentru acel articol;
• Specificarea unor proceduri optionale care pot fi apelate de toti semnatarii. Cand agentul log reader intalneste un astfel de tip de declaratie, intr-o tranzactie marcata pentru replicare, el construieste o apelare a unei proceduri stocata bazata pe aceasta sintaxa si deplaseaza valorile coloanelor la procedura stocata de referinta. Acesta este comportamentul default al SQL Server.

2.15. Tabelele sistem ale replicarii merge.

SQL Server adauga cateva tabele sistem la bazele de date pentru a sprijini urmarirea datelor, sincronizarea eficienta si conflictele de detectare, rezolutiile si rapoartele. Pentru fiecare modificare sau rand nou creat, tabela Msmerge_contents contine generarea in care au aparut cele mai recente modificari. Deasemenea contine versiunea unui intreg rand si toate atributele randurilor. Tabelele contin coloane ROWGUID pentru a se alatura tabelelor publicate.

Coloanele generate in astfel de tabele sunt ca un ceas logic indicand cand un rand a fost ultima data actualizat. Valorile actuale datetime nu sunt folosite pentru marcare cand apar modificari, sau conflicte de decizie si nu este nici o dependenta intre ceasurile sincronizate in diferite locuri (site). Aceasta face conflictele de detectie si algoritmii de rezolutie mai elastici la diferentele de ora ale zonelor si diferenta dintre ceasurile fizice de pe mai multe servere. La un loc dat, generarea numerelor corespund cu ordinea in care modificarile au fost facute de agentul merge, sau un utilizator din alt loc. Daca o tabela publicata are coloane rezervate pentru procesele merge, nu se va putea genera un snapshot initial din cauza coloanelor cu nume duplicate, numele de coloane rezervate sunt: reason_code, source_object, reason_text, pubid, conflict_type, origin_datasource.

2.16. Snapshotul initial si agentul snapshot.

Inainte ca un un semnatar sa poata primi incrementarea modificarilor de date de la editor, semnatarul trebuie sa contina tabele cu aceleasi scheme si date ca tabelele de la editor. Copierea completa a publicatiei de la editor la semnatar este aplicata apeland snapshotul initial, asa cum am explicat in capitolul anterior la replicarea snapshot.
Replicarea modificarilor de date apare doar dupa ce replicarea merge se asigura ca semnatarul are cele mai recente snapshoturi ale tabelelor de scheme si date care au fost generate. Cand snapshoturile sunt distribuite si aplicate asupra semnatarilor, doar acei semnatari care au nevoie de snapshotul initial sunt afectati. Semnatarii care au primit deja inserarile, actualizarile si stergerile, sau alte modificari asupra datelor publicate nu sunt afectati, numai daca subscrierea (aderarea) este marcata pentru reinitializare sau publicatia este marcata pentru reinitializare. In acest caz toate subscrierile corespunzatoare unei publicatii sunt reinitializate in timpul urmatorului proces merge.
O tabela de subscriere, poate subscrie doar la o singura tabela merge. De exemplu daca publicam o tabela de optiuni in doua publicatii, iar apoi suntem semnatari la ambele publicatii de la un semnatar, indicarea aceleiasi aderari la baza de date, vom primi date de la ambele publicatii. Unul dintre agentii merge va esua in timpul sincronizarii initiale.
Snapshotul initial poate fi o subscriptie atasata bazei de date in replicarea snapshot, replicarea tranzactionala, si replicarea merge. Daca folosim subscriptii de baze de date atasabile si subscriptia va fi copiata, ea nu va mai putea fi aplicata altui semnatar.
Agentul snapshot implementeaza snapshoturile initiale folosind aceiasi pasi ca agentul snapshot din replicarea snapshot (vezi pagina 6 ).

2.17. Agentul merge.

Dupa ce snapshotul initial a fost aplicat unui semnatar, mecanismele SQL Server vor incep sa urmareasca declaratiile de inserare , actualizare si stergere facute la editori si semnatari. Agentul merge urmareste la fiecare loc (site), cea mai mare generare de date care a fost trimisa celorlalte locuri si cea mai mare generare de date care a fost trimisa din alte locuri spre el. Aceasta ofera punctul de plecare, astfel incat fiecare tabela poate fi examinata fara a se uita la datele care sunt deja in alte locuri. Generarea stocarilor unui rand (row) trimis poate diferi intre diferite locuri, fiindca numarul locului reflecta ordinea in care modificarile au fost procesate in acel loc. Putem limita numarul de procese care lucreaza simultan prin setarea parametrului @max_concurrent_merge al sp_addmergepublication sau sp_changemergepublication. Daca numarul maxim de procese deja lucreaza, orice nou proces merge care apare va sta in asteptare pana ce alte procese vor fi terminate. Putem seta StartQueueTimeout in linia de comanda a agentului merge pentru a specifica cat timp agentul ar trebui sa astepte pentru ca celelalte procese merge sa se termine.

2.18. Sincronizarea.

Sincronizarea apare atunci cand editorii si semnatarii, intr-o topologie cu replicare merge se reconecteaza si modificarile sunt propagate intre ei, si daca este necesar, conflictele sunt detectate si rezolvate. In timpul sincronizarii, agentul merge trimite toate modificarile de date la semnatar. Datele se deplaseaza de la originea modificarilor spre locurile care au nevoie sa fie actualizate sau sincronizate. Daca numarul modificarilor trebuie sa fie controlate, agentul merge comanda linia de parametrii -;MaxUploadChanges si -; MaxDownloadChanges care pot sa fie configurate. In acest caz datele de la editor si semnatar converg doar atunci cand toate modificarile sunt propagate.
La destinatia bazelor de date, actualizarile propagate din alte locuri sunt comparate cu valorile, detectarea conflictelor si regulile de rezolutie. Un agent merge evalueaza valorile datelor primite si a celor curente, si orice conflict intre cele noi si cele vechi este rezolvat automat pe baza unui default resolver, care a fost specificat cand a fost creata publicatia sau unul optional. Replicarea merge ofera mai multe out-of-the-box custom resolver care pot fi setati dupa necesitati.
Modificarile valorilor de date sunt replicate spre alte locuri si converg cu modificarile facute in acele locuri doar atunci cand apare sincronizarea. Sincronizarea poate sa apara in cateva minute, zile, sau chiar la distante de saptamani si este definita in programarea agentului merge. Datele converg si se actualizeaza, din momentul ultimei sincronizari. Perioada de pastrare pentru sbscriere este specificata pentru fiecare publicatie si cum editorul si semnatarul vor fi sincronizati. Daca semnatarul nu se sincronizeaza cu editorul in perioada de pastrare, publicatia este marcata ca expirata si va trebui sa fie reinitializata. Perioada default pentru retinerea unei publicatii este de 14 zile.

2.19. Validarea permisiunii pentru semnatari.

SQL Server ofera posibilitatea de a valida permisiunea pentru un semnatar de a face descarcarile de modificari de date de la un editor. Aceasta verifica daca conectarea agentului merge are permisiunea de a efectua comenzi de inserari, actualizari si stergeri asupra bazei de date publicate. Validarea permisiunii necesita ca agentul merge conectat sa fie un utilizator valid cu permisiuni corespunzatoare asupra bazelor de date publicate. Validarea permisiunii este adaugata la verificarea daca conectarea utilizata de semnatar este in lista de acces a publicatiei (publication access list <P.A.L.>). Validarea permisiunii pentru un semnatar poate fi setata folosind proprietatea @check_permissions in sp_addmergearticle.
Valoare Descriere
0 (default) Permisiunea nu va fi verificata.
1 Verificarea permisiunii la editor inainte ca inserarile facute la un semnatar sa poata fi descarcate.
2 Verificarea permisiunii la editor inainte ca actualizarile facute la un semnatar sa poata fi descarcate.
4 Verificarea permisiunii la editor inainte ca stergerile facute la un semnatar sa poata fi descarcate.

2.20. Modelele fizice ale replicarii in SQL Server.

Fig4. Modelul editor si distribuitor -; semnatar.

Fig. 5 Modelul editor si distribuitor -; n semnatari.

Fig.6 Modelul legaturii intre doua servere editor -; semnatar.
Fig. 7 Modelul editor cu distribuitor indepartat

Fig. 8 Modelul semnatarului central.
Si dupa aratarea schemelor de principiu al diferitelor tipuri fizice ale replicarii, sa trecem in revista si cateva elemente descriptive ale acestora.
Replicarea din Sql Server poate fi folosit in diferite imprejurari si pentru diferite motive. Pentru a ne familiariza cu cazurile tipice in care se foloseste replicarea in continuare vom prezenta cateva scenarii de replicare aratand si arhitecturile reprezentative:
A. Un scenariu continand doua Sql servere, unul folosit pentru procesarea tranzactiilor online (Online Transaction Processing -; OLTP) si unul folosit ca depozit intr-un sistem de suport decizional (Decizion Support System -; DSS)
B. Un scenariu de replicare in care un server Sql, cu suport de procesare tranzactionala traditionala, replica informatiile catre un server Sql integrat cu un Web server. De acest scenariu ne vom ocupa mai pe larg in Capitolul IV, adica partea de implementare.
C. Un Wan (Wide Area network) cu servere Sql in fiecare locatie geografica, folosind replicarea pentru a consolida informatia fiecarei ramuri al retelei catre sediul central al coorporatiei.

A. Replicare catre un depozit de date (Data Warehouse)

Depozitele de date au devenit o activitate de interes sporit in ultimii ani. Prin adaugarea folosirii tehnologiei de suport pentru OLTP, sisteme informationale (Information Systems -;IS), oamenii de stiinta au descoperit ca o sursa separata de date, numit depozit de date (Data Warehouse) este cel mai bine organizat pentru a oferi suport pentru oamenii de stiinta si manageri in analiza datelor. Atata timp cat aceste doua functii au suportat la inceput doar o singura baza de date, aceasta arhitectura nu a functionat bine.
Pentru ca depozitul de date, in mod normal, este populat de informatii create original sau capturate de o baza de date OLTP, ideea folosirii replicarii pentru transferul informatiei selectate in depozitul de date se autosugereaza. La intervale regulate alese de catre administratorul bazei de date (DBA -; DataBase Administrator), informatia care a fost introdusa in baza de date al orgazinatiei poate fi copiata pe un server Sql separat.
Intr-o organizatie de mari dimensiuni pot exista mai multe servere Sql care pot opera la un nivel al departamentului si fiecare dintre ele poate replica date catre depozitul de date. In aceasta situatie, depozitul de date ar fi un semnatar ai mai multor servere de publicatie.

Fig. Replicarea poate fi folosita pentru a popula un depozit de date cu informatii primite de la un sistem OLTP

Scenariul din figura contine doua retele cu doua servere Sql. Primul suporta procesare de tranzactii. Are multi utilizatori, care introduc comenzi sau alte tipuri de informatii tranzactionale recurente (cerere de servicii de productie). Tranzactiile sunt in general de dimensiuni reduse iar timpul de rapsuns trebuie sa fie rapid pentru ca tranzactia in general trebuie procesata pe loc.
Informatia din acest server este replicata catre un al doilea server Sql, unde informatia este prelucrata pentru a-l pune sub o forma acceptabila pentru analize si alte activitati de suport decizional. Depozitul de date va stoca aceste date pentru o perioada mai mare de timp (pentru suportul analizei istorice), dar nu va avea nevoie de acelasi nivel de detaliu. Dierite componente (sume, medii, etc.) pot fi pre-calculate si stocate in baza de date pentru a creste viteza interogarilor care folosesc aceste functii. In plus, numarul utilizatorilor care acceseaza baza de date este mult mai mic, dar interogarile efectuate sunt mult mai complexe si necesita mai multe resurse computationale, cat si timp de executie mai mare.
In aceasta situatie datele de la sistemul OLTP vor fi replicate in aceeasi forma in care sunt stocate pe sistemul OLTP, dar pana este receptionat pe serverul semnatar, adica serverul pe care se gaseste depozitul de date, el va fi analizat in moduri diferite. Acesta este facut, de exemplu pentru a usura lucrul cu interogari analitice, cum ar fi spre exemple: „ Cum au evoluat vanzarile in al treilea sfert de an in comparatie cu al treilea sfert al anului precedent?” si pentru rezolvarea lor cat mai rapida. Astfel task-ul de sincronizare, care joaca un rol important in multe scenarii de folosire al serverului Sql, este mai putin critica in aceasta situatie.

B.Replicarea ca suport pentru integrarea serverelor de web

In plus la tehnologia Data Warehouse, un fenomen similar este si cea de interogare a unui server web la serverul Sql. Integrarea Sql server cu un server web are cateva din caracteristicile tehnologiei Data Warehouse -; face posibila pentru un grup anume de utilizatori sa foloseasca informatia din baza de date. Desi aceste doua tehnologii seamana mult unul cu altul exista totusi si diferente.
Aplicatia tipica de utilizare al cuplului web server si Sql server este acea de a face accesibila informatia printr-o interfata foarte usor de utilizat, utilizatorii fiind serviti, este in general mult mai putin sofisticata ca analistul care foloseste un depozit de date si nu necesita formularea unor interogari complexe, sau preia responsabilitatea formularii lor.
Cand un utlizator foloseste capatul unui web server, in general nu comunica direct cu serverul Sql, dar stabileste o legatura cu serverul web prin intermediul unui browser web (Fig. 2). Unul dintre avantaje este acela ca nu este necesara instalarea unui software pentru lucrul cu baze de date pe computerul clientului. Acesta este un mare avantaj daca doresti sa prezinti informatia unui grup numeros de utilizatori sau unor utilizatori care sunt in exteriorul intreprinderii, etc.

Fig. 2: Adaugarea unui server Sql pentru a asigura informatii de baza de date la un server web, creaza o combinatie puternica care poate solutiona un mare numar de nevoi

Primul motiv pentru folosirea replicarii in acest caz este acea de a nu supraancarca serverul OLTP cu raspunsurile interogarilor efectuate de catre serverul web. Pentru ca mentinerea serverelor OLTP la viteze de lucru ridicate si timpuri de raspuns marite este o cerinta critica. Chiar si lucrul de distribuire a datelor poate fi mutata de pe serverul OLTP, astfel incat efectul replicarii datelor sa fie minima. O data ce informatia a ajuns pe serverul semnatar, grija fata de neraspuns este mai mica. Depinzand de incarcare, cerintele de timp de raspuns si puterii folosite al hardware-ului, semnatarul poate fi chiar el serverul de web.
Merita amintit ca numarul serverelor web care sunt folosite pentru a oferi informatii clientilor este in continua crestere. Si in aceste situatii merita folosita replicarea pentru a imparti incarcarea intre doua servere Sql, dar neraspunsul web serverului inca ar putea fi un mod de ingrijorare.
In acest caz replicarea ajuta in aplicarea puterii a mai multor calculatoare pentru prelucrarea unor informatii in medii distincte.

C. Replicarea pentru o locatie centrala

Figura de mai jos ne infatiseaza una dintre folosirile clasice ale replicarii datelor -; o firmp cu mai multe sucursale si unsediu central. Informatia este introdusa intr-o baza de date Sql in fiecare din sedii. Aceste informatii sunt apoi copiate sau replicate automat in sediul central unde este supus prelucrarilor. Mai poate fi prelucrat si in continuare si chiar si replicat intr-un depozit de date al companiei.

Rezultatele pot fi apoi replicate inapoi catre filizale de pe siteul coorporatiei. Microsoft Sql Server suporta sa fie atat editorul informatiei replicate („publisher”), cat si semnatarul acestuia („subscriber”). Informatia consolidata poata fi replicata de-alungul zilei sau la ore bine stabilite, depinzand de natura datelor si de cererea la minut al acestuia. Astfel fiecare filiala va avea ultimele informatii accesibile pentru suportul activitatii lor.

Arhitectura specifica unei coorporatii de mari dimensiuni doua filiale si un sediu central

CAPITOLUL III

Replicarea in MySql

3.1 Introducere.

Intr-o baza de date distribuita , replicarea este procesul de copiere si mentinere a mai multor copii de date sau obiecte informationale in general.
Conceptele de distribuire si replicare sunt strans legate una de alta, pentru ca ultima face posibila vizionarea unei baze de date raspandita in mai multe puncte ca fiind un intreg global. Cu toate astea, replicarea ar trebui sa fie un process transparent pentru end useri (aplicatii client), pentru a satisface termenul de intreg. In alte cuvinte, acest mecanism ar trebui sa fie complet transparent utilizatorului. Cand acest lucru este asigurat ptem spune ca s-a respectat termenul de transparenta al replicarii.
In lucrearea de fata se doreste a fi demostrat modul in care MySql implementeaza si foloseste replicarea si felul in care acest lucru se poate incadra in modelul de transparenta al replicarii.

3.2 De ce replicare?

Replicarea este procesul de copiere si mentinere a datelor in mai multe baze de date ce alcatuiesc baza de date distribuita.
In pimul rand, ideea principala din spatele replicarii este aceea ca o operatie de reamprospatare este efectuata mai intai local, dupa care este propagata unei alte remote replica database (replica bazei de date la distanta) apartinand unui singur sistem complet (care devine distribuita).
Teoretic, presupunand ca nu sunt intarzieri datorita sincronizarii si conflicte ale tranzactiilor de reamprospatare, acest sistem va asigura utilizatorului un mod rapid si constant de regasire a informatiei cu acces alternativ la date.
Couloris si Dollimore (DISTRSYS88) imparte caracteristicile replicarii in urmatoarele:
• sporire al performantei
• sporire al disponibilitatii
• consistenta
• transparenta replicarii

3.2.1 Sporirea performantei

Nevoia replicarii se dovedeste in cazul in care un singur sistem de baza de date are de a face cu un numar sporit de operatii de citire din parte clientilor pe care nu le poate poate satisface in timp util. Impartirea datelor stocate cu alte replici, inseamna distribuirea (impartirea) traficului, care la-nceput a fost dirijat catre un singur server, numit fenomen de stamtoare (fenomen bottleneck), catre mai multe destinatii. Astfel pot fi numai beneficii atata timp cat ne ingrijoreaza timpul de raspuns pentru cererile fiecarei aplicatii. Sporirea performantei este mai vizibila in cazurile in care exista mai multe operatii de citire decat operatii de reamprospatare. Acest lucru poate fi verificat usor, prin verificarea raportului citire/reamprospatare(read-update ). Cu cat acest numar este mai mare, cu atat imbunatatirile aduse prin folosirea unui sistem de replicare este mai mare.
Imbunatatirile aduse timpului de raspuns pot fi mai mari daca sistemul detine o interfata inteligenta fata-spate (front-end), care poate sa schimbe cererile catre o anume baza de date distribuita, depinzand de locul unde se gaseste clientul.

3.2.2 Sporire al disponibilitatii si al robustitatii

Repliarile ofera un mare avantaj al disponibilitatii si robustivitatii al serviciului catre aplicaiia client, si astfel catre utilizator (end-user). Cu cat un sistem distribuit are mai multe replicari, cu atat riscul de a avea eroare la raspuns scade mai mult. Sigur acest lucru depinde de interfata front-end, ca acesta sa faca trecerea la alta sursa de date cand una dintre ele nu este disponibila.

3.2.3 Consistenta

Intr-un sistem distribuit, cu replicari, consistanta este capacitatea diferitelor baze de date replicate sa dea acelasi rezultat la aceeasi cerere facuta de clienti, intr-un timp bine stabilit, privind acelasi set de date logice.
Acest concept sufera o schimbare cand trebuie transformata intr-un sistem real. Cand datele sunt reamprospatate pe o baza de date locala, replicaea trebuie sa fie sincronizata. Acest proces de propagare poate fi realizata in doua feluri:
• sincron
• asincron
Procesul de propagare sincron este realizata prin procesarea ordonata a cererilor facute sistemului distribuit. Toate replicile sunt reamprospatate ca tranzactii consecvente si tranzactiile urmatoare sunt blocate pana nu sunt terminate cele dinainte. Modelul sincron este capabil sa mentina compatibilitatea sistemului., dar performanta este redusa datorita blocarii.
In modelul asincron, propagarea datelor dupa reamprospatare nu este realizata de-ndata, ci are o intarziere care poate varia de la un tip de arhitectura la alta. Oricum in acest model, se poate intampla ca un client sa acceseze datele unei replicari, care inca nu este reamprospatata. Astfel consistenta nu este garantata, dar performantele sunt.

3.2.4 Transparenta replicarii

Transparenta intr-un sistem distribuit este menit sa ascunda arhitectura si mecanismul sistemului prin care se realizeaza comunicarea cu clientul, facandu-l pe acesta sa perceapa sistemul ca un tot unitar si nu ca un ansamblu de diferite elemente.
Cand este aplicat replicarii, transparenta are rolul de a ascunde orice replicari din sistem. Acest lucru este realizat prin folosirea unei interfete intre client si sistem, numit fata-spate (front-end ).
Mecanismul front-end schimba mesajele care vin de la aplicatia client catre un maneger de replicari (replica-manager) (in cazul MySql acest manager este insasi mysqld), depinzand de multe criterii, care asigura ca mecanismele front-end opereaza independent unul de altul: in particular, arhitectura care sta la baza sistemului, tipul operatiei (citire / scriere), originea, etc.

3.3 Modelul master copy

Inainte de descrierea modelului master copy, cunoscut si sub numele de primary copy model, sa introducem un alt concept care sta la baza intelegerii replicarii, modelul arhitecturii de baza (basic arhitecture model), care are rolul de a dirija replicarea intr-un sistem distribuit.
In cadrul modelului arhitecturii de baza, cum descrie Couloris si Dollimore (DISTRSYS94), este posibil sa avem trei caractere:
• o aplicatie client
• o aplicatie front-end
• un manager de replicari
Cererea vine din partea clientului, care poate cere atat citire cat si reamprospatare (macar o operatie de scriere). Aceste cereri nu sunt dirijate direct de catre managerul de replicare, ci de un nod intermediar numit front-end.
Un manager de replicari este un proces care contine o replicare si efectueaza operatii direct asupra lui. Astfel conceptul de manager descrie un proces, o aplicatie, mai degraba ca un server, ceea ce face din model unul abstract si mult mai la-ndemana in majoritatea cazurilor.
Depinzand de modelul ales, modul in care front-end-urile si managerul de replicare comunica intre ele, se schimba.
In modelul master copy, conceptul de baza este aceea ca cererile de reampropatare sunt toate dirijate de procesele front-end catre un master sau primary server (server primar), unde cererile de citire sunt distribuite intre celelalte replicari, numite slaves (sclavi).

Fig. 3.1 Clienti, front-end-uri si manageri de replicare in modelul master copy
Unde:
FE = front-end
RM = remote
C = client
In aceasta arhitectura, in general nu se foloseste blocarea in timpul reamprospatarii care poate duce la contradictie de sistem. Pe langa acestea, riscul cel mai mare al modelului master copy, este aceea ca daca cpnexiunea cu serverul principal cade, atunci celelalte replicari vor genera expirare.

3.4 Replicarea Master-Slave

Replicarea in MySql este inca un lucru nou si in continua dezvoltare. Dar oricum modelul ales etse Replicarea master -; slave: de obicei intr-o baza de date distribuita, un server de baze de date MySql se comporta ca server primar, avand in vedere ca alte servere de replicatie se comporta ca sclavi (slaves).
Cum am mai subliniat deja, in MySql, nu exista aplicatie front-end, care in mod exclusiv sa dirijeze taficul de la client in sistemul distribuit. Teoretic orice replicare poate avea un punc de acces la client. Mai mult managerul de replicare este MySql serverul in sine, care prin folosirea thread-urilor dirijeaza replicarea. Din aceasta cauza vom substitui termenul de manager de replicare cu master si slave servere.
Cum agentii front-end lipssesc din MySql lipsesc (cu toate ca dezvoltatorii afirma ca doresc ca in verziunile urmatoare sa introduca cateva procese agent care sa monitorizeze traficul), transparenta replicarii din MySql nu este acordata de insasi serverul MySql, si de-asemanea consistenta datelor poate fi compromisa daca privilegile tabelelor si baze de date nu sunt corect setate.
Propagarea reamprospatarii este bineanteles intr-un singur sens, dinspre serverul master catre serverele slave, prin folosirea si salvarea informatiei si informatiilor de timp intr-un fisier log pe serverul primar. Atata timp cat nu exista si o comunicare in sens invers, adica dinspre slave catre master, poate aparea un caz foarte rau de inconsistenta a datelor, datorita unei reamprospatari catre un slave in loc de un server primar. Din acest motiv, setarea privilegilor devine critica in acest sistem.
Deci modelul master copy va suporta o mica schimbare, cu toate ca aceasta nu inseamna ca in MySql nu poate sa atinga transparenta in replicare.

3.5 O propunere pentru transparenta replicarii sistemelor distribuite MySql

Asa cum este ea, MySql nu ofera elementele obtinerii transparentei replicarii intr-un mediu distribuit, as dori examinarea unei situatii des intalnite al folosirii al acestui soft gratuit, pe Internet.
Astfel avem cateva lucruri prestabilite:
• o baza de date MySql sa poata fi interogata pe internet, folosind replicarea
• raportul citire / reamprospatare arata un numar de interogari care nu vor fi reamprospatate, mai mare decat numarul reamprospatarile
• reamprospatarile sunt efectuate doar de un numar restrans de persoane prin utilizarea unei aplicatii Intranet
• citirile sunt efectuate prin Internet prin vizionarea unui site
• interfata Internet catre baza de date este o aplicatie server care se gaseste pe serverul HTTP gazda

Fig. 3.2 O propunere pentru transparenta replicarii sistemelor distribuite MySql unde:
FE = front-end
MySqld = manager de replicare
HTTPd = server HTTP
C = client
Ideea principala este aceea de a trimite toate operatiunile de reamprospatare catre un server primar si distribuirea citirilor printre serverele slave. Avand aceste replicari, se pot spori performantele. Dar ce se intampla, ca MySql nu ofera aplicatie front-end?
Solutia este construirea unor aplicatii front-end care se gaseste intre web server si sistemul distribuit (vazut ca o colectie de servere MySql), acestea ar putea fi procese de sine statatoare care sa dirijeze intrarea in sistemul distribuit, sau o aplicatie care ruleaza pe server, care este invocat de catre utlizator prin intermediul browserelor.
Cat despre aplicatiile care ruleaza pe server, acest program poate fi scris folosind limbaje de script, cum ar fi: PHP sau ASP, sau prin intermediul programarii CGI, sau folosind tehnologia serverului de aplicatii (Application Server Technology), spre exemplu JSP.

3.6 Concluzii

Este de notat ca dezvoltarea MySql este in continua dezvoltare catre un sistem distribuit robust. Nu este deci o coincidenta ca se doreste construirea unui mecanism de replicare mult mai complex si mai sigur, care ar asigura si trecerea la alt master in caz ca are loc o eroare.
Oricum, o trasatura interesanta va fi cu siguranta introducerea proceselor agent care sa fie capabila sa dirijeze traficul, prin balansarea incarcarii si trimiterea de cereri select catre serverele slave.
Din cauza mecanismului destul de nesigur si inca intr-un stadiu de continua dezvoltare, pentru lucrarea practica am ales implementarea bazei de date cat si a replicarii folosind Microsoft Sql Server 2000, datorita modulelor de securitate implementate, cat si prin securitatea transferului de date, siguranta replicarii, cat si transparenta acesteia.

CAPITOLUL IV

4.1. Prezentarea cerintelor aplicatiei.

Se prusupune existenta mai multor filiale ale unei agentii de publicitate in mai multe orase. La fiecare filiala se va preia mica si mare publicitate, care se vor stoca intr-o baza de date locala. Aceste publicitati vor putea fi vizionate prin intermediul Internetului, pr site-ul firmei. Astfel apare nevoia de folosire a replicarii pentru implementare, pentru ca serverul de baza de date pe pe serverul web trebuie sa aiba acces la toate publicitatile predate in oricare din orasele in care se gaseste o filiala a firmei. La predarea publicitatii exista doua metode:
• Predarea unei prezentari dinainte facute, caz in care calcularea costului implica numai numarul de slide-uri ale prezentatiei
• Redactarea pe loc, caz in care are loc redactarea publicitatii ca text, dupa care acesta este salvata ca fisier o prezentare PowerPoint. La acest mod, la calcularea platii, in afara de taxa pentru numarul de slide-uri, se mai impune si o taxa de redactare, care este calculata dupa numarul de cuvinte redactate.
Publicitatea poate sa contina si elemente multimedia, din aceasta cauza stocarea informatiei se va face in format PowerPoint. Publicitatea va fi divuzata atat in reteua Tv Cablu cat si pe site-ul firmei.
Pentru a demostra lucrul cu baze de date Microsoft Sql Server, in cadrul programului s-a omis folosirea procedurilor stocate, cu toate ca acestea au o viteza de executie mai mare si implica o rata de transfer a informatiei mult mai mica.

4.2 Prezentarea bazei de date

Din cauza ca programul contine si un modul de securitate, cu restrictionarea accesului, se vor folosi doua baze de date:
• publicitate: se vaor menora datele referitoare la publicitate
• utilizatori: se vor