Öll stór verkefni hófust með nokkrum netþjónum. Í fyrstu var einn DB server, síðan var þrælum bætt við hann til að skala lesturinn. Og svo - hættu! Þar er einn húsbóndi, en þrælar eru margir; ef einn af þrælunum fer þá verður allt í lagi en ef húsbóndinn fer þá verður það slæmt: downtime, admins eru að reyna að hækka serverinn. Hvað skal gera? Pantaðu meistara. Kollegi minn Pavel skrifaði þegar um þetta , ég mun ekki endurtaka það. Í staðinn skal ég segja þér hvers vegna þú þarft örugglega Orchestrator fyrir MySQL!
Við skulum byrja á aðalspurningunni: "Hvernig munum við skipta kóðanum yfir í nýja vél þegar skipstjórinn fer?"
- Mér líkar best við kerfið með VIP (Virtual IP), við munum tala um það hér að neðan. Það er einfaldasta og augljósasta, þó að það hafi augljósar takmarkanir: skipstjórinn sem við munum panta verður að vera í L2 hlutanum með nýju vélinni, það er að segja við getum gleymt seinni DC. Og, á vinsamlegan hátt, ef þú fylgir reglunni um að stór L2 sé vondur, vegna þess að L2 er aðeins fyrir hvern rekka, og L3 er á milli rekkana, og slíkt kerfi hefur enn meiri takmarkanir.
- Þú getur skrifað DNS nafn í kóðann og leyst það í gegnum /etc/hosts. Reyndar verður engin upplausn. Kosturinn við kerfið: það er engin takmörkun sem einkennir fyrstu aðferðina, það er, það er hægt að skipuleggja kross-DC. En þá vaknar augljós spurning: hversu fljótt getum við afhent breytinguna til /etc/hosts í gegnum Puppet-Ansible?
- Þú getur breytt seinni aðferðinni aðeins: settu upp skyndiminni DNS á öllum vefþjónum, þar sem kóðinn fer í aðalgagnagrunninn. Þú getur stillt TTL 60 fyrir þessa færslu í DNS. Svo virðist sem ef rétt er útfært sé aðferðin góð.
- Kerfi með þjónustuuppgötvun, sem gefur til kynna notkun ræðismanns og etc.
- Áhugaverður valkostur með . Þú þarft að beina allri umferð til MySQL í gegnum ProxySQL; ProxySQL getur sjálft ákvarðað hver er meistarinn. Við the vegur, þú getur lesið um einn af valkostum til að nota þessa vöru í mínum .
Höfundur Orchestrator, sem starfaði í Github, innleiddi fyrst fyrsta kerfið með VIP og breytti því síðan í kerfi með ræðismanni.
Dæmigert skipulag innviða:
Ég mun strax lýsa augljósum aðstæðum sem taka þarf tillit til:
- VIP heimilisfangið ætti ekki að vera skráð í stillingum á neinum af netþjónunum. Við skulum ímynda okkur aðstæður: húsbóndinn endurræsti sig og á meðan hann var að hlaðast fór Orchestrator í bilunarham og gerði einn þrælanna að meistara; þá reis gamli húsbóndinn og nú er VIP á tveimur bílum. Þetta er slæmt.
- Fyrir hljómsveitarstjórann þarftu að skrifa handrit til að kalla gamla meistarann og nýja meistarann. Á gamla meistaranum þarftu að keyra ifdown, og á nýja meistaranum - ifup vip. Það væri gaman að setja það líka inn í þetta handrit að ef bilun verður, þá er einfaldlega slökkt á tenginu á gamla aðalrofanum til að forðast klofning.
- Eftir að Orchestrator hefur hringt í handritið þitt til að fjarlægja fyrst VIP og/eða slökkva á portinu á rofanum, og svo kallað VIP hækka handritið á nýja masternum, ekki gleyma að nota arping skipunina til að segja öllum að nýja VIP er núna hér.
- Allir þrælar ættu að hafa read_only=1, og um leið og þú færð þrælinn til húsbóndans ætti hann að hafa read_only=0.
- Ekki gleyma því að hvaða þræll sem við höfum valið fyrir þetta getur orðið meistari (hljómsveitarmaður hefur allt valkerfi fyrir hvaða þræll á að líta á sem frambjóðanda fyrir nýjan meistara í fyrsta lagi, hvern í öðru lagi og hvaða þræll ætti alls ekki vera valinn undir neinum kringumstæðum meistari). Ef þrællinn verður húsbóndi, þá verður álag þrælsins áfram á honum og álagi húsbóndans bætist við, það verður að taka tillit til þess.
Af hverju þarftu hljómsveitarstjóra ef þú ert ekki með slíkan?
- Orchestrator er með mjög notendavænt grafískt viðmót sem sýnir alla staðfræði (sjá skjámynd hér að neðan).
- Orchestrator getur fylgst með hvaða þrælar eru á eftir og hvar afritun hefur almennt bilað (við erum með forskriftir tengdar við Orchestrator til að senda SMS).
- Hljómsveitarstjóri segir þér hvaða þrælar eru með GTID villu.
Viðmót hljómsveitarstjóra:
Hvað er GTID villandi?
Það eru tvær meginkröfur fyrir hljómsveitarstjóra að vinna:
- Nauðsynlegt er að gervi GTID sé virkt á öllum vélum í MySQL þyrpingunni; við höfum GTID virkt.
- Það er nauðsynlegt að það sé ein tegund af binlogs alls staðar, þú getur notað yfirlýsingu. Við vorum með uppsetningu þar sem húsbóndinn og flestir þrælar höfðu Row, og tveir héldust í blönduðum ham. Þess vegna vildi Orchestrator einfaldlega ekki tengja þessa þræla við nýja meistarann.
Mundu að það mikilvægasta í framleiðsluþræll er samkvæmni hans við húsbóndann! Ef þú ert með Global Transaction ID (GTID) virkt á bæði húsbónda þínum og þræl, þá geturðu notað gtid_subset aðgerðina til að komast að því hvort sömu beiðnir um gagnabreytingar hafi í raun verið framkvæmdar á þessum vélum. Þú getur lesið meira um þetta .
Þannig sýnir Orchestrator þér í gegnum GTID villuna að það eru viðskipti á þrælnum sem eru ekki á skipstjóranum. Hvers vegna er þetta að gerast?
- Read_only=1 er ekki virkt á þrælnum, einhver tengdi og kláraði beiðni um að breyta gögnum.
- Super_read_only=1 er ekki virkt á þrælnum, þá fór stjórnandinn, eftir að hafa ruglað þjóninn, inn og framkvæmdi beiðnina þar.
- Ef þú hefur tekið tillit til beggja fyrri punkta, þá er enn eitt bragðið: í MySQL fer beiðni um að skola binlogs líka í binlog, þannig að við fyrstu skolun mun GTID villandi birtast á húsbóndanum og öllum þrælum. Hvernig á að forðast þetta? Perona-5.7.25-28 kynnti binlog_skip_flush_commands=1 stillinguna, sem bannar að skrifa flush í binlogs. Það er komið á vefsíðu mysql.com .
Leyfðu mér að draga saman allt ofangreint. Ef þú vilt ekki nota Orchestrator í bilunarstillingu ennþá skaltu setja hann í athugunarham. Þá muntu alltaf hafa fyrir augum þér kort af samspili MySQL véla og sjónrænar upplýsingar um hvers konar afritun er á hverri vél, hvort þrælarnir séu eftirbátar, og síðast en ekki síst, hversu samkvæmir þeir eru meistaranum!
Augljós spurning er: "Hvernig ætti hljómsveitarstjóri að vinna?" Hann verður að velja nýjan húsbónda úr núverandi þrælum og tengja síðan alla þræla við hann aftur (þetta er það sem GTID þarf fyrir; ef þú notar gamla vélbúnaðinn með binlog_name og binlog_pos, þá skipta þræl úr núverandi skipstjóra yfir í nýjan. er einfaldlega ómögulegt!). Áður en við fengum Orchestrator þurfti ég einu sinni að gera þetta allt handvirkt. Gamli húsbóndinn hékk vegna þrjótur Adaptec stjórnandi; hann var með um 10 þræla. Ég þurfti að flytja VIP frá húsbóndanum yfir á einn af þrælunum og tengja alla aðra þræla við hann aftur. Hversu margar leikjatölvur þurfti ég að opna, hversu margar skipanir setti ég inn samtímis... Ég þurfti að bíða til klukkan 3 að morgni, fjarlægja álagið af öllum þrælum nema tveimur, búa til fyrstu vélina af tveimur herra, tengja strax seinni vélina við það, svo festu alla hina þrælana við nýja húsbóndann og skilaðu byrðinni. Á heildina litið, hræðilegt...
Hvernig virkar Orchestrator þegar það fer í bilunarstillingu? Þetta er auðveldast að útskýra með dæmi um aðstæður þar sem við viljum gera meistara að öflugri og nútímalegri vél en við höfum núna.
Myndin sýnir mitt ferli. Hvað hefur þegar verið gert fram að þessu? Við sögðum að við vildum gera einhvern þræl að nýja meistaranum, Orchestrator byrjaði einfaldlega að tengja alla aðra þræla við það aftur, með nýja meistarann sem flutningsvél. Með þessu skema eiga sér stað engar villur, allir þrælar vinna, Orchestrator fjarlægir VIP frá gamla húsbóndanum, flytur hann yfir á þann nýja, gerir read_only=0 og gleymir gamla húsbóndanum. Allt! Niðurtími þjónustu okkar er VIP flutningstími, sem er 2-3 sekúndur.
Þetta er allt í dag, takk allir. Það mun koma önnur grein um Orchestrator fljótlega. Í hinni frægu sovésku mynd „Garage“ sagði ein persóna: „Ég myndi ekki fara í njósn með honum! Svo, hljómsveitarstjóri, ég myndi fara með þér í könnun!
Heimild: www.habr.com