Pagrindinis „Patroni“ tikslas yra užtikrinti aukštą „PostgreSQL“ prieinamumą. Tačiau „Patroni“ yra tik šablonas, o ne paruoštas įrankis (kas apskritai sakoma dokumentacijoje). Iš pirmo žvilgsnio, sukonfigūravę „Patroni“ bandymų laboratorijoje, galite pamatyti, koks tai puikus įrankis ir kaip lengvai jis susidoroja su mūsų bandymais sunaikinti klasterį. Tačiau praktiškai gamybinėje aplinkoje ne visada viskas vyksta taip gražiai ir elegantiškai, kaip bandymų laboratorijoje.
Papasakosiu šiek tiek apie save. Pradėjau dirbti sistemos administratoriumi. Dirbo interneto svetainių kūrimo srityje. „Data Egret“ dirbu nuo 2014 m. Įmonė užsiima konsultacijomis Postgres srityje. Mes aptarnaujame specialiai „Postgres“ ir dirbame su „Postgres“ kiekvieną dieną, todėl turime įvairios veiklos patirties.
O 2018 metų pabaigoje pamažu pradėjome naudoti „Patroni“. Ir tam tikra specifinė patirtis sukaupta. Mes kažkaip ją diagnozavome, suderinome ir priėjome prie geriausios praktikos. Ir šiame pranešime apie juos kalbėsiu.
Be Postgres, man patinka Linux. Man patinka blaškytis ir jį tyrinėti, man patinka rinkti branduolius. Man patinka virtualizacija, konteineriai, „Docker“, „Kubernetes“. Visa tai mane domina, nes seni adminų įpročiai daro savo. Man patinka suprasti stebėjimą. Ir aš mėgstu postgres dalykus, susijusius su administravimu, ty replikacija, atsarginė kopija. O laisvalaikiu rašau į Go. Nesu programinės įrangos inžinierius, rašau tik sau. Ir man tai teikia malonumą.
- Manau, kad daugelis iš jūsų žino, kad „Postgres“ neturi HA (didelio prieinamumo). Norėdami gauti HA, turite ką nors įdėti, sukonfigūruoti, įdėti pastangų ir gauti.
- Yra keletas įrankių ir „Patroni“ yra vienas iš jų, kuris gana šauniai ir labai gerai išsprendžia HA. Tačiau viską sudėję į bandymų laboratoriją ir paleidę, pamatysime, kad viskas veikia, galime atkurti kai kurias problemas, pamatyti, kaip Patroni jas aptarnauja. Ir pamatysime, kad viskas veikia puikiai.
- Tačiau praktiškai susidūrėme su įvairiomis problemomis. Ir aš kalbėsiu apie šias problemas.
- Papasakosiu, kaip diagnozavome, ką pakoregavome – ar padėjo, ar nepadėjo.
- Nepasakysiu, kaip įdiegti Patroni, nes galite paieškoti internete, galite pažvelgti į konfigūracijos failus, kad suprastumėte, kaip viskas prasideda ir kaip jis sukonfigūruotas. Diagramas ir architektūrą galite suprasti radę informacijos apie tai internete.
- Nekalbėsiu apie kitų žmonių patirtį. Kalbėsiu tik apie problemas, su kuriomis susidūrėme.
- Ir aš nekalbėsiu apie problemas, kurios yra už Patroni ir PostgreSQL ribų. Jei, pavyzdžiui, yra problemų, susijusių su balansavimu, kai žlugo mūsų klasteris, aš apie tai nekalbėsiu.
Ir mažas atsisakymas prieš pradedant savo pranešimą.
Visos šios problemos, su kuriomis susidūrėme, jas turėjome per pirmuosius 6-7-8 veiklos mėnesius. Laikui bėgant priėjome prie mūsų pačių geriausios praktikos. Ir mūsų problemos išnyko. Todėl ataskaita buvo pateikta maždaug prieš pusmetį, kai visa tai buvo šviežia mano galvoje ir viską puikiai prisiminiau.
Rengdamas ataskaitą jau pasiėmiau senus pomirtinius ir apžiūrėjau rąstus. Ir kai kurios detalės gali būti pamirštos arba kai kurios detalės nebuvo iki galo ištirtos analizuojant problemas, todėl kai kuriais momentais gali atrodyti, kad problemos nebuvo iki galo apgalvotos, arba yra kokių nors problemų. informacijos stoka. Ir todėl prašau jūsų atleisti man už šią akimirką.
Kas yra Patronis?
- Tai yra HA kūrimo šablonas. Taip parašyta dokumentacijoje. Ir, mano požiūriu, tai labai teisingas paaiškinimas. Patroni nėra sidabrinė kulka, kuri išspręs visas jūsų problemas, t.y. reikia pasistengti, kad ji pradėtų veikti ir būtų naudinga.
- Tai agento paslauga, įdiegta kiekvienoje tarnyboje su duomenų baze ir kuri yra tam tikra jūsų Postgres įvedimo sistema. Jis paleidžia Postgres, sustabdo, paleidžia iš naujo, pakeičia konfigūraciją ir klasterio topologiją.
- Atitinkamai, norint išsaugoti klasterio būseną, dabartinį jo vaizdą, kaip jis atrodo, reikalinga tam tikra saugykla. Ir šiuo požiūriu Patroni pasirinko būsenos saugojimo išorinėje sistemoje kelią. Tai paskirstyta konfigūracijos saugojimo sistema. Tai gali būti Etcd, Consul, ZooKeeper arba kubernetes Etcd, ty viena iš šių parinkčių.
- Ir viena iš „Patroni“ ypatybių yra ta, kad automatinį failų perkėlimą iš dėžutės gausite tik jį nustatę. Jei palyginimui imsime Repmgr, ten yra failas. Su Repmgr gauname perjungimą, bet jei norime automatinio failų perjungimo, tada jį reikia toliau konfigūruoti. Patroni jau turi automatinį failų perkėlimą iš dėžutės.
- Ir dar daug kitų dalykų. Pavyzdžiui, konfigūracijų priežiūra, naujų kopijų pridėjimas, atsarginės kopijos ir tt Bet tai nepatenka į ataskaitos sritį, apie tai nekalbėsiu.
Ir mažas rezultatas yra tai, kad pagrindinė Patroni užduotis yra gerai ir patikimai atlikti automatinį failų perkėlimą, kad mūsų klasteris veiktų ir programa nepastebėtų klasterio topologijos pokyčių.
Bet kai pradedame naudoti Patroni, mūsų sistema tampa šiek tiek sudėtingesnė. Jei anksčiau turėjome Postgres, tai naudodami Patroni gauname patį Patroni, gauname DCS, kur saugoma būsena. Ir viskas kažkaip turi veikti. Taigi, kas gali sugesti?
Gali nutrūkti:
- Postgres gali nutrūkti. Tai gali būti meistras arba kopija, vienas iš jų gali sugesti.
- Patroni gali sulūžti.
- DCS, kurioje saugoma būsena, gali sugesti.
- Ir tinklas gali nutrūkti.
Visus šiuos punktus apsvarstysiu pranešime.
Apsvarstysiu atvejus, kai jie tampa sudėtingesni, o ne iš to požiūrio, kad byla apima daug komponentų. O žvelgiant iš subjektyvių jausmų, man šitas korpusas buvo kompleksinis, sunku išardyti... ir atvirkščiai, kažkoks korpusas buvo lengvas ir lengvai išardomas.
Ir pirmasis atvejis yra paprasčiausias. Taip yra, kai paėmėme duomenų bazės klasterį ir įdiegėme DCS saugyklą tame pačiame klasteryje. Tai dažniausia klaida. Tai klaida kuriant architektūrą, t. y. derinant skirtingus komponentus vienoje vietoje.
Taigi, atsitiko failas, išsiaiškinkime, kas atsitiko.
Ir čia mus domina, kada įvyko failas. Tai yra, mus domina šis laiko momentas, kai pasikeitė klasterio būsena.
Tačiau failas ne visada vyksta akimirksniu, t. y. neužtrunka tam tikro laiko vieneto, gali užsitęsti. Jis gali būti ilgalaikis.
Todėl jis turi pradžios ir pabaigos laiką, t. y. tai yra tęstinis įvykis. Ir visus įvykius suskirstome į tris intervalus: turime laiko prieš failą, per failą ir po failo. Tai yra, mes atsižvelgiame į visus šios laiko juostos įvykius.
Ir visų pirma, kai įvyko padavimas, mes ieškome priežasties, kas atsitiko, kas sukėlė, kas privedė prie padavimo.
Jei pažvelgsime į rąstus, tai yra klasikiniai Patroni rąstai. Juose jis pasakoja, kad serveris tapo pagrindiniu, o šeimininko vaidmuo perėjo šiam mazgui. Čia paryškinta.
Toliau turime suprasti, kodėl įvyko failas, ty kokie įvykiai įvyko, dėl kurių pagrindinis vaidmuo perėjo iš vieno mazgo į kitą. Ir šiuo atveju viskas paprasta. Sąveikaujant su saugojimo sistema įvyko klaida. Meistras suprato, kad negali dirbti su DCS, t. y. kilo tam tikra sąveikos problema. O jis sako nebegalintis būti šeimininku ir atsistatydina. Ši eilutė „pažemintas aš“ sako būtent tai.
Jei pažiūrėtume į įvykius, įvykusius prieš padavimą, pamatytume pačias priežastis, kurios trukdė tęsti magistro darbą.
Jei pažvelgsime į Patroni žurnalus, pamatysime, kad turime daug klaidų ir skirtojo laiko, ty Patroni agentas negali dirbti su DCS. Šiuo atveju tai yra konsulo agentas, su kuriuo bendravimas vyksta 8500 uoste.
Ir problema yra ta, kad „Patroni“ ir duomenų bazė veikia tame pačiame pagrindiniame kompiuteryje. Ir Consul serveriai buvo paleisti tame pačiame mazge. Sukūrę serverio apkrovą, sukūrėme problemų Consul serveriams. Jie negalėjo normaliai bendrauti.
Po kiek laiko, atslūgus krūviui, mūsų Patroni vėl galėjo bendrauti su agentais. Įprastas darbas atnaujintas. Ir tas pats Pgdb-2 serveris vėl tapo pagrindiniu. Tai yra, įvyko nedidelis apsivertimas, dėl kurio mazgas atsisakė savo, kaip šeimininko, galių, o paskui vėl jas perėmė, t.y., viskas grįžo kaip buvę.
Ir tai gali būti vertinama kaip klaidingai teigiama, arba galima laikyti, kad Patroni viską padarė teisingai. Tai yra, jis suprato, kad negali išlaikyti klasterio būklės ir panaikino savo autoritetą.
Ir čia problema atsirado dėl to, kad Consul serveriai yra toje pačioje įrangoje kaip ir duomenų bazės. Atitinkamai, bet kokia apkrova: ar tai būtų diskų ar procesorių apkrova, ji taip pat turi įtakos sąveikai su „Consul“ grupe.
Ir nusprendėme, kad tai neturėtų gyventi kartu, konsului skyrėme atskirą klasterį. O Patroni jau dirbo su atskiru konsulu, t.y. buvo atskiras Postgres klasteris, atskiras konsulų klasteris. Tai pagrindinė instrukcija, kaip atskirti ir laikyti visus šiuos daiktus, kad jie negyventų kartu.
Arba galite pakoreguoti parametrus ttl, loop_wait, retry_timeout, t. y. bandyti išgyventi trumpalaikius apkrovos pikus padidindami šiuos parametrus. Bet tai nėra pats tinkamiausias variantas, nes ši apkrova gali būti ilgalaikė. Ir mes tiesiog peržengsime šias šių parametrų ribas. Ir tai gali tikrai nepadėti.
Pirmoji problema, kaip jūs suprantate, yra paprasta. Mes paėmėme DCS ir sujungėme jį su pagrindu, ir kilo problema.
Antroji problema panaši į pirmąją. Tai panašu tuo, kad vėl turime problemų sąveikaujant su DCS sistema.
Jei pažiūrėsime į žurnalus, pamatysime, kad vėl įvyko ryšio klaida. Ir Patroni sako, kad negaliu bendrauti su DCS, todėl dabartinis meistras pereina į replikos režimą.
Senasis meistras tampa replika, čia Patroni dirba kaip priklauso. Ji paleidžia pg_rewind, kad atsuktų operacijų žurnalą ir prisijungtų prie naujojo pagrindinio įrenginio, o tada pasieks naująjį pagrindinį. Čia Patroni dirba taip, kaip turėtų.
Čia turime rasti vietą, buvusią prieš failą, t. y. tas klaidas, dėl kurių atsirado failas. Ir šiuo atžvilgiu „Patroni“ rąstai yra gana patogu dirbti. Jis rašo tas pačias žinutes tam tikrais intervalais. Ir jei pradėsime greitai slinkti per šiuos žurnalus, tada iš žurnalų pamatysime, kad žurnalai pasikeitė, o tai reiškia, kad prasidėjo tam tikros problemos. Greitai grįžtame į šią vietą ir žiūrime, kas vyksta.
O įprastoje situacijoje rąstai atrodo maždaug taip. Patikrinamas spynos savininkas. Ir jei savininkas, tarkime, pasikeičia, gali įvykti kai kurie įvykiai, į kuriuos Patroni turi reaguoti. Bet šiuo atveju mums viskas gerai. Ieškome vietos, kur prasidėjo klaidos.
Slinkę iki taško, kur pradėjo atsirasti klaidų, matome, kad turime automatinį failų perkėlimą. Ir kadangi mūsų klaidos buvo susijusios su sąveika su DCS ir mūsų atveju mes naudojome Consul, taip pat žiūrime į Consul žurnalus, kad pamatytume, kas ten atsitiko.
Apytiksliai palyginę padavimo laiką ir laiką konsulų žurnaluose, matome, kad mūsų kaimynai konsulų klasteryje pradėjo abejoti kitų konsulų klasterio narių egzistavimu.
O pažiūrėjus į kitų konsulų agentų žurnalus taip pat matyti, kad ten vyksta kažkoks tinklo griūtis. Ir visi konsulų klasterio nariai abejoja vienas kito egzistavimu. Ir tai buvo postūmis paduotojui.
Pažvelgus į tai, kas vyko prieš šias klaidas, matyti, kad yra visokių klaidų, pavyzdžiui, terminas, nukrito RPC, t.y. akivaizdu, kad konsulų klasterio narių tarpusavio sąveikoje yra tam tikra problema.
Paprasčiausias atsakymas yra sutvarkyti tinklą. Bet stovint ant podiumo man lengva tai pasakyti. Tačiau aplinkybės yra tokios, kad klientas ne visada gali sau leisti remontuoti tinklą. Jis gali gyventi nuolatinėje srovėje ir neturėti galimybės taisyti tinklo ar daryti įtakos įrangai. Ir todėl reikia kitų variantų.
Yra parinkčių:
- Paprasčiausias variantas, kuris, mano nuomone, parašyta net dokumentacijoje, yra išjungti konsulinius patikrinimus, t.y. tiesiog perduoti tuščią masyvą. Ir mes liepiame konsulo agentui nenaudoti jokių čekių. Dėl šių patikrinimų galime nepaisyti šių tinklo audrų ir neinicijuoti failo.
- Kitas variantas – dar kartą patikrinti raft_multiplier. Tai yra paties Consul serverio parametras. Pagal numatytuosius nustatymus jis nustatytas į 5. Ši reikšmė rekomenduojama pagal sustojimo aplinkų dokumentaciją. Iš esmės tai turi įtakos pranešimų mainų tarp Consul tinklo narių dažnumui. Iš esmės šis parametras turi įtakos oficialaus ryšio tarp konsulų grupės narių greičiui. O gamybai jau rekomenduojama jį sumažinti, kad mazgai dažniau keistųsi žinutėmis.
- Kita galimybė, kurią pradėjome naudoti, buvo padidinti Consul procesų prioritetą tarp kitų operacinės sistemos procesų planavimo procesų. Yra toks parametras „gražu“, jis tiesiog nustato procesų prioritetą, į kurį planuodamas atsižvelgia OS planuotojas. Taip pat sumažinome konsulų agentams malonią vertę, t.y. padidino prioritetą, kad operacinė sistema Consul procesams suteiktų daugiau laiko dirbti ir vykdyti savo kodą. Mūsų atveju tai išsprendė mūsų problemą.
- Kitas variantas yra nenaudoti Consul. Turiu draugą, kuris yra didelis Etcd rėmėjas. Ir jis ir aš nuolat ginčijamės, kas geriau, ir kt., ar konsulas. Tačiau kalbant apie tai, kas yra geriau, jis ir aš paprastai sutinkame, kad Consulas turi agentą, kuris turi veikti kiekviename duomenų bazės mazge. Tai reiškia, kad Patroni sąveika su konsulų grupe vyksta per šį agentą. Ir šis agentas tampa kliūtimi. Jei agentui kažkas atsitiks, Patroni nebegali dirbti su konsulų grupe. Ir tai yra problema. Etcd plane agento nėra. Patroni gali tiesiogiai dirbti su Etcd serverių sąrašu ir jau bendrauti su jais. Šiuo atžvilgiu, jei savo įmonėje naudojate Etcd, Etcd tikriausiai bus geresnis pasirinkimas nei Consul. Tačiau su savo klientais mus visada riboja tai, ką klientas pasirinko ir naudoja. Ir dažniausiai visi mūsų klientai turi konsulą.
- Ir paskutinis dalykas yra persvarstyti parametrų reikšmes. Šiuos parametrus galime pakelti aukščiau, tikėdamiesi, kad mūsų trumpalaikės tinklo problemos bus trumpos ir nepateks į šių parametrų diapazoną. Tokiu būdu galime sumažinti „Patroni“ agresyvumą atliekant automatinį failų perkėlimą, jei iškyla kokių nors tinklo problemų.
Manau, kad daugelis naudojančių Patroni yra susipažinę su šia komanda.
Ši komanda rodo esamą klasterio būseną. Ir iš pirmo žvilgsnio šis vaizdas gali atrodyti normalus. Mes turime meistrą, turime repliką, replikacijos vėlavimo nėra. Tačiau šis vaizdas yra normalus, kol nežinome, kad šiame klasteryje turėtų būti trys mazgai, o ne du.
Atitinkamai įvyko automatinis failo perkėlimas. Ir po šio automatinio failo perkėlimo mūsų kopija dingo. Turime išsiaiškinti, kodėl ji dingo, ir sugrąžinti, atkurti. Ir vėl einame į žurnalus ir žiūrime, kodėl įvyko automatinis failų perkėlimas.
Šiuo atveju antroji kopija tapo meistru. Viskas čia gerai.
Ir mes turime pažvelgti į kopiją, kuri nukrito ir kurios nėra klasteryje. Atidarome „Patroni“ žurnalus ir matome, kad prisijungdami prie klasterio susidūrėme su problema pg_rewind etape. Norėdami prisijungti prie klasterio, turite atsukti operacijų žurnalą, paprašyti reikalingo operacijų žurnalo iš pagrindinio ir naudoti jį, kad pasiektumėte pagrindinį.
Tokiu atveju neturime operacijų žurnalo ir kopijos negalima pradėti. Atitinkamai sustabdome „Postgres“ su klaida. Ir todėl jo nėra klasteryje.
Turime suprasti, kodėl jo nėra klasteryje ir kodėl nebuvo žurnalų. Einame pas naująjį meistrą ir žiūrime, ką jis turi savo žurnaluose. Pasirodo, kai buvo atlikta pg_rewind, įvyko kontrolinis taškas. O kai kurie senieji operacijų žurnalai buvo tiesiog pervadinti. Kai senasis meistras bandė prisijungti prie naujojo meistro ir paprašyti šių žurnalų, jie jau buvo pervadinti, jų tiesiog nebuvo.
Palyginau laiko žymes, kada šie įvykiai įvyko. Ir ten skirtumas tiesiogine prasme yra 150 milisekundžių, t.y. per 369 milisekundes buvo baigtas patikros taškas, WAL segmentai buvo pervadinti. Ir pažodžiui, 517, po 150 milisekundžių, senosios kopijos atsukimas atgal prasidėjo. Tai reiškia, kad mums pakako 150 milisekundžių, kad kopija negalėtų prisijungti ir neveikti.
Kokios yra galimybės?
Iš pradžių naudojome replikacijos lizdus. Manėme, kad tai gerai. Nors pirmajame veikimo etape išjungėme lizdus. Mums atrodė, kad jei lizdai sukaups daug WAL segmentų, mes galime atsisakyti pagrindinio. Jis kris. Kurį laiką kentėjome be laiko tarpsnių. Ir mes supratome, kad mums reikia laiko tarpsnių, grąžinome laiko tarpsnius.
Tačiau čia yra problema, kad kai pagrindinis kompiuteris pereina į repliką, jis ištrina lizdus ir kartu su lizdais ištrina WAL segmentus. Ir norėdami pašalinti šią problemą, nusprendėme padidinti parametrą wal_keep_segments. Pagal numatytuosius nustatymus yra 8 segmentai. Pakėlėme iki 1 ir pažiūrėjome, kiek turime laisvos vietos. Ir mes skyrėme 000 gigabaitų „wal_keep_segments“. Tai reiškia, kad perjungdami visada turime 16 gigabaitų operacijų žurnalų rezervą visuose mazguose.
Ir pliusas – tai aktualu ir atliekant ilgalaikes priežiūros užduotis. Tarkime, kad turime atnaujinti vieną iš kopijų. Ir mes norime jį išjungti. Turime atnaujinti programinę įrangą, galbūt operacinę sistemą, dar ką nors. Ir kai išjungiame repliką, tos replikos lizdas taip pat pašalinamas. Ir jei naudosime mažus wal_keep_segments, tada, jei ilgai nebus kopijos, operacijų žurnalai bus prarasti. Mes paimsime kopiją, ji paprašys tų operacijų žurnalų, kur ji sustojo, bet jų gali nebūti pagrindiniame kompiuteryje. Ir replika taip pat negalės prisijungti. Štai kodėl turime daug žurnalų.
Turime gamybinę bazę. Ten jau vyksta projektai.
Įvyko failas. Įėjome ir pažiūrėjome – viskas tvarkoje, kopijos vietoje, replikacijos atsilikimo nėra. Žurnaluose irgi klaidų nėra, viskas tvarkoje.
Produkto komanda sako, kad atrodo, kad turėtų būti tam tikrų duomenų, bet mes juos matome iš vieno šaltinio, bet nematome duomenų bazėje. Ir mes turime suprasti, kas jiems nutiko.
Aišku, kad pg_rewind juos ištrynė. Iš karto tai supratome, bet nuėjome pažiūrėti, kas vyksta.
Žurnaluose visada galime rasti, kada įvyko failų teikėjas, kas tapo šeimininku, ir galime nustatyti, kas buvo senasis meistras ir kada norėjo tapti kopija, t. y. šių žurnalų mums reikia, kad sužinotume, kiek operacijų žurnalų buvo prarado.
Mūsų senasis meistras paleido iš naujo. Ir Patroni buvo užregistruotas automatiniame starte. Patroni paleido. Tada jis pradėjo „Postgres“. Tiksliau, prieš paleisdamas „Postgres“ ir prieš padarydamas jos kopiją, „Patroni“ paleido pg_rewind procesą. Atitinkamai jis ištrynė kai kuriuos operacijų žurnalus, atsisiuntė naujų ir prisijungė. Čia Patroni puikiai atliko savo darbą, tai yra, kaip ir turi būti. Mūsų klasteris buvo atkurtas. Turėjome 3 mazgus, po failerio buvo 3 mazgai - viskas buvo šaunu.
Praradome kai kuriuos duomenis. Ir mes turime suprasti, kiek daug praradome. Ieškome būtent to momento, kai atsisukome atgal. Tai galime sužinoti iš šių žurnalo įrašų. atsukimas prasidėjo, ten kažką padarė ir baigėsi.
Turime rasti poziciją operacijų žurnale, kurioje senasis meistras sustojo. Šiuo atveju tai yra šis ženklas. Ir mums reikia antrojo ženklo, t.y. atstumo, kuriuo senasis meistras skiriasi nuo naujojo.
Imame įprastą pg_wal_lsn_diff ir palyginame šiuos du ženklus. Ir šiuo atveju gauname 17 megabaitų. Ar tai daug, ar mažai, kiekvienas nusprendžia pats. Nes vieniems 17 megabaitų nėra daug, kitiems – daug ir nepriimtina. Čia kiekvienas sprendžia individualiai, atsižvelgdamas į verslo poreikius.
Bet ką mes patys sužinojome?
Pirma, turime nuspręsti patys – ar mums visada reikia „Patroni“ automatinio paleidimo po sistemos perkrovimo? Dažniau nutinka taip, kad tenka eiti pas senąjį meistrą, pasižiūrėti, kiek jis nuėjo. Galbūt apžiūrėkite operacijų žurnalo segmentus, pažiūrėkite, kas ten yra. Ir supraskite, ar galime prarasti šiuos duomenis, ar mums reikia paleisti senąjį pagrindinį kompiuterį autonominiu režimu, kad gautume šiuos duomenis.
Ir tik po to turime nuspręsti, ar galime išmesti šiuos duomenis, ar galime juos atkurti, prijungti šį mazgą kaip kopiją prie mūsų klasterio.
Be to, yra parametras „maximum_lag_on_failover“. Pagal numatytuosius nustatymus, jei mano atmintis manęs neapgauna, šio parametro reikšmė yra 1 megabaitas.
Kaip jis dirba? Jei mūsų replika atsilieka 1 megabaitu duomenų replikacijos delsoje, tada ši kopija rinkimuose nedalyvauja. Ir jei staiga įvyksta failas, Patroni žiūri, kurios kopijos atsilieka. Jei jie atsilieka nuo daugybės operacijų žurnalų, jie negali tapti šeimininkais. Tai labai gera saugumo funkcija, kuri neleidžia prarasti daug duomenų.
Tačiau yra problema, kad replikacijos delsa Patroni ir DCS klasteryje atnaujinama tam tikru intervalu. Manau, kad 30 sekundžių yra numatytoji ttl reikšmė.
Atitinkamai, gali būti situacija, kai DCS replikacijų replikacijos delsa yra tokia pati, bet iš tikrųjų gali būti visiškai kitokia delsa arba gali nebūti vėlavimo, t.y. šis dalykas nėra realus. Ir tai ne visada atspindi tikrąjį vaizdą. Ir neverta kurti išgalvotos logikos.
O nuostolių rizika visada išlieka. Ir blogiausiu atveju yra viena formulė, o vidutiniu – kita. Tai yra, kai planuojame „Patroni“ diegimą ir įvertiname, kiek duomenų galime prarasti, turime pasikliauti šiomis formulėmis ir maždaug įsivaizduoti, kiek duomenų galime prarasti.
Ir yra gerų naujienų. Kai senasis meistras pajudėjo į priekį, jis gali judėti į priekį dėl tam tikrų foninių procesų. Tai yra, buvo kažkoks autovakuumas, surašė duomenis ir įrašė į operacijų žurnalą. Ir mes galime lengvai ignoruoti ir prarasti šiuos duomenis. Dėl to nėra jokių problemų.
Taip atrodo žurnalai, jei nustatytas maximum_lag_on_failover ir įvyksta failo perkėlimas ir reikia pasirinkti naują pagrindinį. Replika save vertina kaip negalinčią dalyvauti rinkimuose. Ir ji atsisako dalyvauti lenktynėse dėl lyderystės. Ir ji laukia, kol bus parinktas naujas meistras, kad galėtų prie jo prisijungti. Tai papildoma priemonė nuo duomenų praradimo.
Čia mūsų produktų komanda parašė, kad jų gaminyje kyla problemų dirbant su „Postgres“. Tuo pačiu metu negalite pasiekti paties pagrindinio kompiuterio, nes jis nepasiekiamas per SSH. Ir automatinis failų perkėlimas taip pat nevyksta.
Šis pagrindinis kompiuteris buvo priverstas paleisti iš naujo. Dėl perkrovimo įvyko automatinis failų perkėlimas, nors, kaip dabar suprantu, buvo galima atlikti ir rankinį automatinį failų perkėlimą. O po perkrovimo einame pažiūrėti, ką turėjome su dabartiniu meistru.
Tuo pačiu iš anksto žinojome, kad turime problemų su diskais, t.y. jau iš stebėjimo žinojome, kur kasti ir ko ieškoti.
Įlipome į postgres žurnalą ir pradėjome žiūrėti, kas ten vyksta. Mes matėme įsipareigojimus, kurie truko vieną, dvi ar tris sekundes, o tai visiškai nėra normalu. Pamatėme, kad mūsų autovakuuminis įsijungė labai ilgai ir keistai. Ir mes matėme laikinus failus diske. Tai yra, visa tai rodo problemų su diskais rodiklius.
Peržiūrėjome sistemos dmesg (branduolinių pranešimų žurnalą). Ir pamatėme, kad turime problemų su vienu iš diskų. Disko posistemis buvo programinės įrangos Raid. Pažiūrėjome /proc/mdstat ir pamatėme, kad trūksta vieno disko. Tai yra, yra 8 diskų reidas, mums vieno trūksta. Jei atidžiai pažvelgsite į skaidrę, išvestyje pamatysite, kad ten neturime sde. Mūsų diskas, palyginti, iškrito. Tai sukėlė disko problemas, o programoms taip pat iškilo problemų dirbant su Postgres grupe.
Ir šiuo atveju Patroni mums niekaip nepadėtų, nes Patroni neturi užduoties stebėti serverio būsenos, disko būsenos. Ir mes turime stebėti tokias situacijas su išorine stebėsena. Prie išorinio stebėjimo pridėjome operatyvų disko stebėjimą.
Ir kilo tokia mintis – ar galėtų mums padėti tvoros ar sargybos programinė įranga? Pagalvojome, kad vargu ar jis būtų mums padėjęs šiuo atveju, nes iškilus problemoms Patroni toliau bendravo su DCS klasteriumi ir nematė jokios problemos. Tai yra, DCS ir Patroni požiūriu, su klasteriumi viskas buvo gerai, nors iš tikrųjų buvo problemų su disku, buvo problemų su duomenų bazės prieinamumu.
Mano nuomone, tai yra viena keisčiausių problemų, kurią labai ilgai tyrinėjau, perskaičiau daugybę žurnalų, sugalvojau ir pavadinau klasterio simuliatoriumi.
Problema ta, kad senasis meistras negalėjo tapti normalia kopija, t.y. Patroni jį paleido, Patroni parodė, kad šis mazgas yra kaip replika, bet tuo pačiu metu tai nebuvo įprasta kopija. Dabar pamatysite kodėl. Aš nenagrinėjau šios problemos.
Ir nuo ko viskas prasidėjo? Jis prasidėjo, kaip ir ankstesnė problema, su diskiniais stabdžiais. Įsipareigodavome po vieną sekundę, po dvi.
Buvo ryšio pertraukų, t.y. klientai buvo atjungti.
Buvo įvairaus sunkumo užsikimšimų.
Ir atitinkamai disko posistemis nelabai reaguoja.
Ir pats paslaptingiausias dalykas man yra nedelsiant gautas išjungimo prašymas. „Postgres“ turi tris išjungimo režimus:
- Gražu, kai laukiame, kol visi klientai atsijungs patys.
- Pasitaiko greitai, kai priverčiame klientus atsijungti, nes ketiname išjungti.
- Ir nedelsiant. Tokiu atveju nedelsiant net nesako klientams išsijungti, jis tiesiog išsijungia be įspėjimo. O operacinė sistema siunčia RST žinutę visiems klientams (TCP žinutė, kad ryšys nutrūko ir klientui daugiau nėra ką gaudyti).
Kas atsiuntė šį signalą? Fonas Postgres procesai nesiunčia vienas kitam tokių signalų, t.y. tai yra kill-9. Jie to nesiunčia vienas kitam, jie tik į tai reaguoja, t. y. tai yra avarinis „Postgres“ paleidimas. Nežinau, kas jį atsiuntė.
Pažiūrėjau į „paskutinę“ komandą ir pamačiau vieną žmogų, kuris taip pat prisijungė prie šio serverio kartu su mumis, bet man buvo nepatogu užduoti klausimą. Galbūt tai buvo nužudymas -9. Matyčiau nužudyti -9 rąstuose, nes... Postgres sako, kad priėmė kill -9, bet aš to nemačiau žurnaluose.
Žiūrėdamas toliau, pamačiau, kad Patroni į žurnalą nerašė gana ilgai – 54 sekundes. Ir jei palyginsite du laiko žymes, pranešimų nebuvo apie 54 sekundes.
Ir per tą laiką įvyko automatinis failų perkėlimas. Patroni čia vėl puikiai dirbo. Mūsų senasis meistras buvo nepasiekiamas, jam kažkas atsitiko. Ir prasidėjo naujo meistro rinkimai. Čia viskas pavyko puikiai. Mūsų pgsql01 tapo mūsų naujuoju lyderiu.
Turime kopiją, kuri tapo meistre. Ir yra antra kopija. O dėl antrosios pastabos kilo problemų. Ji bandė perkonfigūruoti. Kaip suprantu, ji bandė pakeisti recovery.conf, iš naujo paleisti Postgres ir prisijungti prie naujojo pagrindinio. Ji kas 10 sekundžių rašo žinutes, kad bando, bet jai nesiseka.
Ir per šiuos bandymus pas senąjį meistrą ateina nedelsiant išjungimo signalas. Meistras paleidžia iš naujo. Taip pat atkūrimas sustoja, nes senasis meistras persikrauna. Tai reiškia, kad kopija negali prisijungti prie jos, nes ji yra išjungimo režimu.
Tam tikru momentu tai veikė, bet replikacija neprasidėjo.
Vienintelė hipotezė, kurią turiu, yra ta, kad recovery.conf yra senojo meistro adresas. O kai atsirado naujas meistras, antroji replika vis tiek bandė prisijungti prie senojo meistro.
Kai „Patroni“ paleido antrąją kopiją, mazgas įsijungė, bet negalėjo prisijungti per replikaciją. Ir susidarė replikacijos atsilikimas, kuris atrodė maždaug taip. Tai yra, visi trys mazgai buvo vietoje, bet antrasis mazgas atsiliko.
Tuo pačiu metu, jei pažvelgsite į įrašytus žurnalus, pamatytumėte, kad replikacija negalėjo prasidėti, nes operacijų žurnalai skiriasi. O vedlio siūlomi operacijų žurnalai, kurie yra pateikti recovery.conf, tiesiog netinka mūsų dabartiniam mazgui.
Ir čia aš padariau klaidą. Turėjau atvykti pažiūrėti, kas ten yra recovery.conf, kad patikrinčiau savo hipotezę, kad jungiamės su netinkamu šeimininku. Bet aš tuo metu tai tik sugalvojau ir man neatėjo į galvą, arba pamačiau, kad replika atsilieka ir turės būti papildyta, t.y. kažkaip neatsargiai tai padariau. Tai buvo mano kamštis.
Po 30 minučių atvyko administratorius, ty iš naujo paleidau Patroni kopijoje. Jau buvau jo atsisakiusi, galvojau, kad reiks papildyti. Ir pagalvojau, iš naujo paleisiu „Patroni“, gal kas nors gero išeis. Prasidėjo atsigavimas. O bazė net atsidarė, buvo pasiruošusi priimti ryšius.
Replikacija prasidėjo. Tačiau po minutės jis sudužo su klaida, kad operacijų žurnalai jam netinka.
Maniau, kad vėl paleisiu iš naujo. Iš naujo paleidau Patroni, o ne Postgres, bet iš naujo paleidau Patroni tikėdamasis, kad tai stebuklingai paleis duomenų bazę.
Replikacija prasidėjo iš naujo, tačiau užrašai operacijų žurnale skyrėsi, jie buvo ne tokie patys, kaip ir ankstesniame bandyme pradėti. Replikacija vėl sustojo. Ir žinutė buvo šiek tiek kitokia. Ir man tai nebuvo itin informatyvu.
Ir tada man ateina į galvą mintis – o kas, jei iš naujo paleisiu Postgres, šiuo metu dabartiniame pagrindiniame kompiuteryje nustatysiu patikros tašką, kad perkelčiau tašką operacijų žurnale šiek tiek į priekį, kad atkūrimas prasidėtų nuo kito momento? Be to, ten dar turėjome WAL rezervų.
Paleidau „Patroni“ iš naujo, padariau porą pagrindinio pagrindinio tikrinimo punktų, kelis iš naujo paleidau kopiją, kai ji atsidarė. Ir tai padėjo. Ilgai galvojau, kodėl tai padėjo ir kaip tai veikė. Ir prasidėjo replika. Ir replikacija nebepavyko.
Ši problema man yra viena paslaptingiausių, dėl kurios iki šiol nesuprantu, kas ten iš tikrųjų atsitiko.
Kokios čia išvados? Patroni gali dirbti pagal paskirtį ir be klaidų. Tačiau kartu tai nėra 100% garantija, kad pas mus viskas gerai. Replika gali paleisti, bet ji gali būti pusiau darbinės būsenos, o programa negali dirbti su tokia kopija, nes ten bus seni duomenys.
O po fileover visada reikia patikrinti, ar su klasteriumi viskas gerai, t.y. turime reikiamą replikų skaičių ir nėra replikacijos uždelsimo.
Ir kai mes svarstysime šias problemas, suformuluosiu rekomendacijas. Bandžiau juos sujungti į dvi skaidres. Tikriausiai visas istorijas buvo galima sujungti į dvi skaidres ir tik jas pasakoti.
Kai naudojate Patroni, turite stebėti. Visada turėtumėte žinoti, kada įvyko automatinis failų perkėlimas, nes jei nežinote, kad turėjote automatinį failų perkėlimą, jūs nevaldote klasterio. Ir tai yra blogai.
Po kiekvieno failo visada turėtume rankiniu būdu patikrinti klasterį. Turime įsitikinti, kad visada turime naujausią kopijų skaičių, nėra replikacijos delsos ir žurnaluose, susijusių su srautiniu replikavimu, Patroni ar DCS sistema, nėra klaidų.
Automatika gali sėkmingai veikti, Patroni yra labai geras įrankis. Tai gali veikti, bet neatves klasterio į norimą būseną. O jei mes to nežinosime, turėsime problemų.
Ir Patroni nėra sidabrinė kulka. Vis dar turime suprasti, kaip veikia „Postgres“, kaip veikia replikacija ir kaip „Patroni“ dirba su „Postgres“ ir kaip pasiekiamas ryšys tarp mazgų. Tai būtina norint išspręsti problemas savo rankomis.
Kaip spręsti diagnozės problemą? Taip susiklostė, kad dirbame su skirtingais klientais ir niekas neturi ELK kamino, o žurnalus turime suprasti atidarę 6 pultus ir 2 skirtukus. Viename skirtuke yra kiekvieno mazgo Patroni žurnalai, kitame skirtuke yra Consul žurnalai arba, jei reikia, Postgres žurnalai. Labai sunku diagnozuoti.
Kokius metodus sukūriau? Pirma, aš visada žiūriu, kada atvyko paduotojas. Ir man tai yra savotiškas vandens baseinas. Žiūriu, kas atsitiko iki padavimo, per padavimo ir po padavimo. Fileover turi du ženklus: tai pradžios ir pabaigos laikas.
Toliau žurnaluose žiūriu į įvykius prieš failą, kurie buvo prieš failą, t.y. ieškau priežasčių, kodėl atsirado failas.
Tai leidžia suprasti, kas atsitiko ir ką galima padaryti ateityje, kad tokios aplinkybės nepasikartotų (ir dėl to failo perkėlimas neįvyksta).
O kur mes dažniausiai žiūrime? Aš atrodau:
- Pirmiausia į „Patroni“ žurnalus.
- Toliau žiūriu į „Postgres“ arba „DCS“ žurnalus, atsižvelgiant į tai, kas buvo rasta „Patroni“ žurnaluose.
- Sistemos žurnalai taip pat kartais leidžia suprasti, kas sukėlė failą.
Kaip aš jaučiu Patronį? Jaučiuosi labai gerai dėl Patroni. Mano nuomone, tai yra geriausia, kas šiandien yra. Žinau daug kitų produktų. Tai yra Stolon, Repmgr, Pg_auto_failover, PAF. 4 įrankiai. Aš išbandžiau juos visus. Man labiausiai patiko Patroni.
Jei jie manęs klausia: „Ar aš rekomenduoju Patroni? Pasakysiu taip, nes man patinka Patroni. Ir manau, kad išmokau jį virti.
Jei norite sužinoti, kokių kitų problemų yra su Patroni, be mano išsakytų problemų, visada galite eiti į puslapį „GitHub“. Ten daug įvairių istorijų ir daug įdomių problemų aptariama. Dėl to buvo įvestos ir išspręstos kai kurios klaidos, t. y. tai įdomu.
Ten yra įdomių istorijų apie žmones, kurie šaudo sau į koją. Labai informatyvu. Perskaitote ir suprantate, kad jums to daryti nereikia. Pati pasižymėjau.
Ir aš norėčiau pasakyti didelį ačiū Zalando įmonei už šio projekto vystymą, būtent Aleksandrui Kukuškinui ir Aleksejui Klyukinui. Aleksejus Klyukinas yra vienas iš bendraautorių, jis nebedirba Zalando, bet tai du žmonės, kurie pradėjo dirbti su šiuo produktu.
Ir aš manau, kad Patroni yra labai šaunus dalykas. Džiaugiuosi, kad ji egzistuoja, su ja įdomu būti. Ir labai ačiū visiems bendradarbiams, kurie rašo pataisas „Patroni“. Tikiuosi, kad Patroni su amžiumi taps brandesnis, šaunesnis ir pajėgesnis. Jis jau efektyvus, bet tikiuosi, kad jis taps dar geresnis. Taigi, jei planuojate naudoti Patroni savo namuose, nebijokite. Tai geras sprendimas, jį galima įgyvendinti ir panaudoti.
Tai viskas. Jei turite klausimų, klauskite.
Klausimai
Ačiū už pranešimą! Jei po failo vis tiek reikia labai atidžiai ten žiūrėti, tai kam mums reikalingas automatinis failas?
Nes tai naujas dalykas. Su ja dirbame tik metus. Geriau žaisti saugiai. Norime ateiti ir pamatyti, kad viskas iš tikrųjų veikia taip, kaip turėtų. Tai suaugusiųjų nepasitikėjimo lygis – geriau dar kartą patikrinti ir pamatyti.
Pavyzdžiui, mes atėjome šį rytą ir pažiūrėjome, ar ne?
Ne ryte, paprastai apie automatinį failų perkėlimą sužinome beveik iš karto. Gauname pranešimus, matome, kad įvyko automatinis failų perkėlimas. Beveik iš karto įeiname ir pasižiūrime. Tačiau visi šie patikrinimai turi būti perkelti į stebėjimo lygį. Jei prisijungiate prie „Patroni“ per REST API, yra istorija. Naudodami istoriją galite peržiūrėti laiko žymas, kada failas buvo atsiųstas. Remiantis tuo, galima atlikti stebėjimą. Galite pažvelgti į istoriją, kad pamatytumėte, kiek įvykių buvo. Jei turime daugiau įvykių, tai reiškia, kad įvyko automatinis failų perkėlimas. Galite eiti ir pasižiūrėti. Arba mūsų stebėjimo automatika patikrino, ar turime visas kopijas, nėra atsilikimo ir viskas gerai.
Dėkojame!
Labai ačiū už puikią istoriją! Jei DCS klasterį perkėlėme kur nors toliau nuo Postgres klasterio, ar šį klasterį taip pat reikia periodiškai aptarnauti? Kokia yra geriausia praktika, kai kai kurias DCS klasterio dalis reikia išjungti, ką nors su jomis daryti ir pan.? Kaip visa ši struktūra gyvena? Ir kaip daryti šiuos dalykus?
Vienai įmonei reikėjo sukurti problemų matricą, kas atsitiks, jei vienas ar keli komponentai sugenda. Naudodami šią matricą nuosekliai peržiūrime visus komponentus ir sukuriame scenarijus šių komponentų gedimo atveju. Atitinkamai, kiekvienam gedimo scenarijui galite turėti veiksmų planą atstatymui. O DCS atveju tai yra standartinės infrastruktūros dalis. Ir administratorius tai administruoja, o mes jau pasikliaujame tai administruojančiais administratoriais ir jo galimybėmis sutvarkyti nelaimių atveju. Jei DCS iš viso nėra, tai diegiame, bet ypatingai nestebime, nes neatsakome už infrastruktūrą, bet pateikiame rekomendacijas, kaip ir ką stebėti.
Tai yra, ar teisingai supratau, kad prieš ką nors darant su hostais reikia išjungti Patroni, išjungti failą, išjungti viską?
Tai priklauso nuo to, kiek mazgų turime DCS klasteryje. Jei mazgų yra daug ir išjungiame tik vieną iš mazgų (repliką), tada klasteryje išlaikomas kvorumas. Ir „Patroni“ toliau veikia. Ir niekas nesuveikia. Jei turime keletą sudėtingų operacijų, kurios paveikia daugiau mazgų, kurių nebuvimas gali sunaikinti kvorumą, tada taip, galbūt prasminga pristabdyti Patroni. Turi atitinkamą komandą – patronictl pause, patronictl resume. Mes tiesiog pristabdome, o automatinis failų perkėlimas šiuo metu neveikia. Atliekame DCS klasterio priežiūrą, tada pašaliname pauzę ir tęsiame gyvenimą.
Labai ačiū!
Labai ačiū už pranešimą! Kaip produkto komanda jaučiasi praradusi duomenis?
Produktų komandos nesijaudina, bet komandos vadovai nerimauja.
Kokios garantijos yra?
Su garantijomis labai sunku. Aleksandras Kukushkinas turi ataskaitą „Kaip apskaičiuoti RPO ir RTO“, t.y. atkūrimo laiką ir kiek duomenų galime prarasti. Manau, kad turime surasti šias skaidres ir jas išstudijuoti. Kiek pamenu, yra konkretūs žingsniai, kaip šiuos dalykus apskaičiuoti. Kiek operacijų galime prarasti, kiek duomenų galime prarasti. Kaip parinktį galime naudoti sinchroninį replikavimą Patroni lygiu, tačiau tai yra dviašmenis kardas: arba turime duomenų patikimumą, arba prarandame greitį. Yra sinchroninis replikavimas, tačiau jis taip pat negarantuoja 100% apsaugos nuo duomenų praradimo.
Aleksejus, ačiū už nuostabų reportažą! Ar turite patirties naudojant Patroni nulinio lygio apsaugai? Tai yra, kartu su sinchroniniu budėjimo režimu? Tai pirmas klausimas. Ir antras klausimas. Naudojote skirtingus sprendimus. Naudojome Repmgr, bet be automatinio failų perkėlimo ir dabar planuojame įjungti automatinį failų perkėlimą. Ir mes laikome Patroni alternatyviu sprendimu. Kokie yra pranašumai, palyginti su Repmgr?
Pirmasis klausimas buvo apie sinchronines kopijas. Čia niekas nenaudoja sinchroninio replikavimo, nes visi bijo (keli klientai jau naudojasi, jie nepastebėjo jokių veikimo problemų - Pranešėjo pastaba). Bet mes patys sukūrėme taisyklę, kad sinchroninio replikacijos klasteryje turi būti bent trys mazgai, nes jei turime du mazgus ir jei pagrindinis ar kopija sugenda, tada Patroni perjungia šį mazgą į autonominį režimą, kad programa toliau dirbtų. dirbti. Tokiu atveju kyla duomenų praradimo pavojus.
Kalbant apie antrąjį klausimą, mes naudojome Repmgr ir vis dar naudojame kai kuriems klientams dėl istorinių priežasčių. Ką galime pasakyti? Programoje „Patroni“ automatinis failų perkėlimas išeina iš dėžutės; „Repmgr“ automatinis failų perkėlimas yra papildoma funkcija, kurią reikia įjungti. Kiekviename mazge turime paleisti „Repmgr“ demoną ir tada galime sukonfigūruoti automatinį failų perkėlimą.
Repmgr patikrina, ar Postgres mazgai yra gyvi. Repmgr procesai tikrina vienas kito egzistavimą, tai nėra labai efektyvus būdas, nes Gali būti sudėtingų tinklo izoliavimo atvejų, kai didelė Repmgr klasteris gali suskaidyti į keletą mažų ir toliau veikti. Ilgai neseku Repmgr, gal tai buvo ištaisyta... o gal ne. Tačiau informacijos apie klasterio būseną perkėlimas į DCS, kaip tai daro Stolonas ir Patroni, yra perspektyviausias pasirinkimas.
Aleksejus, turiu klausimą, kuris gali būti kvailas. Viename iš pirmųjų pavyzdžių perkėlėte DCS iš vietinio įrenginio į nuotolinį mazgą. Suprantame, kad tinklas yra dalykas, turintis savo ypatybes, jis gyvena pats. O kas atsitiks, jei dėl kokių nors priežasčių DCS klasteris taps nepasiekiamas? Priežasčių nesakysiu, jų gali būti daug: nuo kreivų tinklininkų rankų iki tikrų problemų.
Aš to nesakiau garsiai, bet DCS klasteris taip pat turi būti atsparus gedimams, tai reiškia, kad jame yra nelyginis mazgų skaičius, kad susidarytų kvorumas. Kas atsitiks, jei DCS klasteris taps nepasiekiamas arba nepasiekiamas kvorumas, t. y. įvyksta tinklo padalijimas arba mazgo gedimas? Tokiu atveju „Patroni“ klasteris pereina į tik skaitymo režimą. „Patroni“ klasteris negali nustatyti klasterio būsenos ir ką daryti. Jis negali susisiekti su DCS ir ten išsaugoti naujos klasterio būsenos, todėl visas klasteris pereina į tik skaitymo režimą. Ir laukia rankinio operatoriaus įsikišimo arba DCS atkūrimo.
Grubiai tariant, DCS mums tampa tokia pat svarbia paslauga, kaip ir pati duomenų bazė?
Taip taip. Daugelyje šiuolaikinių įmonių Service Discovery yra neatsiejama infrastruktūros dalis. Jis diegiamas dar prieš tai, kai infrastruktūroje dar nebuvo duomenų bazės. Santykinai kalbant, paleidome infrastruktūrą, įdiegėme ją į DC ir iš karto turime „Service Discovery“. Jei tai yra konsulas, tada DNS gali būti sukurtas ant jo. Jei tai Etcd, tada gali būti dalis iš Kubernetes klasterio, kurioje bus įdiegta visa kita. Man atrodo, kad Service Discovery jau yra neatsiejama šiuolaikinės infrastruktūros dalis. Ir jie apie tai galvoja daug anksčiau nei duomenų bazės.
Dėkojame!
Šaltinis: www.habr.com