ProHoster > Blog > Administrim > Orkestratori për MySQL: pse nuk mund të ndërtojmë një projekt të qëndrueshëm pa të

Orkestratori për MySQL: pse nuk mund të ndërtojmë një projekt të qëndrueshëm pa të

Çdo projekt i madh ka filluar me disa serverĂ«. Fillimisht kishte njĂ« server DB, pastaj iu shtuan skllavĂ«t pĂ«r tĂ« shkallĂ«zuar leximin. Dhe kĂ«tu – stop! Masteri Ă«shtĂ« njĂ«, por skllavĂ«t janĂ« shumĂ«; nĂ«se njĂ« nga skllavĂ«t largohet, gjithçka do tĂ« shkojĂ« mirĂ«, por nĂ«se masteri largohet – do tĂ« jetĂ« keq: kohĂ« pezullimi, administratorĂ«t nĂ« panik ngrisin serverin. ÇfarĂ« tĂ« bĂ«jmĂ«? TĂ« rezervojmĂ« masterin. Kolegu im Pavel ka shkruar tashmĂ« pĂ«r kĂ«tĂ« artikull, nuk do ta pĂ«rsĂ«ris atĂ«. NĂ« vend tĂ« kĂ«saj, do t'ju tregoj pse ju nevojitet patjetĂ«r Orkestratori pĂ«r MySQL!

Të fillojmë me pyetjen kryesore: "Si do ta kalojmë kodin në makinë të re kur masteri largohet?".

  • Schemes me VIP (IP Virtual) mĂ« pĂ«lqen mĂ« sĂ« shumti, pĂ«r tĂ« cilĂ«n do tĂ« flasim mĂ« poshtĂ«. Ajo Ă«shtĂ« mĂ« e thjeshtĂ« dhe mĂ« e dukshme, megjithatĂ« ka njĂ« kufizim tĂ« qartĂ«: masteri qĂ« do tĂ« rezervojmĂ« duhet tĂ« jetĂ« nĂ« segmentin L2 me makinĂ«n e re, domethĂ«nĂ« mund ta harrojmĂ« qendrĂ«n e dytĂ«. Dhe, nĂ« tĂ« vĂ«rtetĂ«, nĂ«se ndjekim rregullin qĂ« L2 i madh Ă«shtĂ« i keq, sepse L2 Ă«shtĂ« vetĂ«m nĂ« kabinet, ndĂ«rmjet kabinave Ă«shtĂ« L3, dhe njĂ« skemĂ« e tillĂ« ka akoma mĂ« shumĂ« kufizime.
  • Mund tĂ« shkruajmĂ« nĂ« kod emrin DNS dhe ta zgjidhim pĂ«rmes /etc/hosts. NĂ« fakt nuk do tĂ« ketĂ« zgjidhje. Avantazhi i skemĂ«s: nuk ka kufizimin karakteristik pĂ«r mĂ«nyrĂ«n e parĂ«, domethĂ«nĂ« mund tĂ« organizojmĂ« edhe cross-DC. Por atĂ«herĂ« lind pyetja e qartĂ«, si shpejt do tĂ« sjellim ndryshimin nĂ« /etc/hosts pĂ«rmes Puppet-Ansible.
  • Mund ta modifikojmĂ« pak mĂ«nyrĂ«n e dytĂ«: nĂ« tĂ« gjithĂ« serverĂ«t web vendosim DNS qĂ« ruan nĂ« cache, pĂ«rmes tĂ« cilit Kodi do tĂ« shkojĂ« nĂ« bazĂ«n master. Mund tĂ« vendosim TTL 60 pĂ«r kĂ«tĂ« regjistrim nĂ« DNS. Duke u dukur, kur zbatohet siç duhet, metoda Ă«shtĂ« e mirĂ«.
  • Schemes me zbulimin e shĂ«rbimeve, qĂ« pĂ«rfshin pĂ«rdorimin e Consul dhe etcd.
  • NjĂ« variant interesant me ProxySQL. Duhet tĂ« kalojmĂ« tĂ« gjithĂ« trafikun nĂ« MySQL pĂ«rmes ProxySQL, qĂ« vetĂ« di tĂ« identifikojĂ« kush Ă«shtĂ« tani masteri. PĂ«r t'u pĂ«rmendur, pĂ«r njĂ« nga variantet e pĂ«rdorimit tĂ« kĂ«tij produkti mund tĂ« lexoni nĂ« artikullin tim artikulli ynĂ«.

