Replicarea bazelor de date - Articol Blog Michael flonova

Replicarea - nu este doar un cuvânt nou buzz, acesta este un instrument destul de convenabil și puternic în mâinile lustruit în mod corespunzător. Unii cred că replicarea - este sinonim cu sincronizare. Dacă te uiți la ABBYY Lingvo, atunci nu se va vedea sincronizarea între traduceri posibile ale replicării cuvântul, dar sunt cuvinte, cum ar fi: ecou, ​​o reflecție, duplicare, repetiție, reproducere. Aceste cuvinte reflectă bine tehnologia și ceea ce noi considerăm astăzi.

Publisher-distribuitor-abonat

Cel mai adesea asociată cu replicarea bazelor de date si vom vorbi in principal despre bazele de date cu privire la exemplul de MS SQL Server. Și nu numai cu bazele de date clasice, dar o astfel de specialitate ca Active Directory. Dar această lume nu este răsturnată, replicarea poate fi folosit cu succes pentru fișiere simple, cel mai important, abordarea corectă.

Replicarea în MS SQL Server bazate pe trei concepte - editor. distribuitor și abonat. Pentru a înțelege ce înseamnă acest lucru, este suficient să se întoarcă la viața noastră reală, în cazul în care editorul oferă unele informații distribuitorului, care îl trimite către abonați. În mod similar, în viața de calculator. Dar, mai întâi lucrurile primele.

Distribuitor - un server de baze de date care conține și stochează un distribuite metadate, datele și istoricul tranzacțiilor. Rolul distribuitorului poate fi diferit și depinde de tipul de replicare desfășurate.

Distribuitor și Publisher poate fi pe același computer. Cel mai adesea, nu are nici un sens să aloce pentru fiecare server în parte, dar pentru site-uri de baze de date și cele mai active mari, distribuitorul poate fi plasat pe serverul dvs. pentru a optimiza performanța.

Abonat - deține o copie a datelor, și primește modificările făcute de către editor. În funcție de setările de replicare, abonatul poate avea dreptul de a modifica datele și să le reproducă la editor pentru replicare altor abonați. Aceasta se numește reînnoire abonat.

filtre Bazaar

Filtru orizontală cuprinde un subset de rânduri din tabel. Abonatul primește doar subsetul de rânduri. În cazul în care nu este necesar de a reproduce informații despre veniturile din stânga, atunci este posibil pentru a filtra interogarea.

Posibilitatea de a semna la publicarea folosind Push și metoda Pop. Metoda Push este utilizată în mod obișnuit în aplicații care au nevoie pentru a trimite modificările la abonat, cât mai curând posibil după schimbarea. Această metodă este mai preferată pentru publicații care necesită înaltă securitate și în cazul în care o sarcină de mare procesor de la distribuitor nu afectează performanța.

Metoda Pop este mai potrivită în publicații cu mai puțin sigure și poate suporta un număr mare de abonați, precum abonații la Internet.

tipuri de replicare

• date variază considerabil, dar rar;
• datele de abonat este necesară pentru read-only;
• Acesta poate fi o lungă întârziere, deoarece datele sunt actualizate, de obicei numai periodic;
• abonatul este necesară o autonomie.

Atunci când reproducerea tranzacțională de la sursa numai modificările vin la receptor. Agentul monitorizează schimbările în jurnalul de tranzacții privind modificarea datelor replicată și transferă înregistrarea distribuitorului necesar. Distribuitor Agent trimite modificări la abonat. Înainte de acest tip de înceapă să lucreze, abonatul este trimis un instantaneu complet al tabelului replicat, iar apoi abonatul primește doar modificările.

replicare tranzacțională poate fi utilizată în cazul în care este necesar să se schimbe abonatul a primit cu întârziere minimă.

Amestecarea - acest tip permite site-uri autonome să modifice datele replicate. Modificările aduse ulterior site-urile de îmbinare într-una singură. Acest tip nu garantează integritatea tranzacției, dar se asigură că toate site-urile sunt unite într-un singur set de rezultate.

