SITIMOBILis kasutame MySQL andmebaasi peamise püsivaremedinäiteks. Meil on mitu andmebaasi klastri erinevate teenuste ja eesmärkide jaoks.

Meisteri pidev kättesaadavus on kogu süsteemi ja selle üksikute osade töövõimekuse kriitiline näitaja. Meistri rikke korral automaatne klasteri taastamine vähendab oluliselt reageerimisaega ja süsteemi katkestusaega. Selles artiklis käsitlen MySQL klastri kõrge kättesaadavuse (HA) tagamise skeemi, mis põhineb MySQL Orchestrator ja virtuaalsetel IP-aadressidel (VIP).

VIP-põhine HA-lahendus

Alustuseks räägin lühidalt meie andmehoidmise süsteemi olemusest.

Kasutame klassikalist replikatsiooni, kus üks master on kirjutamisõigustega ja palju replikate, mis on ainult lugemiseks. Kluster võib sisaldada vahepealset masterit - sõlme, mis on samal ajal nii replikata kui ka teiste master. Kliendid suunavad replikatele läbi HAProxy, mis võimaldab koormuse ühtlast jaotamist ning lihtsat skaleerimist. HAProxy kasutamine tuleneb ajaloolistest põhjustest ning praegu oleme ProxSQL-ile üleminekul.

Replikatsioon toimub pool-sünkroonsetes tingimustes, mis põhinevad GTID. See tähendab, et vähemalt üks replik peab kogu kirjutama tehingu logisse, enne kui see tunnustatakse õnnestunuks. Selline replikatsiooni režiim tagab optimaalse tasakaalu jõudluse ja andmete säilitamise vahel peamise sõlme rikke korral. Enamik muudatusi edastatakse masterilt replikatele Row Based Replication (RBR), kuid osa sõlmi võib kasutada mixed binlog format.

Orkestrator uuendab aeg-ajalt klastrite topoloogia olekut, analüüsib saadud teavet ja võib probleemide korral alustada automaatse taastumise protseduuri. Taastumise eest vastutab arendaja, kuna selle rakendamine võib toimuda erinevatel viisidel: VIP, DNS, teenuste avastamise teenuste (service discovery) või kohandatud mehhanismide põhjal.

Üks lihtsamaid meetodeid meistri taastamiseks tema rikke korral on kasutada ujukiva VIP-aadresse.

Mida on vaja selles lahenduses teada, enne kui edasi liikuda:

VIP on IP-aadress, mis ei ole seotud konkreetse füüsilise võrgu liidesega. Kui sõlm rikki läheb või plaaniliste tööde ajal, saame VIP samadust teisele ressursile minimaalse seisakuga üle kanda.
Võrgu IP-aadressi vabastamine ja väljastamine on odavad ja kiired toimingud.
VIP kasutamiseks on vajalik juurdepääs serverile SSH kaudu või spetsiaalsete utiliitide kasutamine, näiteks keepalived.

Vaatame meie meistri võimalikke probleeme ja kirjeldame, kuidas automaatse taastumise mehhanism peaks toimima.

Ühenduvus peavõrku on kadunud või on tekkinud riistvaraline probleem ning server ei ole kättesaadav.

Orkestrator uuendab klastritopoloogiat, iga replikatsioon teatab peavõrgu kättesaamatuks. Orkestrator käivitab reklaampinna valimise protsessi, et leida sobiv replikatsioon uue peavõrgu rolli ning alustab taastamist.
Püüame eemaldada VIP vanalt peavõrgult — ebaõnnestunult.
Replikatsioon lülitub peavõrguks. Topoloogia ehitatakse ümber.
Lisame uue võrgu liidese VIP-iga. Kuna VIP eemaldamine ebaõnnestus, käivitame taustal perioodilise päringu saatmise. gratuitous ARP. See päringu/vastuse tüüp võimaldab värskendada ühendatud lülitites IP- ja MAC-aadresside vastavustabelit, teavitades seeläbi meie VIP-i liikumisest. See vähendab tõenäosust split brain vanema peavõrgu taastumise korral.
Kõik uued ühendused suunatakse kohe uuele peavõrgule. Vanad ühendused lõpetatakse ebaõnnestunult, rakendustasandil tehakse uuesti päringud andmebaasi.

Server töötab normaalses režiimis, andmebaasi tasandil on toimunud rike.

Algoritm on sarnane eelneva juhtumiga: topoloogia uuendamine ja taastamisprotsessi käivitamine. Kuna server on saadaval, vabastame me edukalt VIP-i vanalt masterilt, liigume selle uuele ja saadame mitu ARP-päringut. Võimalik naasmine vana masteri juurde ei tohi mõjutada rekonstrueeritud klastrit ja rakenduse tööd.

Teised probleemid

Replikate või vahepealsete masterite tõrge ei põhjusta automaatseid toiminguid ja nõuab käsitsi sekkumist.

Virtuaalne võrgu liides lisatakse alati ajutiselt, see tähendab, et serveri taaskäivitamisel VIP ei määrata automaatselt. Iga andmebaasi instants alustab vaikimisi ainult lugemisrežiimis, orkestreerija lülitab automaatselt uue masteri kirjutamisrežiimi ja proovib seada ainult lugemine vana masteri juurde. Need toimingud on suunatud tõenäosuse vähendamisele. split brain.

Taastamisprotsessi käigus võivad esineda probleemid, millest tasub samuti teavitada orkestreerija UI kaudu, lisaks standardsetele jälgimisvahenditele. Oleme laiendanud REST API-d, lisades sellise võimaluse (PR on praegu ülevaatamisel).

HA-lahenduse üldskeem on esitatud allpool.

Uue meistri valik

Orkestreerija on piisavalt nutikas ja püüab valida kõige sobivama repliika uueks meistriks järgmiste kriteeriumide alusel:

repliika mahajäämus meistri ees;
MySQL meistri ja repliika versioon;
replikatsiooni tüüp (RBR, SBR või segatud);
asukoht ühes või erinevates andmesaalides;
olemasolu errant GTID — tehingud, mis on repliikas täidetud ja puuduvad meistris;
arvesse võetakse ka kasutaja valikureegleid.

Kuid iga repliika ei ole ideaalne kandidaat meistriks. Näiteks võib repliikat kasutada andmete varundamiseks või serveril võib olla nõrgem riistvara konfiguratsioon. Orkestreerija toetab käsi-reeglid, millega saab seadistada oma eelistusi kandidaadi valimiseks alates kõige eelistatumast kuni ignoreeritavani.

Reageerimise ja taastumise aeg

Juhtumi korral on oluline minimeerida süsteemi seiskumise aega, seetõttu vaatame MySQL parameetreid, mis mõjutavad orkestreerija klastritopoloogia ehitamist ja uuendamist:

slave_net_timeout — sekunde, mille replikatsioon ootab uute andmete või südame signaalide vastuvõtmist meistrilt, enne kui ühendus tunnistatakse kadunuks ja viiakse läbi uuesti ühendamine. Mida väiksem väärtus, seda kiiremini suudab replikatsioon tuvastada, et ühendus meistriga on katkenud. Seetõttu seame selle väärtuse 5 sekundiks.
MASTER_CONNECT_RETRY — sekundite arv, mis kulub uuesti ühendamise katsete vahel. Võrguprobleemide korral võimaldab madal väärtus kiiresti uuesti ühendada ja takistada kaskaadi taastumisprotsessi käivitumist. Soovitatav väärtus on 1 sekund.
MASTER_RETRY_COUNT — maksimaalne uuesti ühendamise katsete arv.
MASTER_HEARTBEAT_PERIOD — sekundi intervall, pärast mida meister saadab südame signaali. Vaikimisi on see pool slave_net_timeout.

Orkestratori seaded:

DelayMasterPromotionIfSQLThreadNotUpToDate — kui see on true, siis ei rakendata meistri rolli kandidaat-replikatsioonis enne, kui repliika SQL-voog on täitnud kõik rakendamata tehingud Relay Logist. Kasutame seda võimalust, et vältida tehingute kaotamist kõikide kandidaatreplika ülejäägiga.
InstancePollSeconds — topoloogia koostamise ja uuendamise sagedus.
RecoveryPollSeconds — topoloogia analüüsi sagedus. Probleemi tuvastamisel käivitatakse topoloogia taastamine. See on konstant, mille väärtus on 1 sekund.

