Orkestruesi për MySQL: pse nuk mund të ndërtoni një projekt tolerant ndaj gabimeve pa të

Çdo projekt i madh filloi me disa serverë. Në fillim kishte një server DB, më pas atij iu shtuan skllevër për të shkallëzuar leximin. Dhe pastaj - ndaloni! Ka një zotëri, por ka shumë skllevër; nëse njëri prej skllevërve largohet, atëherë gjithçka do të jetë mirë, por nëse mjeshtri largohet, do të jetë keq: koha e ndërprerjes, administratorët po përpiqen të ngrenë serverin. Çfarë duhet bërë? Rezervoni një mjeshtër. Kolegu im Pavel ka shkruar tashmë për këtë një artikull, nuk do ta përsëris. Në vend të kësaj, unë do t'ju them pse ju duhet patjetër Orkestratori për MySQL!

Le të fillojmë me pyetjen kryesore: "Si do ta kalojmë kodin në një makinë të re kur mjeshtri të largohet?"

• Më pëlqen më shumë skema me VIP (IP Virtual), do të flasim për të më poshtë. Është më e thjeshta dhe më e dukshme, megjithëse ka një kufizim të dukshëm: masteri që do të rezervojmë duhet të jetë në segmentin L2 me makinën e re, domethënë mund të harrojmë DC-në e dytë. Dhe, në mënyrë miqësore, nëse ndiqni rregullin që një L2 i madh është i keq, sepse L2 është vetëm për raft, dhe L3 është midis rafteve, dhe një skemë e tillë ka edhe më shumë kufizime.
• Ju mund të shkruani një emër DNS në kod dhe ta zgjidhni atë përmes /etc/hosts. Në fakt nuk do të ketë zgjidhje. Avantazhi i skemës: nuk ka karakteristikë kufizimi të metodës së parë, domethënë është e mundur të organizohet një ndër-DC. Por atëherë lind pyetja e qartë: sa shpejt mund ta dorëzojmë ndryshimin te /etc/hosts nëpërmjet Puppet-Ansible?
• Mund ta ndryshoni pak metodën e dytë: instaloni memorien e DNS në të gjithë serverët në internet, përmes të cilit kodi do të shkojë në bazën e të dhënave master. Mund të vendosni TTL 60 për këtë hyrje në DNS. Duket se nëse zbatohet siç duhet, metoda është e mirë.
• Një skemë me zbulim shërbimi, që nënkupton përdorimin e konsullit etj.
• Një opsion interesant me ProxySQL. Ju duhet të drejtoni të gjithë trafikun në MySQL përmes ProxySQL; vetë ProxySQL mund të përcaktojë se kush është master. Nga rruga, ju mund të lexoni në lidhje me një nga opsionet për përdorimin e këtij produkti në tim artikull.

Autori i Orchestrator, duke punuar në Github, fillimisht ka zbatuar skemën e parë me VIP, dhe më pas e ka kthyer në skemë me konsull.

Struktura tipike e infrastrukturës:

Unë do të përshkruaj menjëherë situatat e dukshme që duhet të merren parasysh:

• Adresa VIP nuk duhet të regjistrohet në konfigurimin në asnjë nga serverët. Le të imagjinojmë një situatë: mjeshtri u rindez dhe ndërsa po ngarkohej, Orkestratori kaloi në modalitetin failover dhe e bëri një nga skllevërit mjeshtër; pastaj mjeshtri i vjetër u ngrit, dhe tani VIP është në dy makina. Kjo është e keqe.
• Për orkestratorin, do t'ju duhet të shkruani një skenar për të thirrur mjeshtrin e vjetër dhe mjeshtrin e ri. Në masterin e vjetër ju duhet të ekzekutoni ifdown, dhe në masterin e ri - ifup vip. Do të ishte mirë të përfshihej gjithashtu në këtë skenar që në rast të një dështimi, porti në çelësin e vjetër të masterit thjesht fiket për të shmangur çdo ndarje të trurit.
• Pasi Orkestratori të ketë thirrur skriptin tuaj për të hequr fillimisht VIP-në dhe/ose për të fikur portin në çelës, dhe më pas ka thirrur skriptin e rritjes së VIP-së në masterin e ri, mos harroni të përdorni komandën arping për t'i treguar të gjithëve se VIP-i i ri është tani këtu.
• Të gjithë skllevërit duhet të kenë read_only=1, dhe sapo ta promovoni skllavin te masteri, ai duhet të ketë read_only=0.
• Mos harroni se çdo skllav që kemi zgjedhur për këtë mund të bëhet mjeshtër (Orkestratori ka një mekanizëm të tërë preferencash se cilin skllav të konsiderojë si kandidat për një zot të ri në radhë të parë, cili në radhë të dytë dhe cili skllav duhet të mos zgjidhet fare në asnjë rrethanë master). Nëse robi bëhet zot, atëherë mbi të do të mbetet ngarkesa e robit dhe do të shtohet ngarkesa e zotërisë, kjo duhet pasur parasysh.

Pse keni nevojë për Orkestrator nëse nuk keni një të tillë?

• Orkestratori ka një ndërfaqe grafike shumë miqësore për përdoruesit që shfaq të gjithë topologjinë (shih pamjen e ekranit më poshtë).
• Orkestratori mund të gjurmojë se cilët skllevër mbeten prapa dhe ku në përgjithësi është prishur riprodhimi (ne kemi skriptet e bashkangjitura te Orkestratori për dërgimin e SMS-ve).
• Orkestratori ju tregon se cilët skllevër kanë një gabim GTID.

Ndërfaqja e orkestruesit:

Çfarë është e gabuar GTID?

Ekzistojnë dy kërkesa kryesore që orkestratori të punojë:

• Është e nevojshme që pseudo GTID të aktivizohet në të gjitha makinat në grupin MySQL; ne kemi GTID të aktivizuar.
• Është e nevojshme që të ketë një lloj binlogesh kudo, mund të përdorni deklaratën. Ne kishim një konfigurim në të cilin masteri dhe shumica e skllevërve kishin Rreshtin, dhe dy historikisht mbetën në modalitetin Mixed. Si rezultat, Orkestratori thjesht nuk donte t'i lidhte këta skllevër me zotërinë e ri.

Mos harroni se gjëja më e rëndësishme në një skllav prodhimi është konsistenca e tij me zotërinë! Nëse keni të aktivizuar ID-në Globale të Transaksionit (GTID) si në master ashtu edhe në skllave, atëherë mund të përdorni funksionin gtid_subset për të zbuluar nëse të njëjtat kërkesa për ndryshime të të dhënave janë ekzekutuar në të vërtetë në këto makina. Ju mund të lexoni më shumë për këtë këtu.

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

• Read_only=1 nuk është aktivizuar në skllavë, dikush u lidh dhe plotësoi një kërkesë për të ndryshuar të dhënat.
• Super_read_only=1 nuk është aktivizuar në skllave, atëherë administratori, pasi ngatërroi serverin, hyri dhe ekzekutoi kërkesën atje.
• Nëse keni marrë parasysh të dyja pikat e mëparshme, atëherë ka një mashtrim më shumë: në MySQL, një kërkesë për të fshirë bilogët shkon gjithashtu në binlog, kështu që në fillimin e parë, një gabim GTID do të shfaqet te masteri dhe të gjithë skllevërit. Si ta shmangni këtë? Perona-5.7.25-28 prezantoi cilësimin binlog_skip_flush_commands=1, i cili ndalon shkrimin flush në binlog. Ekziston një i krijuar në faqen e internetit mysql.com insekt.

Më lejoni të përmbledh të gjitha sa më sipër. Nëse nuk dëshironi të përdorni ende Orchestrator në modalitetin e dështimit, atëherë vendoseni në modalitetin e vëzhgimit. Atëherë do të keni gjithmonë para syve një hartë të ndërveprimit të makinerive MySQL dhe informacione vizuale se çfarë lloj replikimi është në secilën makinë, nëse skllevërit mbeten prapa dhe më e rëndësishmja, sa të qëndrueshme janë me zotërinë!

Pyetja e qartë është: "Si duhet të funksionojë orkestratori?" Ai duhet të zgjedhë një master të ri nga skllevërit aktual dhe më pas të rilidhë të gjithë skllevërit me të (kjo është ajo për të cilën nevojitet GTID; nëse përdorni mekanizmin e vjetër me binlog_name dhe binlog_pos, atëherë kaloni një skllav nga masteri aktual në një të ri është thjesht e pamundur!). Përpara se të kishim Orkestratorin, një herë më duhej ta bëja të gjithë këtë me dorë. Mjeshtri i vjetër ishte i varur për shkak të një kontrolluesi Adaptec me karroca; kishte rreth 10 skllevër. Më duhej të transferoja VIP-në nga masteri te një prej skllevërve dhe të rilidhesha të gjithë skllevërit e tjerë me të. Sa konsola duhej të hapja, sa komanda të njëkohshme futa... Më duhej të prisja deri në orën 3 të mëngjesit, të hiqja ngarkesën nga të gjitha skllavërat përveç dy, të bëja makinën e parë nga dy master, të bashkangjisja menjëherë makinën e dytë. në të, kështu që bashkojini të gjithë skllevërit e tjerë me zotërinë e re dhe kthejeni ngarkesën. Në përgjithësi, e tmerrshme ...

Si funksionon Orkestratori kur kalon në modalitetin e dështimit? Kjo ilustrohet më lehtë nga një shembull i një situate ku ne duam ta bëjmë një mjeshtër një makinë më të fuqishme, më moderne se sa kemi tani.

Figura tregon mesin e procesit. Çfarë është bërë tashmë deri në këtë pikë? Ne thamë se donim të bënim një skllav mjeshtër të ri, Orkestratori filloi thjesht të rilidhë të gjithë skllevërit e tjerë me të, me mjeshtrin e ri që vepronte si një makinë tranziti. Me këtë skemë nuk ndodhin gabime, të gjithë skllevërit punojnë, Orkestratori heq VIP-në nga masteri i vjetër, e transferon te ai i ri, bën read_only=0 dhe harron masterin e vjetër. Të gjitha! Kohëzgjatja e shërbimit tonë është koha e transferimit VIP, e cila është 2-3 sekonda.

Kjo është e gjitha për sot, faleminderit të gjithëve. Së shpejti do të ketë një artikull të dytë për Orkestratorin. Në filmin e famshëm sovjetik "Garazh", një personazh tha: "Unë nuk do të shkoja në zbulim me të!" Pra, orkestrator, do të shkoja me ju në zbulim!

Burimi: www.habr.com