Autori i Orkestratorit, duke punuar në Github, fillimisht implementoi skemën e parë me VIP, dhe pastaj e përmirësoi në skemën me Consul.

Schema tipike e infrastrukturës:

Orkestratori për MySQL: pse nuk mund të ndërtojmë një projekt të qëndrueshëm pa të
Menjëherë do të përshkruaj situatat e qarta që duhet të marrim parasysh:

  • VIP adresa nuk duhet tĂ« regjistrohet nĂ« konfigurim nĂ« asnjĂ« nga serverat. Imagjinoni situatĂ«n: masteri u ribotua, dhe ndĂ«rsa ai po ngarkohet, Orchestrator kaloi nĂ« modalitetin failover dhe bĂ«ri njĂ« nga slave-Ă«t master; mĂ« pas u ngjall masteri i vjetĂ«r, dhe tani VIP Ă«shtĂ« nĂ« dy makina. Kjo Ă«shtĂ« e keqe.
  • PĂ«r Orchestrator do tĂ« duhet tĂ« shkruhet njĂ« skenar pĂ«r tĂ« komunikuar me masterin e vjetĂ«r dhe masterin e ri. NĂ« tĂ« vjetrin duhet tĂ« ekzekutohet ifdown, dhe nĂ« masterin e ri — ifup vip. Po ashtu do tĂ« ishte mirĂ« tĂ« pĂ«rfshihet nĂ« kĂ«tĂ« skenar qĂ« nĂ« rastin e failover-it porta nĂ« switch-in e masterit tĂ« vjetĂ«r thjesht tĂ« mbyllet, pĂ«r tĂ« shmangur ndonjĂ« splitbrain.
  • Pas qĂ« Orchestrator thirri skenarin tuaj, pĂ«r tĂ« hequr fillimisht VIP dhe\/ose pĂ«r tĂ« fikur portin nĂ« switch-in, e pastaj nĂ« masterin e ri thirri skenarin pĂ«r ngritjen e VIP, mos harroni tĂ« pĂ«rdorni komandĂ«n arping pĂ«r tĂ« bĂ«rĂ« tĂ« ditur tĂ« gjithĂ«ve se tani Ă«shtĂ« kĂ«tu VIP-i i ri.
  • NĂ« tĂ« gjitha slave-t duhet tĂ« jetĂ« read_only=1, dhe sapo tĂ« promovoni njĂ« slave nĂ« master, ai duhet tĂ« ketĂ« read_only=0.
  • Mos harroni se çdo slave mund tĂ« bĂ«het master, qĂ« ne e kemi zgjedhur pĂ«r kĂ«tĂ« (Orchestrator ka njĂ« mekanizĂ«m tĂ« tĂ«rĂ« preferencash pĂ«r tĂ« vendosur se cili slave tĂ« konsiderohet si kandidati kryesor pĂ«r master nĂ« radhĂ« tĂ« parĂ«, cili nĂ« tĂ« dytĂ«n, dhe cili slave nuk duhet kurrĂ« tĂ« zgjidhet si master). NĂ«se nje slave bĂ«het master, atĂ«herĂ« ai do tĂ« mbajĂ« ngarkesĂ«n e slave dhe do t'i shtohet ngarkesa e master, kjo duhet tĂ« merret parasysh.