Replicarea MS SQL Server

Foarte bine făcut pentru a reproduce în MS SQL Server. Setarea simplu ca un ban, pentru că este ușor de a face cu ajutorul a doi stăpâni, dar există capcane, pe care expertul nu poate spune, și manuale doar silențioase. Deci, să trecem pe scurt asupra procesului de replicare de configurare și se va concentra pe pietre subacvatice, dintre care toate sunt tăcut ca un pește.

În primul rând avem nevoie pentru a crea un editor și distribuitor. Pentru a face acest lucru pe un server, selectați Instrumente | replicarea | Creați și gestionați publicare. Mi-ar recomanda să folosească o mașină mult mai puternic pentru editor. Primul lucru pe care îl cerem expertul - selecta baza de date. Alegeți, faceți clic pe Creare publicare. și următoarea fază a serverului vă solicită să creați un distribuitor. distribuitor implicit invitat să facă aceeași mașină.

Expertul solicită crearea distribuitorului replicare

Configurarea contului MS SQL Server Agent

După aceea, vi se va oferi pentru a configura agentul însuși manual sau automat. Dacă selectați modul manual, numărul de pași expertul brusc, dar acestea sunt simple și cu cunoștințe minime de limba engleza pe care le va înțelege. Dacă selectați automată, puteți specifica doar tipul necesar de replicare de master - un instantaneu (publicarea Instantaneu), tranzacție (publicare tranzacție) sau amestecare (Merge publicare) și specificați tabelele necesare. Da, replicare nu participă la întreaga bază menționată și de masă. Nu este nevoie de a reproduce tabelele de sistem.

Alegerea tipului de replicare

După ce creați editor și abonat, trebuie să creați setarea este completă. În timpul creării unui abonat, puteți ajusta planul de implementare de zile specificate sau intervale de timp, prin care aveți nevoie pentru a reproduce.

Cheia de Aur

Următoarea problemă pe care s-ar putea întâlni - Replicarea domenii-cheie. În cazul în care aveți tipul de GUID, atunci nici o problema nu va fi aici, dar dacă identitatea, atunci se va confrunta cu probleme serioase. Faptul este, care crește în mod automat câmpurile nu pot fi reproduse corect cu setările implicite, mai ales când este amestecat în cazul în care abonatul poate modifica datele și trebuie să fie în măsură să le revină editorului.

Să presupunem că cele două calculatoare sunt două înregistrări diferite, cu aceiași identificatori au fost create, serverul ce să fac? Pe care să aleagă înregistrările? Ideea este că, în tabelul de rezultat ar trebui să obțineți două intrări, dar nu se poate schimba ID-ul, mai ales în cazul în care masa este asociată, și două intrări cu aceeași cheie nu este posibilă.

Problema este rezolvată destul de simplu, trebuie doar să efectuați următorii pași:

• 1. Creați o copie a bazei de date editor pe calculatorul abonatului.
• 2. Deschideți tabelul de ferestre de editare, sau utilizând o interogare SQL pe editor pentru a seta valoarea inițială a tasta 1, iar pentru abonatul de 1 milion.

Totul este simplu și frumos. Acum, când o înregistrare se adaugă la editorul noua înregistrare va fi numerotate de la 1, 2, 3, 4 și pe Abonatul 1000001, 1000002, 1000003. Astfel, înregistrarea nu va intersecta în curând și de conflict nu poate avea loc, în special în cazul în care înregistrările nu sunt adăugate la tabel prea intens. În cazul în care intrările se adaugă rapid, apoi să renunțe și de a folosi câmpul autogrow GUID ca o cheie.

Dar asta nu e tot. Când creați un abonat, vi se va oferi pentru a transfera întreaga schemă a editorului. Acest lucru este util în cazul în care structura de tabele diferite, și pe care doriți să le sincronizați, dar în acest caz este inacceptabil. Dacă conduc la această propunere și răspunsurile la Da, editorul schemei vor fi copiate pe abonat și atât valoarea inițială va fi unitatea-cheie, precum și toate eforturile tale transforma în cenușă, adică zatrutsya. Pentru a preveni acest lucru, și bucurați-vă de PUSH Nu, principalul lucru pe care la structura tabelelor de abonat este aceeași cu cea a editorului.

