Page 1

Replicarea n MySQL
Monash University, CSE3002 Distributed Computing
Sisteme - Lectori: Peter Granville i Arkadi Zaslavsky
Gabriele Bartolini (ID 18316719)
angusgb@users.sf.net
Prato
PO
Italia
Declaraie
Certific c acest lucru nu ncorporeaz fr confirmare nici o material publicate sau n scris de ctre o alt persoan n cazul n care de referin, datorit
anterior
nu se face n text.
n fede, Gabriele Bartolini
Universitatea Monash, Australia
05 septembrie 2001
Cuprins
Introducere ........ .................................................................................................................
..3
De ce
replication?............ .......................................................................................................3
Copia de master
model............... .........................................................................................5
Master / slave, modelul de replicare adoptat de MySQL ............... ......................... .....
6
O propunere pentru un transparen replicare sistem distribuit n siguran cu
MySQL. ..6
Conclusions.......... ................................................................................................................
..7
Referinte ........ ......................................................................................................................
7
Page 2
Page 3
Introducere
ntr-un sistem de baze de date distribuite, replicare este procesul de copiere i apoi
inerea
Taining mai multe copii ale datelor sau obiecte de informare n general.
Conceptele de baze de date distribuite i replicare sunt puternic legate, pentru c
din urm o face posibil pentru a vedea o grmad de baze de date de propagare ca un
ntreg unul global;
astfel, replicarea trebuie sa fie un proces ascuns pentru utilizatorul final (aplicaii client)
de o
sistem de baze de date, n scopul de a acorda validitatea ntregului termen.

Cu alte cuvinte, acest mecanism ar trebui s funcioneze ntr-un mod complet transparent
pentru
Utilizatorii; cnd acest lucru este realizat, putem presupune c funcia este respectat:
replicare
transparen.
Ca si iubit de software liber i dezvoltator mic, am ales s trateze aceast funcie prin
avnd n vedere una dintre cele mai populare DBMS-uri disponibile astzi software ca
liber: MySQL
[MYSQL], precum versiunea curent de astzi (3.23.41).
n aceast lucrare, a dori s demonstreze ct de MySQL implementeaz i se ocup de
replicarii
cation, care arhitectural model este prevzut i n general modul n care aceasta se
ncadreaz n replicare
facilitate transparen TION. A dori, de asemenea, s scrie n jos un design simplu
pentru a fi utilizate
pe un scenariu Internet, cu aplicatii server-side care ruleaz pe un server web i
interfaare cu un sistem distribuit transparent MySQL.
De ce replicare?
Replicarea este procesul de copiere i meninerea obiecte baz de date n baze de date
multiple
care alctuiesc un sistem distribuit de baze de date [ORACLE33].
Practic, ideea principal din spatele replicare este c se efectueaz o operaie de
actualizare
n primul rnd la nivel local, apoi propagat la alte baze de date la distan replica
aparinnd unui singur
ntreg sistem (prin urmare, care devine distribuite).
Teoretic, presupunnd c nu exist ntrzieri datorate de sincronizare i nici o actualizare
conflicte tranzacii, acest sistem ar asigura utilizatorul final o rapid i consistent
mod de regsire informaii cu disponibilitate ridicat (datorit accesul la date alternativ).
Couloris i Dollimore [DISTRSYS88] rezuma motivaiile pentru replicare n
dup cum urmeaz:

Accesoriu de performan

Disponibilitate mbuntit

Consisten

Transparen Replication
Accesoriu de performan
Nevoia de replicare are loc atunci cnd un sistem de baze de date unice trebuie s se
ocupe de mai multe
citeste operaiuni de clienti care nu se pot servi intr-un timp eficient; schimbul de date
stocate cu alte replici, ar nsemna, de asemenea, distribuirea traficul care a fost iniial
direcionat ctre un singur server de (fenomen blocaj) ctre mai multe destinaii: nu se
poate

fi doar beneficii n ceea ce privete timpul de rspuns pentru fiecare cerere de aplicare
este n cauz.
Accesoriu de performan este mai mare n ansamblu ntr-un scenariu n care exist mai
citite
operaii sunt mai mult dect actualizri: acest lucru poate fi realizat destul de uor de
verificarea ra3
Page 4
Replicarea n MySQL
tio citire / actualizri; mai mare acest numr este, cu att mai multe mbuntiri nu poate
fi de
de adoptare a unui mecanism de replicare.
mbuntirile n timp de rspuns poate fi mai mare n cazul n care sistemul are o
inteligent front-end
sau interfa care poate trece cerere la anumite serverul de baze de date distribuite
(destinaie
II), n funcie de originea clientului. Aceste aspecte vor fi considere mai trziu n
aceast lucrare.
Disponibilitate i robustee mbuntit
Reproduceri ofera un avantaj mare n ceea ce privete disponibilitatea i robusteea
serviciului
pentru aplicaiile client, i, prin urmare, pentru utilizatorul final. Este de la sine neles c
mai multe replici sistemul nostru are, mai puin probabil este pentru client de a avea un
eec
rspuns; desigur, acest lucru depinde de capacitatea de front-end pentru a trece la un alt
surs de date atunci cnd unul dintre ei nu este accesibil.
Consisten
ntr-un sistem de baze de date distribuite cu replicare, consecven este capacitatea de
difebaze de date replica ENT pentru a da aceleai rezultate la acelai solicitarea efectuate de
ctre clieni,
la un moment exact i n ceea ce privete acelai set logic a datelor.
Acest concept are de a face cu un compromis atunci cnd trebuie s fie transpus ntr-un
sis- real
TEM; atunci cnd datele sunt actualizate pe o baz de date local, replici trebuie s fie
syncronised. Acest
proces de propagare se poate face n dou moduri:

sincron

asincron
Prima modalitate devine posibil printr-o prelucrare ordonat a cererilor fcut
la sistemul distribuit; toate replici sunt actualizate ca tranzacii consistente, i urmeze
cererile urm- sunt "blocate" pn la cele precedente sunt efectuate. Modelul sincron este
capabil s menin coerena sistemului, dar, desigur, performanta este

redus cu ncuietori.
n modelul asincron propagarea de date dup actualizri, nu se face imediat
ci are o ntrziere care poate varia de la o arhitectur la alta. Oricum, n
acest model, se poate ntmpla ca un client ar putea accesa o date de la o replica, care a
fost
nu nc actualizate. Prin urmare, Coerena nu este garantat, n timp ce performanele
sunt.
Transparen Replication
Transparena ntr-un sistem distribuit, n general, este proprietatea de a ascunde archicturii i mecanismele de un sistem de utilizatorul final, n scopul de a lsa s-l perceap
ca un ntreg, mai degrab dect un ansamblu de elemente diferite.
Atunci cnd se aplic la replicare, transparen i propune s se ascund de utilizator cu
privire la orice replicarii
cas din sistem. Acest lucru se realizeaz prin utilizarea unei interfee ntre client
i sistemul: front-end.
Front-end switch mesajele provenind de la aplicaiile client la o dup
caz replica-manager (n MySQL managerul replica este serverul mysqld n sine),
in functie de mai multe criterii, care asigur faptul c fa-capete funcioneaz diferit
4
Page 5
Replicarea n MySQL
una de alta: n special, architecure de baz a sistemului, de tipul de
operaie (citire / scriere), originea, etc.
Din pcate, MySQL nu are o aplicaie front-end sau proces capabil s gestioneze o dissistem contribuit, ceea ce ar putea acorda transparen la clienti.
Modelul copie de master
nainte de a descrie maestru modelul de copiere, de asemenea, cunoscut sub numele de
model exemplar primar, vreau s introduce modelul arhitectural de baz pentru gestionarea replicare ntr-o baz de date
distribuit
sistem.
In modelul arhitectural de baz, aa cum este descris de ctre Couloris i Dollimore
[DISTRSYS94],
este posibil s aib trei caractere:

o aplicaie client

o aplicaie front-end

un manager de replica
Cererea vine din partea clientului, care poate fie implic citi (read-only operaiune
II) sau modificare (cel puin o operaie de scriere) tranzacii pe date logice; aceste
cereri
nu sunt gestionate direct de ctre managerul replica, mai degrab de un nod de mijloctier, denumit

n fa.
Un manager replica este un proces care conine o replica i efectueaz operaiuni direct pe ea (Couloris i Dollimore [DISTRSYS94]): conceptul de administrator decrturari, prin urmare, un proces, o cerere mai degrab dect un server, care face
abstract model i de mult mai adecvat n majoritatea cazurilor.
n funcie de modelul ales, de modul n front-end i managerii replica comunic
nicate ntre ele se schimb.
n modelul copie maestru, conceptul de baz este c cererile de actualizare sunt toate n
regia lui
front-end la un maestru sau un server primar, n timp ce citii cererile sunt distribuite
ntre
alte replici, numit sclavi.
Figura 1. O prezentare general a clienilor, front-end i managerilor replica n
comandantului sau primar
Modelul copie.
n aceast arhitectur, care vine de la Soare Yellow Pages service, de obicei, nu exist
nici o
blocare n timpul propagarea de actualizri, ceea ce poate duce la un sistem inconsis5
Page 6
Replicarea n MySQL
tency. n plus, riscul principal al modelului de copiere principal este faptul c, pentru
orice motiv,
comunicarea cu serverul principal eueaz, alte replici sunt prestate out-of-data.
Cu toate acestea, modelul exemplar primar este modelul de replicare utilizat n MySQL.
Master / slave, modelul de replicare adoptat de MySQL
Replicarea n MySQL este un lucru destul de nou, i este nc n curs de dezvoltare
continu
ment; Cu toate acestea, modelul care a fost ales este master / slave una din urmatoarele:
practic, n
un sistem distribuit, un server de baze de date MySQL acioneaz ca primar ntruct alte
replica
servere acioneaz n calitate de sclavi.
Dup cum am subliniat deja, din pcate, n MySQL nu exist front-end aplicare
cationi, care pot gestiona exclusiv traficul de la client n distribuite
sistem; teoretic fiecare replic ar putea avea un punct de acces pentru client. Mai Multpeste, managerul replica este serverul MySQL n sine, care, prin fire, de om
replicare vrstele; de aceea termenul de administrator replica va fi substituit cu
servere master i slave.
Ca front-end nu sunt puse n aplicare (chiar dac dezvoltatorii MySQL spune c n
versiunea 4.x
acest lucru se va face, prin emiterea unor ageni de procese de monitorizare a traficului),
replicare
transparena nu este acordat de MySQL n sine, precum i, de asemenea, coerena datelor
poate fi re-

