Við hjá Citymobil notum MySQL gagnagrunn sem okkar helsta viðvarandi gagnageymslu. Við höfum nokkra gagnagrunnsklasa fyrir ýmsa þjónustu og tilgang.

Stöðugt aðgengi meistarans er mikilvægur vísbending um frammistöðu alls kerfisins og einstakra hluta þess. Sjálfvirk klasabati ef aðalbilun kemur upp dregur verulega úr viðbragðstíma atvika og niður í kerfi. Í þessari grein mun ég skoða hönnun með háu framboði (HA) fyrir MySQL þyrping byggt á MySQL hljómsveitarstjóri og sýndar IP tölur (VIP).

HA lausn byggð á VIP

Fyrst skal ég segja þér stuttlega hvað gagnageymslukerfið okkar er.

Við notum klassískt afritunarkerfi með einum skrifaðgengilegum master og mörgum skrifvarandi eftirmyndum. Þyrping getur innihaldið millimeistara - hnút sem er bæði eftirmynd og meistari fyrir aðra. Viðskiptavinir fá aðgang að eftirlíkingum í gegnum HAProxy, sem gerir kleift að dreifa álagi jafna og auðvelda stærðarstærð. Notkun HAProxy er af sögulegum ástæðum og við erum núna að fara yfir í ProxySQL.

Afritun er framkvæmd í hálf-samstilltum ham byggt á GTID. Þetta þýðir að að minnsta kosti ein eftirmynd verður að skrá færslu áður en hún telst vel heppnuð. Þessi afritunarhamur veitir ákjósanlegu jafnvægi milli frammistöðu og gagnaöryggis ef bilun verður í aðalhnút. Í grundvallaratriðum eru allar breytingar fluttar frá skipstjóranum til eftirmyndanna með því að nota Row Based Replication (RBR), en sumir hnútar kunna að hafa mixed binlog format.

Hljómsveitarstjórinn uppfærir reglulega stöðu þyrpunnar, greinir upplýsingarnar sem berast og ef vandamál koma upp getur hann ræst sjálfvirka endurheimtunarferli. Framkvæmdaraðilinn er ábyrgur fyrir málsmeðferðinni sjálfri, þar sem hægt er að útfæra hana á mismunandi vegu: byggt á VIP, DNS, með því að nota þjónustuuppgötvunarþjónustu eða sjálfskrifað kerfi.

Ein einföld leið til að endurheimta meistara ef það mistekst er að nota fljótandi VIP vistföng.

Það sem þú þarft að vita um þessa lausn áður en þú heldur áfram:

VIP er IP-tala sem er ekki tengt tilteknu líkamlegu netviðmóti. Ef hnútur bilar eða meðan á áætlunarhaldi stendur, getum við skipt VIP yfir í aðra auðlind með lágmarks niður í miðbæ.
Að losa og gefa út sýndar-IP tölu er ódýr og fljótleg aðgerð.
Til að vinna með VIP þarftu aðgang að þjóninum í gegnum SSH, eða notkun sérstakra tóla, til dæmis, keepalived.

Við skulum skoða hugsanleg vandamál með töframanninum okkar og ímynda okkur hvernig sjálfvirka endurheimtarkerfið ætti að virka.

Nettenging við skipstjóra er horfin eða vandamál hefur komið upp á vélbúnaðarstigi og þjónninn er ekki tiltækur

Hljómsveitarstjórinn uppfærir svæðisfræði klasans, hver eftirmynd greinir frá því að meistarinn sé ekki tiltækur. Hljómsveitarstjórinn byrjar ferlið við að velja eftirmynd sem hæfir hlutverki nýja meistarans og byrjar bata.
Við erum að reyna að fjarlægja VIP frá gamla meistaranum - án árangurs.
Eftirmyndin skiptir yfir í hlutverk meistara. Verið er að endurbyggja landfræðina.
Bætir við nýju netviðmóti með VIP. Þar sem það var ekki hægt að fjarlægja VIP, byrjum við að senda beiðni reglulega í bakgrunni ókeypis ARP. Þessi tegund af beiðni/svari gerir þér kleift að uppfæra IP og MAC vistfanga kortlagningartöfluna á tengdum rofum og láta þig þar með vita að VIP okkar hefur flutt. Þetta dregur úr líkunum split brain þegar skilað er gamla húsbóndanum.
Allar nýjar tengingar eru umsvifalaust sendar til nýja meistarans. Gamlar tengingar bila og endurtekin símtöl í gagnagrunninn eru gerð á umsóknarstigi.

