Katika Citymobil tunatumia hifadhidata ya MySQL kama hifadhi yetu kuu endelevu ya data. Tuna makundi kadhaa ya hifadhidata kwa huduma na madhumuni mbalimbali.

Upatikanaji wa mara kwa mara wa bwana ni kiashiria muhimu cha utendaji wa mfumo mzima na sehemu zake za kibinafsi. Urejeshaji wa kiotomatiki wa nguzo katika tukio la kushindwa kuu hupunguza sana muda wa majibu ya tukio na kukatika kwa mfumo. Katika nakala hii, nitaangalia muundo wa upatikanaji wa juu (HA) kwa nguzo ya MySQL kulingana na MySQL Orchestrator na anwani za IP (VIP).

Suluhisho la HA kulingana na VIP

Kwanza, nitakuambia kwa ufupi mfumo wetu wa kuhifadhi data ni nini.

Tunatumia mpango wa kawaida wa urudufishaji na bwana mmoja unaoweza kufikiwa na maandishi na nakala nyingi za kusoma tu. Nguzo inaweza kuwa na bwana wa kati - nodi ambayo ni nakala na bwana kwa wengine. Wateja hufikia nakala kupitia HAProxy, ambayo inaruhusu usambazaji hata wa mzigo na kuongeza kwa urahisi. Matumizi ya HAProxy yanatokana na sababu za kihistoria, na kwa sasa tuko katika harakati za kuhamia ProxySQL.

Urudiaji unafanywa katika hali ya nusu-synchronous kulingana na GTID. Hii ina maana kwamba angalau nakala moja lazima iandikishe muamala kabla ya kuchukuliwa kuwa umefaulu. Hali hii ya urudufishaji hutoa uwiano bora kati ya utendakazi na usalama wa data katika tukio la kushindwa kwa nodi kuu. Kimsingi mabadiliko yote yanahamishwa kutoka kwa bwana hadi nakala kwa kutumia Row Based Replication (RBR), lakini baadhi ya nodi zinaweza kuwa nazo mixed binlog format.

Orchestrator mara kwa mara husasisha hali ya topolojia ya nguzo, inachambua habari iliyopokelewa, na ikiwa matatizo yatatokea, inaweza kuzindua utaratibu wa kurejesha moja kwa moja. Msanidi anajibika kwa utaratibu yenyewe, kwa kuwa inaweza kutekelezwa kwa njia tofauti: kulingana na VIP, DNS, kwa kutumia huduma za ugunduzi wa huduma au taratibu za kujiandikisha.

Njia moja rahisi ya kurejesha bwana ikiwa itashindwa ni kutumia anwani za VIP zinazoelea.

Unachohitaji kujua kuhusu suluhisho hili kabla ya kusonga mbele:

VIP ni anwani ya IP ambayo haihusiani na kiolesura maalum cha mtandao halisi. Ikiwa nodi itashindwa au wakati wa matengenezo yaliyoratibiwa, tunaweza kubadili VIP hadi rasilimali nyingine kwa muda mdogo wa kupungua.
Kufungua na kutoa anwani pepe ya IP ni operesheni ya bei nafuu na ya haraka.
Ili kufanya kazi na VIP, unahitaji ufikiaji wa seva kupitia SSH, au matumizi ya huduma maalum, kwa mfano, keepalived.

Hebu tuangalie matatizo iwezekanavyo na mchawi wetu na fikiria jinsi utaratibu wa kurejesha moja kwa moja unapaswa kufanya kazi.

Muunganisho wa mtandao kwa bwana umetoweka, au tatizo limetokea katika kiwango cha maunzi, na seva haipatikani.

Orchestrator husasisha topolojia ya nguzo, kila nakala inaripoti kuwa bwana hapatikani. Orchestrator huanza mchakato wa kuchagua replica inayofaa kwa jukumu la bwana mpya na huanza kupona.
Tunajaribu kuondoa VIP kutoka kwa bwana wa zamani - bila mafanikio.
Replica inabadilika hadi jukumu la bwana. Topolojia inajengwa upya.
Inaongeza kiolesura kipya cha mtandao na VIP. Kwa kuwa haikuwezekana kuondoa VIP, tunaanza kutuma ombi mara kwa mara chinichini ARP ya bure. Aina hii ya ombi/jibu hukuruhusu kusasisha jedwali la ramani ya IP na MAC kwenye swichi zilizounganishwa, na hivyo kukuarifu kuwa VIP yetu imehama. Hii inapunguza uwezekano split brain wakati wa kurudi bwana wa zamani.
Viunganisho vyote vipya mara moja huelekezwa kwa bwana mpya. Viunganisho vya zamani vinashindwa na simu zinazorudiwa kwa hifadhidata hufanywa katika kiwango cha programu.

