Meginmarkmið Patroni er að bjóða upp á mikla aðgengi fyrir PostgreSQL. En Patroni er bara sniðmát, ekki tilbúið tól (sem er almennt sagt í skjölunum). Við fyrstu sýn, eftir að hafa sett upp Patroni í prófunarstofunni, geturðu séð hversu frábært tól það er og hversu auðveldlega það höndlar tilraunir okkar til að brjóta þyrpinguna. Hins vegar, í reynd, í framleiðsluumhverfi, gerist ekki alltaf allt eins fallega og glæsilega og í tilraunastofu.
Ég skal segja þér aðeins frá sjálfum mér. Ég byrjaði sem kerfisstjóri. Vann við vefþróun. Ég hef starfað hjá Data Egret síðan 2014. Fyrirtækið stundar ráðgjöf á sviði Postgres. Og við þjónum einmitt Postgres og vinnum með Postgres á hverjum degi, þannig að við höfum mismunandi sérfræðiþekkingu sem tengist starfseminni.
Og í lok árs 2018 fórum við að nota Patroni hægt og rólega. Og nokkur reynsla hefur safnast. Við greindum það einhvern veginn, stilltum það, komum að okkar bestu starfsvenjum. Og í þessari skýrslu mun ég tala um þau.
Fyrir utan Postgres elska ég Linux. Mér finnst gaman að pæla í því og kanna, mér finnst gaman að safna kjarna. Ég elska sýndarvæðingu, gáma, bryggju, Kubernetes. Allt þetta vekur áhuga minn, því gömlu stjórnunarvenjurnar hafa áhrif. Mér finnst gaman að fást við eftirlit. Og ég elska postgres hluti sem tengjast stjórnun, þ.e. afritun, öryggisafrit. Og í frítíma mínum skrifa ég í Go. Ég er ekki hugbúnaðarverkfræðingur, ég skrifa bara fyrir sjálfan mig í Go. Og það veitir mér ánægju.
- Ég held að mörg ykkar viti að Postgres er ekki með HA (High Availability) úr kassanum. Til að fá HA þarftu að setja eitthvað upp, stilla það, gera tilraun og ná því.
- Það eru nokkur verkfæri og Patroni er eitt þeirra sem leysir HA frekar flott og mjög vel. En með því að setja þetta allt í prófunarstofu og keyra það getum við séð að þetta virkar allt, við getum endurskapað nokkur vandamál, séð hvernig Patroni þjónar þeim. Og við munum sjá að þetta virkar allt frábærlega.
- En í reynd stóðum við frammi fyrir mismunandi vandamálum. Og ég mun tala um þessi vandamál.
- Ég skal segja þér hvernig við greindum það, hvað við breyttum - hvort sem það hjálpaði okkur eða ekki.
- Ég mun ekki segja þér hvernig á að setja upp Patroni, því þú getur googlað á netinu, þú getur skoðað stillingarskrárnar til að skilja hvernig þetta byrjar allt, hvernig það er stillt. Þú getur skilið kerfin, arkitektúr, fundið upplýsingar um það á Netinu.
- Ég ætla ekki að tala um reynslu einhvers annars. Ég ætla aðeins að tala um vandamálin sem við stóðum frammi fyrir.
- Og ég mun ekki tala um vandamál sem eru utan Patroni og PostgreSQL. Ef það eru til dæmis vandamál tengd jafnvægi, þegar klasinn okkar hefur hrunið, ætla ég ekki að tala um það.
Og smá fyrirvari áður en við byrjum á skýrslunni okkar.
Öll þessi vandamál sem við lentum í, við höfðum þau á fyrstu 6-7-8 mánuðum starfseminnar. Með tímanum komumst við að okkar innri bestu starfsvenjum. Og vandamál okkar hurfu. Þess vegna var skýrslan kynnt fyrir um hálfu ári síðan, þegar þetta var allt í fersku minni og ég mundi þetta allt fullkomlega.
Við undirbúning skýrslunnar hef ég þegar vakið upp gamlar skurðaðgerðir, skoðað annálana. Og sum smáatriðin gætu gleymst, eða sum sum smáatriðin var ekki hægt að rannsaka til hlítar við greiningu á vandamálunum, þannig að á sumum stöðum gæti virst að vandamálin séu ekki ígrunduð að fullu eða að það vanti upplýsingar. Og þess vegna bið ég þig að afsaka þessa stund.
Hvað er Patroni?
- Þetta er sniðmát fyrir byggingu HA. Það er það sem segir í skjölunum. Og frá mínu sjónarhorni er þetta mjög rétt skýring. Patroni er ekki silfurkúla sem leysir öll vandamál þín, það er, þú þarft að gera tilraun til að láta það virka og skila ávinningi.
- Þetta er umboðsþjónusta sem er sett upp á hverri gagnagrunnsþjónustu og er eins konar init kerfi fyrir Postgres þinn. Það ræsir Postgres, stoppar, endurræsir, endurstillir og breytir staðfræði klasans þíns.
- Í samræmi við það, til að geyma ástand klasans, þarf núverandi framsetning hans, eins og hann lítur út, einhvers konar geymslu. Og frá þessu sjónarhorni tók Patroni leiðina til að geyma ástand í ytra kerfi. Það er dreifð geymslukerfi fyrir stillingar. Það getur verið Etcd, Consul, ZooKeeper, eða kubernetes Etcd, þ.e.a.s. einn af þessum valkostum.
- Og einn af eiginleikum Patroni er að þú færð sjálfvirka skráninguna úr kassanum, aðeins með því að setja hann upp. Ef við tökum Repmgr til samanburðar, þá er skrárinn innifalinn þar. Með Repmgr fáum við skiptingu, en ef við viljum sjálfvirka skráningu, þá þurfum við að stilla það til viðbótar. Patroni er nú þegar með sjálfvirka skráningu úr kassanum.
- Og það er margt annað. Til dæmis, viðhald á stillingum, úthelling nýrra eftirmynda, öryggisafrit osfrv. En þetta er utan gildissviðs skýrslunnar, ég ætla ekki að tala um það.
Og lítil niðurstaða er sú að aðalverkefni Patroni er að gera sjálfvirka skráningu vel og áreiðanlega þannig að þyrpingin okkar haldist starfhæf og forritið tekur ekki eftir breytingum á þyrpunarsvæðinu.
En þegar við byrjum að nota Patroni verður kerfið okkar aðeins flóknara. Ef við höfðum Postgres áður, þá fáum við Patroni sjálft þegar við notum Patroni, við fáum DCS þar sem ástand er geymt. Og þetta verður allt að virka einhvern veginn. Svo hvað getur farið úrskeiðis?
Getur brotnað:
- Postgres gæti brotnað. Það getur verið meistari eða eftirmynd, annað þeirra gæti mistekist.
- Patroni sjálft gæti brotnað.
- DCS þar sem ástand er geymt getur bilað.
- Og netið getur rofnað.
Öll þessi atriði mun ég fjalla um í skýrslunni.
Ég mun skoða málin eftir því sem þau verða flóknari, ekki út frá því sjónarmiði að málið snúi að mörgum þáttum. Og frá sjónarhóli huglægra tilfinninga, að þetta mál væri erfitt fyrir mig, það var erfitt að taka það í sundur ... og öfugt, sumt mál var létt og það var auðvelt að taka það í sundur.
Og fyrsta tilfellið er það auðveldasta. Þetta er raunin þegar við tókum gagnagrunnsklasa og settum DCS geymsluna okkar á sama klasa. Þetta eru algengustu mistökin. Þetta eru mistök í byggingararkitektúr, þ.e. að sameina mismunandi hluti á einum stað.
Svo, það var filari, við skulum fara að takast á við það sem gerðist.
Og hér höfum við áhuga á því hvenær filurinn gerðist. Það er að segja, við höfum áhuga á þessu augnabliki í tíma þegar klasaástandið breyttist.
En skráningin er ekki alltaf samstundis, þ.e.a.s. það tekur enga tímaeiningu, það getur tafist. Það getur verið langvarandi.
Þess vegna hefur það upphafstíma og lokatíma, þ.e.a.s. það er samfelldur atburður. Og við skiptum öllum atburðum í þrjú tímabil: við höfum tíma fyrir skráningu, meðan á skráningu stendur og eftir skráningu. Það er að segja, við skoðum alla atburði á þessari tímalínu.
Og það fyrsta, þegar skráning gerðist, leitum við að orsökinni fyrir því sem gerðist, hvað var orsök þess sem leiddi til skráningarinnar.
Ef við skoðum stokkana þá verða þeir klassískir Patroni stokkar. Hann segir okkur í þeim að þjónninn sé orðinn meistari og hlutverk meistarans hefur farið yfir á þennan hnút. Hér er það undirstrikað.
Næst þurfum við að skilja hvers vegna skráningin gerðist, þ. Og í þessu tilfelli er allt einfalt. Við höfum villu í samskiptum við geymslukerfið. Húsbóndinn áttaði sig á því að hann gæti ekki unnið með DCS, það er að það var einhvers konar vandamál með samskiptin. Og hann segist ekki geta verið meistari lengur og segir af sér. Þessi lína „lækkað sjálf“ segir nákvæmlega það.
Ef við skoðum atburðina sem voru á undan skráningunni, getum við séð þar einmitt ástæðurnar sem olli því að vandamálið hélt áfram töframanninum.
Ef við skoðum Patroni logs, munum við sjá að við höfum mikið af villum, tímamörkum, þ.e.a.s. Patroni umboðsmaður getur ekki unnið með DCS. Í þessu tilviki er þetta Consul umboðsmaður, sem er í samskiptum á höfn 8500.
Og vandamálið hér er að Patroni og gagnagrunnurinn eru í gangi á sama vélinni. Og Consul netþjónarnir voru ræstir á sama hnút. Með því að búa til álag á netþjóninn bjuggum við til vandamál fyrir Consul netþjónana líka. Þeir gátu ekki átt almennilega samskipti.
Eftir nokkurn tíma, þegar álagið minnkaði, gat Patroni okkar aftur átt samskipti við umboðsmenn. Venjuleg vinna hófst aftur. Og sami Pgdb-2 þjónn varð aftur meistarinn. Það er að segja, það var lítið flipp, vegna þess að hnúturinn sagði upp völdum meistarans og tók þá yfir aftur, það er að segja allt skilaði sér eins og það var.
Og það má líta á þetta sem falska viðvörun, eða það má líta svo á að Patroni hafi gert allt rétt. Það er að segja að hann áttaði sig á því að hann gæti ekki viðhaldið ástandi klasans og fjarlægði vald sitt.
Og hér kom vandamálið upp vegna þess að Consul netþjónarnir eru á sama vélbúnaði og bækistöðvarnar. Í samræmi við það, hvaða álag sem er: hvort sem það er álagið á diska eða örgjörva, hefur það einnig áhrif á samskipti við Consul klasann.
Og við ákváðum að það ætti ekki að búa saman, við úthlutuðum sérstakan klasa fyrir ræðismann. Og Patroni var þegar að vinna með sérstökum ræðismanni, það er að segja, það var sérstakur Postgres þyrping, sérstakt ræðisþyrping. Þetta er grunnkennsla um hvernig á að bera og geyma alla þessa hluti þannig að það lifi ekki saman.
Sem valkostur geturðu snúið breytunum ttl, loop_wait, retry_timeout, þ.e. reynt að lifa af þessa skammtímaálagstoppa með því að auka þessar færibreytur. En þetta er ekki heppilegasti kosturinn, því þetta álag getur verið langur tími. Og við munum einfaldlega fara út fyrir þessi mörk þessara breytu. Og það gæti í rauninni ekki hjálpað.
Fyrsta vandamálið, eins og þú skilur, er einfalt. Við tókum og settum DCS saman við grunninn, við fengum vandamál.
Annað vandamálið er svipað og hið fyrra. Það er svipað að því leyti að við höfum aftur samvirknivandamál með DCS kerfið.
Ef við skoðum annálana þá sjáum við að við höfum aftur samskiptavillu. Og Patroni segir að ég geti ekki haft samskipti við DCS þannig að núverandi meistari fer í afritunarham.
Gamli húsbóndinn verður eftirmynd, hér vinnur Patroni, eins og vera ber. Það keyrir pg_rewind til að spóla færsluskránni til baka og tengjast svo nýja skipstjóranum til að ná í nýja skipstjórann. Hér vinnur Patroni eins og hann á að gera.
Hér verðum við að finna staðinn sem var á undan skráningunni, þ. Og í þessu sambandi eru Patroni logs nokkuð þægilegt að vinna með. Hann skrifar sömu skilaboðin með ákveðnu millibili. Og ef við byrjum að fletta í gegnum þessar logs fljótt, þá munum við sjá af lognum að logs hafa breyst, sem þýðir að einhver vandamál eru hafin. Við snúum fljótt aftur á þennan stað, sjáum hvað gerist.
Og í venjulegum aðstæðum líta logarnir eitthvað svona út. Eigandi lássins er athugaður. Og ef eigandinn hefur til dæmis breyst, þá geta einhverjir atburðir átt sér stað sem Patroni verður að bregðast við. En í þessu tilfelli höfum við það gott. Við erum að leita að staðnum þar sem villurnar byrjuðu.
Og eftir að hafa skrunað að þeim stað þar sem villurnar fóru að birtast, sjáum við að við höfum fengið sjálfvirka skráningu. Og þar sem villur okkar voru tengdar samskiptum við DCS og í okkar tilviki notuðum við Consul, skoðum við líka Consul logs, hvað gerðist þar.
Við gróflega samanburð á tíma framseljanda og tíma í Consul logs sjáum við að nágrannar okkar í Consul klasanum fóru að efast um tilvist annarra meðlima Consul klasans.
Og ef þú skoðar annála annarra Consul umboðsmanna geturðu líka séð að það er einhvers konar nethrun í gangi þar. Og allir meðlimir ræðisklasans efast um tilvist hvors annars. Og þetta var hvatinn fyrir fylgjendan.
Ef þú skoðar hvað gerðist fyrir þessar villur, þá geturðu séð að það eru alls konar villur, til dæmis frestur, RPC féll, það er greinilega einhver vandamál í samskiptum Consul klasameðlima sín á milli .
Einfaldasta svarið er að gera við netið. En fyrir mig, þar sem ég stend á verðlaunapallinum, er auðvelt að segja þetta. En aðstæður eru þannig að viðskiptavinurinn hefur ekki alltaf efni á að gera við netið. Hann gæti búið í DC og gæti ekki gert við netið, haft áhrif á búnaðinn. Og því er þörf á nokkrum öðrum valkostum.
Það eru valkostir:
- Einfaldasti kosturinn, sem er skrifaður, að mínu mati, jafnvel í skjölunum, er að slökkva á Consul eftirliti, það er einfaldlega að fara framhjá tómu fylki. Og við segjum ræðismanninum að nota engar ávísanir. Með þessum athugunum getum við hunsað þessa netstorm og ekki hafið skráningu.
- Annar valkostur er að tvítékka raft_multiplier. Þetta er færibreyta á Consul netþjóninum sjálfum. Sjálfgefið er það stillt á 5. Þetta gildi er mælt með í skjölunum fyrir sviðsetningarumhverfi. Reyndar hefur þetta áhrif á tíðni skilaboða milli meðlima Consul netsins. Reyndar hefur þessi breytu áhrif á hraða þjónustusamskipta milli meðlima Consul klasans. Og fyrir framleiðslu er nú þegar mælt með því að minnka það þannig að hnútarnir skiptast á skilaboðum oftar.
- Annar valkostur sem við höfum fundið upp er að auka forgang Consul ferla meðal annarra ferla fyrir ferlaáætlun stýrikerfisins. Það er svo „fín“ færibreyta, hún ákvarðar bara forgang ferla sem er tekinn til greina af stýrikerfisáætluninni við tímasetningu. Við höfum líka lækkað fínt gildi fyrir Consul umboðsmenn, þ.e. aukið forganginn þannig að stýrikerfið gefur Consul ferlum meiri tíma til að vinna og keyra kóðann sinn. Í okkar tilviki leysti þetta vandamál okkar.
- Annar valkostur er að nota ekki Consul. Ég á vin sem er mikill stuðningsmaður Etcd. Og við rífumst reglulega við hann hvort er betra Etcd eða Consul. En hvað varðar það sem er betra, erum við venjulega sammála honum um að Consul er með umboðsmann sem ætti að vera í gangi á hverjum hnút með gagnagrunni. Það er að segja að samskipti Patroni við Consul klasann fara í gegnum þennan umboðsmann. Og þessi umboðsmaður verður flöskuháls. Ef eitthvað kemur fyrir umboðsmanninn getur Patroni ekki lengur unnið með Consul klasanum. Og þetta er vandamálið. Það er enginn umboðsmaður í Etcd áætluninni. Patroni getur unnið beint með lista yfir Etcd netþjóna og þegar haft samskipti við þá. Í þessu sambandi, ef þú notar Etcd í fyrirtækinu þínu, þá mun Etcd líklega vera betri kostur en Consul. En við hjá viðskiptavinum okkar erum alltaf takmörkuð af því sem viðskiptavinurinn hefur valið og notar. Og við höfum Consul að mestu leyti fyrir alla viðskiptavini.
- Og síðasti liðurinn er að endurskoða færibreytugildin. Við getum hækkað þessar færibreytur í von um að skammtímanetvandamál okkar verði stutt og falli ekki utan sviðs þessara breytu. Þannig getum við dregið úr árásargirni Patroni við sjálfvirka skráningu ef einhver netvandamál koma upp.
Ég held að margir sem nota Patroni kannast við þessa skipun.
Þessi skipun sýnir núverandi stöðu þyrpingarinnar. Og við fyrstu sýn kann þessi mynd að virðast eðlileg. Við erum með meistara, við höfum eftirmynd, það er engin afritunartöf. En þessi mynd er eðlileg nákvæmlega þar til við vitum að þessi þyrping ætti að hafa þrjá hnúta, ekki tvo.
Í samræmi við það var sjálfvirk skráning. Og eftir þessa autofile hvarf eftirmyndin okkar. Við þurfum að komast að því hvers vegna hún hvarf og koma henni aftur, endurheimta hana. Og við förum aftur í skrárnar og sjáum hvers vegna við vorum með sjálfvirka skráningu.
Í þessu tilviki varð önnur eftirmyndin meistarinn. Það er allt í lagi hérna.
Og við þurfum að skoða eftirmyndina sem datt af og sem er ekki í klasanum. Við opnum Patroni logs og sjáum að við áttum í vandræðum meðan á tengingu við þyrpinguna stóð á pg_rewind stigi. Til að tengjast þyrpingunni þarftu að spóla færsluskránni til baka, biðja um nauðsynlegan færslubók frá skipstjóranum og nota hann til að ná í skipstjórann.
Í þessu tilviki erum við ekki með færsluskrá og eftirmyndin getur ekki byrjað. Í samræmi við það stöðvum við Postgres með villu. Og þess vegna er það ekki í klasanum.
Við þurfum að skilja hvers vegna það er ekki í þyrpingunni og hvers vegna það voru engir logs. Við förum til nýja meistarans og skoðum hvað hann hefur í stokkunum. Það kemur í ljós að þegar pg_rewind var lokið kom eftirlitsstöð. Og sumir af gömlu viðskiptaskránum voru einfaldlega endurnefndir. Þegar gamli meistarinn reyndi að tengjast nýja meistaranum og spyrjast fyrir um þessa annála, voru þeir þegar endurnefndir, þeir voru bara ekki til.
Ég bar saman tímastimpla þegar þessir atburðir gerðust. Og þar er munurinn bókstaflega 150 millisekúndur, það er, eftirlitsstöðin kláraðist á 369 millisekúndum, WAL hlutarnir voru endurnefndir. Og bókstaflega árið 517, eftir 150 millisekúndur, byrjaði afturábak á gömlu eftirlíkingunni. Það er, bókstaflega 150 millisekúndur voru nóg fyrir okkur svo að eftirmyndin gæti ekki tengst og unnið sér inn.
Hverjir eru kostirnir?
Við notuðum upphaflega afritunartíma. Okkur fannst það gott. Þó að á fyrsta stigi aðgerðarinnar slökktum við á rifunum. Okkur virtist sem ef rifa safnast upp mörgum WAL-hlutum getum við sleppt meistaranum. Hann mun falla. Við þjáðumst í nokkurn tíma án rifa. Og við áttum okkur á því að við þurfum spilakassa, við skiluðum þeim.
En það er vandamál hér, að þegar meistarinn fer í eftirmyndina, eyðir hann raufunum og eyðir WAL-hlutunum ásamt raufunum. Og til að útrýma þessu vandamáli ákváðum við að hækka breytu wal_keep_segments. Sjálfgefið er það 8 hlutar. Við hækkuðum það í 1 og skoðuðum hversu mikið laust pláss við höfðum. Og við gáfum 000 gígabæt fyrir wal_keep_segments. Það er, þegar skipt er, höfum við alltaf varasjóð upp á 16 gígabæta af viðskiptaskrám á öllum hnútum.
Og plús - það er enn viðeigandi fyrir langtíma viðhaldsverkefni. Segjum að við þurfum að uppfæra eina af eftirlíkingunum. Og við viljum slökkva á því. Við þurfum að uppfæra hugbúnaðinn, kannski stýrikerfið, eitthvað annað. Og þegar við slökkva á eftirmynd er raufin fyrir þá eftirmynd líka fjarlægð. Og ef við notum lítið wal_keep_segments, þá munu viðskiptaskrárnar glatast með langa fjarveru á eftirmynd. Við munum taka upp eftirmynd, það mun biðja um þá viðskiptaskrár þar sem það hætti, en þeir eru kannski ekki á masternum. Og eftirmyndin mun ekki geta tengst heldur. Þess vegna eigum við stóran lager af tímaritum.
Við erum með framleiðslustöð. Nú þegar eru verkefni í gangi.
Það var filari. Við fórum inn og skoðuðum - allt er í lagi, eftirlíkingarnar eru á sínum stað, það er engin afritunartöf. Það eru heldur engar villur í loggunum, allt er í lagi.
Vöruhópurinn segir að það ættu að vera einhver gögn, en við sjáum þau frá einum uppruna, en við sjáum þau ekki í gagnagrunninum. Og við þurfum að skilja hvað varð um þá.
Það er greinilegt að pg_rewind missti af þeim. Við skildum þetta strax en fórum að athuga hvað væri að gerast.
Í annálunum getum við alltaf fundið hvenær skráningin gerðist, hver varð meistarinn, og við getum ákvarðað hver var gamli meistarinn og hvenær hann vildi verða eftirmynd, þ.e. var glataður.
Gamli húsbóndinn okkar hefur endurræst. Og Patroni var skráður í autorun. Setti Patroni á markað. Hann hóf síðan Postgres. Nánar tiltekið, áður en Postgres hófst og áður en hann gerði það að eftirmynd, hóf Patroni pg_rewind ferlið. Í samræmi við það eyddi hann hluta af viðskiptaskránum, hlaðið niður nýjum og tengdi. Hér vann Patroni vel, það er að segja eins og við var að búast. Þyrpingin hefur verið endurreist. Við vorum með 3 hnúta, á eftir skránni 3 hnúta - allt er flott.
Við höfum misst nokkur gögn. Og við þurfum að skilja hversu miklu við höfum tapað. Við erum að leita að augnablikinu þegar við spólum til baka. Við getum fundið það í slíkum dagbókarfærslum. Rewind byrjaði, gerði eitthvað þar og endaði.
Við þurfum að finna stöðuna í viðskiptaskránni þar sem gamli meistarinn hætti. Í þessu tilfelli er þetta merkið. Og við þurfum annað merki, það er fjarlægðin sem gamli meistarinn er frábrugðinn þeim nýja.
Við tökum venjulega pg_wal_lsn_diff og berum saman þessi tvö merki. Og í þessu tilfelli fáum við 17 megabæti. Mikið eða lítið, hver ákveður sjálfur. Vegna þess að fyrir einhvern er 17 megabæti ekki mikið, fyrir einhvern er það mikið og óviðunandi. Hér ákveður hver einstaklingur fyrir sig í samræmi við þarfir fyrirtækisins.
En hvað höfum við sjálf komist að?
Í fyrsta lagi verðum við að ákveða sjálf - þurfum við alltaf að Patroni ræsist sjálfkrafa eftir endurræsingu kerfisins? Það kemur oft fyrir að við þurfum að fara til gamla meistarans, sjá hversu langt hann er kominn. Skoðaðu kannski hluta viðskiptaskrárinnar, sjáðu hvað er þar. Og til að skilja hvort við getum tapað þessum gögnum eða hvort við þurfum að keyra gamla meistarann í sjálfstæðum ham til að draga þessi gögn út.
Og aðeins eftir það verðum við að ákveða hvort við getum fargað þessum gögnum eða við getum endurheimt þau, tengt þennan hnút sem eftirmynd við þyrpinguna okkar.
Að auki er færibreytan „hámark_lag_á_failover“. Sjálfgefið, ef minnið mitt þjónar mér, hefur þessi færibreyta gildið 1 megabæti.
Hvernig virkar hann? Ef eftirmyndin okkar er á eftir 1 megabæti af gögnum í afritunartöfinni, þá tekur þessi eftirmynd ekki þátt í kosningunum. Og ef allt í einu er skrá yfir, lítur Patroni á hvaða eftirlíkingar eru eftirbátar. Ef þeir eru á eftir miklum fjölda viðskiptaskráa geta þeir ekki orðið meistari. Þetta er mjög góður öryggiseiginleiki sem kemur í veg fyrir að þú missir mikið af gögnum.
En það er vandamál í því að afritunartöfin í Patroni þyrpingunni og DCS er uppfærð með ákveðnu millibili. Ég held að 30 sekúndur sé sjálfgefið ttl gildi.
Í samræmi við það getur komið upp sú staða að það sé ein afritunartöf fyrir eftirmyndir í DCS, en í raun getur verið allt önnur töf eða engin töf, þ.e. þetta er ekki rauntíma. Og það endurspeglar ekki alltaf raunverulega mynd. Og það er ekki þess virði að gera fína rökfræði á því.
Og tapshættan er alltaf til staðar. Og í versta tilfelli, ein formúla, og í meðaltali, önnur formúla. Það er að segja, þegar við skipuleggjum innleiðingu Patroni og metum hversu mikið af gögnum við getum tapað verðum við að treysta á þessar formúlur og ímynda okkur í grófum dráttum hversu mikið af gögnum við getum tapað.
Og það eru góðar fréttir. Þegar gamli meistarinn er kominn á undan getur hann farið á undan vegna einhverra bakgrunnsferla. Það er, það var einhvers konar autovacuum, hann skrifaði gögnin, vistaði þau í viðskiptaskránni. Og við getum auðveldlega hunsað og týnt þessum gögnum. Það er ekkert vandamál í þessu.
Og svona líta logarnir út ef maximum_lag_on_failover er stillt og skráning hefur átt sér stað og þú þarft að velja nýjan meistara. Eftirmyndin metur sig ófær um að taka þátt í kosningunum. Og hún neitar að taka þátt í keppninni um leiðtogann. Og hún bíður eftir að nýr meistari verði valinn, svo að hún geti síðan tengst honum. Þetta er viðbótarráðstöfun gegn gagnatapi.
Hér erum við með vöruteymi sem skrifaði að vara þeirra væri í vandræðum með Postgres. Á sama tíma er ekki hægt að nálgast meistarann sjálfan, vegna þess að hann er ekki í boði í gegnum SSH. Og sjálfvirk skráning gerist ekki heldur.
Þessi gestgjafi neyddist til að endurræsa. Vegna endurræsingarinnar gerðist sjálfvirk skrá, þó það væri hægt að gera handvirka sjálfvirka skrá, eins og ég skil núna. Og eftir endurræsingu erum við nú þegar að fara að sjá hvað við áttum með núverandi meistara.
Á sama tíma vissum við fyrirfram að við áttum í vandræðum með diska, það er að segja að við vissum þegar frá því að fylgjast með hvar ætti að grafa og hvað ætti að leita að.
Við komumst inn í postgres log, byrjuðum að sjá hvað var að gerast þar. Við sáum skuldbindingar sem endast þar í eina, tvær, þrjár sekúndur, sem er alls ekki eðlilegt. Við sáum að autovacuum okkar byrjar mjög hægt og undarlega. Og við sáum tímabundnar skrár á disknum. Það er, þetta eru allt vísbendingar um vandamál með diska.
Við skoðuðum kerfið dmesg (kjarnalog). Og við sáum að við áttum í vandræðum með einn af diskunum. Diska undirkerfið var hugbúnaður Raid. Við skoðuðum /proc/mdstat og sáum að okkur vantaði eitt drif. Það er, það er Raid af 8 diskum, okkur vantar einn. Ef þú skoðar glæruna vandlega, þá geturðu séð í úttakinu að við höfum ekki sde þar. Hjá okkur, skilyrt séð, hefur diskurinn dottið út. Þetta olli diskavandamálum og forrit lentu einnig í vandræðum þegar unnið var með Postgres klasanum.
Og í þessu tilfelli myndi Patroni ekki hjálpa okkur á nokkurn hátt, því Patroni hefur ekki það verkefni að fylgjast með stöðu þjónsins, ástandi disksins. Og við verðum að fylgjast með slíkum aðstæðum með utanaðkomandi eftirliti. Við bættum fljótt diskvöktun við ytri eftirlit.
Og það var svona hugsun - gæti skylmingar eða varðhundahugbúnaður hjálpað okkur? Við héldum að hann hefði varla hjálpað okkur í þessu tilfelli, því meðan á vandamálunum stóð hélt Patroni áfram að hafa samskipti við DCS klasann og sá engin vandamál. Það er að segja frá sjónarhóli DCS og Patroni var allt í lagi með þyrpinguna, þó í raun hafi verið vandamál með diskinn, þá voru vandamál með aðgengi gagnagrunnsins.
Að mínu mati er þetta eitt furðulegasta vandamál sem ég hef rannsakað í mjög langan tíma, ég hef lesið fullt af logs, endurvalið og kallað þetta klasahermi.
Vandamálið var að gamli meistarinn gat ekki orðið venjuleg eftirmynd, þ.e.a.s. Patroni byrjaði á því, Patroni sýndi að þessi hnútur væri til staðar sem eftirmynd, en á sama tíma var þetta ekki venjuleg eftirmynd. Nú munt þú sjá hvers vegna. Þetta er það sem ég hef haldið frá greiningu á því vandamáli.
Og hvernig byrjaði þetta allt saman? Það byrjaði, eins og í fyrra vandamálinu, með diskabremsum. Við höfðum skuldbindingar í sekúndu, tvær.
Það voru rof á samböndum, þ.e.a.s. skjólstæðingar slitnuðu.
Það voru stíflur af mismunandi alvarleika.
Og í samræmi við það er diskundirkerfið ekki mjög móttækilegt.
Og það dularfullasta fyrir mig er beiðnin um lokun strax sem barst. Postgres hefur þrjár lokunarstillingar:
- Það er tignarlegt þegar við bíðum eftir að allir viðskiptavinir aftengi sig á eigin spýtur.
- Það er hratt þegar við þvingum viðskiptavini til að aftengjast vegna þess að við erum að fara að loka.
- Og strax. Í þessu tilviki segir strax viðskiptavinum ekki einu sinni að leggja niður, það slekkur bara á sér án viðvörunar. Og til allra viðskiptavina sendir stýrikerfið nú þegar RST skilaboð (TCP skilaboð um að tengingin sé rofin og biðlarinn hafi ekkert meira að grípa).
Hver sendi þetta merki? Postgres bakgrunnsferlar senda ekki slík merki sín á milli, þ.e.a.s. þetta er kill-9. Þeir senda ekki slíkt hvert á annað, þeir bregðast bara við slíku, þ.e.a.s. þetta er neyðarendurræsing Postgres. Hver sendi það, ég veit ekki.
Ég horfði á "síðasta" skipunina og sá einn mann sem skráði sig líka inn á þennan server hjá okkur, en ég var of feiminn til að spyrja spurninga. Kannski var það drepa -9. Ég myndi sjá drepa -9 í loggunum, vegna þess að Postgres segir að það hafi tekið kill -9, en ég sá það ekki í loggunum.
Þegar ég leitaði lengra sá ég að Patroni skrifaði ekki í færslubókina í frekar langan tíma - 54 sekúndur. Og ef við berum saman tvo tímastimpla voru engin skilaboð í um 54 sekúndur.
Og á þessum tíma var sjálfvirk skrá. Patroni stóð sig frábærlega hér aftur. Gamli húsbóndinn okkar var ófáanlegur, eitthvað kom fyrir hann. Og kosning nýs meistara hófst. Hér gekk allt vel. pgsql01 okkar er orðinn nýr leiðtogi.
Við eigum eftirlíkingu sem er orðin meistari. Og það er annað svar. Og það voru vandamál með seinni eftirmyndina. Hún reyndi að stilla upp aftur. Eins og ég skil þetta þá reyndi hún að breyta recovery.conf, endurræsa Postgres og tengjast nýja meistaranum. Hún skrifar skilaboð á 10 sekúndna fresti um að hún sé að reyna, en það tekst ekki.
Og meðan á þessum tilraunum stendur berst tafarlaust merki um lokun til gamla meistarans. Skipstjórinn er endurræstur. Og bati hættir líka vegna þess að gamli meistarinn fer í endurræsingu. Það er, eftirmyndin getur ekki tengst því, vegna þess að hún er í lokunarham.
Á einhverjum tímapunkti virkaði það, en afritunin byrjaði ekki.
Eina giska á að það hafi verið gamalt meistara heimilisfang í recovery.conf. Og þegar nýr meistari birtist reyndi seinni eftirmyndin samt að tengjast gamla meistaranum.
Þegar Patroni byrjaði á annarri eftirmyndinni fór hnúturinn í gang en gat ekki endurtekið. Og afritunartöf myndaðist, sem leit eitthvað á þessa leið. Það er að segja að allir þrír hnútarnir voru á sínum stað en seinni hnúturinn var eftir.
Á sama tíma, ef þú skoðar annálana sem voru skrifaðir, gætirðu séð að afritun gæti ekki hafist vegna þess að færsluskrárnar voru mismunandi. Og þessir viðskiptaskrár sem skipstjórinn býður upp á, sem eru tilgreindir í recovery.conf, passa einfaldlega ekki við núverandi hnút okkar.
Og hér gerði ég mistök. Ég þurfti að koma og sjá hvað væri í recovery.conf til að prófa þá tilgátu mína að við værum að tengjast röngum meistara. En svo var ég bara að fást við þetta og það hvarflaði ekki að mér, eða ég sá að eftirlíkingin var eftir og þyrfti að fylla á aftur, það er að segja ég vann einhvern veginn kæruleysislega. Þetta var mitt lið.
Eftir 30 mínútur kom admin þegar, þ.e.a.s. ég endurræsti Patroni á eftirmyndinni. Ég er búinn að binda enda á það, ég hélt að það þyrfti að fylla á hana aftur. Og ég hugsaði - ég mun endurræsa Patroni, kannski kemur eitthvað gott í ljós. Bati hófst. Og stöðin opnaði meira að segja, hún var tilbúin til að taka við tengingum.
Afritun er hafin. En mínútu síðar datt hún af með villu um að viðskiptaskrár henta henni ekki.
Ég hélt að ég myndi endurræsa aftur. Ég endurræsti Patroni aftur, og ég endurræsti ekki Postgres, heldur endurræsti Patroni í von um að það myndi töfrandi ræsa gagnagrunninn.
Afritunin hófst aftur, en merkin í færsluskránni voru önnur, þau voru ekki þau sömu og fyrri upphafstilraun. Afritun stöðvaðist aftur. Og skilaboðin voru þegar aðeins öðruvísi. Og það var ekki mjög fræðandi fyrir mig.
Og þá dettur mér í hug - hvað ef ég endurræsa Postgres, á þessum tíma geri ég eftirlitsstöð á núverandi skipstjóra til að færa punktinn í viðskiptaskránni aðeins áfram svo að bati hefjist frá öðru augnabliki? Auk þess áttum við enn birgðir af WAL.
Ég endurræsti Patroni, gerði nokkra eftirlitspunkta á masternum, nokkra endurræsingarpunkta á eftirmyndinni þegar hún opnaði. Og það hjálpaði. Ég hugsaði í langan tíma hvers vegna það hjálpaði og hvernig það virkaði. Og eftirmyndin byrjaði. Og afritunin var ekki lengur rifin.
Slíkt vandamál fyrir mig er eitt af þeim dularfyllstu, sem ég velti enn fyrir mér yfir því hvað raunverulega gerðist þarna.
Hver eru afleiðingarnar hér? Patroni getur unnið eins og til er ætlast og án allra villna. En á sama tíma er þetta ekki 100% trygging fyrir því að allt sé í lagi hjá okkur. Eftirmyndin gæti byrjað, en hún gæti verið í hálfvirku ástandi og forritið getur ekki virkað með slíkri eftirmynd, því það verða gömul gögn.
Og eftir skráninguna þarftu alltaf að athuga hvort allt sé í lagi með þyrpinguna, það er að það sé tilskilinn fjöldi afrita, það er engin afritunartöf.
Og þegar við förum í gegnum þessi mál mun ég gera tillögur. Ég reyndi að sameina þær í tvær glærur. Líklega var hægt að sameina allar sögurnar í tvær glærur og aðeins segja þær.
Þegar þú notar Patroni verður þú að hafa eftirlit. Þú ættir alltaf að vita hvenær sjálfvirk yfirskráning átti sér stað, því ef þú veist ekki að þú varst með sjálfvirka skráningu hefurðu enga stjórn á þyrpingunni. Og það er slæmt.
Eftir hverja skráningu verðum við alltaf að athuga þyrpinguna handvirkt. Við þurfum að ganga úr skugga um að við séum alltaf með uppfærðan fjölda afrita, það er engin afritunartöf, það eru engar villur í loggunum sem tengjast straumafritun, með Patroni, með DCS kerfinu.
Sjálfvirkni getur virkað með góðum árangri, Patroni er mjög gott tæki. Það getur virkað, en þetta mun ekki koma þyrpingunni í æskilegt ástand. Og ef við komumst ekki að því, þá verðum við í vandræðum.
Og Patroni er ekki silfurkúla. Við þurfum enn að skilja hvernig Postgres virkar, hvernig afritun virkar og hvernig Patroni vinnur með Postgres og hvernig samskipti milli hnúta eru veitt. Þetta er nauðsynlegt til að geta lagað vandamál með höndunum.
Hvernig nálgast ég vandamálið um greiningu? Það gerðist þannig að við vinnum með mismunandi viðskiptavini og enginn er með ELK stafla, og við verðum að raða út loggunum með því að opna 6 leikjatölvur og 2 flipa. Í einum flipanum eru þetta Patroni logs fyrir hvern hnút, í hinum flipanum eru þetta Consul logs, eða Postgres ef þörf krefur. Það er mjög erfitt að greina þetta.
Hvaða aðferðir hef ég farið? Fyrst horfi ég alltaf þegar skrárinn er kominn. Og fyrir mér eru þetta vatnaskil. Ég horfi á hvað gerðist fyrir framlagningu, meðan á framlagningu stóð og eftir framlagningu. Yfirlýsingin hefur tvö merki: þetta er upphafs- og lokatími.
Næst leita ég í loggunum að atburðum á undan skráningunni, sem voru á undan skráningunni, þ.e.a.s. ég leita að ástæðum hvers vegna skráningin varð.
Og þetta gefur mynd af því að skilja hvað gerðist og hvað hægt er að gera í framtíðinni svo að slíkar aðstæður komi ekki upp (og þar af leiðandi er engin skráning).
Og hvert leitum við venjulega? Ég horfi:
- Í fyrsta lagi að Patroni logunum.
- Næst skoða ég Postgres logs, eða DCS logs, allt eftir því hvað fannst í Patroni logunum.
- Og kerfisskrárnar gefa líka stundum skilning á því hvað olli skráningunni.
Hvað finnst mér um Patroni? Ég á mjög gott samband við Patroni. Að mínu mati er þetta það besta sem til er í dag. Ég þekki margar aðrar vörur. Þetta eru Stolon, Repmgr, Pg_auto_failover, PAF. 4 verkfæri. Ég prófaði þá alla. Patroni er í uppáhaldi hjá mér.
Ef þeir spyrja mig: "Mæli ég með Patroni?". Ég mun segja já, því mér líkar við Patroni. Og ég held að ég hafi lært hvernig á að elda það.
Ef þú hefur áhuga á að sjá hvaða önnur vandamál eru með Patroni fyrir utan vandamálin sem ég hef nefnt, geturðu alltaf skoðað síðuna á GitHub. Þar eru margar ólíkar sögur til og mörg áhugaverð mál rædd. Og fyrir vikið voru nokkrar villur kynntar og leystar, það er að segja þetta er áhugaverð lesning.
Það eru nokkrar áhugaverðar sögur af fólki sem skaut sig í fótinn. Mjög fræðandi. Þú lest og skilur að það er ekki nauðsynlegt að gera það. Ég hakaði við mig.
Og ég vil þakka Zalando kærlega fyrir að þróa þetta verkefni, nefnilega Alexander Kukushkin og Alexey Klyukin. Aleksey Klyukin er einn af meðhöfundunum, hann starfar ekki lengur hjá Zalando en þetta eru tveir einstaklingar sem byrjuðu að vinna með þessa vöru.
Og ég held að Patroni sé mjög flottur hlutur. Ég er ánægður með að hún sé til, það er áhugavert hjá henni. Og kærar þakkir til allra þátttakenda sem skrifa plástra á Patroni. Ég vona að Patroni verði þroskaðri, flottari og duglegri með aldrinum. Það er nú þegar virkt, en ég vona að það verði enn betra. Þess vegna, ef þú ætlar að nota Patroni, ekki vera hræddur. Þetta er góð lausn, það er hægt að útfæra hana og nota.
Það er allt og sumt. Ef þú hefur spurningar skaltu spyrja.
spurningar
Takk fyrir skýrsluna! Ef eftir skráningu þarftu samt að skoða það mjög vandlega, hvers vegna þurfum við þá sjálfvirka skráningu?
Vegna þess að það er nýtt efni. Við erum bara búin að vera hjá henni í eitt ár. Betra að vera öruggur. Við viljum koma inn og sjá að allt gekk í raun eins og það átti að gera. Þetta er stig vantrausts fullorðinna - það er betra að athuga það og sjá.
Við fórum til dæmis um morguninn og skoðuðum, ekki satt?
Ekki á morgnana, við lærum venjulega um sjálfvirka skráningu næstum strax. Við fáum tilkynningar, við sjáum að sjálfvirk skráning hefur átt sér stað. Við förum nánast strax og skoðum. En allar þessar athuganir ættu að vera komnar á eftirlitsstig. Ef þú opnar Patroni í gegnum REST API, þá er til saga. Með sögu er hægt að sjá tímastimpla þegar skráningin átti sér stað. Út frá þessu er hægt að gera eftirlit. Þú getur séð söguna, hversu margir atburðir voru þar. Ef við höfum fleiri atburði, þá hefur sjálfvirk skráning átt sér stað. Þú getur farið og skoðað. Eða sjálfvirkni vöktunar okkar athugaði að við erum með allar eftirlíkingar á sínum stað, það er engin töf og allt er í lagi.
Þakka þér!
Takk kærlega fyrir frábæra sögu! Ef við fluttum DCS klasann eitthvað langt frá Postgres klasanum, þarf þá líka að þjónusta þennan klasa reglulega? Hver eru bestu vinnubrögðin að slökkva þurfi á sumum hlutum DCS klasans, eitthvað að gera við þá o.s.frv.? Hvernig lifir allt þetta mannvirki af? Og hvernig gerir maður þessa hluti?
Fyrir eitt fyrirtæki var nauðsynlegt að gera fylki af vandamálum, hvað gerist ef einn af íhlutunum eða fleiri þættir bila. Samkvæmt þessu fylki förum við í gegnum alla íhlutina í röð og búum til atburðarás ef bilun verður í þessum íhlutum. Í samræmi við það, fyrir hverja bilunaratburðarás, getur þú haft aðgerðaáætlun fyrir bata. Og þegar um DCS er að ræða, þá kemur það sem hluti af stöðluðum innviðum. Og stjórnandinn stjórnar því og við treystum nú þegar á stjórnendurna sem stjórna því og getu þeirra til að laga það ef slys verða. Ef það er alls ekki DCS, þá sendum við það upp, en á sama tíma fylgjumst við ekki sérstaklega með því, vegna þess að við berum ekki ábyrgð á innviðunum, en við gefum ráðleggingar um hvernig og hvað á að fylgjast með.
Það er að segja, skildi ég rétt að ég þarf að slökkva á Patroni, slökkva á skránni, slökkva á öllu áður en ég geri eitthvað með vélunum?
Það fer eftir því hversu marga hnúta við höfum í DCS klasanum. Ef það eru margir hnútar og ef við slökkva aðeins á einum af hnútunum (eftirmyndin), þá heldur þyrpingin hæfileika. Og Patroni er áfram starfræktur. Og ekkert er ræst. Ef við erum með flóknar aðgerðir sem hafa áhrif á fleiri hnúta, en fjarvera þeirra getur eyðilagt sveitina, þá - já, það gæti verið skynsamlegt að setja Patroni í hlé. Það hefur samsvarandi skipun - patronictl pause, patronictl resume. Við gerum bara hlé og sjálfvirk skráning virkar ekki á þeim tíma. Við gerum viðhald á DCS klasanum, þá tökum við hléið af og höldum áfram að lifa.
Þakka þér kærlega!
Þakka þér kærlega fyrir skýrsluna þína! Hvernig finnst vöruteyminu um að gögn glatist?
Vöruhópum er sama og liðsforingjar hafa áhyggjur.
Hvaða tryggingar eru til staðar?
Ábyrgðir eru mjög erfiðar. Alexander Kukushkin er með skýrslu „Hvernig á að reikna út RPO og RTO“, þ.e. batatíma og hversu mikið af gögnum við getum tapað. Ég held að við þurfum að finna þessar glærur og kynna sér þær. Eftir því sem ég man eftir eru sérstök skref um hvernig á að reikna þessa hluti. Hversu mörgum viðskiptum við getum tapað, hversu mikið af gögnum við getum tapað. Sem valkostur getum við notað samstillta afritun á Patroni stigi, en þetta er tvíeggjað sverð: annað hvort höfum við áreiðanleika gagna eða við missum hraða. Það er samstillt afritun, en það tryggir heldur ekki 100% vernd gegn gagnatapi.
Alexey, takk fyrir frábæra skýrslu! Einhver reynsla af því að nota Patroni fyrir núllstigsvörn? Það er, í tengslum við samstilltan biðstöðu? Þetta er fyrsta spurningin. Og seinni spurningin. Þú hefur notað mismunandi lausnir. Við notuðum Repmgr, en án sjálfvirkrar skráningar, og nú ætlum við að taka með sjálfvirkri skráningu. Og við lítum á Patroni sem aðra lausn. Hvað geturðu sagt sem kosti miðað við Repmgr?
Fyrsta spurningin var um samstilltar eftirmyndir. Enginn notar samstillta afritun hér vegna þess að allir eru hræddir (Nokkrir viðskiptavinir eru nú þegar að nota það, í grundvallaratriðum tóku þeir ekki eftir afköstum - Athugasemd ræðumanns). En við höfum þróað reglu fyrir okkur sjálf um að það ættu að vera að minnsta kosti þrír hnútar í samstilltum afritunarþyrpingum, því ef við erum með tvo hnúta og ef masterinn eða eftirmyndin bilar, þá skiptir Patroni þessum hnút yfir í sjálfstæða stillingu þannig að forritið heldur áfram að vinna. Í þessu tilviki er hætta á að gögn tapist.
Varðandi seinni spurninguna höfum við notað Repmgr og gerum enn við nokkra viðskiptavini af sögulegum ástæðum. Hvað er hægt að segja? Patroni kemur með sjálfvirkri skráningu úr kassanum, Repmgr kemur með sjálfvirkri skráningu sem viðbótareiginleika sem þarf að virkja. Við þurfum að keyra Repmgr púkann á hverjum hnút og þá getum við stillt sjálfvirka skráninguna.
Repmgr athugar hvort Postgres hnútar séu á lífi. Repmgr ferlar athuga hvort annað sé til, þetta er ekki mjög skilvirk nálgun. það geta verið flókin tilvik um einangrun nets þar sem stór Repmgr þyrping getur fallið í sundur í nokkra smærri og haldið áfram að vinna. Ég hef ekki fylgst með Repmgr lengi, kannski var það lagað ... eða kannski ekki. En fjarlæging upplýsinga um stöðu klasans í DCS, eins og Stolon, Patroni gerir, er raunhæfasti kosturinn.
Alexey, ég er með spurningu, kannski lélegri. Í einu af fyrstu dæmunum færðir þú DCS frá staðbundinni vél yfir á ytri hýsil. Við skiljum að netið er hlutur sem hefur sín sérkenni, það lifir sjálft. Og hvað gerist ef af einhverjum ástæðum verður DCS þyrpingin ófáanleg? Ég mun ekki segja ástæðurnar, þær geta verið margar: allt frá skakka höndum netverja til raunverulegra vandamála.
Ég sagði það ekki upphátt, en DCS þyrpingin verður líka að vera failover, þ.e.a.s. það er oddafjöldi af hnútum, til þess að ályktun sé uppfyllt. Hvað gerist ef DCS þyrpingin verður ófáanleg, eða ekki er hægt að mæta ályktun, þ.e.a.s. einhvers konar netskipti eða hnútabilun? Í þessu tilviki fer Patroni þyrpingin í skrifvarinn ham. Patroni klasinn getur ekki ákvarðað stöðu klasans og hvað á að gera. Það getur ekki haft samband við DCS og geymt nýja klasastöðuna þar, þannig að allur klasinn fer í skrifvarinn. Og bíður annað hvort eftir handvirkum inngripum frá rekstraraðila eða eftir að DCS jafni sig.
Í grófum dráttum verður DCS þjónusta fyrir okkur jafn mikilvæg og grunnurinn sjálfur?
Já já. Í svo mörgum nútímafyrirtækjum er Service Discovery óaðskiljanlegur hluti innviðanna. Það er verið að innleiða það jafnvel áður en það var einu sinni gagnagrunnur í innviðunum. Hlutfallslega séð var innviðum hleypt af stokkunum, komið fyrir í DC og við höfum strax þjónustuuppgötvun. Ef það er Consul, þá er hægt að byggja DNS á það. Ef þetta er Etcd, þá gæti verið hluti af Kubernetes þyrpingunni, þar sem allt annað verður notað. Mér sýnist að Service Discovery sé nú þegar óaðskiljanlegur hluti af nútíma innviðum. Og þeir hugsa um það miklu fyrr en um gagnagrunna.
Þakka þér!
Heimild: www.habr.com