Yn Citymobil rydym yn defnyddio cronfa ddata MySQL fel ein prif storfa ddata barhaus. Mae gennym nifer o glystyrau cronfa ddata ar gyfer gwasanaethau a dibenion amrywiol.

Mae argaeledd cyson y meistr yn ddangosydd hanfodol o berfformiad y system gyfan a'i rhannau unigol. Mae adferiad clwstwr awtomatig mewn achos o fethiant meistr yn lleihau'n fawr yr amser ymateb i ddigwyddiad ac amser segur y system. Yn yr erthygl hon, byddaf yn edrych ar ddyluniad argaeledd uchel (HA) ar gyfer clwstwr MySQL yn seiliedig ar Cerddorfa MySQL a chyfeiriadau IP rhithwir (VIP).

Datrysiad HA yn seiliedig ar VIP

Yn gyntaf, byddaf yn dweud wrthych yn fyr beth yw ein system storio data.

Rydym yn defnyddio cynllun atgynhyrchu clasurol gydag un meistr y gellir ei ysgrifennu a nifer o gopïau darllen yn unig. Gall clwstwr gynnwys meistr canolradd - nod sy'n atgynhyrchiad ac yn feistr i eraill. Mae cleientiaid yn cyrchu atgynyrchiadau trwy HAProxy, sy'n caniatáu ar gyfer dosbarthu llwyth hyd yn oed a graddio'n hawdd. Mae'r defnydd o HAProxy oherwydd rhesymau hanesyddol, ac ar hyn o bryd rydym yn y broses o fudo i ProxySQL.

Perfformir dyblygu mewn modd lled-gydamserol yn seiliedig ar GTID. Mae hyn yn golygu bod yn rhaid i o leiaf un replica logio trafodiad cyn yr ystyrir ei fod yn llwyddiannus. Mae'r modd atgynhyrchu hwn yn darparu'r cydbwysedd gorau posibl rhwng perfformiad a diogelwch data pe bai prif nod yn methu. Yn y bôn mae pob newid yn cael ei drosglwyddo o'r meistr i'r replicas gan ddefnyddio Row Based Replication (RBR), ond efallai y bydd gan rai nodau mixed binlog format.

Mae'r cerddorfa yn diweddaru cyflwr topoleg y clwstwr o bryd i'w gilydd, yn dadansoddi'r wybodaeth a dderbynnir, ac os bydd problemau'n codi, gall lansio gweithdrefn adfer awtomatig. Mae'r datblygwr yn gyfrifol am y weithdrefn ei hun, gan y gellir ei weithredu mewn gwahanol ffyrdd: yn seiliedig ar VIP, DNS, defnyddio gwasanaethau darganfod gwasanaeth neu fecanweithiau hunan-ysgrifenedig.

Un ffordd syml o adfer meistr os yw'n methu yw defnyddio cyfeiriadau VIP fel y bo'r angen.

Beth sydd angen i chi ei wybod am y datrysiad hwn cyn symud ymlaen:

• Cyfeiriad IP yw VIP nad yw'n gysylltiedig â rhyngwyneb rhwydwaith ffisegol penodol. Os bydd nod yn methu neu yn ystod gwaith cynnal a chadw wedi'i drefnu, gallwn newid y VIP i adnodd arall heb fawr o amser segur.
• Mae rhyddhau a chyhoeddi cyfeiriad IP rhithwir yn weithrediad rhad a chyflym.
• I weithio gyda VIP, mae angen mynediad i'r gweinydd trwy SSH, neu ddefnyddio cyfleustodau arbennig, er enghraifft, keepalived.

Gadewch i ni edrych ar broblemau posibl gyda'n dewin a dychmygu sut y dylai'r mecanwaith adfer awtomatig weithio.

Mae cysylltedd rhwydwaith i'r meistr wedi diflannu, neu mae problem wedi codi ar lefel caledwedd, ac nid yw'r gweinydd ar gael

1. Mae'r cerddorfa'n diweddaru topoleg y clwstwr, ac mae pob replica yn adrodd nad yw'r meistr ar gael. Mae'r cerddorfa'n dechrau'r broses o ddewis replica sy'n addas ar gyfer rôl y meistr newydd ac yn dechrau adferiad.
2. Rydyn ni'n ceisio tynnu'r VIP o'r hen feistr - heb lwyddiant.
3. Mae'r replica yn newid i rôl meistr. Mae'r dopoleg yn cael ei hailadeiladu.
4. Ychwanegu rhyngwyneb rhwydwaith newydd gyda VIP. Gan nad oedd yn bosibl cael gwared ar y VIP, rydym yn dechrau anfon cais yn y cefndir o bryd i'w gilydd ARP rhad ac am ddim. Mae'r math hwn o gais / ymateb yn caniatáu ichi ddiweddaru'r tabl mapio cyfeiriad IP a MAC ar y switshis cysylltiedig, a thrwy hynny eich hysbysu bod ein VIP wedi symud. Mae hyn yn lleihau'r tebygolrwydd split brain wrth ddychwelyd yr hen feistr.
5. Mae pob cysylltiad newydd yn cael ei ailgyfeirio ar unwaith i'r meistr newydd. Mae hen gysylltiadau'n methu a gwneir galwadau mynych i'r gronfa ddata ar lefel y cais.

Mae'r gweinydd yn gweithredu yn y modd arferol, bu methiant ar lefel DBMS

Mae'r algorithm yn debyg i'r achos blaenorol: diweddaru'r topoleg a dechrau'r broses adfer. Gan fod y gweinydd ar gael, rydym yn rhyddhau'r VIP yn llwyddiannus ar yr hen feistr, yn ei drosglwyddo i'r un newydd, ac yn anfon sawl cais ARP. Ni ddylai dychweliad posibl yr hen feistr effeithio ar y clwstwr ailadeiladu a gweithrediad y cais.

Problemau eraill

Methiant atgynyrchiadau neu feistri canolradd ddim yn arwain i gamau gweithredu awtomatig ac mae angen ymyrraeth â llaw.

Mae rhyngwyneb rhwydwaith rhithwir bob amser yn cael ei ychwanegu dros dro, hynny yw, ar ôl ailgychwyn gweinydd, nid yw'r VIP yn cael ei neilltuo'n awtomatig. Mae pob enghraifft cronfa ddata yn cychwyn yn y modd darllen yn unig yn ddiofyn, mae'r cerddorfa'n newid y meistr newydd yn awtomatig i ysgrifennu ac yn ceisio gosod read only ar yr hen feistr. Nod y camau hyn yw lleihau'r tebygolrwydd split brain.

Gall problemau godi yn ystod y broses adfer, y dylid hefyd eu hysbysu trwy'r UI cerddorfaol yn ogystal ag offer monitro safonol. Rydym wedi ehangu'r API REST trwy ychwanegu'r nodwedd hon (PR yn cael ei adolygu ar hyn o bryd).

Mae'r diagram cyffredinol o'r datrysiad HA wedi'i gyflwyno isod.

Dewis meistr newydd

Mae'r cerddor yn ddigon craff ac yn ceisio dewis y replica mwyaf addas fel meistr newydd yn unol â'r meini prawf canlynol:

• mae'r replica ar ei hôl hi o'r meistr;
• Fersiwn MySQL o feistr a replica;
• math atgynhyrchu (RBR, SBR neu gymysg);
• lleoliad yn yr un canolfannau data neu wahanol ganolfannau data;
• argaeledd errant GTID — trafodion a gyflawnwyd ar y replica ac nad ydynt ar y meistr;
• mae rheolau dewis arferiad hefyd yn cael eu hystyried.

