Orice proiect mare a început cu câteva servere. La început a existat un server DB, apoi i-au fost adăugați sclavi pentru a scala citirea. Și apoi - oprește-te! Există un singur stăpân, dar sunt mulți sclavi; dacă unul dintre sclavi pleacă, atunci totul va fi bine, dar dacă stăpânul pleacă, va fi rău: timp de nefuncționare, administratorii încearcă să ridice serverul. Ce să fac? Rezervă un maestru. Colegul meu Pavel a scris deja despre asta , nu o voi repeta. În schimb, vă voi spune de ce aveți nevoie cu siguranță de Orchestrator pentru MySQL!
Să începem cu întrebarea principală: „Cum vom schimba codul la o nouă mașină atunci când comandantul pleacă?”
- Cel mai mult imi place schema cu VIP (Virtual IP), despre ea vom vorbi mai jos. Este cel mai simplu și mai evident, deși are o limitare evidentă: masterul pe care îl vom rezerva trebuie să fie în segmentul L2 cu noua mașinărie, adică putem uita de al doilea DC. Și, într-un mod amiabil, dacă urmați regula conform căreia un L2 mare este rău, pentru că L2 este doar pe rafturi, iar L3 este între rafturi, iar o astfel de schemă are și mai multe restricții.
- Puteți scrie un nume DNS în cod și îl puteți rezolva prin /etc/hosts. De fapt, nu va exista nicio rezoluție. Avantajul schemei: nu există o caracteristică de limitare a primei metode, adică este posibil să se organizeze un cross-DC. Dar atunci apare întrebarea evidentă: cât de repede putem livra modificarea către /etc/hosts prin Puppet-Ansible?
- Puteți schimba puțin a doua metodă: instalați DNS cache pe toate serverele web, prin care codul va ajunge la baza de date master. Puteți seta TTL 60 pentru această intrare în DNS. Se pare că dacă este implementată corect, metoda este bună.
- O schemă cu descoperire de servicii, care implică utilizarea Consulului și etcd.
- O varianta interesanta cu . Trebuie să direcționați tot traficul către MySQL prin ProxySQL; ProxySQL însuși poate determina cine este stăpânul. Apropo, puteți citi despre una dintre opțiunile de utilizare a acestui produs în my .
Autorul cărții Orchestrator, care lucrează în Github, a implementat prima schemă cu VIP, apoi a convertit-o într-o schemă cu consul.
Aspectul tipic al infrastructurii:
Voi descrie imediat situațiile evidente care trebuie luate în considerare:
- Adresa VIP nu ar trebui să fie înregistrată în configurația de pe niciunul dintre servere. Să ne imaginăm o situație: masterul a repornit și, în timp ce se încărca, Orchestrator a intrat în modul failover și a făcut unul dintre sclavi master; apoi bătrânul maestru s-a ridicat, iar acum VIP-ul este pe două mașini. Asta e rău.
- Pentru orchestrator, va trebui să scrieți un script pentru apelarea vechiului master și a noului master. Pe vechiul master trebuie să rulați ifdown, iar pe noul master – ifup vip. Ar fi bine să includeți în acest script și faptul că, în cazul unui failover, portul de pe vechiul comutator master este pur și simplu oprit pentru a evita orice splitbrain.
- După ce Orchestrator a apelat scriptul pentru a elimina mai întâi VIP-ul și/sau a stinge portul de pe comutator și apoi a apelat script-ul de ridicare VIP pe noul master, nu uitați să utilizați comanda arping pentru a spune tuturor că noul VIP este acum Aici.
- Toți sclavii ar trebui să aibă read_only=1, iar de îndată ce promovați slave la master, ar trebui să aibă read_only=0.
- Nu uitați că orice sclav pe care l-am ales pentru aceasta poate deveni maestru (Orchestrator are un întreg mecanism de preferință pentru care sclav să îl considere candidat pentru un nou maestru în primul rând, care în al doilea rând și care sclav ar trebui nu fi selectat deloc sub nicio formă master). Dacă sclavul devine stăpân, atunci sarcina sclavului va rămâne pe el și va fi adăugată sarcina stăpânului, acest lucru trebuie luat în considerare.
De ce ai nevoie de Orchestrator dacă nu ai unul?
- Orchestrator are o interfață grafică foarte ușor de utilizat, care afișează întreaga topologie (vezi captura de ecran de mai jos).
- Orchestrator poate urmări ce sclavi rămân în urmă și unde replicarea s-a întrerupt în general (avem scripturi atașate la Orchestrator pentru trimiterea de SMS-uri).
- Orchestrator vă spune ce sclavi au o eroare GTID.
Interfață orchestrator:
Ce este GTID errat?
Există două cerințe principale pentru ca Orchestrator să funcționeze:
- Este necesar ca pseudo GTID să fie activat pe toate mașinile din clusterul MySQL; avem GTID activat.
- Este necesar ca peste tot un tip de binlog-uri, puteți folosi declarație. Aveam o configurație în care masterul și majoritatea sclavilor aveau Row, iar doi au rămas istoric în modul Mixed. Drept urmare, Orchestrator pur și simplu nu a vrut să conecteze acești sclavi la noul master.
Amintiți-vă că cel mai important lucru într-un slave de producție este consistența acestuia cu stăpânul! Dacă aveți ID-ul tranzacției globale (GTID) activat atât pe master, cât și pe slave, atunci puteți utiliza funcția gtid_subset pentru a afla dacă aceleași solicitări de modificare a datelor au fost de fapt executate pe aceste mașini. Puteți citi mai multe despre asta .
Astfel, Orchestrator vă arată prin erratul GTID că există tranzacții pe slave care nu sunt pe master. De ce se întâmplă asta?
- Read_only=1 nu este activat pe slave, cineva s-a conectat și a finalizat o solicitare de modificare a datelor.
- Super_read_only=1 nu este activat pe slave, apoi administratorul, după ce a încurcat serverul, a intrat și a executat cererea acolo.
- Dacă ai ținut cont de ambele puncte anterioare, atunci mai există un truc: în MySQL, o solicitare de spălare a binlog-urilor merge și la binlog, așa că la prima spălare, va apărea un errant GTID pe master și pe toți slave. Cum să evitați acest lucru? Perona-5.7.25-28 a introdus setarea binlog_skip_flush_commands=1, care interzice scrierea flush în binlog-uri. Există unul stabilit pe site-ul mysql.com .
Permiteți-mi să rezum toate cele de mai sus. Dacă nu doriți să utilizați încă Orchestrator în modul failover, atunci puneți-l în modul de observare. Apoi veți avea întotdeauna în fața ochilor o hartă a interacțiunii mașinilor MySQL și informații vizuale despre ce tip de replicare este pe fiecare mașină, dacă sclavii sunt în urmă și, cel mai important, cât de consecvenți sunt cu masterul!
Întrebarea evidentă este: „Cum ar trebui să funcționeze Orchestrator?” El trebuie să selecteze un nou master dintre sclavii actuali și apoi să reconectați toți sclavii la acesta (asta este necesar GTID; dacă utilizați vechiul mecanism cu binlog_name și binlog_pos, atunci comutați un slave de la masterul actual la unul nou este pur și simplu imposibil!). Înainte să avem Orchestrator, odată a trebuit să fac toate acestea manual. Vechiul maestru era agățat din cauza unui controler Adaptec cu buggy; avea aproximativ 10 sclavi. Trebuia să transfer VIP de la master la unul dintre sclavi și să reconectam toți ceilalți sclavi la acesta. Câte console a trebuit să deschid, câte comenzi simultane am introdus... A trebuit să aștept până la 3 a.m., să scot sarcina de la toți sclavii cu excepția a doi, să fac prima mașină a celor doi master, să atașez imediat a doua mașină la el, așa că atașați toți ceilalți sclavi la noul maestru și returnați sarcina. Per total, groaznic...
Cum funcționează Orchestrator când intră în modul failover? Acest lucru este cel mai ușor ilustrat printr-un exemplu de situație în care dorim să facem un maestru o mașină mai puternică și mai modernă decât avem acum.
Figura arată mijlocul procesului. Ce s-a făcut deja până în acest moment? Am spus că vrem să facem din un sclav noul maestru, Orchestrator a început pur și simplu să reconnecteze toți ceilalți sclavi la el, noul maestru acționând ca o mașină de tranzit. Cu această schemă, nu apar erori, toți sclavii funcționează, Orchestrator elimină VIP-ul de pe vechiul master, îl transferă pe cel nou, face read_only=0 și uită de vechiul master. Toate! Timpul de nefuncționare al serviciului nostru este timpul de transfer VIP, care este de 2-3 secunde.
Asta e tot pentru astăzi, mulțumesc tuturor. Va apărea un al doilea articol despre Orchestrator în curând. În celebrul film sovietic „Garage”, un personaj a spus: „Nu aș merge la recunoaștere cu el!” Deci, orchestrator, aș merge cu tine la recunoaștere!
Sursa: www.habr.com