Iga klastrisõlme küsitletakse orkestratori poolt kord InstancePollSeconds sekundi jooksul. Probleemi tuvastamisel värskendatakse klastri olekut sundlikult , seejärel tehakse lõplik otsus taastamise teostamise kohta. Katsetades erinevate andmebaasi ja orkestratori parameetritega, suutsime reageerimise ja taastamise kestuse vähendada 30 sekundi peale.HA-skeemi testimine algas kohaliku

Teststand

testimisseadmestiku arendamisest ja edasise rakendamisega test- ja tootmiskeskkondades. Kohalik seade on täielikult automatiseeritud Docker'i alusel ja võimaldab eksperimenteerida orkestratori ja võrgu konfigureerimisega, skaleerida klastrit 2-3 serverilt kuni mitme kümnendini ja korraldada harjutusi turvalises keskkonnas. Harjutuste käigus valime ühe probleemide emuleerimise meetodi: masteri kohe eemaldamine

, protsessi pehme lõpetamine ja serveri peatamine ( kill -9docker-compose stopdocker-compose peata), simuleerida võrguprobleeme kasutades iptables -j REJECT või iptables -j DROP. Me ootame selliseid tulemusi:

orkestrator tuvastab probleeme meistri ja värskendab topoloogiat mitte hiljem kui 10 sekundi jooksul;
protseduur taastamine käivitatakse automaatselt: võrgu konfiguratsioon muutub, meistri roll läheb replikale, topoloogia rekonstrueeritakse;
uus meister on kirjutamiseks saadaval, elavad replikad ei kao rekonstrueerimise käigus;
andmed hakkavad kirjutama uude meistrisse ja replikatsioon käivitub;
kokkuvõttes taastamise aeg on mitte rohkem kui 30 sekundit.

Nagu te teate, võib süsteem käituda erinevalt test- ja tootmisringkondades erineva «raha» ja võrgu konfiguratsiooni tõttu, samuti sünteetilise ja reaalse koormuse erinevuste tõttu jne. Seetõttu korraldame perioodiliselt tegelikke harjutusi, kontrollides, kuidas süsteem käitub võrguühenduse kadumise või selle üksikute osade halvenemise korral. Tulevikus tahame luua täielikult identse infrastruktuuri mõlema keskkonna jaoks ja automatiseerida selle testimise.

Järeldused

Andmete salvestamise põhisaidi toimivus on SRE ja haldusteamile üks peamisi ülesandeid. Orkestri ja HA-lahenduse põhjal VIP kasutuselevõtt on võimaldanud saavutada järgmisi tulemusi:

usaldusväärne DB klusteri topoloogia probleemide tuvastamine;
automaatsed ja kiire reageerimine probleemide korral, mis on seotud masteriga, mis vähendab süsteemi seisakuaega.

Kuid lahendusel on oma piirangud ja puudused:

HA-skeemi laiendamine mitmesse andmekeskusesse nõuab ühtset L2-võrku nende vahel;
enne VIP määramist uuele masterile peame selle vanalt vabastama. Protsess on järkjärguline, mis pikendab taastumisaega;
VIP vabastamine nõuab SSH-juurdepääsu serverile või mõnda muud kaugprotseduuride väljakutsumise meetodit. Kuna server või DB kogeb probleeme, mis käivitas taastamisprotsessi, ei saa me olla kindlad, et VIP-i eemaldamine õnnestub. See võib põhjustada kahte serverit sama virtuaalse IP-aadressiga ja probleemid. split brain.

Probleemide vältimiseks split brain, võib kasutada meetodit STONITH («Tulista teist sõlme pähe»), mis isoleerib või keelab probleemse sõlme. On ka teisi viise klastrite kõrge kättesaadavuse rakendamiseks: VIP ja DNS kombinatsioon, teenuste avastamine ja puhverserverite teenused, sünkroonne replikatsioon ja muud meetodid, milles on oma eelised ja puudused.

Rääkisin meie lähenemisest MySQLi veakindla klastrite loomisele. See on lihtne rakendada ja tagab aktsepteeritava usaldusväärsuse taseme praegustes tingimustes. Kogu süsteemi ja põhivõrgu arenedes muutub see lähenemine kindlasti.

Allikas: habr.com