aliat compromis dac privilegii pe tabele i baze de date nu sunt setate corect (de fapt,
ele trebuie s fie forat s "joace" ca read-only instantanee).
ntr-adevr, actualizri propagare merge doar ntr-o direcie, de la comandantul la
serverele slave,
prin utilizarea i salvarea informaiilor i amprente de timp ntr-un jurnal binar pe
primar; ca
timp ct nu exist nici o napoi comunicare ntre sclav i master, acolo
poate fi un caz foarte proast a inconsecven a datelor, din cauza unei actualizare
efectuate la un sclav
n loc de un primar. De aceea, configuraia privilegiilor devine crucial
n acest sistem.
Astfel, scenariul de la modelul de copiere primar schimb un pic; chiar dac acest lucru
nu
nu nseamn c MySQL nu se poate realiza transparena n replicare.
O propunere pentru un transparen replicare sistem distribuit n condiii de
siguran
cu MySQL
Avnd n vedere MySQL n sine nu ofer elementele pentru realizarea replicare transtransparenei ntr-un mediu distribuit, a dori s examineze un caz foarte frecvente
de utilizare pe Internet a acestui SGBD software gratuit.
Acestea sunt premisele pentru cazul de studiu:

o baz de date MySQL pentru a fi puse la dispoziie pentru interogarea pe Internet prin
intermediul replicarii
cation;

citete / actualizri raport prezinta o serie de interogri de baz non-actualizare sensibil

mai mare dect
actualizri;

actualizri sunt efectuate doar de un set restrns de utilizatori prin intermediul unui
Intranet aplicare
cation;

citete sunt efectuate de ctre utilizatorii de Internet a unui site;

interfaa Internet la baza de date este o aplicaie server-side care se afl pe

Gazd server HTTP.
6
Page 7
Replicarea n MySQL
Figura 2. O propunere de sistem sigur de transparen replicare distribuite cu MySQL.
Ideea principal este de a trimite toate operaiunile de actualizare la un server primar, i
pentru a distribut citete printre sclavi; avnd n aceste replici pot spori performanele,

dar ce se ntmpl dac MySQL nu ofer un front-end pentru sistemul distribuit?

Soluia este de a construi aplicaii front-end inteligente care locuiesc ntre
server web i sistemul distribuit (vzut ca o colecie de servere MySQL); acestea
ar putea s fie un proces independent de gestionare punctele de intrare ale distribuite
sistem, sau aplicaia server-side invocat de ctre utilizator de browser.
Lund n considerare cazul de aplicare server-side, acest program poate fi scris prin
utilizarea
Limbi script, cum ar fi PHP sau ASP, prin programare CGI sau prin utilizarea
Tehnologia server de aplicaii (de exemplu JSP).
Concluzii
n ateptare pentru echipa MySQL dezvoltator pentru a construi un produ- sigur
transparen replicare
UCT, ntr-o vedere mai distribuit, lucru n jurul a folosind un ad-hoc front-end aplicare
cation ar putea fi o soluie.
Cu toate acestea, este foarte vizibil c dezvoltarea MySQL se va spre o mai
sistem robust i distribuite; aceasta nu este o coinciden faptul c se fac eforturi n
Pentru a construi un mecanism mai sigur i mai complex de replicare, permind de
exemplu
introducerea unui algoritm de vot posibilitatea de a trece la un alt maestru dac ceva
nu merge bine.
Oricum, caracteristica cea mai interesanta noi vor fi cu siguran introducerea de agent
procese care vor putea s gestioneze traficul, prin echilibrarea sarcina i trimiterea
selectai interogri pentru diferite sclavi.
Referinte
[DISTRSYS88], "sisteme distribuite: Concepte si amenajari", Coulouris George i
Dollimore cu Jean - Addison Wesley, 1988
[DISTRSYS94], "sisteme distribuite: Concepte si amenajari", Capitolul 11 - Replication,
Coulouris George i Dollimore cu Jean - Addison Wesley, 1994
[MYSQL], site-ul web MySQL, http://www.mysql.com