Patroniren helburu nagusia PostgreSQL-ri erabilgarritasun handia eskaintzea da. Baina Patroni txantiloi bat besterik ez da, ez prest egindako tresna bat (hori, oro har, dokumentazioan esaten da). Lehen begiratuan, Patroni proba-laborategian konfiguratu ondoren, ikusi ahal izango duzu zer tresna bikaina den eta zein erraz kudeatzen dituen klusterra apurtzeko saiakerak. Hala ere, praktikan, produkzio-ingurunean, dena ez da beti proba-laborategi batean bezain eder eta dotore gertatzen.
Nire buruari buruz pixka bat kontatuko dizut. Sistema administratzaile gisa hasi nintzen. Web garapenean lan egin du. Data Egret enpresan nabil 2014tik. Konpainia Postgresen alorrean aholkularitzan dihardu. Eta Postgres-ek zehatz-mehatz zerbitzatzen dugu, eta Postgres-ekin egunero lan egiten dugu, beraz, eragiketarekin lotutako esperientzia desberdinak ditugu.
Eta 2018 amaieran, poliki-poliki Patroni erabiltzen hasi ginen. Eta esperientzia pixka bat pilatu da. Nolabait diagnostikatu dugu, sintonizatu, gure jardunbide egokietara iritsi gara. Eta erreportaje honetan haiei buruz hitz egingo dut.
Postgresez gain, Linux maite dut. Gustatzen zait bertan ibiltzea eta esploratzea, nukleoak biltzea gustatzen zait. Birtualizazioa, edukiontziak, docker, Kubernetes maite ditut. Hau guztia interesatzen zait, administratzaileen ohitura zaharrak eragiten baitute. Jarraipenari aurre egitea gustatzen zait. Eta administrazioarekin zerikusia duten postgres gauzak maite ditut, hau da, erreplikazioa, babeskopia. Eta nire aisialdian Go-n idazten dut. Ez naiz software ingeniaria, Go-n niretzat idazten dut. Eta plazerra ematen dit.
- Uste dut zuetako askok badakizuela Postgres-ek ez duela HA (Erabilgarritasun Handia) kutxaz kanpo. HA lortzeko, zerbait instalatu, konfiguratu, ahalegina egin eta lortu behar duzu.
- Hainbat tresna daude eta Patroni HA nahiko polita eta oso ondo konpontzen duen horietako bat da. Baina proba-laborategi batean dena jarri eta martxan jarrita, denak funtzionatzen duela ikusiko dugu, arazo batzuk erreproduzi ditzakegu, Patronik nola ematen dien ikusi. Eta dena ondo funtzionatzen duela ikusiko dugu.
- Baina praktikan, arazo ezberdinei aurre egin genien. Eta arazo horiei buruz hitz egingo dut.
- Esango dizut nola diagnostikatu genuen, zer moldatu genuen, lagundu zigun ala ez.
- Ez dizut esango Patroni nola instalatu, Interneten Googlen google dezakezulako, konfigurazio-fitxategiak begiratu ditzakezu dena nola hasten den ulertzeko, nola konfiguratzen den. Eskemak, arkitekturak uler ditzakezu, horri buruzko informazioa Interneten aurkitzeko.
- Ez dut beste inoren esperientziaz hitz egingo. Aurreratu ditugun arazoei buruz bakarrik hitz egingo dut.
- Eta ez dut Patronitik eta PostgreSQLtik kanpo dauden arazoez hitz egingo. Esaterako, orekatzearekin lotutako arazoak baldin badaude, gure klusterra erori denean, ez dut horretaz hitz egingo.
Eta gure txostena hasi baino lehen oharra txiki bat.
Aurkitu genituen arazo hauek guztiak, funtzionamenduaren lehen 6-7-8 hilabeteetan izan genituen. Denborarekin, gure barneko jardunbide egokietara iritsi ginen. Eta gure arazoak desagertu egin ziren. Hori dela eta, duela sei hilabete inguru jakinarazi zuten txostena, buruan dena freskoa nengoela eta primeran gogoratzen nuenean.
Txostena prestatzeko garaian, jadanik postmortem zaharrak planteatu nituen, erregistroak begiratu nituen. Eta xehetasun batzuk ahaztu daitezke, edo xehetasun batzuk ezin izan dira guztiz ikertu arazoak aztertzean, beraz, puntu batzuetan badirudi arazoak ez direla guztiz kontuan hartzen, edo informazio faltaren bat dagoela. Eta, beraz, barka nazazula momentu hau eskatzen dizut.
Zer da Patroni?
- Hau HA eraikitzeko txantiloia da. Horixe dio dokumentazioan. Eta nire ikuspuntutik, hau oso argiketa zuzena da. Patroni ez da zure arazo guztiak konponduko dituen zilarrezko bala, hau da, ahalegina egin behar duzu funtziona dezan eta onurak ekartzeko.
- Datu-base zerbitzu guztietan instalatuta dagoen agente-zerbitzua da eta zure Postgres-erako hasierako sistema moduko bat da. Postgres abiarazten du, gelditu, berrabiarazi, birkonfiguratu eta zure klusterraren topologia aldatzen du.
- Horren arabera, klusterraren egoera gordetzeko, bere egungo irudikapena, itxura denez, nolabaiteko biltegiratze bat behar da. Eta ikuspuntu horretatik, Patronik egoera kanpoko sistema batean gordetzeko bidea hartu zuen. Banatutako konfigurazio biltegiratze sistema bat da. Etcd, Consul, ZooKeeper edo kubernetes Etcd izan daiteke, hau da, aukera horietako bat.
- Eta Patroniren ezaugarrietako bat da fitxategi automatikoa kutxatik ateratzen duzula, konfiguratuz soilik. Konparaziorako Repmgr hartzen badugu, fitxategia hor sartzen da. Repmgr-ekin, aldaketa bat lortzen dugu, baina fitxategi automatiko bat nahi badugu, gainera, konfiguratu beharko dugu. Patronik dagoeneko automatikoki fitxategi bat dauka.
- Eta beste gauza asko daude. Adibidez, konfigurazioen mantentzea, erreplika berriak botatzea, babeskopia, etab. Baina hau txostenaren esparrutik kanpo dago, ez dut horretaz hitz egingo.
Eta emaitza txiki bat da Patroniren zeregin nagusia autofitxategi bat ondo eta fidagarritasunez egitea dela, gure klusterrak funtzionatzen jarrai dezan eta aplikazioak klusterraren topologian aldaketarik nabaritu ez dezan.
Baina Patroni erabiltzen hasten garenean, gure sistema pixka bat konplikatu egiten da. Lehen Postgres bagenuen, Patroni erabiltzean Patroni bera lortzen dugu, egoera gordetzen den DCS lortzen dugu. Eta denak funtzionatu behar du nolabait. Beraz, zer egin daiteke gaizki?
Apurtu daiteke:
- Baliteke Postgres-ek hautsi. Maisua edo erreplika izan daiteke, horietako batek huts egin dezake.
- Patroni bera hautsi daiteke.
- Egoera gordetzen den DCS-a hautsi daiteke.
- Eta sarea hautsi daiteke.
Txostenean kontuan hartuko ditut puntu hauek guztiak.
Konplexuagoak diren heinean aztertuko ditut kasuak, ez kasuak osagai asko dituenaren ikuspuntutik. Eta sentimendu subjektiboen ikuspuntutik, kasu hau zaila zela niretzat, zaila zela desmuntatzea... eta alderantziz, kasuren bat arina zen eta erraza zen desmuntatzea.
Eta lehenengo kasua da errazena. Hori gertatzen da datu-baseen kluster bat hartu eta gure DCS biltegiratzea kluster berean zabaldu genuenean. Hau da akats ohikoena. Hau akats bat da arkitekturak eraikitzeko, hau da, osagai desberdinak leku batean konbinatzea.
Beraz, fitxategi bat zegoen, goazen gertatutakoari aurre egitera.
Eta hemen interesatzen zaigu noiz gertatu den fitxategia. Hau da, kluster egoera aldatu den une honetan interesatzen zaigu.
Baina fitxategia ez da beti berehalakoa, hau da, ez du denbora-unitaterik behar, atzeratu egin daiteke. Iraupen luzea izan daiteke.
Horregatik, hasierako ordua eta amaierako ordua ditu, hau da, etengabeko gertaera bat da. Eta gertaera guztiak hiru tartetan banatzen ditugu: fitxategiaren aurretik, fitxategian zehar eta fitxategiaren ondoren denbora dugu. Hau da, denbora-lerro honetako gertaera guztiak kontuan hartzen ditugu.
Eta lehenengo gauza, fitxategi bat gertatu zenean, gertatutakoaren zergatia bilatzen dugu, zein izan zen fitxategira eraman zuenaren kausa.
Erregistroei erreparatzen badiegu, Patroni enbor klasikoak izango dira. Berak esaten digu horietan zerbitzaria maisu bihurtu dela, eta maisuaren rola nodo honetara pasatu dela. Hemen nabarmentzen da.
Ondoren, artxibatzailea zergatik gertatu den ulertu behar dugu, hau da, rol maisua nodo batetik bestera mugitzea eragin duten gertakariak. Eta kasu honetan, dena erraza da. Errore bat dugu biltegiratze sistemarekin elkarreraginean. Maisua konturatu zen ezin zuela DCSrekin lan egin, hau da, elkarrekintzan arazoren bat zegoela. Eta jada maisu izan ezin dela dio eta dimititu egiten du. Lerro honek "demoted self" horixe dio zehazki.
Fitxategiaren aurreko gertakariei erreparatzen badiegu, morroiarekin jarraitzeko arazoa eragin zuten arrazoiak bertan ikus ditzakegu.
Patroni erregistroak aztertzen baditugu, ikusiko dugu errore asko ditugula, denbora-muga, hau da, Patroni agenteak ezin du DCSrekin lan egin. Kasu honetan, hau Kontsularen agentea da, 8500 atakan komunikatzen ari dena.
Eta hemen arazoa da Patroni eta datu-basea ostalari berean exekutatzen ari direla. Eta Consul zerbitzariak nodo berean abiarazi ziren. Zerbitzarian karga bat sortuz, arazoak sortu ditugu Kontsul zerbitzarientzat ere. Ezin ziren behar bezala komunikatu.
Denboraren buruan, zama apaldu zenean, gure Patroni agenteekin berriro komunikatu ahal izan zen. Lan arrunta berriro hasi zen. Eta Pgdb-2 zerbitzari bera maisu bihurtu zen berriro. Hau da, iraulketa txiki bat egon zen, horren ondorioz nodoak maisuaren eskumenak uko egin zituen, eta gero berriro hartu zituen, hau da, dena zegoen bezala itzuli zen.
Eta hori alarma faltsutzat har daiteke, edo Patronik dena ongi egin zuela har daiteke. Hau da, klusterraren egoera ezin zuela mantendu konturatu eta agintea kendu zion.
Eta hemen arazoa sortu zen Kontsularen zerbitzariak oinarrien hardware berean daudelako. Horren arabera, edozein karga: disko edo prozesadoreetako karga izan, Consul klusterrarekiko elkarrekintzan ere eragiten du.
Eta elkarrekin bizi behar ez zuela erabaki genuen, kontsulentzako kluster bereizi bat esleitu genion. Eta Patroni jadanik aparteko Kontsula batekin lanean ari zen, hau da, aparteko Postgres kluster bat zegoen, aparteko Kontsul kluster bat. Gauza hauek guztiak nola eraman eta gordetzeko oinarrizko argibide bat da, elkarrekin bizi ez dadin.
Aukera gisa, ttl, loop_wait, retry_timeout parametroak bihur ditzakezu, hau da, epe laburreko karga-gailur horiei bizirik irauten saiatu, parametro horiek handituz. Baina hau ez da aukerarik egokiena, karga hori denbora luzea izan daitekeelako. Eta parametro horien muga horietatik haratago joango gara, besterik gabe. Eta horrek agian ez du benetan lagunduko.
Lehenengo arazoa, ulertzen duzun bezala, erraza da. DCS hartu eta oinarriarekin batera jarri genuen, arazo bat izan genuen.
Bigarren arazoa lehenengoaren antzekoa da. Antzekoa da berriro ere elkarreragingarritasun arazoak ditugula DCS sistemarekin.
Erregistroei erreparatzen badiegu, berriro komunikazio-errore bat dugula ikusiko dugu. Eta Patronik dio ezin dudala DCSrekin elkarreragin, beraz, uneko maisua erreplika moduan doa.
Maisu zaharra erreplika bihurtzen da, hemen Patronik lan egiten du, behar den bezala. pg_rewind exekutatzen du transakzioen erregistroa atzera egiteko eta, ondoren, maisu berrira konektatu maisu berriarekin konektatzeko. Hemen Patronik lan egiten du, behar bezala.
Hemen aurkitu behar dugu fitxategiaren aurreko lekua, hau da, fitxategia izatea eragin diguten akats horiek. Eta zentzu honetan, Patroni erregistroak nahiko erosoak dira lan egiteko. Mezu berdinak idazten ditu tarte jakin batean. Eta erregistro hauek azkar mugitzen hasten bagara, erregistroetatik ikusiko dugu erregistroak aldatu direla, hau da, arazo batzuk hasi direla. Azkar itzultzen gara toki honetara, ea zer gertatzen den.
Eta egoera normal batean, erregistroek antzeko zerbait dute. Sarrailaren jabea egiaztatzen da. Eta jabea, adibidez, aldatu bada, Patronik erantzun behar dituen gertaera batzuk gerta daitezke. Baina kasu honetan, ondo gaude. Akatsak hasi ziren lekuaren bila gabiltza.
Eta akatsak agertzen hasi ziren punturaino joan ondoren, auto-fitxategi bat izan dugula ikusten dugu. Eta gure akatsak DCSrekin elkarreraginarekin zerikusia zutenez eta gure kasuan Kontsula erabili genuenez, Kontsularen erregistroak ere begiratzen ditugu, bertan gertatu zena.
Gutxi gorabehera, fitxategiaren denbora eta Kontsularen erregistroetako ordua alderatuz gero, ikusten dugu Kontsul klusterreko gure bizilagunak zalantzan jartzen hasi zirela Kontsul klusterreko beste kide batzuen existentziaz.
Eta beste Kontsuletako agenteen erregistroak begiratuz gero, sarearen kolapso moduko bat gertatzen ari dela ere ikusiko duzu. Eta Kontsul multzoko kide guztiek zalantzan jartzen dute elkarren existentziaz. Eta hori izan zen filerren bultzada.
Akats hauen aurretik gertatutakoari erreparatuz gero, ikus dezakezu mota guztietako akatsak daudela, adibidez, epea, RPC eroria, hau da, argi dago Consul klusterreko kideen elkarreraginean arazoren bat dagoela. .
Erantzun errazena sarea konpontzea da. Baina niretzat, podiumean zutik, erraza da hau esatea. Baina zirkunstantziak halakoak dira, non beti bezeroak ez du sarea konpondu ahal. Baliteke DC batean bizitzea eta baliteke sarea konpondu ezin izatea, ekipamenduari eragin diezaioke. Eta, beraz, beste aukera batzuk behar dira.
Aukerak daude:
- Aukerarik errazena, nire ustez, dokumentazioan ere idatzita dagoena, Kontsularen egiaztapenak desgaitzea da, hau da, array huts bat pasatzea besterik ez. Eta Kontsularen agenteari esaten diogu txekerik ez erabiltzeko. Egiaztapen hauekin, sareko ekaitz horiei ez ikusi egin diezaiokegu eta ez fitxategia abiarazi.
- Beste aukera bat raft_multiplier egiaztatzea da. Hau Kontsul zerbitzariaren beraren parametro bat da. Lehenespenez, 5ean ezartzen da. Balio hori eszena-inguruneetarako dokumentazioak gomendatzen du. Izan ere, honek Kontsul sareko kideen arteko mezuen maiztasunari eragiten dio. Izan ere, parametro honek Kontsul klusterreko kideen arteko zerbitzuen komunikazioaren abiadurari eragiten dio. Eta ekoizpenerako, dagoeneko murriztea gomendatzen da, nodoek mezuak maizago trukatzeko.
- Aurkeztu dugun beste aukera bat sistema eragilearen prozesu-planifikatzailerako Kontsul-prozesuen lehentasuna handitzea da beste prozesu batzuen artean. Parametro "polita" bat dago, programazioan OS programatzaileak kontuan hartzen duen prozesuen lehentasuna zehazten du. Kontsularen agenteei ere balio polita murriztu diegu, hau da. lehentasuna areagotu zuen, sistema eragileak Consul prozesuei denbora gehiago eman diezaien beren kodea lan egiteko eta exekutatzeko. Gure kasuan, honek gure arazoa konpondu zuen.
- Beste aukera bat Kontsula ez erabiltzea da. Etcd-en aldeko handia den lagun bat dut. Eta aldian-aldian eztabaidatzen dugu zein den hobe Etcd edo Kontsul. Baina hobea den aldetik, normalean berarekin ados gaude Kontsulak datu-base batekin nodo bakoitzean exekutatu beharko lukeen agente bat duela. Hau da, Patroni-k Kontsul klusterrarekin duen interakzioa agente honen bitartez pasatzen da. Eta agente hori botila-lepo bihurtzen da. Agenteari zerbait gertatzen bazaio, Patronik ezingo du Kontsul klusterarekin lan egin. Eta hau da arazoa. Etcd planean ez dago agenterik. Patroni Etcd zerbitzarien zerrenda batekin zuzenean lan egin dezake eta dagoeneko haiekin komunikatu. Zentzu honetan, Etcd zure enpresan erabiltzen baduzu, Etcd seguruenik Consul baino aukera hobea izango da. Baina gure bezerook beti gaude bezeroak aukeratu eta erabiltzen duenaren arabera. Eta Kontsul dugu gehienetan bezero guztientzat.
- Eta azken puntua parametroen balioak berrikustea da. Parametro hauek igo ditzakegu epe laburreko gure sare-arazoak laburrak izango diren eta parametro horien barrutitik kanpo ez egotearen itxaropenarekin. Horrela Patroni-ren oldarkortasuna murriztu dezakegu autofitxatzeko sareko arazo batzuk gertatzen badira.
Patroni erabiltzen duten askok komando hau ezagutzen dutela uste dut.
Komando honek klusterraren uneko egoera erakusten du. Eta lehen begiratuan, irudi hau normala dirudi. Maisu bat dugu, erreplika bat dugu, ez dago erreplikatze atzerapenik. Baina argazki hau normala da zehazki kluster honek hiru nodo izan behar dituela jakin arte, ez bi.
Horren arabera, fitxategi automatiko bat zegoen. Eta autofitxategi honen ondoren, gure erreplika desagertu egin zen. Zergatik desagertu den aurkitu eta itzuli egin behar dugu, berreskuratu. Eta berriro joango gara erregistroetara eta ikusiko dugu zergatik genuen auto-fitxategi bat.
Kasu honetan, bigarren erreplika maisu bihurtu zen. Hemen dago dena.
Eta erori den eta multzoan ez dagoen erreplika begiratu behar dugu. Patroni erregistroak irekitzen ditugu eta pg_rewind fasean klusterera konektatzeko prozesuan arazo bat izan dugula ikusten dugu. Klusterera konektatzeko, transakzio-erregistroa atzera bota behar duzu, beharrezko transakzio-erregistroa eskatu behar diozu maisuari eta erabili maisuarekin harremanetan jartzeko.
Kasu honetan, ez dugu transakzioen erregistrorik eta erreplika ezin da hasi. Horren arabera, akats batekin gelditzen dugu Postgres. Eta, beraz, ez dago multzoan.
Ulertu behar dugu zergatik ez dagoen klusterrean eta zergatik ez zegoen erregistrorik. Maisu berriarengana joaten gara eta zer daukan erregistroetan ikusten dugu. Ematen du pg_rewind egin zenean, kontrol puntu bat gertatu zela. Eta transakzioen erregistro zahar batzuei besterik gabe izena aldatu zitzaien. Maisu zaharra maisu berrira konektatzen eta erregistro hauek kontsultatzen saiatu zenean, jada izena aldatu zitzaien, ez ziren existitzen.
Gertaera hauek gertatu zirenean denbora-zigiluak alderatu nituen. Eta hor aldea literalki 150 milisegundokoa da, hau da, kontrol-puntua 369 milisegundotan osatu zen, WAL segmentuei izena aldatu zitzaien. Eta, literalki, 517an, 150 milisegundoren ondoren, atzeraboina hasi zen erreplika zaharrean. Hau da, literalki 150 milisegundo nahikoa zen guretzat, erreplika ezin konektatu eta lanean hasteko.
Zeintzuk dira aukerak?
Hasieran erreplika zirrikituak erabili genituen. Ona zela pentsatu genuen. Eragiketaren lehen fasean zirrikituak itzali genituen arren. Iruditu zitzaigun zirrikituak WAL segmentu asko pilatzen badituzte, maisua jar dezakegula. Erori egingo da. Denbora pixka bat sufritu genuen zirrikiturik gabe. Eta zirrikituak behar ditugula konturatu ginen, zirrikituak itzuli genituen.
Baina hemen arazo bat dago, maisua erreplikara joaten denean, zirrikituak ezabatzen dituela eta zirrikituekin batera WAL segmentuak ezabatzen dituela. Eta arazo hau kentzeko, wal_keep_segments parametroa igotzea erabaki dugu. Lehenetsita 8 segmentu ditu. 1era igo genuen eta zenbat leku libre genuen aztertu genuen. Eta 000 gigabyte eman genituen wal_keep_segments. Hau da, aldatzean, 16 gigabyteko transakzioen erregistroen erreserba dugu beti nodo guztietan.
Gainera, epe luzerako mantentze-lanetarako garrantzitsua da oraindik. Demagun errepliketako bat eguneratu behar dugula. Eta itzali nahi dugu. Softwarea eguneratu behar dugu, agian sistema eragilea, beste zerbait. Eta erreplika bat itzaltzen dugunean, erreplika horren zirrikitua ere kentzen da. Eta wal_keep_segments txiki bat erabiltzen badugu, erreplikarik ez dagoenez, transakzioen erregistroak galduko dira. Erreplika bat igoko dugu, gelditu den transakzio-erregistro horiek eskatuko ditu, baina baliteke maisuan ez egotea. Eta erreplika ere ezingo da konektatu. Hori dela eta, aldizkarien stock handia gordetzen dugu.
Ekoizpen oinarri bat dugu. Dagoeneko proiektuak daude martxan.
Fitxategi bat zegoen. Sartu eta begiratu dugu - dena ondo dago, erreplikak lekuan daude, ez dago erreplikatze-lagrik. Erregistroetan ere ez dago akatsik, dena ondo dago.
Produktu taldeak dio datu batzuk egon beharko liratekeela, baina iturri batetik ikusten ditugu, baina ez ditugu datu-basean ikusten. Eta ulertu behar dugu zer gertatu zitzaien.
Argi dago pg_wind-ek galdu egin zituela. Berehala ulertu genuen hori, baina zer gertatzen zen ikustera joan ginen.
Erregistroetan, beti aurki dezakegu fitxategia noiz gertatu den, nor bihurtu zen maisu, eta nor zen maisu zaharra eta noiz izan nahi zuen erreplika bat zehaztu dezakegu, hau da, erregistro hauek behar ditugu transakzioen erregistro kopurua jakiteko. galdu zen.
Gure maisu zaharra berrabiarazi da. Eta Patroni autorun izena emanda zegoen. Patroni abian jarri zuen. Gero Postgres hasi zuen. Zehatzago esanda, Postgres hasi aurretik eta erreplika egin aurretik, Patronik pg_rewind prozesua abiarazi zuen. Horren arabera, transakzioen erregistroen zati bat ezabatu zuen, berriak deskargatu eta konektatu zuen. Hemen Patroni dotore aritu zen, hau da, espero bezala. Klusterra leheneratu da. 3 nodo izan genituen, fitxategiaren ondoren 3 nodo - dena polita da.
Datu batzuk galdu ditugu. Eta zenbat galdu dugun ulertu behar dugu. Atzera egin genuen momentuaren bila gabiltza. Halako aldizkariko sarreretan aurki dezakegu. Rewind hasi, zerbait egin eta amaitu zen.
Transakzioen erregistroan maisu zaharrak utzi zuen posizioa aurkitu behar dugu. Kasu honetan, hau da marka. Eta bigarren marka bat behar dugu, hau da, maisu zaharra zein den berria den distantzia.
Ohiko pg_wal_lsn_diff hartu eta bi marka hauek konparatzen ditugu. Eta kasu honetan, 17 megabyte lortzen ditugu. Asko edo gutxi, bakoitzak bere kabuz erabakitzen du. Norbaitentzat 17 megabyte ez delako asko, norbaitentzat asko eta onartezina da. Hemen, norbanako bakoitzak bere kabuz zehazten du negozioaren beharren arabera.
Baina zer aurkitu dugu geuk?
Lehenik eta behin, guk geuk erabaki behar dugu: beti behar al dugu Patroni automatikoki abiarazteko sistema berrabiarazi ondoren? Askotan gertatzen da nagusi zaharrarengana joan behar dugula, ea noraino joan den. Agian transakzioen erregistroko segmentuak ikuskatu, ikusi zer dagoen. Eta datu hauek gal ditzakegun edo maisu zaharra modu autonomoan exekutatu behar dugun ulertzeko datu hauek ateratzeko.
Eta horren ondoren bakarrik erabaki behar dugu datu hauek baztertu ditzakegun edo leheneratu ditzakegun, konektatu nodo hau gure kluster-era erreplika gisa.
Horrez gain, "maximum_lag_on_failover" parametro bat dago. Lehenespenez, nire memoriak balio badu, parametro honek 1 megabyte-ko balioa du.
Nola egiten du lan? Gure erreplika datuen 1 megabyte atzeratuta badago erreplikazio-lagean, orduan erreplika honek ez du parte hartuko hauteskundeetan. Eta bat-batean artxibo bat gertatzen bada, Patronik zein erreplika atzean geratzen diren begiratzen du. Transakzio-erregistro ugariren atzean badaude, ezin dira maisu bihurtu. Datu asko galtzea eragozten dizun segurtasun-eginbide oso ona da.
Baina arazo bat dago Patroni klusterrean eta DCSn erreplikazioaren atzerapena tarte jakin batean eguneratzen baita. Uste dut 30 segundo ttl balio lehenetsia dela.
Horren arabera, baliteke DCSn errepliketarako erreplika-lag bat dagoen egoera bat, baina, egia esan, guztiz bestelako desfase bat egon daiteke edo ez dago batere atzerapenik, hau da, gauza hau ez da denbora errealean. Eta ez du beti benetako irudia islatzen. Eta ez du merezi logika dotorea egiteak.
Eta galtzeko arriskua beti geratzen da. Eta kasurik txarrenean, formula bat, eta batez bestekoan, beste formula bat. Hau da, Patroniren ezarpena planifikatzen dugunean eta zenbat datu gal ditzakegun ebaluatzen dugunean, formula horietan oinarritu behar dugu eta gutxi gorabehera zenbat datu galdu ditzakegun imajinatu behar dugu.
Eta bada berri onak. Maisu zaharrak aurrera egin duenean, aurrera egin dezake atzeko prozesu batzuen ondorioz. Hau da, auto-hutseko moduko bat zegoen, datuak idatzi zituen, transakzioen erregistroan gorde zituen. Eta datu hauek erraz baztertu eta galdu ditzakegu. Honetan ez dago arazorik.
Eta horrela itxura dute erregistroak maximum_lag_on_failover ezarri eta fitxategi bat gertatu bada, eta maisu berri bat hautatu behar baduzu. Erreplikak bere burua hauteskundeetan parte hartzeko gai ez dela baloratzen du. Eta liderra izateko lasterketan parte hartzeari uko egiten dio. Eta maisu berri bat aukeratzeko zain dago, gero harekin konektatu ahal izateko. Hau datu-galeren aurkako neurri gehigarria da.
Hemen produktu-talde bat dugu bere produktuak Postgres-ekin arazoak dituela idatzi zuena. Aldi berean, masterra bera ezin da sartu, ez baitago eskuragarri SSH bidez. Eta fitxategi automatikoa ere ez da gertatzen.
Ostalari hau berrabiararaztera behartu da. Berrabiaraztea dela eta, fitxategi automatiko bat gertatu da, nahiz eta eskuz fitxategi automatiko bat egitea posible izan, orain ulertzen dudanez. Eta berrabiarazi ondoren, dagoeneko ikusiko dugu zer genuen egungo maisuarekin.
Aldi berean, aldez aurretik bagenekien diskoekin arazoak genituela, hau da, monitorizaziotik bagenekien non zulatu eta zer bilatu.
Postgres erregistroan sartu ginen, han zer gertatzen zen ikusten hasi ginen. Bat, bi, hiru segundo irauten duten konpromisoak ikusi ditugu, eta hori ez da batere normala. Ikusi genuen gure hutsunea oso poliki eta arraro abiarazten dela. Eta aldi baterako fitxategiak ikusi genituen diskoan. Hau da, horiek guztiak diskoen arazoen adierazleak dira.
Sistema dmesg (kernel erregistroa) aztertu dugu. Eta ikusi genuen diskoren batekin arazoak ditugula. Diskoaren azpisistema Raid softwarea zen. /proc/mdstat begiratu eta disko bat falta zitzaigula ikusi genuen. Hau da, 8 diskoko Raid bat dago, bat falta zaigu. Diapositiba arretaz begiratuz gero, irteeran ikusiko duzu ez dugula sde hor. Gurean, baldintzatuta, diskoa atera da. Honek disko-arazoak eragin zituen, eta aplikazioek ere arazoak izan zituzten Postgres klusterarekin lan egiten zutenean.
Eta kasu honetan, Patronik ez liguke inola ere lagunduko, Patronik ez baitu zerbitzariaren egoera, diskoaren egoera kontrolatzeko zereginik. Eta horrelako egoerak kanpoko monitorizazioaren bidez kontrolatu behar ditugu. Azkar gehitu dugu diskoaren monitorizazioa kanpoko monitorizazioari.
Eta halako pentsamendu bat zegoen: esgrimak edo zaintzaileen softwareak lagundu al digu? Kasu honetan nekez lagunduko zigula uste genuen, arazoetan Patronik DCS klusterrekin elkarreraginean jarraitu baitzuen eta ez baitzuen arazorik ikusten. Hau da, DCS eta Patroniren ikuspuntutik, dena ondo zegoen klusterrekin, nahiz eta egia esan diskoarekin arazoak egon, datu-basearen erabilgarritasunarekin arazoak egon ziren.
Nire ustez, denbora luzez ikertu dudan arazo bitxienetako bat da, erregistro asko irakurri ditut, berriro hautatu eta cluster simulator deitu dut.
Arazoa zen maisu zaharra ezin zela erreplika normal bihurtu, hau da, Patronik hasi zuen, Patronik erakutsi zuen nodo hau erreplika gisa presente zegoela, baina aldi berean ez zen erreplika normal bat. Orain ikusiko duzu zergatik. Hau da arazo horren azterketatik gorde dudana.
Eta nola hasi zen dena? Aurreko arazoan bezala, disko-balaztekin hasi zen. Konpromisoak izan genituen segundo baterako, bi.
Konexioetan eten ziren, hau da, bezeroak urratuta zeuden.
Larritasun ezberdineko blokeoak zeuden.
Eta, horren arabera, diskoaren azpisistema ez da oso sentikorra.
Eta niretzat gauzarik misteriotsuena iritsi zen berehala ixteko eskaera da. Postgres-ek hiru itzaltzeko modu ditu:
- Dotorea da bezero guztiak beren kabuz deskonektatzeko zain gaudenean.
- Azkar gertatzen da bezeroak deskonektatzera behartzen ditugunean itzaltzera goazelako.
- Eta berehalakoa. Kasu honetan, berehalakoak ez die bezeroei itzaltzeko esaten, abisatu gabe itzaltzen da. Eta bezero guztiei, sistema eragileak dagoeneko RST mezu bat bidaltzen die (TCP mezu bat, konexioa eteten dela eta bezeroak ez duela ezer gehiago harrapatzeko).
Nork bidali zuen seinale hori? Postgres atzeko planoko prozesuek ez diote halako seinalerik bidaltzen elkarri, hau da, hau kill-9 da. Ez diote elkarri halako gauzak bidaltzen, horrelako gauzetan bakarrik erreakzionatzen dute, hau da, larrialdiko Postgres berrabiarazi da. Nork bidali zuen, ez dakit.
"Azken" komandoari begiratu eta zerbitzari honetan ere gurekin saioa hasi zuen pertsona bat ikusi nuen, baina lotsatiegi nintzen galdera bat egiteko. Agian -9 hil zen. Hiltzeko -9 ikusiko nuke erregistroetan, zeren Postgres-ek dio kill -9 behar zuela, baina ez nuen ikusi erregistroetan.
Harago begiratuta, ikusi nuen Patronik ez zuela erregistroan idatzi denbora luzez - 54 segundo. Eta bi denbora-zigilu konparatzen baditugu, 54 segundo inguruko mezurik ez zegoen.
Eta denbora horretan autofile bat zegoen. Patronik lan bikaina egin zuen hemen berriro. Gure maisu zaharra ez zegoen erabilgarri, zerbait gertatu zitzaion. Eta maisu berriaren aukeraketa hasi zen. Hemen dena ondo atera zen. Gure pgsql01 lider berria bihurtu da.
Maisu bihurtu den erreplika dugu. Eta bigarren erantzun bat dago. Eta bigarren erreplikarekin arazoak izan ziren. Berriz konfiguratzen saiatu zen. Ulertzen dudanez, recovery.conf aldatzen saiatu zen, Postgres berrabiarazi eta maisu berrira konektatu. 10 segundoro saiatzen ari den mezuak idazten ditu, baina ez du lortzen.
Eta saiakera horietan, berehala itzaltzeko seinalea iristen zaio maisu zaharrari. Masterra berrabiarazi da. Eta berreskuratzea ere gelditzen da, maisu zaharra berrabiarazi egiten delako. Hau da, erreplika ezin da bertara konektatu, itzali moduan dagoelako.
Noizbait, funtzionatu zuen, baina erreplikazioa ez zen hasi.
Nire uste bakarra da recovery.conf-en helbide nagusi zahar bat zegoela. Eta maisu berri bat agertu zenean, bigarren erreplika oraindik maisu zaharrarekin konektatzen saiatu zen.
Patroni bigarren erreplikan hasi zenean, nodoa martxan jarri zen baina ezin izan zuen errepikatu. Eta erreplika-lag bat sortu zen, antzeko zerbait zuena. Hau da, hiru nodoak zeuden tokian, baina bigarren nodoa atzean geratu zen.
Aldi berean, idatzitako erregistroak aztertzen badituzu, erreplikazioa ezin zela hasi ikusiko zen transakzioen erregistroak desberdinak zirelako. Eta maisuak eskaintzen dituen transakzio-erregistro horiek, recovery.conf-en zehazten direnak, besterik gabe ez datoz bat gure egungo nodoa.
Eta hemen akats bat egin nuen. Recovery.conf-en zer zegoen ikusi behar nuen nire hipotesia probatzeko, okerreko maisuarekin konektatzen ari ginela. Baina orduan honetaz ari nintzen eta ez zitzaidan bururatu, edo ikusi nuen erreplika atzean geratzen zela eta berriro bete behar zela, hau da, nolabait arduragabekeriaz lan egin nuen. Hau izan zen nire juntura.
30 minutu igaro ondoren, jadanik administratzailea etorri zen, hau da, Patroni berrabiarazi nuen erreplikan. Dagoeneko amaitu egin nuen, berriro bete beharko zela pentsatu nuen. Eta pentsatu nuen: Patroni berrabiaraziko dut, agian zerbait ona aterako da. Errekuperazioa hasi zen. Eta oinarria ireki ere, konexioak onartzeko prest zegoen.
Erreplikatzea hasi da. Baina minutu bat geroago, transakzioen erregistroak ez zirela egokiak akats batekin erori zen.
Berriro berrabiaraziko nuela pentsatu nuen. Patroni berrabiarazi nuen berriro, eta ez nuen Postgres berrabiarazi, baina Patroni berrabiarazi nuen datu-basea magiaz abiaraziko zuelakoan.
Erreplikazioa berriro hasi zen, baina transakzioen erregistroko markak desberdinak ziren, ez ziren aurreko hasierako saiakeraren berdinak. Erreplikazioa berriro gelditu zen. Eta mezua jada apur bat ezberdina zen. Eta ez zen oso informatiboa izan niretzat.
Eta orduan bururatzen zait: zer gertatzen da Postgres berrabiarazten badut, une honetan uneko maisuan kontrol-puntu bat egiten dut transakzioen erregistroko puntua apur bat aurrera eramateko, berreskurapena beste momentu batetik hasi dadin? Gainera, oraindik WAL-en izakinak genituen.
Patroni berrabiarazi nuen, maisuan kontrol pare bat egin nituen, irekitzean erreplikan berrabiarazi puntu pare bat. Eta lagundu zuen. Denbora luzez pentsatu nuen zergatik laguntzen zuen eta nola funtzionatzen zuen. Eta erreplika hasi zen. Eta erreplikazioa ez zen jada urratu.
Niretzat halako arazo bat misteriotsuenetako bat da, eta oraindik ere han benetan gertatutakoa zalantzan jartzen dut.
Zein ondorio ditu hemen? Patronik nahi bezala lan egin dezake eta akatsik gabe. Baina, aldi berean, hau ez da % 100eko bermea gurekin dena ondo dagoela. Erreplika abiarazte daiteke, baina erdi-laneko egoeran egon daiteke eta aplikazioak ezin du horrelako erreplika batekin funtzionatu, datu zaharrak egongo direlako.
Eta fitxategiaren ondoren, beti egiaztatu behar duzu dena ordenatuta dagoela kluster-arekin, hau da, beharrezkoa den erreplika kopurua dagoela, ez dago erreplikazio-lagrik.
Eta gai hauek igaro ahala, gomendioak egingo ditut. Bi diapositibatan konbinatzen saiatu nintzen. Seguruenik, istorio guztiak bi diapositibatan konbinatu eta soilik konta litezke.
Patroni erabiltzen duzunean, jarraipena izan behar duzu. Beti jakin beharko zenuke noiz gertatu zen autofileover, izan ere, ez badakizu autofileover bat duzula, ez duzu klusterren gaineko kontrolik. Eta hori txarra da.
Fitxategi bakoitzaren ondoren, beti eskuz egiaztatu behar dugu clusterra. Ziurtatu behar dugu beti erreplika-kopuru eguneratua dugula, ez dagoela erreplika-lagrik, ez dago akatsik streaming-erreplikarekin lotutako erregistroetan, Patronirekin, DCS sistemarekin.
Automatizazioak arrakastaz funtziona dezake, Patroni tresna oso ona da. Funtziona dezake, baina honek ez du klusterra nahi den egoerara eramango. Eta horren berri ez badugu, arazoak izango ditugu.
Eta Patroni ez da zilarrezko bala. Oraindik ulertu behar dugu nola funtzionatzen duen Postgres-ek, nola erreplikatzeak eta Patronik nola funtzionatzen duen Postgres-ekin, eta nola ematen den nodoen arteko komunikazioa. Hau beharrezkoa da zure eskuekin arazoak konpondu ahal izateko.
Nola planteatu diagnostikoaren gaiari? Gertatu zen bezero ezberdinekin lan egiten dugula eta inork ez duela ELK pilarik, eta erregistroak ordenatu behar ditugu 6 kontsola eta 2 fitxa irekiz. Fitxa batean, hauek nodo bakoitzeko Patroni-ren erregistroak dira, beste fitxan, hauek dira Consul-en erregistroak, edo Postgres-ak behar izanez gero. Oso zaila da hori diagnostikatzea.
Zein planteamendu hartu ditut? Lehenik eta behin, beti begiratzen dut fitxategia noiz iritsi den. Eta niretzat hau ur-indar bat da. Fitxategiaren aurretik, fitxategian zehar eta fitxategiaren ondoren gertatutakoa ikusten dut. Fitxategiak bi marka ditu: hasiera eta amaiera ordua da.
Jarraian, erregistroetan fitxategiaren aurreko gertaerak bilatzen ditut, fitxategiaren aurretikoa, hau da, fitxategia gertatu izanaren arrazoiak bilatzen ditut.
Eta horrek zer gertatu den eta etorkizunean zer egin daitekeen ulertzeko irudi bat ematen du, halako inguruabarrik gerta ez dadin (eta, ondorioz, ez dago fitxategirik).
Eta nora begiratzen dugu normalean? Begiratzen dut:
- Lehenik, Patroni erregistroetara.
- Ondoren, Postgres erregistroak edo DCS erregistroak ikusten ditut, Patroni erregistroetan aurkitutakoaren arabera.
- Eta sistemaren erregistroek batzuetan fitxategia zerk eragin duen ulertzen dute.
Zer sentitzen dut Patroni? Patronirekin oso harreman ona daukat. Nire ustez, hau da gaur egun dagoen onena. Beste produktu asko ezagutzen ditut. Hauek dira Stolon, Repmgr, Pg_auto_failover, PAF. 4 tresna. Denak probatu nituen. Patroni da nire gogokoena.
Galdetzen badidate: "Gomendatzen al dut Patroni?". Baietz esango dut, Patroni gustatzen zaidalako. Eta sukaldatzen ikasi dudala uste dut.
Aipatu ditudan arazoez gain Patronirekin zer beste arazo dauden ikustea interesatzen bazaizu, beti begiratu dezakezu orrialdea GitHub-en. Istorio ezberdin asko daude eta gai interesgarri asko jorratzen dira bertan. Eta ondorioz, akats batzuk sartu eta konpondu ziren, hau da, irakurketa interesgarria da.
Badaude istorio interesgarri batzuk bere buruari tiroka ematen dioten jendeari buruz. Oso informatzailea. Irakurri eta ulertzen duzu ez dela beharrezkoa hori egitea. Nik neuk markatu nuen.
Eta eskerrik asko Zalandori proiektu hau garatzeagatik, hots, Alexander Kukushkin eta Alexey Klyukini. Aleksey Klyukin da egileetako bat, jada ez du Zalandon lan egiten, baina produktu honekin lanean hasi ziren bi pertsona dira.
Eta Patroni oso gauza polita dela uste dut. Pozik nago bera existitzen dela, interesgarria da berarekin. Eta eskerrik asko Patroni adabakiak idazten dituzuen laguntzaile guztiei. Espero dut Patroni helduagoa, cool eta eraginkorragoa izatea adinarekin. Dagoeneko funtzionala da, baina are hobea izango dela espero dut. Beraz, Patroni erabiltzeko asmoa baduzu, ez izan beldurrik. Hau irtenbide ona da, inplementatu eta erabil daiteke.
Hori da dena. Galderarik baduzu, galdetu.
Zure galderak
Eskerrik asko erreportajeagatik! Artxibatzaile baten ondoren oraindik arreta handiz begiratu behar baduzu, zergatik behar dugu fitxategi automatiko bat?
Gauza berriak direlako. Urtebete besterik ez dugu berarekin. Hobe seguru egotea. Sartu nahi dugu eta dena behar den moduan funtzionatu duela ikusi nahi dugu. Hau da helduen mesfidantza maila - hobe da bikoiztu eta ikustea.
Esaterako, goizean joan ginen eta begiratzen genuen, ezta?
Goizean ez, normalean fitxategi automatikoari buruz ia berehala ikasten dugu. Jakinarazpenak jasotzen ditugu, fitxategi automatiko bat gertatu dela ikusten dugu. Ia berehala goaz eta begiratzen dugu. Baina egiaztapen horiek guztiak monitorizazio mailara eraman behar dira. Patroni REST APIaren bidez sartzen bazara, historia bat dago. Historiaren arabera, fitxategia gertatu zeneko denbora-zigiluak ikus ditzakezu. Horren arabera, jarraipena egin daiteke. Historia ikus dezakezu, zenbat gertakari egon ziren. Gertaera gehiago baditugu, fitxategi automatiko bat gertatu da. Joan zaitezke ikustera. Edo gure monitorizazioan automatizazioak erreplika guztiak jarrita ditugula egiaztatu du, ez dago atzerapenik eta dena ondo dagoela.
Eskerrik asko!
Mila esker istorio bikainagatik! DCS klusterra Postgres klusterretik urrun mugitzen badugu, orduan kluster hau ere aldian-aldian zaindu behar da? Zeintzuk dira DCS klusterreko pieza batzuk itzali behar dituzten praktika onenak, haiekin egin beharreko zerbait, etab.? Nola irauten du egitura guzti honek? Eta nola egiten dituzu gauza hauek?
Enpresa batentzat, arazoen matrize bat egitea beharrezkoa zen, zer gertatzen den osagairen batek edo hainbat osagai huts egiten badu. Matrize honen arabera, osagai guztiak sekuentzialki zeharkatzen ditugu eta osagai horien hutsegite kasuan eszenatokiak eraikitzen ditugu. Horren arabera, hutsegite-egoera bakoitzerako, berreskuratzeko ekintza-plan bat izan dezakezu. Eta DCSren kasuan, azpiegitura estandarraren zati gisa dator. Eta administratzaileak kudeatzen du, eta dagoeneko kudeatzen duten administratzaileekin eta istripuen kasuan konpontzeko duten gaitasunean oinarritzen gara. DCSrik ez badago, hedatzen dugu, baina, aldi berean, ez dugu bereziki kontrolatzen, ez garelako azpiegituraz arduratzen, baina gomendioak ematen ditugu nola eta zer kontrolatu.
Hau da, ondo ulertu al dut Patroni desgaitu behar dudala, fitxategia desgaitu, dena desgaitu ostalariekin ezer egin aurretik?
DCS klusterrean zenbat nodo ditugun araberakoa da. Nodo asko badaude eta nodoetako bakarra desgaitzen badugu (erreplika), orduan klusterrak quoruma mantentzen du. Eta Patronik martxan jarraitzen du. Eta ez da ezer pizten. Nodo gehiagori eragiten dioten eragiketa konplexu batzuk baditugu, eta horien faltak quoruma hondatu dezake, orduan - bai, zentzuzkoa izan liteke Patroni pausaldian jartzea. Dagokion komando bat du - patronictl pausa, patronictl resume. Pausatu besterik ez dugu egiten eta une horretan fitxategi automatikoak ez du funtzionatzen. DCS klusterrean mantentze-lanak egiten ditugu, gero etenaldia kendu eta bizitzen jarraitzen dugu.
Eskerrik asko!
Mila esker zure txostenagatik! Nola sentitzen da produktu-taldea datuak galtzeaz?
Produktu-taldeei berdin zaie, eta taldeko arduradunak kezkatuta daude.
Zein berme daude?
Bermeak oso zailak dira. Alexander Kukushkinek "Nola kalkulatu RPO eta RTO" txostena du, hau da, berreskuratzeko denbora eta zenbat datu gal ditzakegun. Diapositiba hauek aurkitu eta aztertu behar ditugula uste dut. Gogoratzen dudanez, gauza hauek kalkulatzeko urrats zehatzak daude. Zenbat transakzio gal ditzakegun, zenbat datu gal ditzakegun. Aukera gisa, Patroni mailan erreplikazio sinkronikoa erabil dezakegu, baina hau bi ahoko ezpata da: edo datuen fidagarritasuna dugu, edo abiadura galtzen dugu. Erreplikazio sinkronikoa dago, baina ez du bermatzen datu-galeren aurkako %100eko babesa.
Alexey, eskerrik asko erreportaje bikainagatik! Zero maila babesteko Patroni erabiltzean esperientziarik? Hau da, standby sinkronoarekin batera? Hau da lehen galdera. Eta bigarren galdera. Irtenbide desberdinak erabili dituzu. Repmgr erabili genuen, baina fitxategi automatikorik gabe, eta orain fitxategi automatikoa sartzeko asmoa dugu. Eta Patroni irtenbide alternatibotzat hartzen dugu. Zer esan dezakezu abantaila gisa Repmgrrekin alderatuta?
Lehenengo galdera erreplika sinkronoei buruzkoa zen. Inork ez du hemen erreplikazio sinkronikoa erabiltzen, denak beldurtuta daudelako (Hainbat bezero dagoeneko erabiltzen ari dira, printzipioz, ez zuten errendimendu arazorik nabaritu - Hizlariaren oharra). Baina guk geuk garatu dugu erreplikazio sinkronikoko kluster batean gutxienez hiru nodo egon behar direlako arau bat, izan ere, bi nodo baditugu eta maisuak edo erreplikak huts egiten badu, Patronik nodo hau Standalone modura aldatzen du aplikazioak jarraitu dezan. lana. Kasu honetan, datuak galtzeko arriskua dago.
Bigarren galderari dagokionez, Repmgr erabili dugu eta oraindik bezero batzuekin egiten dugu arrazoi historikoengatik. Zer esan daiteke? Patroni-k automatikoki fitxategi batekin dator, Repmgr-ek automatikoki fitxategiarekin dator gaitu behar den funtzio gehigarri gisa. Nodo bakoitzean Repmgr deabrua exekutatu behar dugu eta, ondoren, fitxategi automatikoa konfiguratu dezakegu.
Repmgr-ek Postgres nodoak bizirik dauden egiaztatzen du. Repmgr prozesuek elkarren existentzia egiaztatzen dute, hau ez da ikuspegi oso eraginkorra. sarearen isolamendu kasu konplexuak egon daitezke, zeinetan Repmgr kluster handi bat hainbat txikiagotan desegin eta lanean jarraitzeko. Aspaldi ez dut Repmgr jarraitzen, agian konponduta zegoen... edo agian ez. Baina DCSn klusterraren egoerari buruzko informazioa kentzea, Stolon, Patroni-k egiten duen moduan, aukerarik bideragarriena da.
Alexey, galdera bat daukat, agian herren bat. Lehenengo adibideetako batean, DCS tokiko makinatik urruneko ostalari batera eraman duzu. Sarea bere ezaugarriak dituen gauza bat dela ulertzen dugu, bere kabuz bizi dela. Eta zer gertatzen da arrazoiren batengatik DCS klusterra erabilgarri ez badago? Arrazoiak ez ditut esango, asko izan daitezke: saregileen esku makurretatik hasi eta benetako arazoetara.
Ez nuen ozen esan, baina DCS klusterrak ere failover izan behar du, hau da, nodo kopuru bakoitia da quoruma betetzeko. Zer gertatzen da DCS klusterra erabilgarri ez badago edo quoruma bete ezin bada, hau da, sarearen zatiketa edo nodoen hutsegite motaren bat? Kasu honetan, Patroni klusterra irakurtzeko soilik moduan sartzen da. Patroni klusterrak ezin du zehaztu klusterraren egoera eta zer egin. Ezin du DCSrekin harremanetan jarri eta kluster egoera berria bertan gorde, beraz, kluster osoa irakurtzeko soilik sartzen da. Eta operadorearen eskuzko esku-hartzea edo DCS berreskuratu arte itxarongo du.
Gutxi gorabehera, DCS oinarria bezain garrantzitsua den zerbitzu bihurtzen zaigu?
Bai bai. Hainbeste enpresa modernotan, Service Discovery azpiegituraren zati bat da. Azpiegituran datu-base bat egon aurretik ere ezartzen ari da. Erlatiboki hitz eginez, azpiegitura martxan jarri zen, DCn zabaldu zen, eta berehala dugu Service Discovery. Kontsul bada, orduan DNS eraiki daiteke. Hau Etcd bada, orduan Kubernetes klusterreko zati bat egon daiteke, eta bertan gainerako guztia zabalduko da. Iruditzen zait Service Discovery dagoeneko azpiegitura modernoen osagaia dela. Eta datu-baseetan baino askoz lehenago pentsatzen dute.
Eskerrik asko!
Iturria: www.habr.com