pornire manuală replicare

Replicarea Active Directory (AD)

Active Directory, care este utilizat în mod activ de servere Windows - este, de asemenea, o bază de date. Acesta poate fi distribuit în cazul în care activitatea implică mai multe servere, și, în același timp, utilizatorul trebuie să fie capabil să se conecteze la oricare dintre ele cu aceeași parolă. Cum de a face acest lucru? Înregistrează-te pe fiecare server individual? Prost și inutil. Și apoi vine la replicarea de salvare. Pur și simplu înregistrați-vă pe un singur server și prescrie permisiunile necesare și toate informațiile vor fi reproduse în cazul în care este necesar.

replicare AD are loc în mod automat, și de obicei nu necesită intervenții speciale, dar necesită o bună înțelegere a ideii de bază. Dacă un Active Directory ar fi atât de ușor, nu aș fi luate în considerare separat această tehnologie. Mai întâi, trebuie să înțeleagă că pentru protocolul de autentificare Kerberos este utilizat și responsabilitatea pentru autenticitatea ia pe un controler de domeniu. Când vii la server, numele de utilizator și parola sunt trimise la server, care verifică datele și în cazul în care produce cu succes bilet alb. Nu, desigur, nu bilet alb, dar pe aceasta, utilizatorul primeste anumite drepturi. Dacă există o dorință și nu există nici cunoștințe, te sfătuiesc să faceți cunoștință cu Active Directory și Kerberos, iar sarcina noastră - replicare.

Configurarea manuală a conexiunii dintre controlerele de domeniu în rețea nu este necesară, deși este posibil. ele însele servere la intervale regulate, monitorizează controlorii disponibile și stocate în memoria tuturor informațiilor necesare.

În mod implicit, replicarea are loc la fiecare cincisprezece minute. Prin aceste intervale, serverul trimite un mesaj de controlere de domeniu, care au o schimbare de curs și să devină un distribuitor. Alți participanți de replicare, care au primit un astfel de mesaj, conectați la server și trage de date. distribuitor în sine, fără a necesita modificări rețelei lor nu scuipa la hackerii rele nu au putut intercepta un pachet similar. Doar nu are nici un sens fără a fi nevoie de a arunca într-o rețea de astfel de date sensibile, dintr-o dată celelalte controlere de domeniu au scăzut (deși țara se odihnesc în pace și cenușă).

Conflicte în Active Directory

Deoarece replicarea este întârziată, serverul reproduce pachetele de actualizare. Toate modificările la Active Directory și se acumulează la un moment dat să fie trimise la toate controlerele de domeniu. Acest lucru este bun, dar din cauza întârzierii și posibilele probleme. Să presupunem că într-o anumită perioadă de timp, în același timp, a existat o schimbare în cele două controlere de domeniu. A cui modificări vor fi replicat? Să încercăm să înțelegem.

Toate obiectele Active Directory au versiunea care primește valoarea în crearea unei unități. După fiecare versiune de editare a crește obiect, așa că, dacă cererea vine replica de intrare cu un număr de versiune mai mic decât cel actual, atunci aceste modificări sunt laminate înapoi.

Ce se întâmplă dacă serverul va veni în același timp, două propuneri privind reproducerea diferitelor controlere, și la aceeași versiune a obiectului va fi la fel, dar ele însele obiectele sunt diferite? Acest lucru se poate întâmpla, atunci când același obiect cu versiunea identică este schimbat la diferite controlere. Ambele controlere crește versiunea, și va fi la fel din nou. În acest caz, câștigătorul este server și modificarea corespunzătoare, care a fost făcută ultima.

Cel mai extreme caz - atunci când versiunile sunt aceleași, și chiar în momentul schimbării este identică. Desigur, probabilitatea este prea mică, dar este, prin urmare, Active Directory, dezvoltatorii în acest caz, preferă să aleagă schimbarea care a venit cu serverul cu o mare GUID la nivel mondial. Desigur, aceasta este o alegere proastă și poate fi departe de a fi exacte, dar într-un fel rezolvă conflictul.