Miðlarinn starfar í venjulegum ham, bilun kom upp á DBMS stigi

Reikniritið er svipað og í fyrra tilviki: að uppfæra staðfræði og hefja bataferli. Þar sem þjónninn er tiltækur gefum við út VIP á gamla meistarann, flytjum hann yfir á þann nýja og sendum nokkrar ARP beiðnir. Hugsanleg endurkoma gamla meistarans ætti ekki að hafa áhrif á endurbyggða klasann og rekstur forritsins.

Önnur vandamál

Bilun á eftirmyndum eða millimeistara leiðir ekki til sjálfvirkra aðgerða og krefst handvirkrar íhlutunar.

Sýndarnetsviðmóti er alltaf bætt við tímabundið, það er, eftir endurræsingu miðlara, er VIP ekki sjálfkrafa úthlutað. Hvert gagnagrunnstilvik byrjar sjálfgefið í skrifvarinn ham, hljómsveitarstjórinn skiptir sjálfkrafa um nýja meistarann til að skrifa og reynir að setja upp read only á gamla meistaranum. Þessar aðgerðir miða að því að draga úr líkunum split brain.

Vandamál geta komið upp meðan á bataferlinu stendur, sem ætti einnig að tilkynna í gegnum hljómsveitarviðmótið auk venjulegra eftirlitstækja. Við höfum stækkað REST API með því að bæta þessum eiginleika (PR nú til skoðunar).

Almenn skýringarmynd af HA lausninni er sýnd hér að neðan.

Að velja nýjan meistara

Hljómsveitarstjórinn er nógu klár og reynir að velja heppilegasta eftirmyndin sem nýr meistari samkvæmt eftirfarandi forsendum:

eftirmyndin situr eftir meistaranum;
MySQL útgáfa af master og eftirmynd;
afritunartegund (RBR, SBR eða blandað);
staðsetning í sömu eða mismunandi gagnaverum;
framboð errant GTID — viðskipti sem voru framkvæmd á eftirmyndinni og eru ekki á skipstjóranum;
Einnig er tekið tillit til sérvalsreglna.

Ekki er sérhver vísbending tilvalinn frambjóðandi fyrir meistara. Til dæmis er hægt að nota eftirmynd til að taka öryggisafrit af gögnum eða þjónninn er með veikari vélbúnaðarstillingu. Hljómsveitarstjóri styður handvirkar reglur sem þú getur sérsniðið val þitt umsækjenda með frá mest valinn til hunsuð.

Viðbragðs- og batatími

Ef atvik eiga sér stað er mikilvægt að lágmarka kerfisniðurtíma, svo við skulum íhuga MySQL færibreyturnar sem hafa áhrif á sköpun og uppfærslu á þyrpingastórfræði af hljómsveitarstjóra:

slave_net_timeout — fjölda sekúndna sem eftirmyndin bíður eftir að ný gögn eða hjartsláttarmerki berist frá skipstjóranum áður en tengingin er viðurkennd sem rofin og tengd aftur. Því lægra sem gildið er, því hraðar getur eftirmyndin ákvarðað að samskipti við skipstjórann séu rofin. Við stillum þetta gildi á 5 sekúndur.
MASTER_CONNECT_RETRY — fjöldi sekúndna á milli tilrauna til endurtengingar. Ef upp koma netvandamál mun lágt gildi fyrir þessa færibreytu leyfa skjóta endurtengingu og koma í veg fyrir að endurheimtarferlið klasans hefjist. Ráðlagt gildi er 1 sekúnda.
MASTER_RETRY_COUNT — hámarksfjöldi tilrauna til endurtengingar.
MASTER_HEARTBEAT_PERIOD — bil í sekúndum þar sem skipstjórinn sendir hjartsláttarmerki. Sjálfgefið er hálft gildi slave_net_timeout.

Færibreytur hljómsveitarstjóra:

DelayMasterPromotionIfSQLThreadNotUpToDate - ef jafnt true, þá verður aðalhlutverkinu ekki beitt á eftirmynd umsækjanda fyrr en SQL þráður eftirmyndarinnar hefur lokið öllum óbeittum færslum úr Relay Log. Við notum þennan möguleika til að forðast að tapa viðskiptum þegar allar eftirlíkingar umsækjenda falla á eftir.
InstancePollSeconds — tíðni byggingar og uppfærslu staðfræðinnar.
RecoveryPollSeconds — tíðni staðfræðigreiningar. Ef vandamál uppgötvast er staðfræðibati hafin. Þetta stöðugt, jafnt og 1 sekúndu.