Seva inafanya kazi katika hali ya kawaida, hitilafu ilitokea katika kiwango cha DBMS

Algorithm ni sawa na kesi ya awali: uppdatering topolojia na kuanza mchakato wa kurejesha. Kwa kuwa seva inapatikana, tunatoa VIP kwa mafanikio kwenye bwana wa zamani, tuhamishe kwa mpya, na kutuma maombi kadhaa ya ARP. Kurudi iwezekanavyo kwa bwana wa zamani haipaswi kuathiri kikundi kilichojengwa upya na uendeshaji wa programu.

Shida zingine

Kushindwa kwa nakala au mabwana wa kati haiongoi kwa vitendo otomatiki na inahitaji uingiliaji wa mwongozo.

Kiolesura cha mtandao wa kawaida huongezwa kwa muda, yaani, baada ya kuwasha upya seva, VIP haijapewa kiotomatiki. Kila mfano wa hifadhidata huanza katika hali ya kusoma tu kwa chaguo-msingi, orchestrator hubadilisha kiotomatiki bwana mpya kuandika na kujaribu kusakinisha. read only juu ya bwana mzee. Hatua hizi zinalenga kupunguza uwezekano split brain.

Matatizo yanaweza kutokea wakati wa mchakato wa urejeshaji, ambao unapaswa pia kuarifiwa kupitia orchestrator UI pamoja na zana za kawaida za ufuatiliaji. Tumepanua API ya REST kwa kuongeza kipengele hiki (PR kwa sasa inakaguliwa).

Mchoro wa jumla wa suluhisho la HA umewasilishwa hapa chini.

Kuchagua bwana mpya

Orchestrator ni smart kutosha na anajaribu kuchagua replica inayofaa zaidi kama bwana mpya kulingana na vigezo vifuatavyo:

replica iko nyuma ya bwana;
Toleo la MySQL la bwana na nakala;
aina ya replication (RBR, SBR au mchanganyiko);
eneo katika vituo sawa au tofauti vya data;
upatikanaji errant GTID - shughuli ambazo zilitekelezwa kwenye replica na sio kwa bwana;
sheria za uteuzi maalum pia huzingatiwa.

Sio kila ishara ni mgombea anayefaa kwa bwana. Kwa mfano, nakala inaweza kutumika kuhifadhi data, au seva ina usanidi dhaifu wa maunzi. Orchestrator huunga mkono sheria za mwongozo ambazo unaweza kutumia kubinafsisha mapendeleo yako ya uteuzi kutoka kwa wengi wanaopendelea hadi kupuuzwa.

Wakati wa kujibu na kupona

Katika tukio la tukio, ni muhimu kupunguza muda wa kupungua kwa mfumo, kwa hivyo hebu tuzingatie vigezo vya MySQL ambavyo vinaathiri uundaji na uppdatering wa topolojia ya nguzo na orchestrator:

slave_net_timeout — idadi ya sekunde ambapo nakala husubiri data mpya au mawimbi ya mapigo ya moyo kufika kutoka kwa mkuu kabla ya muunganisho kutambuliwa kuwa umepotea na kuunganishwa tena. Thamani ya chini, kasi ya replica inaweza kuamua kuwa mawasiliano na bwana yamevunjika. Tunaweka thamani hii kwa sekunde 5.
MASTER_CONNECT_RETRY - idadi ya sekunde kati ya majaribio ya kuunganisha tena. Katika tukio la matatizo ya mtandao, thamani ya chini ya parameter hii itaruhusu kuunganisha haraka na kuzuia mchakato wa kurejesha nguzo kuanza. Thamani inayopendekezwa ni sekunde 1.
MASTER_RETRY_COUNT - idadi ya juu zaidi ya majaribio ya kuunganisha tena.
MASTER_HEARTBEAT_PERIOD - muda katika sekunde baada ya bwana kutuma ishara ya mapigo ya moyo. Chaguomsingi hadi nusu ya thamani slave_net_timeout.

Chaguzi za orchestrator:

DelayMasterPromotionIfSQLThreadNotUpToDate - ikiwa ni sawa true, basi jukumu kuu halitatumika kwenye nakala ya mgombea hadi safu ya nakala ya SQL ikamilishe miamala yote ambayo haijatekelezwa kutoka kwa Relay Relay. Tunatumia chaguo hili ili kuepuka kupoteza miamala wakati nakala zote za wagombea zinasalia nyuma.
InstancePollSeconds - frequency ya kujenga na kusasisha topolojia.
RecoveryPollSeconds - mzunguko wa uchambuzi wa topolojia. Ikiwa tatizo linagunduliwa, urejeshaji wa topolojia huanzishwa. Hii mara kwa mara, sawa na sekunde 1.