Nid yw pob ciw yn ymgeisydd delfrydol ar gyfer meistr. Er enghraifft, gellir defnyddio replica i wneud copi wrth gefn o ddata, neu mae gan y gweinydd gyfluniad caledwedd gwannach. Cerddorfa yn cefnogi rheolau â llaw y gallwch chi addasu eich dewisiadau dethol ymgeiswyr â nhw o'r rhai mwyaf dewisol i'r rhai sy'n cael eu hanwybyddu.

Amser ymateb ac adfer

Os bydd digwyddiad, mae'n bwysig lleihau amser segur y system, felly gadewch i ni ystyried y paramedrau MySQL sy'n effeithio ar greu a diweddaru topoleg y clwstwr gan y cerddorfa:

• slave_net_timeout — nifer yr eiliadau pan fydd y replica yn aros i ddata newydd neu signal curiad calon gyrraedd oddi wrth y meistr cyn y cydnabyddir bod y cysylltiad wedi'i golli a'i ailgysylltu. Po isaf yw'r gwerth, y cyflymaf y gall y replica benderfynu bod cyfathrebu â'r meistr wedi'i dorri. Rydym yn gosod y gwerth hwn i 5 eiliad.
• MASTER_CONNECT_RETRY — nifer yr eiliadau rhwng ymdrechion ailgysylltu. Mewn achos o broblemau rhwydwaith, bydd gwerth isel ar gyfer y paramedr hwn yn caniatáu ailgysylltu cyflym ac yn atal y broses adfer clwstwr rhag cychwyn. Y gwerth a argymhellir yw 1 eiliad.
• MASTER_RETRY_COUNT — uchafswm nifer yr ymdrechion i ailgysylltu.
• MASTER_HEARTBEAT_PERIOD — egwyl mewn eiliadau ac ar ôl hynny mae'r meistr yn anfon signal curiad calon. Rhagosodiadau i hanner y gwerth slave_net_timeout.

Dewisiadau cerddor:

• DelayMasterPromotionIfSQLThreadNotUpToDate - os cyfartal true, yna ni fydd y rôl meistr yn cael ei gymhwyso ar y replica ymgeisydd nes bod edefyn SQL y replica wedi cwblhau'r holl drafodion heb eu cymhwyso o'r Log Relay. Rydym yn defnyddio'r opsiwn hwn i osgoi colli trafodion pan fydd pob atgynhyrchiad ymgeisydd ar ei hôl hi.
• InstancePollSeconds — amlder adeiladu a diweddaru'r dopoleg.
• RecoveryPollSeconds — amlder dadansoddi topoleg. Os canfyddir problem, cychwynnir adferiad topoleg. hwn cyson, yn hafal i 1 eiliad.

Mae pob nod clwstwr yn cael ei archwilio gan y cerddorfa unwaith bob InstancePollSeconds eiliadau Pan ganfyddir problem, mae cyflwr y clwstwr yn cael ei orfodi diweddaru, ac yna gwneir y penderfyniad terfynol i berfformio adferiad. Trwy arbrofi gyda gwahanol baramedrau cronfa ddata a cherddorfawr, roeddem yn gallu lleihau'r amser ymateb ac adfer i 30 eiliad.

stondin prawf

Dechreuon ni brofi'r cynllun CT gyda datblygiad lleol mainc prawf a gweithredu pellach mewn amgylcheddau profi a chynhyrchu. Mae'r stondin leol yn gwbl awtomataidd yn seiliedig ar Docker ac mae'n caniatáu ichi arbrofi gyda chyfluniad y cerddor a'r rhwydwaith, graddio'r clwstwr o 2-3 gweinydd i sawl dwsin, a chynnal ymarferion mewn amgylchedd diogel.

Yn ystod yr ymarferion, rydym yn dewis un o'r dulliau efelychu problem: saethu'r meistr yn syth gan ddefnyddio kill -9, terfynwch y broses yn ysgafn ac atal y gweinydd (docker-compose stop), efelychu problemau rhwydwaith gan ddefnyddio iptables -j REJECT neu iptables -j DROP. Disgwyliwn y canlyniadau canlynol:

• bydd y cerddorfa yn canfod problemau gyda'r meistr ac yn diweddaru'r topoleg mewn dim mwy na 10 eiliad;
• bydd y weithdrefn adfer yn cychwyn yn awtomatig: bydd y ffurfweddiad rhwydwaith yn newid, bydd rôl y meistr yn trosglwyddo i'r replica, bydd y topoleg yn cael ei ailadeiladu;
• bydd y meistr newydd yn dod yn ysgrifenadwy, ni fydd atgynyrchiadau byw yn cael eu colli yn ystod y broses ailadeiladu;
• bydd data'n dechrau cael ei ysgrifennu at y meistr newydd a'i ailadrodd;
• Ni fydd cyfanswm yr amser adfer yn fwy na 30 eiliad.

Fel y gwyddoch, gall y system ymddwyn yn wahanol mewn amgylcheddau prawf a chynhyrchu oherwydd gwahanol gyfluniadau caledwedd a rhwydwaith, gwahaniaethau mewn llwyth synthetig a real, ac ati. Felly, rydym yn cynnal ymarferion o bryd i'w gilydd mewn amodau real, gan wirio sut mae'r system yn ymddwyn pan fydd cysylltedd rhwydwaith yn cael ei golli neu pan fydd ei rannau unigol yn cael eu diraddio. Yn y dyfodol, rydym am adeiladu seilwaith hollol union yr un fath ar gyfer y ddau amgylchedd ac awtomeiddio ei brofi.

Canfyddiadau

Mae iechyd nod y brif system storio yn un o brif dasgau'r tîm ARhPh a gweithrediadau. Roedd gweithredu'r datrysiad cerddorfaol a HA yn seiliedig ar VIP yn ein galluogi i gyflawni'r canlyniadau canlynol:

• canfod problemau gyda thopoleg y clwstwr cronfa ddata yn ddibynadwy;
• ymateb awtomatig a chyflym i ddigwyddiadau sy'n ymwneud â meistr, gan leihau amser segur y system.

Fodd bynnag, mae gan yr ateb ei gyfyngiadau a'i anfanteision:

• er mwyn ehangu'r cynllun HA i sawl canolfan ddata bydd angen un rhwydwaith L2 rhyngddynt;
• Cyn aseinio VIP ar y meistr newydd, mae angen inni ei ryddhau ar yr hen un. Mae'r broses yn ddilyniannol, sy'n cynyddu'r amser adfer;
• mae rhyddhau'r VIP yn gofyn am fynediad SSH i'r gweinydd, neu unrhyw ddull arall o alw gweithdrefnau o bell. Gan fod y gweinydd neu'r gronfa ddata yn cael problemau a achosodd y broses adfer, ni allwn fod yn siŵr y bydd y gwarediad VIP yn cael ei gwblhau'n llwyddiannus. A gall hyn arwain at ymddangosiad dau weinydd gyda'r un cyfeiriad IP rhithwir a phroblem split brain.

I osgoi split brain, gallwch ddefnyddio'r dull STONITH (“Saethu’r Nod Arall Yn Y Pen”), sy’n ynysu neu’n analluogi’r nod problemus yn llwyr. Mae yna ffyrdd eraill o weithredu argaeledd uchel clwstwr: cyfuniad o VIP a DNS, darganfod gwasanaeth a gwasanaethau dirprwy, dyblygu cydamserol a dulliau eraill sydd â'u hanfanteision a'u manteision eu hunain.

Siaradais am ein dull o greu clwstwr methiant MySQL. Mae'n hawdd ei weithredu ac mae'n darparu lefel dderbyniol o ddibynadwyedd o dan yr amodau presennol. Wrth i'r system gyfan yn gyffredinol a seilwaith yn arbennig ddatblygu, bydd y dull hwn yn ddi-os yn esblygu.

Ffynhonnell: hab.com