Hver klasahnút er könnuð af hljómsveitarstjóra einu sinni á hverjum tíma InstancePollSeconds sekúndur Þegar vandamál uppgötvast er klasaástandið þvingað uppfært, og þá er endanleg ákvörðun tekin um að framkvæma endurheimt. Með því að gera tilraunir með mismunandi gagnagrunns- og hljómsveitarfæribreytur gátum við dregið úr svörunar- og batatíma í 30 sekúndur.

Prófstandur

Við byrjuðum að prófa HA kerfið með þróun staðbundins prófbekkur og frekari innleiðingu í prófunar- og framleiðsluumhverfi. Staðbundinn standurinn er fullkomlega sjálfvirkur byggður á Docker og gerir þér kleift að gera tilraunir með uppsetningu hljómsveitarstjórans og netsins, skala þyrpinguna úr 2-3 netþjónum í nokkra tugi og stunda æfingar í öruggu umhverfi.

Meðan á æfingunum stendur veljum við eina af aðferðum til að herma eftir vandamálum: skjóta meistarann samstundis kill -9, slítu ferlinu mjúklega og stöðvaðu netþjóninn (docker-compose stop), líkja eftir netvandamálum með því að nota iptables -j REJECT eða iptables -j DROP. Við búumst við eftirfarandi niðurstöðum:

hljómsveitarstjórinn mun greina vandamál með meistarann og uppfæra staðfræðina á ekki meira en 10 sekúndum;
endurheimtarferlið mun sjálfkrafa hefjast: netuppsetningin mun breytast, hlutverk meistarans mun fara í eftirmyndina, staðfræðin verður endurbyggð;
nýi meistarinn verður skriflegur, lifandi eftirlíkingar glatast ekki meðan á endurbyggingu stendur;
byrjað verður að skrifa gögn á nýja skipstjórann og endurtaka þau;
Heildar batatími verður ekki meira en 30 sekúndur.

Eins og þú veist getur kerfið hegðað sér öðruvísi í prófunar- og framleiðsluumhverfi vegna mismunandi uppsetningar vélbúnaðar og netkerfis, mismunar á tilbúnu og raunverulegu álagi osfrv. Þess vegna gerum við reglulega æfingar við raunverulegar aðstæður, athugum hvernig kerfið hegðar sér þegar nettenging rofnar eða einstakir hlutar þess skerðast. Í framtíðinni viljum við byggja upp alveg eins innviði fyrir bæði umhverfi og gera prófun þess sjálfvirkan.

Niðurstöður

Heilbrigði hnúts aðalgeymslukerfisins er eitt af meginverkefnum SRE og rekstrarteymis. Innleiðing hljómsveitarstjóra og HA lausnar byggða á VIP gerði okkur kleift að ná eftirfarandi árangri:

áreiðanlega uppgötvun vandamála með staðfræði gagnagrunnsklasans;
sjálfvirk og hröð viðbrögð við meistaratengdum atvikum, sem dregur úr kerfistíma.

Hins vegar hefur lausnin sínar takmarkanir og galla:

að skala HA kerfið í nokkrar gagnaver mun krefjast eins L2 nets á milli þeirra;
Áður en við úthlutum VIP á nýja meistarann þurfum við að gefa það út á þeim gamla. Ferlið er raðbundið, sem eykur batatíma;
losun VIP krefst SSH aðgangs að þjóninum, eða einhverri annarri aðferð til að hringja í ytri verklagsreglur. Þar sem þjónninn eða gagnagrunnurinn er að lenda í vandræðum sem ollu bataferlinu, getum við ekki verið viss um að VIP fjarlægingin ljúki með góðum árangri. Og þetta getur leitt til útlits tveggja netþjóna með sömu sýndar-IP tölu og vandamál split brain.

Til að koma í veg fyrir split brain, þú getur notað aðferðina STONITH ("Skjótu hinn hnútinn í höfuðið"), sem einangrar eða gerir vandamálshnútinn algjörlega óvirkan. Það eru aðrar leiðir til að innleiða háa framboð klasa: sambland af VIP og DNS, þjónustuuppgötvun og umboðsþjónustu, samstillt afritun og aðrar aðferðir sem hafa sína eigin galla og kosti.

Ég talaði um nálgun okkar við að búa til MySQL failover þyrping. Það er auðvelt í framkvæmd og veitir viðunandi áreiðanleika við núverandi aðstæður. Eftir því sem allt kerfið almennt og innviðir sérstaklega þróast mun þessi nálgun án efa þróast.

Heimild: www.habr.com

Hljómsveitarstjóri og VIP sem HA lausn fyrir MySQL þyrping