Në Citymobil ne përdorim një bazë të dhënash MySQL si ruajtjen tonë të vazhdueshme të të dhënave. Ne kemi disa grupe të dhënash për shërbime dhe qëllime të ndryshme.

Disponueshmëria e vazhdueshme e masterit është një tregues kritik i performancës së të gjithë sistemit dhe pjesëve të tij individuale. Rikuperimi automatik i grupit në rast të një dështimi master redukton shumë kohën e reagimit ndaj incidentit dhe kohën e ndërprerjes së sistemit. Në këtë artikull, unë do të shikoj një dizajn me disponueshmëri të lartë (HA) për një grupim MySQL bazuar në Orkestratori MySQL dhe adresat IP virtuale (VIP).

Zgjidhje HA bazuar në VIP

Së pari, unë do t'ju tregoj shkurtimisht se cili është sistemi ynë i ruajtjes së të dhënave.

Ne përdorim një skemë klasike replikimi me një master të aksesueshëm për shkrim dhe kopje të shumta vetëm për lexim. Një grup mund të përmbajë një master të ndërmjetëm - një nyje që është njëkohësisht një kopje dhe një master për të tjerët. Klientët aksesojnë kopjet përmes HAProxy, i cili lejon shpërndarje të barabartë të ngarkesës dhe shkallëzim të lehtë. Përdorimi i HAProxy është për arsye historike dhe aktualisht jemi në proces të migrimit në ProxySQL.

Replikimi kryhet në mënyrë gjysmë sinkron bazuar në GTID. Kjo do të thotë që të paktën një kopje duhet të regjistrojë një transaksion përpara se të konsiderohet i suksesshëm. Kjo mënyrë riprodhimi siguron një ekuilibër optimal midis performancës dhe sigurisë së të dhënave në rast të dështimit të nyjes kryesore. Në thelb të gjitha ndryshimet transferohen nga master në kopjet duke përdorur Row Based Replication (RBR), por disa nyje mund të kenë mixed binlog format.

Orkestratori përditëson periodikisht gjendjen e topologjisë së grupit, analizon informacionin e marrë dhe nëse lindin probleme, mund të nisë një procedurë rikuperimi automatik. Zhvilluesi është përgjegjës për vetë procedurën, pasi ajo mund të zbatohet në mënyra të ndryshme: bazuar në VIP, DNS, duke përdorur shërbime të zbulimit të shërbimit ose mekanizma të vetë-shkruar.

Një mënyrë e thjeshtë për të rivendosur një master nëse dështon është përdorimi i adresave VIP lundruese.

Çfarë duhet të dini për këtë zgjidhje përpara se të ecni përpara:

Një VIP është një adresë IP që nuk është e lidhur me një ndërfaqe të caktuar fizike të rrjetit. Nëse një nyje dështon ose gjatë mirëmbajtjes së planifikuar, ne mund ta kalojmë VIP-në në një burim tjetër me kohë minimale joproduktive.
Lirimi dhe lëshimi i një adrese IP virtuale është një operacion i lirë dhe i shpejtë.
Për të punuar me VIP, ju duhet qasje në server nëpërmjet SSH, ose përdorimi i shërbimeve të veçanta, për shembull, keepalived.

Le të shohim problemet e mundshme me magjistarin tonë dhe të imagjinojmë se si duhet të funksionojë mekanizmi automatik i rikuperimit.

Lidhja e rrjetit me masterin është zhdukur ose ka lindur një problem në nivelin e harduerit dhe serveri nuk është i disponueshëm

Orkestratori përditëson topologjinë e grupimit, çdo kopje raporton se masteri nuk është i disponueshëm. Orkestratori fillon procesin e zgjedhjes së një kopjeje të përshtatshme për rolin e mjeshtrit të ri dhe fillon rikuperimin.
Ne po përpiqemi të heqim VIP-in nga mjeshtri i vjetër - pa sukses.
Replika kalon në rolin e mjeshtrit. Topologjia po rindërtohet.
Shtimi i një ndërfaqe të re rrjeti me VIP. Meqenëse nuk ishte e mundur të hiqni VIP-in, ne fillojmë të dërgojmë periodikisht një kërkesë në sfond ARP falas. Ky lloj kërkese/përgjigje ju lejon të përditësoni tabelën e hartës së adresave IP dhe MAC në çelësat e lidhur, duke ju njoftuar kështu që VIP-ja jonë është zhvendosur. Kjo minimizon gjasat split brain kur kthente mjeshtrin e vjetër.
Të gjitha lidhjet e reja ridrejtohen menjëherë te masteri i ri. Lidhjet e vjetra dështojnë dhe thirrjet e përsëritura në bazën e të dhënave bëhen në nivelin e aplikacionit.

Serveri funksionon në modalitetin normal, ndodhi një dështim në nivelin DBMS

Algoritmi është i ngjashëm me rastin e mëparshëm: përditësimi i topologjisë dhe fillimi i procesit të rikuperimit. Meqenëse serveri është i disponueshëm, ne lëshojmë me sukses VIP-në në masterin e vjetër, e transferojmë atë në atë të ri dhe dërgojmë disa kërkesa ARP. Kthimi i mundshëm i masterit të vjetër nuk duhet të ndikojë në grupin e rindërtuar dhe funksionimin e aplikacionit.

Probleme të tjera

Dështimi i kopjeve ose mjeshtrave të ndërmjetëm nuk udhëheq ndaj veprimeve automatike dhe kërkon ndërhyrje manuale.

Një ndërfaqe e rrjetit virtual shtohet gjithmonë përkohësisht, domethënë, pas rindezjes së serverit, VIP nuk caktohet automatikisht. Çdo shembull i bazës së të dhënave fillon në modalitetin vetëm për lexim si parazgjedhje, orkestratori e ndërron automatikisht masterin e ri për të shkruar dhe përpiqet të instalojë read only mbi mjeshtrin e vjetër. Këto veprime kanë për qëllim zvogëlimin e gjasave split brain.

Problemet mund të lindin gjatë procesit të rikuperimit, i cili duhet të njoftohet gjithashtu nëpërmjet UI-së së orkestruesit, përveç mjeteve standarde të monitorimit. Ne kemi zgjeruar API-në REST duke shtuar këtë veçori (PR aktualisht në shqyrtim).

Diagrami i përgjithshëm i zgjidhjes HA është paraqitur më poshtë.

Zgjedhja e një mjeshtri të ri

Orkestratori është mjaft i zgjuar dhe përpiqet të zgjedhë kopja më e përshtatshme si master i ri sipas kritereve të mëposhtme:

kopja mbetet pas mjeshtrit;
Versioni MySQL i master dhe kopje;
lloji i përsëritjes (RBR, SBR ose i përzier);
vendndodhjen në qendra të njëjta ose të ndryshme të të dhënave;
наличие errant GTID — transaksionet që janë ekzekutuar në kopje dhe nuk janë në master;
merren parasysh edhe rregullat e përzgjedhjes me porosi.

Jo çdo sugjerim është një kandidat ideal për një master. Për shembull, një kopje mund të përdoret për të kopjuar të dhënat, ose serveri ka një konfigurim më të dobët të harduerit. Orkestruesi mbështet rregullat manuale me të cilat mund të personalizoni preferencat tuaja të përzgjedhjes së kandidatëve nga më të preferuarat tek ato të shpërfillura.

Koha e reagimit dhe e rikuperimit

Në rast incidenti, është e rëndësishme të minimizoni kohën e ndërprerjes së sistemit, kështu që le të shqyrtojmë parametrat MySQL që ndikojnë në krijimin dhe përditësimin e topologjisë së grupimit nga orkestratori:

slave_net_timeout — numri i sekondave gjatë të cilave kopja pret të mbërrijë të dhëna të reja ose një sinjal rrahjeje zemre nga masteri përpara se lidhja të njihet si e humbur dhe të rilidhet. Sa më e ulët të jetë vlera, aq më shpejt kopja mund të përcaktojë se komunikimi me masterin është i prishur. Ne e vendosëm këtë vlerë në 5 sekonda.
MASTER_CONNECT_RETRY — numri i sekondave ndërmjet përpjekjeve për rilidhje. Në rast problemesh në rrjet, një vlerë e ulët për këtë parametër do të lejojë rilidhjen e shpejtë dhe do të parandalojë fillimin e procesit të rikuperimit të grupit. Vlera e rekomanduar është 1 sekondë.
MASTER_RETRY_COUNT — numri maksimal i përpjekjeve për rilidhje.
MASTER_HEARTBEAT_PERIOD — intervali në sekonda pas së cilës mjeshtri dërgon një sinjal të rrahjeve të zemrës. Parazgjedhur në gjysmën e vlerës slave_net_timeout.

Opsionet e orkestruesit:

DelayMasterPromotionIfSQLThreadNotUpToDate - nëse është e barabartë true, atëherë roli kryesor nuk do të zbatohet në kopjen e kandidatit derisa thread-i SQL i replikës të ketë përfunduar të gjitha transaksionet e pazbatuara nga Regjistri Relay. Ne e përdorim këtë opsion për të shmangur humbjen e transaksioneve kur të gjitha kopjet e kandidatëve bien prapa.
InstancePollSeconds — Frekuenca e ndërtimit dhe përditësimit të topologjisë.
RecoveryPollSeconds — frekuenca e analizës së topologjisë. Nëse zbulohet një problem, fillon rikuperimi i topologjisë. Kjo konstante, e barabartë me 1 sekondë.

Çdo nyje klaster anketohet nga orkestratori një herë në çdo InstancePollSeconds sekonda Kur zbulohet një problem, gjendja e grupimit detyrohet përditësuar, dhe më pas merret vendimi përfundimtar për kryerjen e rikuperimit. Duke eksperimentuar me parametra të ndryshëm të bazës së të dhënave dhe orkestruesit, ne mundëm të reduktonim kohën e përgjigjes dhe rikuperimit në 30 sekonda.

Stand testimi

Ne filluam testimin e skemës HA me zhvillimin e një lokali stol provë dhe zbatimi i mëtejshëm në mjediset e testimit dhe prodhimit. Stenda lokale është plotësisht e automatizuar bazuar në Docker dhe ju lejon të eksperimentoni me konfigurimin e orkestruesit dhe rrjetit, të shkallëzoni grupin nga 2-3 serverë në disa dhjetëra dhe të kryeni ushtrime në një mjedis të sigurt.

Gjatë ushtrimeve, ne zgjedhim një nga metodat e emulimit të problemit: qëlloni menjëherë masterin duke përdorur kill -9, mbyllni butësisht procesin dhe ndaloni serverin (docker-compose stop), simuloni problemet e rrjetit duke përdorur iptables -j REJECT ose iptables -j DROP. Ne presim rezultatet e mëposhtme:

orkestratori do të zbulojë problemet me masterin dhe do të përditësojë topologjinë në jo më shumë se 10 sekonda;
procedura e rikuperimit do të fillojë automatikisht: konfigurimi i rrjetit do të ndryshojë, roli i masterit do të kalojë në kopje, topologjia do të rindërtohet;
masteri i ri do të bëhet i shkrueshëm, kopjet e drejtpërdrejta nuk do të humbasin gjatë procesit të rindërtimit;
të dhënat do të fillojnë të shkruhen në masterin e ri dhe të përsëriten;
Koha totale e rikuperimit nuk do të jetë më shumë se 30 sekonda.

Siç e dini, sistemi mund të sillet ndryshe në mjediset e testimit dhe prodhimit për shkak të konfigurimeve të ndryshme të harduerit dhe rrjetit, ndryshimeve në ngarkesën sintetike dhe reale, etj. Prandaj, ne kryejmë periodikisht ushtrime në kushte reale, duke kontrolluar se si sillet sistemi kur lidhja e rrjetit humbet ose pjesët e tij individuale degradohen. Në të ardhmen, ne duam të ndërtojmë një infrastrukturë krejtësisht identike për të dy mjediset dhe të automatizojmë testimin e saj.

Gjetjet

Shëndeti i nyjës kryesore të sistemit të ruajtjes është një nga detyrat kryesore të SRE dhe ekipit të operacioneve. Zbatimi i zgjidhjes së orkestruesit dhe HA bazuar në VIP na lejoi të arrijmë rezultatet e mëposhtme:

zbulim i besueshëm i problemeve me topologjinë e grupit të bazës së të dhënave;
përgjigje automatike dhe e shpejtë ndaj incidenteve të lidhura me masterin, duke reduktuar kohën e ndërprerjes së sistemit.

Sidoqoftë, zgjidhja ka kufizimet dhe disavantazhet e saj:

shkallëzimi i skemës HA në disa qendra të dhënash do të kërkojë një rrjet të vetëm L2 ndërmjet tyre;
Para se të caktojmë VIP në masterin e ri, duhet ta lëshojmë atë në atë të vjetër. Procesi është sekuencial, gjë që rrit kohën e rikuperimit;
lëshimi i VIP-it kërkon qasje SSH në server, ose ndonjë metodë tjetër të thirrjes së procedurave në distancë. Meqenëse serveri ose baza e të dhënave po përjetojnë probleme që shkaktuan procesin e rikuperimit, nuk mund të jemi të sigurt që heqja e VIP-ave do të përfundojë me sukses. Dhe kjo mund të çojë në shfaqjen e dy serverëve me të njëjtën adresë IP virtuale dhe një problem split brain.

Per te shmangur split brain, mund të përdorni metodën STONITH ("Gjuaj nyjen tjetër në kokë"), e cila izolon ose çaktivizon plotësisht nyjen problematike. Ka mënyra të tjera për të zbatuar disponueshmërinë e lartë të grupeve: një kombinim i VIP dhe DNS, zbulimi i shërbimit dhe shërbimet proxy, riprodhimi sinkron dhe metoda të tjera që kanë disavantazhet dhe avantazhet e tyre.

Unë fola për qasjen tonë për krijimin e një grupi të dështimit të MySQL. Është e lehtë për t'u zbatuar dhe siguron një nivel të pranueshëm besueshmërie në kushtet aktuale. Ndërsa i gjithë sistemi në përgjithësi dhe infrastruktura në veçanti zhvillohen, kjo qasje pa dyshim do të evoluojë.

Burimi: www.habr.com

Orkestruesi dhe VIP si një zgjidhje HA për një grup MySQL