Fiecare controler de la primirea modificărilor, încercând vtulit alte controlere lor în rețea. Aici, de asemenea, există o problemă - ne imaginăm că avem trei dintre controlerul de domeniu. Editați obiectul pe teren, și el, desigur, trebuie să notifice cealaltă a modificărilor. Au luat aceste schimbări, dar în acest moment un al doilea controler încearcă să se ghiftui aceeași schimbare înapoi la noi sau de la un al treilea domeniu care a avut deja schimbarea. Ce se poate face în acest caz? Este foarte simplu - avem, de asemenea, o schimbare de versiune și poate fi găsit, este necesar să se ia în considerare, sau a fost deja replicat.

Această problemă este rezolvată parțial prin faptul că replicarea nu poate merge dincolo de cele trei controlerele. În cazul în care serverul a primit a treia schimbare, cu atât mai mult nu are nimeni nu va trece. lanț de transmisie Replicarea are loc numai în cazul în care operatorul a primit o nouă versiune a elementului prima sau a doua.

Replicarea AD prin 56k

Replicarea date la fiecare 15 minute, convenabile și plăcute, dar numai în cazul în care toate controlerele de domeniu sunt conexiune de mare viteză interconectate. Ce se întâmplă dacă două controlere sunt într-o altă zonă sau țară în care acestea pot fi conectate la rețea numai DialUp? În acest caz, traficul de replicare poate lua prea multe resurse, și lățimea de bandă nu este suficient pentru alte sarcini.

Pentru a evita acest lucru, este posibil și chiar necesar să se separe site-urile de server. Toate controlerele conectate printr-o conexiune de mare viteză pentru a plasa într-un singur site și două de la distanță într-un alt site. În interiorul site-ul de replicare poate avea loc în conformitate cu normele stabilite în mod implicit, dar între site-uri, puteți configura schimbul astfel încât să nu supraîncărcați banda și lăsați-l să transmită date mai importante. Acest lucru vă separare fără probleme pot fi configurate folosind site-uri anticipate AD și servicii.

Opțiunile oferite ca opțiuni posibile de conservare a traficului, TechNet de la MS:

• replicare a datelor timp de noapte;
• Replicarea pauze de prânz;
• Replicarea cu intervale mari.

Îmi place primele două opțiuni, mai ales în cazul în care site-urile sunt în același fus orar. Dar dacă unul este situat în Moscova, iar celălalt în regiunea Chukotka, nu că ești la prânz, nu se poate ajunge acolo, atunci când la Moscova, în ziua în Petropavlovsk la miezul nopții.

Mai multe despre replicare Active Directory (AD)

Dacă doriți să aflați mai multe despre replicare Acive Director, și nu există probleme cu limba engleză, vă recomand să descărcați următorul document: www.certmag.com/bookshelf/C0617953.pdf. Acesta este de 92 de pagini de utile și khaljavnogo ficțiune. Dacă acest lucru nu este suficient, apoi rula pe TechNet de la Microsoft. Informații se prezintă nu la fel de convenabil și consecvent, dar o mulțime de sfaturi bune.

Sper să vă pot convinge că replicarea - nu este doar să se sincronizeze și mai avansat și inteligent pas înainte. Cu abordarea corectă, acest pas va fi mare. Dacă face bine se va ocupa de acest subiect, se poate face chiar și replicare manuală, fără probleme, astfel în cazul în care acesta nu este original. La urma urmei, nu toate bazele de date puse în aplicare o astfel de posibilitate.

În spatele scenei acestui articol a fost foarte interesant subiect - replicare Exchange Server. Ea este foarte asemănător cu Active Directory și SQL Server, dar există unele nuanțe interesante.

Avertizare. Dacă copiați acest articol pe site-ul dvs., apoi lăsați un link direct către această pagină. Vă mulțumim pentru înțelegere