V Citymobilu uporabljamo podatkovno bazo MySQL kot glavno trajno shrambo podatkov. Imamo več gruč baz podatkov za različne storitve in namene.

Stalna razpoložljivost masterja je kritičen pokazatelj delovanja celotnega sistema in njegovih posameznih delov. Samodejna obnovitev gruče v primeru glavne okvare močno skrajša odzivni čas incidenta in izpad sistema. V tem članku si bom ogledal zasnovo visoke razpoložljivosti (HA) za gručo MySQL, ki temelji na Orkestrator MySQL in navideznih naslovov IP (VIP).

HA rešitev, ki temelji na VIP

Najprej vam bom na kratko povedal, kaj je naš sistem za shranjevanje podatkov.

Uporabljamo klasično replikacijsko shemo z enim zapisovalno dostopnim masterjem in več replikami samo za branje. Grozd lahko vsebuje vmesni master – vozlišče, ki je tako replika kot master za druge. Stranke dostopajo do replik prek HAProxy, ki omogoča enakomerno porazdelitev obremenitve in enostavno skaliranje. Uporaba HAProxy je posledica zgodovinskih razlogov in trenutno smo v procesu selitve na ProxySQL.

Replikacija se izvaja v polsinhronem načinu na podlagi GTID. To pomeni, da mora vsaj ena replika zabeležiti transakcijo, preden se šteje za uspešno. Ta način replikacije zagotavlja optimalno ravnotežje med zmogljivostjo in varnostjo podatkov v primeru okvare glavnega vozlišča. V bistvu se vse spremembe prenesejo iz glavnega v replike z uporabo Row Based Replication (RBR), vendar nekatera vozlišča morda imajo mixed binlog format.

Orkestrator občasno posodablja stanje topologije gruče, analizira prejete informacije in v primeru težav lahko sproži postopek samodejne obnovitve. Za sam postopek je odgovoren razvijalec, saj ga je mogoče implementirati na različne načine: na podlagi VIP, DNS, z uporabo storitev odkrivanja storitev ali samonapisanih mehanizmov.

Eden preprostih načinov za obnovitev masterja, če ne uspe, je uporaba plavajočih naslovov VIP.

Kaj morate vedeti o tej rešitvi, preden nadaljujete:

VIP je naslov IP, ki ni povezan z določenim fizičnim omrežnim vmesnikom. Če vozlišče odpove ali med načrtovanim vzdrževanjem, lahko VIP preklopimo na drug vir z minimalnimi izpadi.
Sprostitev in izdaja virtualnega naslova IP je poceni in hiter postopek.
Za delo z VIP potrebujete dostop do strežnika prek SSH ali uporabo posebnih pripomočkov, na primer keepalived.

Oglejmo si morebitne težave z našim čarovnikom in si zamislimo, kako naj deluje mehanizem samodejne obnovitve.

Omrežna povezljivost z glavnim je izginila ali pa se je pojavila težava na ravni strojne opreme in strežnik ni na voljo

Orkestrator posodobi topologijo gruče, vsaka replika poroča, da glavni ni na voljo. Orkestrat začne postopek izbire replike, primerne za vlogo novega mojstra, in začne okrevanje.
Poskušamo odstraniti VIP od starega mojstra - brez uspeha.
Replika preide v vlogo mojstra. Topologija se obnavlja.
Dodajanje novega omrežnega vmesnika z VIP. Ker ni bilo mogoče odstraniti VIP-ja, začnemo občasno pošiljati zahteve v ozadju brezplačni ARP. Ta vrsta zahteve/odgovora vam omogoča, da posodobite tabelo preslikave naslovov IP in MAC na povezanih stikalih, s čimer vas obvestimo, da se je naš VIP premaknil. To zmanjša verjetnost split brain ob vrnitvi starega gospodarja.
Vse nove povezave so takoj preusmerjene na novo glavno enoto. Stare povezave ne uspejo in ponavljajoči se klici v bazo podatkov se izvajajo na ravni aplikacije.

Strežnik deluje v normalnem načinu, prišlo je do napake na ravni DBMS

