Deci, am început să implementez Cluster-ul Percona XtraDB în organizația mea - pentru a traduce baze de date dintr-un server MySQL obișnuit într-o arhitectură în cluster.
Pe scurt despre sarcină și datele de intrare
În cluster, trebuie să păstrăm:
- DB a mai multor site-uri cu utilizatori
- DB cu date statistice ale acestor utilizatori
- DB pentru sisteme de bilete, sisteme de management de proiect și alte probleme
Cu alte cuvinte, baza de date a aproape tuturor proiectelor noastre, din cele pe care le rotim pe MySQL, trebuie să trăiască acum într-un grup.
Cele mai multe proiecte pe care le păstrăm de la distanță în DC, așa că clusterul va fi acolo.
Sarcina de a răspândi grupul geografic în diferite centre de date nu merită.
Pentru a configura un cluster utilizând 3 configurație identică server: HP DL160 G6, 2X Xeon E5620, 24 GB RAM, 4x SAS 300GB în RAID 10. Un hardware bun sub fier de brand, pe care am folosi pentru o lungă perioadă de timp și că eu nu reușesc.
De ce Percona?
- Replicare sincronă reală multi-master (Galera)
- Posibilitatea unui sprijin comercial de la Percona
- Furca MySQL cu o listă impresionantă de optimizări
Schema clusterului
În grupul 3 noduri, pentru fiecare server fizic de mai sus (OS Ubuntu 12.04).
Nodul A este folosit ca nod de referință (Backup), pe care aplicațiile noastre nu îl vor încărca cu cereri. În același timp, va fi membru cu drepturi depline al clusterului și va participa la replicare. Acest lucru se face datorită faptului că, în caz de eșec în cluster, sau corupere de date, vom avea un nod, care aproape sigur conține cele mai unsori datele la care aplicația pur și simplu nu a putut rupe în jos din cauza lipsei de acces. Poate că ar părea o utilizare risipitoare a resurselor, dar pentru noi, 99% din fiabilitatea datelor este încă mai importantă decât disponibilitatea 24/7. Vom folosi acest nod pentru SST - Snapshot State Transfer - dump automat al dump-ului unui nou nod atașat la cluster sau ridicat după un accident. În plus, Nodul A este un candidat excelent pentru server, de unde vom trage copii de rezervă standard periodice.
Schematic, toate pot fi reprezentate astfel:
Nodul B și Nodul C sunt căi de lucru care dețin o sarcină, dar numai unul dintre ei are grijă de operațiunile de scriere. Aceasta este recomandarea multor specialiști, iar în cele ce urmează voi vorbi în detaliu despre această problemă.
Echilibrarea detaliilor
Solicitări care ajung la portul 3306. HAProxy cheltuiește pe Robin rotund între nodurile B și C.
Ceea ce vine în 3307. este doar proxy pe Nod B. Dacă nodul B cade brusc, cererile vor merge la Nodul specificat C.
Pentru realizarea ideilor noastre (scrie doar pe unul dintre nodurile) cererile trebuie să fie scrise la cereri de citire a merge printr-o conexiune cu 10.0.0.70:3306 (10.0.0.70 - nostru VIP), o cerere de scriere îndreptată către 10.0.0.70: 3307.
În cazul nostru, acest lucru va necesita o lucrare pentru a crea o nouă conexiune în fișierul de configurare PHP și a înlocui numele variabilei DBHandler cu o valoare diferită. În general, acest lucru nu este atât de dificil pentru acele aplicații pe care le-am scris. Pentru proiectele unor terțe părți, ale căror baze de date vor fi și ele în cluster, specificăm portul 3307 în mod implicit. Încărcați aceste proiecte creând un mic și pierderea posibilității de citire distribuită nu este atât de critică.
Configurația HAProxy (/etc/haproxy/haproxy.cfg):
Pentru ca HAProxy să determine dacă un nod de cluster este în viață, se folosește utilitarul clustercheck. (inclusă în clusterul percona-xtradb), care afișează informațiile despre starea nodurilor (Synced / Not Synced) ca răspuns HTTP. Pe fiecare dintre noduri serviciul xinetd trebuie să fie configurat:
Configurarea nodurilor
Mai întâi de toate, nu uitați să sincronizați timpul pe toate nodurile. Mi-a fost dor de acest moment și de mult timp nu am putut înțelege de ce SST-ul meu se blochează - a început, a atârnat în procese, dar de fapt nu sa întâmplat nimic.
my.cnf pe Nodul A (în configurația mea este node105):
Mai departe - numai parametrii diferiți:
În ultimele două configurările ne spune fără echivoc serverul unde sa caute primul nod din cluster (cine știe unde toți membrii grupului de viață), și că a fost cu ea, nu și celelalte disponibile, aveți nevoie pentru a colecta date care urmează să fie sincronizate.
În această configurație am oprit acum și voi traduce treptat proiectele într-un grup. Voi continua să scriu despre experiența mea.
Probleme problematice
Voi menționa aici întrebări la care nu am găsit imediat răspunsul, dar răspunsul la care este deosebit de important pentru înțelegerea tehnologiei și pentru lucrul corect cu clusterul.
De ce se recomandă scrierea pe un nod din toate cele disponibile în cluster? La urma urmei, s-ar părea că acest lucru contravine ideii unei replicări multiple.
Testele mele au arătat că, atunci când au fost scrise agresiv la toate nodurile, au căzut unul după altul, lăsând doar Nodul de referință de lucru, adică de fapt, putem spune că clusterul a încetat să mai funcționeze. Acest lucru este cu siguranta un dezavantaj al acestei configurații, pentru că al treilea nod ar putea, în acest caz, pentru a lua povara de pe ei înșiși, dar suntem siguri că datele sunt acolo intact și în cel mai rău caz, putem rula manual într-o lucrare în modul single-server.
Există 2 directive pentru aceasta:
Semnificația acestor directive mi-a determinat inițial o confuzie specială.
Faptul este că multe manuale au sfătuit pe primul nod al clusterului să lase valoarea goală a gcomm: // în wsrep_urls.
Sa dovedit că este greșit. Prezența lui gcomm: // înseamnă inițierea unui nou grup. Prin urmare, imediat după începerea primului nod în config, trebuie să ștergeți această valoare. În caz contrar, după repornirea acestui nod, veți primi două clustere diferite, dintre care unul va consta numai din primul nod.
Pentru mine, am arătat ordinea configurației când grupul a fost pornit și reluat (deja descris mai detaliat mai sus)
1. Nod A: începe cu gcomm: // B, gcomm: // C, gcomm: //
2. Nod A: eliminarea gcomm: // la sfârșitul liniei
3. Noduri B, C: începeți cu gcomm: // A
NB: trebuie să specificați numărul portului pentru solicitările de comunicații de grup, implicit este 4567. Aceasta înseamnă că intrarea corectă este: gcomm: // A: 4567
Este posibil să scrieți cu non-blocking xtrabackup ca metodă SST pe un nod donator?
În timpul SST clustercheck la donatorul va afișa HTTP 503, respectiv, pentru HAProxy sau alte LB, care utilizează acest instrument pentru a determina starea nodului donator este considerat de neatins, precum și nodul la care se face transferul. Dar acest comportament poate fi schimbat prin editarea clustercheck-ului. care este, în esență, un script bash normal.
Aceasta se face prin editarea următoare:
NB: Rețineți că puteți face acest lucru numai dacă sunteți sigur că xtrabackup este folosit ca SST. și nu o altă metodă. În cazul nostru, când folosim un nod ca donator ca donator, această corecție nu are sens deloc.
Link-uri utile
Trimiteți-le prietenilor: