Ădo projekt i madh ka nisur me disa serverĂ«. Fillimisht kishte njĂ« server DB, mĂ« pas iu shtuan slave pĂ«r tĂ« skalier leximin. Dhe kĂ«tu â ndal! Masteri Ă«shtĂ« njĂ«, ndĂ«rsa slave janĂ« shumĂ«; nĂ«se njĂ« nga slave ikĂ«n, gjithçka do tĂ« jetĂ« nĂ« rregull, por nĂ«se masteri ikĂ«n â do tĂ« jetĂ« keq: kohĂ« e pashpjegueshme, administratorĂ«t do tĂ« rikthejnĂ« serverin me vĂ«shtirĂ«si. ĂfarĂ« tĂ« bĂ«jmĂ«? TĂ« rezervojmĂ« masterin. Kolegu im Pavel ka shkruar tashmĂ« pĂ«r kĂ«tĂ«, , nuk do ta pĂ«rsĂ«ris. NĂ« vend tĂ« kĂ«saj, do tĂ« tregoj pse ju nevojitet patjetĂ«r Orchestrator pĂ«r MySQL!
Të fillojmë me pyetjen kryesore: "Si do ta kalojmë kodin në makinë të re kur masteri ikën?".
- Skema me VIP (Virtual IP) më pëlqen më shumë, mbi të do të flasim më poshtë. Ajo është më e thjeshtë dhe më e dukshme, megjithatë ka një kufizim të qartë: masteri, i cili do të rezervojmë, duhet të jetë në segmentin L2 me makinën e re, pra mund të harrojmë mbi qendrën e dytë. Po ashtu, nëse ndiqet rregulli se një L2 i madh është i keq, sepse L2 është vetëm për raft, ndërsa mes raftesh është L3, dhe kjo skemë ka edhe më shumë kufizime.
- Mund të specifikohet emri DNS në kod dhe të zgjidhet përmes /etc/hosts. Në të vërtetë, do të ketë pasiguri në zgjidhje. Avantazhi i skemës: nuk ka kufizime që karakterizojnë metodën e parë, domethënë, mund të krijoni një arkitekturë cross-DC. Por atëherë lind pyetja e qartë, se sa shpejt do ta përshtasim ndryshimin në /etc/hosts përmes Puppet-Ansible.
- Mund të ndryshoni pak metodën e dytë: në të gjitha serverat web vendosim një DNS cache, përmes të cilit kodi do të lidhë në master bazë. Mund të specifikohet TTL 60 për këtë regjistrim në DNS. Duket se, me realizimin e duhur, ky është një metodë e mirë.
- Një skemë me zbulim shërbimi, që nënkupton përdorimin e Consul dhe etcd.
- Një variant interesant me . Duhet të drejtohet e gjithë trafiku në MySQL përmes ProxySQL, i cili vetë di të identifikojë se kush është aktualisht master. Për një nga variantet e përdorimit të këtij produkti mund të lexoni në .
Autori Orchestrator, duke punuar në Github, fillimisht realizoi skemën e parë me VIP, e më pas e riparoi në skemën me consul.
Një skemë tipike infrastrukture:
Menjëherë do të përshkruaj situatat evidente që duhet të merren parasysh:
- VIP adresa nuk duhet të jetë e regjistruar në konfigurim në asnjë nga serverët. Imagjinoni një situatë: masteri rindez, dhe ndërkohë që po ngarkohet, Orchestrator kalon në modalitetin failover dhe bën një nga slave-t master; pastaj rindez masteri i vjetër, dhe tani VIP është në dy makina. Kjo është e keqe.
- PĂ«r orchestratorin do tĂ« nevojitet njĂ« skript pĂ«r t'u drejtuar nĂ« masterin e vjetĂ«r dhe masterin e ri. NĂ« masterin e vjetĂ«r duhet tĂ« ekzekutohet ifdown, ndĂ«rsa nĂ« masterin e ri â ifup vip. Do tĂ« ishte mirĂ« tĂ« pĂ«rfshihej gjithashtu nĂ« kĂ«tĂ« skript qĂ« nĂ« rast failover porti nĂ« switch-in e masterit tĂ« vjetĂ«r thjesht tĂ« mbyllet, pĂ«r tĂ« shmangur ndonjĂ« splitbrain.
- Pas thirrjes së skriptit tuaj nga Orchestrator, për të çaktivizuar fillimisht VIP dhe/ose për të mbyllur portin në switch, dhe pastaj në masterin e ri të thirrni skriptin për aktivizimin e VIP, mos harroni të thoni të gjithëve me komandën arping se tani VIP i ri është këtu.
- Në të gjitha slave-t duhet të jetë read_only=1, dhe sa herë që promovoni një slave në master, atij duhet t'i ndryshohet në read_only=0.
- Mos e harroni se çdo skllav që kemi zgjedhur për këtë mund të bëhet mjeshtër (Orchestrator ka një mekanizëm të plotë preferencash për të vendosur se cili skllav duhet konsideruar si kandidat për mjeshtrin e ri në radhë të parë, cili në radhë të dytë, dhe cili skllav nuk duhet zgjedhur për mjeshtër aspak). Nëse një skllav bëhet mjeshtër, ai do të mbajë ngarkesën e skllavit dhe do t'i shtohet ngarkesa e mjeshtrit, kështu që duhet ta merrni parasysh këtë.
Pse ju nevojitet patjetër Orchestrator nëse nuk e keni atë?
- Orchestrator ka një ndërfaqe grafike shumë të përshtatshme që tregon të gjithë topologjinë (shikoni screenshotin më poshtë).
- Orchestrator mund të ndjekë se cilët skllavë janë prapa dhe ku replikimi është prishur krejtësisht (ne kemi skriptet e lidhura me Orchestrator për të dërguar SMS).
- Orchestrator ju thotë se në cilët skllavë ka një gabim GTID errant.
Ndërfaqja e Orchestrator:
ĂfarĂ« Ă«shtĂ« GTID errant?
Ka dy kërkesa themelore për funksionimin e Orchestrator:
- ĂshtĂ« e nevojshme qĂ« nĂ« tĂ« gjitha makinat e klasterit MySQL tĂ« jetĂ« aktivizuar pseudo GTID, ne kemi aktivizuar GTID.
- Duhet që të ketë një lloj binlogu kudo, mundësisht statement. Ne kishim një konfigurim të tillë, ku në master dhe në shumicën e slaveve ishte Row, ndërsa në dy mbeti historikisht mënyra Mixed. Si rezultat, këto slave Orchestrator thjesht nuk dëshironin të lidhnin me masterin e ri.
Kujtoni se më e rëndësishme në një production-slave është konsistenca e tij me masterin! Nëse keni Global Transaction ID (GTID) aktiv në master dhe slave, atëherë përmes funksionit gtid_subset mund të mësoni nëse në këto makina janë ekzekutuar të njëjtat kërkesa për ndryshimin e të dhënave. Mund të lexoni më shumë rreth kësaj. .
Kështu, Orchestrator tregon përmes gabimit GTID errant se në slave ka transaksione që nuk ekzistojnë në master. Pse ndodh kjo?
- Në slave nuk është aktivizuar read_only=1, dikush u lidh dhe ekzekutoi një kërkesë për ndryshimin e të dhënave.
- Në slave nuk është aktivizuar super_read_only=1, atëherë admini, duke u ngatërruar me serverin, hyri dhe ekzekutoi atje një kërkesë.
- Nëse keni marrë parasysh të dy pikat e mëparshme, atëherë ka edhe një truk tjetër: në MySQL, kërkesa për flush-in e binlogëve gjithashtu përfshihet në binlog, prandaj me flush-in e parë në master dhe në të gjitha slave-t do të shfaqet GTID errant. Si të shmangni këtë? Në versionin perona-5.7.25-28 u shtua konfigurimi binlog_skip_flush_commands=1, që ndalon shkruajtjen e flush në binlog. Në faqen mysql.com ka një regjistrim .
Përmbledh të gjitha të thëna më sipër. Nëse ende nuk dëshironi të përdorni Orchestrator në modin failover, vendoseni atë në modin e monitorimit. Atëherë do të keni gjithmonë para syve një hartë të ndërveprimit të makinave MySQL dhe informacion të qartë mbi atë se çfarë lloji replikimi ka në çdo makinë, nëse slave-t janë në vonesë dhe, më e rëndësishmja, sa konsistentë janë ata me master-in!
Pyetjes evidente: "Si duhet tĂ« punojĂ« Orchestrator?" Ai duhet tĂ« zgjedhĂ« njĂ« master tĂ« ri nga skllavĂ«t aktualĂ« dhe pastaj tĂ« rikonfigurojĂ« tĂ« gjithĂ« skllavĂ«t me tĂ« (pikĂ«risht pĂ«r kĂ«tĂ« Ă«shtĂ« e nevojshme GTID; nĂ«se pĂ«rdoret mekanizmi i vjetĂ«r me binlog_name dhe binlog_pos, kalimi i skllavit nga masteri aktual nĂ« tĂ« riun Ă«shtĂ« thjesht e pamundur!). Para se tĂ« kishim Orchestrator, njĂ« herĂ« mĂ« doli tĂ« bĂ«ja gjithĂ« kĂ«tĂ« manualisht. Masteri i vjetĂ«r mbetej i ngjallur pĂ«r shkak tĂ« njĂ« kontrolluesi tĂ« gabuar Adaptec, kishte rreth 10 skllavĂ«. Duhej tĂ« kaloja VIP nga masteri nĂ« njĂ« nga skllavĂ«t dhe tĂ« rikonfiguroja tĂ« gjithĂ« skllavĂ«t e tjerĂ« me tĂ«. Sa ekrane mĂ« duhej tĂ« hapja, sa komanda tĂ« njĂ«kohshme tĂ« jepja⊠Duhej tĂ« prisja deri nĂ« orĂ«n 3 tĂ« mĂ«ngjesit, tĂ« heqja ngarkesĂ«n nga tĂ« gjithĂ« skllavĂ«t, pĂ«rveç dy, tĂ« bĂ«nte master makinĂ«n e parĂ« nga dy, menjĂ«herĂ« tĂ« lidhesha me makinĂ«n e dytĂ«, e pastaj tĂ« lidhesha me tĂ« gjithĂ« skllavĂ«t e tjerĂ« dhe ta ktheja ngarkesĂ«n. NĂ« pĂ«rgjithĂ«si, njĂ« tmerrâŠ
Si funksionon Orchestrator kur kalon nĂ« modin failover? ĂshtĂ« mĂ« e lehtĂ« ta tregosh me njĂ« shembull situate kur duam tĂ« bĂ«jmĂ« master njĂ« makinĂ« mĂ« tĂ« fuqishme dhe mĂ« moderne se ajo qĂ« kemi tani.
NĂ« skemĂ« paraqitet mesazhi i procesit. ĂfarĂ« ka ndodhur deri nĂ« kĂ«tĂ« moment? Ne thamĂ« se duam ta bĂ«jmĂ« njĂ« slave si njĂ« master tĂ« ri, Orchestrator filloi thjesht tĂ« riçkonte tĂ« gjithĂ« slave-t e tjerĂ« me tĂ«, ndĂ«rkohĂ« qĂ« master-i i ri luan rolin e makinĂ«s tranzite. Me kĂ«tĂ« skemĂ« nuk ndodhin gabime, tĂ« gjithĂ« slave-t funksionojnĂ«, Orchestrator hoqi VIP nga master-i i vjetĂ«r, e transferon tek i ri, e bĂ«n read_only=0 dhe harron pĂ«r master-in e vjetĂ«r. Mjaft! KohĂ«zgjatja e shĂ«rbimit tonĂ« Ă«shtĂ« koha e transferimit tĂ« VIP-it, kjo Ă«shtĂ« 2-3 sekonda.
Kjo është gjithçka për sot, faleminderit të gjithëve. Shpejt do të jetë artikulli i dytë për Orchestrator. Në një film të njohur sovjetik "Garazh", një personazh tha: "Unë s'do të shkoja në zbulim me të!" Pra, Orchestrator, unë do të shkoja në zbulim me ty!
Burimi: habr.com