Algoritem je podoben prejšnjemu primeru: posodobitev topologije in začetek postopka obnovitve. Ker je strežnik na voljo, uspešno sprostimo VIP na starem masterju, ga prenesemo na novega in pošljemo več ARP zahtev. Morebitna vrnitev starega masterja ne bi smela vplivati na prenovljeno gručo in delovanje aplikacije.

Druge težave

Napaka replik ali vmesnih mojstrov ne vodi do samodejnih dejanj in zahteva ročno posredovanje.

Navidezni omrežni vmesnik je vedno dodan začasno, to pomeni, da po ponovnem zagonu strežnika VIP ni samodejno dodeljen. Vsak primerek baze podatkov se privzeto zažene v načinu samo za branje, orkestrator samodejno preklopi novo glavno zbirko na pisanje in poskuša namestiti read only na starega mojstra. Ti ukrepi so namenjeni zmanjšanju verjetnosti split brain.

Med postopkom obnovitve lahko pride do težav, o katerih je poleg standardnih orodij za spremljanje treba obvestiti tudi prek uporabniškega vmesnika orkestratorja. API REST smo razširili z dodajanjem te funkcije (PR trenutno v pregledu).

Splošni diagram rešitve HA je predstavljen spodaj.

Izbira novega gospodarja

Orkestrat je dovolj pameten in poskuša izbrati najprimernejša replika kot novi mojster po naslednjih kriterijih:

replika zaostaja za mojstrom;
MySQL različica master in replike;
vrsta replikacije (RBR, SBR ali mešana);
lokacijo v istem ali različnih podatkovnih centrih;
razpoložljivost errant GTID — transakcije, ki so bile izvedene na replici in niso na glavnem;
upoštevana so tudi pravila izbire po meri.

Vsaka iztočnica ni idealen kandidat za mojstra. Za varnostno kopiranje podatkov je na primer mogoče uporabiti repliko ali pa ima strežnik šibkejšo konfiguracijo strojne opreme. Orkestrator podpira ročna pravila, s katerimi lahko prilagodite svoje izbirne nastavitve kandidatov od najbolj priljubljenih do prezrtih.

Odzivnost in čas okrevanja

V primeru incidenta je pomembno zmanjšati izpade sistema, zato razmislimo o parametrih MySQL, ki vplivajo na ustvarjanje in posodabljanje topologije gruče s strani orkestratorja:

slave_net_timeout — število sekund, med katerimi replika čaka na nove podatke ali signal srčnega utripa, ki prispe od glavne enote, preden je povezava prepoznana kot izgubljena in ponovno vzpostavljena. Nižja kot je vrednost, hitreje lahko replika ugotovi, da je komunikacija z glavno enoto prekinjena. To vrednost nastavimo na 5 sekund.
MASTER_CONNECT_RETRY — število sekund med poskusi ponovne povezave. V primeru težav z omrežjem bo nizka vrednost tega parametra omogočila hitro ponovno povezavo in preprečila zagon postopka obnovitve gruče. Priporočena vrednost je 1 sekunda.
MASTER_RETRY_COUNT — največje število poskusov ponovne povezave.
MASTER_HEARTBEAT_PERIOD — interval v sekundah, po katerem master pošlje signal srčnega utripa. Privzeto na polovico vrednosti slave_net_timeout.

Možnosti orkestracije:

DelayMasterPromotionIfSQLThreadNotUpToDate - če je enako true, potem glavna vloga ne bo uporabljena za repliko kandidata, dokler nit SQL replike ne dokonča vseh neuporabljenih transakcij iz dnevnika releja. To možnost uporabljamo, da se izognemo izgubi transakcij, ko vse kandidatne replike zaostanejo.
InstancePollSeconds — pogostost gradnje in posodabljanja topologije.
RecoveryPollSeconds — pogostost analize topologije. Če je zaznana težava, se sproži obnovitev topologije. to konstantna, enako 1 sekundi.