Kila nodi ya nguzo hupigwa kura na orchestrator mara moja kila InstancePollSeconds sekunde Tatizo linapogunduliwa, hali ya nguzo inalazimishwa imesasishwa, na kisha uamuzi wa mwisho unafanywa kufanya ahueni. Kwa kufanya majaribio na hifadhidata tofauti na vigezo vya ochestra, tuliweza kupunguza muda wa majibu na urejeshaji hadi sekunde 30.

benchi ya mtihani

Tulianza kujaribu mpango wa HA na maendeleo ya ndani benchi ya mtihani na utekelezaji zaidi katika mazingira ya majaribio na uzalishaji. Stendi ya ndani imejiendesha kikamilifu kulingana na Docker na hukuruhusu kujaribu usanidi wa orchestrator na mtandao, kuongeza kikundi kutoka seva 2-3 hadi dazeni kadhaa, na kufanya mazoezi katika mazingira salama.

Wakati wa mazoezi, tunachagua moja ya njia za kuiga shida: piga risasi bwana kwa kutumia kill -9, sitisha mchakato kwa upole na usimamishe seva (docker-compose stop), kuiga matatizo ya mtandao kwa kutumia iptables -j REJECT au iptables -j DROP. Tunatarajia matokeo yafuatayo:

orchestrator itagundua shida na bwana na kusasisha topolojia kwa si zaidi ya sekunde 10;
utaratibu wa kurejesha utaanza moja kwa moja: usanidi wa mtandao utabadilika, jukumu la bwana litapita kwa replica, topolojia itajengwa tena;
bwana mpya ataandikwa, nakala za moja kwa moja hazitapotea wakati wa mchakato wa kujenga upya;
data itaanza kuandikwa kwa bwana mpya na kuigwa;
Jumla ya muda wa kurejesha hautakuwa zaidi ya sekunde 30.

Kama unavyojua, mfumo unaweza kuwa na tabia tofauti katika mazingira ya majaribio na uzalishaji kutokana na maunzi tofauti na usanidi wa mtandao, tofauti za upakiaji wa sintetiki na halisi, n.k. Kwa hiyo, sisi mara kwa mara tunafanya mazoezi katika hali halisi, kuangalia jinsi mfumo unavyofanya wakati muunganisho wa mtandao unapotea au sehemu zake za kibinafsi zimeharibika. Katika siku zijazo, tunataka kujenga miundombinu inayofanana kabisa kwa mazingira yote mawili na kufanyia majaribio yake kiotomatiki.

Matokeo

Afya ya nodi kuu ya mfumo wa kuhifadhi ni moja ya kazi kuu za SRE na timu ya uendeshaji. Utekelezaji wa orchestrator na ufumbuzi wa HA kulingana na VIP ulituruhusu kufikia matokeo yafuatayo:

utambuzi wa kuaminika wa shida na topolojia ya nguzo ya hifadhidata;
majibu ya moja kwa moja na ya haraka kwa matukio yanayohusiana na bwana, kupunguza muda wa mfumo.

Walakini, suluhisho lina mapungufu na hasara zake:

kuongeza mpango wa HA kwa vituo kadhaa vya data itahitaji mtandao mmoja wa L2 kati yao;
Kabla ya kugawa VIP kwa bwana mpya, tunahitaji kuifungua kwa ile ya zamani. Mchakato ni mlolongo, ambayo huongeza muda wa kurejesha;
kuachilia VIP kunahitaji ufikiaji wa SSH kwa seva, au njia nyingine yoyote ya kupiga taratibu za mbali. Kwa kuwa seva au hifadhidata inakabiliwa na matatizo yaliyosababisha mchakato wa kurejesha, hatuwezi kuwa na uhakika kwamba uondoaji wa VIP utakamilika kwa ufanisi. Na hii inaweza kusababisha kuonekana kwa seva mbili zilizo na anwani sawa ya IP na tatizo split brain.

Ili kuepuka split brain, unaweza kutumia njia STONITH ("Shoot Node Nyingine Katika Kichwa"), ambayo hutenganisha kabisa au kuzima nodi ya tatizo. Kuna njia zingine za kutekeleza upatikanaji wa juu wa nguzo: mchanganyiko wa VIP na DNS, ugunduzi wa huduma na huduma za wakala, urudufishaji wa synchronous na njia zingine ambazo zina hasara na faida zao.

Nilizungumza juu ya mbinu yetu ya kuunda nguzo ya kushindwa kwa MySQL. Ni rahisi kutekeleza na hutoa kiwango cha kukubalika cha kuaminika chini ya hali ya sasa. Mfumo mzima kwa ujumla na miundombinu hasa inavyoendelea, mbinu hii bila shaka itabadilika.

Chanzo: mapenzi.com

Orchestrator na VIP kama suluhisho la HA kwa nguzo ya MySQL