Pse ju nevojitet Orchestrator nëse nuk e keni atë?

  • Orchestrator ka njĂ« ndĂ«rfaqe shumĂ« tĂ« pĂ«rshtatshme grafike, qĂ« tregon gjithĂ« topologjinĂ« (shihni screenshot-in mĂ« poshtĂ«).
  • Orchestrator mund tĂ« ndjekĂ« se cilat slave janĂ« prapa, dhe ku replikimi ka dĂ«shtuar plotĂ«sisht (ne kemi skenare tĂ« lidhura me Orchestrator pĂ«r tĂ« dĂ«rguar SMS).
  • Orchestrator ju thotĂ« se nĂ« cilat slave ka gabime GTID errant.

Ndërfaqja e Orchestrator-it:

Orkestratori për MySQL: pse nuk mund të ndërtojmë një projekt të qëndrueshëm pa të
ÇfarĂ« Ă«shtĂ« GTID errant?

Ka dy kërkesa kryesore për funksionimin e Orchestrator-it:

  • Duhet qĂ« nĂ« tĂ« gjitha makinat e klasterit MySQL tĂ« jetĂ« i aktivizuar pseudo GTID, ne kemi aktivizuar GTID.
  • Duhet tĂ« ketĂ« njĂ« lloj tĂ« vetĂ«m tĂ« binlog-ve kudo, mundĂ«sisht statement. Ne kishim njĂ« konfigurim tĂ« tillĂ«, ku nĂ« master dhe nĂ« shumicĂ«n e slave-Ă«ve ishte Row, ndĂ«rsa nĂ« dy histori kishte mbetur nĂ« mĂ«nyrĂ«n Mixed. Si rezultat, kĂ«ta slave Orchestrator nuk deshi t'i lidhte me masterin e ri.

Mbani se kujtoni se gjëja më e rëndësishme në slavin e production-it është konsistenca e tij me master-in! Nëse ju keni aktivizuar Global Transaction ID (GTID) si në master ashtu edhe në slave, mund të kuptoni përmes funksionit gtid_subset nëse kërkesat për ndryshimin e të dhënave janë kryer të njëjtat në këto makina. Më shumë rreth kësaj mund të lexoni. këtu.

Kështu, Orchestrator ju tregon përmes gabimit GTID errant se në slave ka transaksione që nuk janë në master. Pse ndodh kjo?

  • NĂ« slave nuk Ă«shtĂ« aktivizuar read_only=1, dikush Ă«shtĂ« lidhur dhe ka kryer njĂ« kĂ«rkesĂ« pĂ«r ndryshimin e tĂ« dhĂ«nave.
  • NĂ« slave nuk Ă«shtĂ« aktivizuar super_read_only=1, atĂ«herĂ« admin, duke bĂ«rĂ« njĂ« gabim me serverin, ka hyrĂ« dhe ka kryer njĂ« kĂ«rkesĂ«.
  • NĂ«se keni marrĂ« parasysh tĂ« dy pikat e mĂ«parshme, ka njĂ« tjetĂ«r hile: nĂ« MySQL, kĂ«rkesa pĂ«r flush binlog-Ă«ve gjithashtu shkon nĂ« binlog, prandaj me flush-in e parĂ« nĂ« master dhe nĂ« tĂ« gjitha slave-t do tĂ« shfaqet GTID errant. Si ta shmangim kĂ«tĂ«? NĂ« perona-5.7.25-28 u shfaq njĂ« konfigurim binlog_skip_flush_commands=1, qĂ« ndalon shkruarjen e flush nĂ« binlog. NĂ« faqen mysql.com Ă«shtĂ« regjistruar njĂ« çështje.

PĂ«rmbledh tĂ« gjitha tĂ« mĂ«suara mĂ« sipĂ«r. NĂ«se ende nuk dĂ«shironi tĂ« pĂ«rdorni Orchestrator nĂ« modalitetin failover, vendoseni atĂ« nĂ« modalitetin e vĂ«zhgimit. AtĂ«herĂ« do tĂ« keni gjithmonĂ« para syve njĂ« hartĂ« tĂ« ndĂ«rveprimit tĂ« makinave MySQL dhe informacione tĂ« qarta mbi llojin e replikimit nĂ« çdo makinĂ«, nĂ«se slave-t janĂ« pas dhe mĂ« e rĂ«ndĂ«sishmja—sa konsistent janĂ« ata me master-in!

Pyetja evidente është: "Si duhet të funksionojë Orchestrator?". Ai duhet të zgjedhë një master të ri nga slave-t aktualë dhe pastaj të rikonfigurojë të gjithë slave-t ndaj tij (pasi për këtë është e nevojshme GTID; nëse përdorim mekanizmin e vjetër me binlog_name dhe binlog_pos, është thjesht e pamundur kalimi i një slave nga master-i aktual në një të ri!). Para se të kishim Orchestrator, njëherë më është dashur ta bëj gjithë këtë manualisht. Master-i i vjetër ngrinte për shkak të një kontrolluesi problematik Adaptec, kishte rreth 10 slave. Më duhej të kaloja VIP nga master-i te një prej slave-ve dhe të rikonfiguroja të gjithë slave-t e tjerë ndaj tij. Sa shumë konsolla më është dashur të hapja, sa komandat e përkohshme të vendosja... Ishte nevojshme të prisja deri në orën 3 të mëngjesit, të lajë barrën nga të gjithë slave-t, përveç dyve, të bëja një makinë nga dyta master, menjëherë të lidhja makinën e dytë, pastaj të lidhen të gjithë slave-t e tjerë me master-in e ri dhe të kthej barrën. Në përgjithësi, tmerr...

Siht qĂ« Orchestrator funksionon kur kalon nĂ« modalitetin e dĂ«shtimit? ËshtĂ« mĂ« e lehtĂ« tĂ« ilustrohet me njĂ« shembull tĂ« situatĂ«s ku duam tĂ« bĂ«jmĂ« njĂ« makinĂ« mĂ« tĂ« fuqishme dhe mĂ« moderne se ajo aktuale, master.

Orkestratori për MySQL: pse nuk mund të ndërtojmë një projekt të qëndrueshëm pa të
NĂ« figurĂ« paraqitet mesi i procesit. ÇfarĂ« Ă«shtĂ« bĂ«rĂ« deri nĂ« kĂ«tĂ« moment? Ne thamĂ« se duam tĂ« bĂ«jmĂ« njĂ« skllav tĂ« caktuar njĂ« master tĂ« ri, Orchestrator filloi thjesht tĂ« lidhĂ« pĂ«rsĂ«ri tĂ« gjithĂ« skllavĂ«t e tjerĂ«, ndĂ«rsa masteri i ri ka rol si makinĂ« tranziti. Me kĂ«tĂ« skemĂ« nuk ka gabimesh, tĂ« gjithĂ« skllavĂ«t funksionojnĂ«, Orchestrator heq VIP nga masteri i vjetĂ«r, e transferon te i ri, bĂ«n read_only=0 dhe e harron masterin e vjetĂ«r. Kaq! Koha e papĂ«rshtatshme e shĂ«rbimit tonĂ« Ă«shtĂ« koha e transferimit tĂ« VIP, qĂ« Ă«shtĂ« 2-3 sekonda.

Këtu përfundon gjithçka për sot, faleminderit të gjithëve. Shpejt do të publikohet një artikull i dytë për Orchestrator. Në një film të njohur sovjetik "Garazhi" një hero tha "Unë nuk do të shkoja në spiunazh me të!" Pra, Orchestrator, unë do të shkoja në spiunazh me ty!

Burimi: habr.com

Bleni hostin e besueshĂ«m pĂ«r faqet me mbrojtje nga DDoS, VPS VDS servera đŸ”„ Bli hostin e besueshĂ«m pĂ«r faqet me mbrojtje nga DDoS, VPS VDS servera | ProHoster