Orkestrator enkrat vpraša vsako vozlišče gruče InstancePollSeconds sekund Ko je zaznana težava, je stanje gruče vsiljeno posodobljeno, nato pa se sprejme dokončna odločitev o obnovitvi. Z eksperimentiranjem z različnimi parametri podatkovne baze in orkestratorja smo lahko skrajšali odziv in čas obnovitve na 30 sekund.

Testno stojalo

Shemo HA smo začeli testirati z razvojem lokalnega testna miza in nadaljnja implementacija v testnih in produkcijskih okoljih. Lokalno stojalo je popolnoma avtomatizirano na podlagi Dockerja in vam omogoča eksperimentiranje s konfiguracijo orkestratorja in omrežja, povečanje gruče od 2-3 strežnikov do več deset in izvajanje vaj v varnem okolju.

Med vajami izberemo enega od načinov posnemanja problema: takoj ustrelimo mojstra z uporabo kill -9, mehko zaključite proces in zaustavite strežnik (docker-compose stop), simulirajte težave z omrežjem z uporabo iptables -j REJECT ali iptables -j DROP. Pričakujemo naslednje rezultate:

orkestrator bo zaznal težave z masterjem in posodobil topologijo v največ 10 sekundah;
postopek obnovitve se bo samodejno začel: konfiguracija omrežja se bo spremenila, vloga masterja bo prešla na repliko, topologija bo obnovljena;
novi master bo postal zapisljiv, žive replike ne bodo izgubljene med postopkom obnove;
podatki se bodo začeli zapisovati na novo glavno enoto in replicirati;
Skupni čas okrevanja ne bo daljši od 30 sekund.

Kot veste, se lahko sistem v preskusnem in produkcijskem okolju obnaša drugače zaradi različnih konfiguracij strojne opreme in omrežja, razlik v sintetični in dejanski obremenitvi itd. Zato občasno izvajamo vaje v realnih razmerah, kjer preverjamo, kako se sistem obnaša ob izgubi omrežne povezljivosti ali degradaciji posameznih delov. V prihodnosti želimo zgraditi popolnoma enako infrastrukturo za obe okolji in avtomatizirati njeno testiranje.

Ugotovitve

Zdravje glavnega vozlišča sistema za shranjevanje je ena od glavnih nalog SRE in operativne ekipe. Implementacija orkestratorja in rešitve HA na osnovi VIP nam je omogočila doseganje naslednjih rezultatov:

zanesljivo odkrivanje težav s topologijo gruče baze podatkov;
samodejni in hitri odziv na incidente, povezane z glavno enoto, kar zmanjša čas izpadov sistema.

Vendar ima rešitev svoje omejitve in slabosti:

prilagajanje sheme HA na več podatkovnih centrov bo zahtevalo eno samo omrežje L2 med njimi;
Preden dodelimo VIP na novem masterju, ga moramo sprostiti na starem. Postopek poteka zaporedno, kar poveča čas okrevanja;
sprostitev VIP zahteva dostop SSH do strežnika ali katero koli drugo metodo klicanja oddaljenih procedur. Ker ima strežnik ali baza podatkov težave, ki so povzročile postopek obnovitve, ne moremo biti prepričani, da se bo odstranitev VIP-ja uspešno končala. In to lahko privede do pojava dveh strežnikov z istim virtualnim naslovom IP in težave split brain.

Izogniti se split brain, lahko uporabite metodo STONITH (»Shoot The Other Node In The Head«), ki popolnoma izolira ali onemogoči težavno vozlišče. Obstajajo tudi drugi načini za implementacijo visoke razpoložljivosti gruče: kombinacija VIP in DNS, storitev odkrivanja storitev in posredniških storitev, sinhrono podvajanje in druge metode, ki imajo svoje slabosti in prednosti.

Govoril sem o našem pristopu k ustvarjanju samodejne gruče MySQL. Je enostaven za izvedbo in zagotavlja sprejemljivo raven zanesljivosti v trenutnih razmerah. Z razvojem celotnega sistema na splošno in zlasti infrastrukture se bo ta pristop nedvomno razvijal.

Vir: www.habr.com

Orchestrator in VIP kot rešitev HA za gručo MySQL