Hadithi za Kushindwa kwa Patroni au Jinsi ya kuharibu nguzo yako ya PostgreSQL. Alexey Lesovsky

Lengo kuu la Patroni ni kutoa Upatikanaji wa Juu kwa PostgreSQL. Lakini Patroni ni template tu, sio chombo kilichopangwa tayari (ambacho, kwa ujumla, kinasemwa katika nyaraka). Kwa mtazamo wa kwanza, baada ya kusanidi Patroni kwenye maabara ya majaribio, unaweza kuona ni chombo gani kikubwa na jinsi inavyoshughulikia kwa urahisi majaribio yetu ya kuvunja nguzo. Walakini, katika mazoezi, katika mazingira ya uzalishaji, kila kitu haifanyiki kila wakati kwa uzuri na kifahari kama kwenye maabara ya majaribio.

Nitakuambia kidogo juu yangu mwenyewe. Nilianza kama msimamizi wa mfumo. Ilifanya kazi katika ukuzaji wa wavuti. Nimekuwa nikifanya kazi katika Data Egret tangu 2014. Kampuni hiyo inajishughulisha na ushauri katika uwanja wa Postgres. Na tunahudumia Postgres haswa, na tunafanya kazi na Postgres kila siku, kwa hivyo tuna utaalam tofauti unaohusiana na operesheni.

Na mwisho wa 2018, tulianza kutumia polepole Patroni. Na uzoefu fulani umekusanywa. Kwa njia fulani tuliigundua, tukaiweka, tukaja kwa mazoea yetu bora. Na katika ripoti hii nitazungumza juu yao.

Kando na Postgres, napenda Linux. Ninapenda kuzunguka ndani yake na kuchunguza, napenda kukusanya cores. Ninapenda uboreshaji, vyombo, docker, Kubernetes. Haya yote yananipendeza, kwa sababu tabia za zamani za msimamizi zinaathiri. Ninapenda kushughulika na ufuatiliaji. Na ninapenda vitu vya postgres vinavyohusiana na utawala, i.e. replication, backup. Na kwa wakati wangu wa ziada ninaandika Go. Mimi si mhandisi wa programu, ninajiandikia tu katika Go. Na inanipa raha.

• Nadhani wengi wenu mnajua kuwa Postgres haina HA (Upatikanaji wa Juu) nje ya boksi. Ili kupata HA, unahitaji kufunga kitu, kusanidi, kufanya jitihada na kupata.
• Kuna zana kadhaa na Patroni ni mmoja wao anayesuluhisha HA nzuri na vizuri sana. Lakini kwa kuweka yote katika maabara ya mtihani na kuiendesha, tunaweza kuona kwamba yote yanafanya kazi, tunaweza kuzalisha matatizo fulani, angalia jinsi Patroni anawahudumia. Na tutaona kwamba yote yanafanya kazi vizuri.
• Lakini katika mazoezi, tulikabili matatizo tofauti. Na nitazungumza juu ya shida hizi.
• Nitakuambia jinsi tulivyoigundua, tulichobadilisha - ikiwa ilitusaidia au la.

• Sitakuambia jinsi ya kufunga Patroni, kwa sababu unaweza google kwenye mtandao, unaweza kuangalia faili za usanidi ili kuelewa jinsi yote yanavyoanza, jinsi imeundwa. Unaweza kuelewa miradi, usanifu, kupata habari juu yake kwenye mtandao.
• Sitazungumza juu ya uzoefu wa mtu mwingine. Nitazungumza tu juu ya shida ambazo tulikabili.
• Na sitazungumza juu ya shida ambazo ziko nje ya Patroni na PostgreSQL. Ikiwa, kwa mfano, kuna matatizo yanayohusiana na kusawazisha, wakati nguzo yetu imeanguka, sitazungumzia kuhusu hilo.

Na kanusho kidogo kabla ya kuanza ripoti yetu.

Shida hizi zote ambazo tulikutana nazo, tulikuwa nazo katika miezi 6-7-8 ya kwanza ya operesheni. Baada ya muda, tulifikia mazoea yetu bora ya ndani. Na shida zetu zilitoweka. Kwa hivyo, ripoti hiyo ilitangazwa kama miezi sita iliyopita, wakati ilikuwa safi kichwani mwangu na nilikumbuka yote kikamilifu.

Wakati wa kuandaa ripoti, tayari niliinua postmortems za zamani, niliangalia magogo. Na baadhi ya maelezo yanaweza kusahau, au baadhi ya maelezo hayakuweza kuchunguzwa kikamilifu wakati wa uchambuzi wa matatizo, kwa hiyo kwa wakati fulani inaweza kuonekana kuwa matatizo hayajazingatiwa kikamilifu, au kuna ukosefu wa habari. Na kwa hivyo nakuomba uniwie radhi kwa wakati huu.

Patroni ni nini?

• Hiki ni kiolezo cha kujenga HA. Hiyo ndivyo inavyosema katika nyaraka. Na kwa mtazamo wangu, huu ni ufafanuzi sahihi sana. Patroni sio risasi ya fedha ambayo itasuluhisha shida zako zote, ambayo ni, unahitaji kufanya bidii kuifanya ifanye kazi na kuleta faida.
• Hii ni huduma ya wakala ambayo imesakinishwa kwenye kila huduma ya hifadhidata na ni aina ya mfumo wa init kwa Postgres zako. Huanzisha Postgres, husimamisha, kuwasha upya, kusanidi upya, na kubadilisha topolojia ya nguzo yako.
• Ipasavyo, ili kuhifadhi hali ya nguzo, uwakilishi wake wa sasa, kama inavyoonekana, aina fulani ya uhifadhi inahitajika. Na kwa mtazamo huu, Patroni alichukua njia ya kuhifadhi hali katika mfumo wa nje. Ni mfumo wa uhifadhi wa usanidi uliosambazwa. Inaweza kuwa Etcd, Consul, ZooKeeper, au kubernetes Etcd, yaani, mojawapo ya chaguo hizi.
• Na moja ya vipengele vya Patroni ni kwamba unapata kiotomatiki nje ya boksi, kwa kukiweka tu. Ikiwa tutachukua Repmgr kwa kulinganisha, basi kiweka faili kinajumuishwa hapo. Kwa Repmgr, tunapata ubadilishaji, lakini ikiwa tunataka faili ya kiotomatiki, basi tunahitaji kuisanidi kwa kuongeza. Patroni tayari ana faili kiotomatiki nje ya boksi.
• Na kuna mambo mengine mengi. Kwa mfano, matengenezo ya usanidi, kumwaga nakala mpya, chelezo, nk. Lakini hii ni zaidi ya upeo wa ripoti, sitazungumza juu yake.

Na matokeo madogo ni kwamba kazi kuu ya Patroni ni kufanya faili kiotomatiki vizuri na kwa uhakika ili nguzo yetu iendelee kufanya kazi na programu haitambui mabadiliko katika topolojia ya nguzo.

Lakini tunapoanza kutumia Patroni, mfumo wetu unakuwa mgumu zaidi. Ikiwa mapema tulikuwa na Postgres, basi tunapotumia Patroni tunapata Patroni yenyewe, tunapata DCS ambapo hali imehifadhiwa. Na yote yanapaswa kufanya kazi kwa namna fulani. Kwa hivyo ni nini kinachoweza kwenda vibaya?

Inaweza kuvunja:

• Postgres inaweza kuvunjika. Inaweza kuwa bwana au replica, mmoja wao anaweza kushindwa.
• Patroni yenyewe inaweza kuvunja.
• DCS ambapo hali imehifadhiwa inaweza kuvunjika.
• Na mtandao unaweza kuvunja.

Mambo haya yote nitazingatia katika ripoti.

Nitazingatia kesi kadri zinavyozidi kuwa ngumu, sio kutoka kwa mtazamo kwamba kesi hiyo inahusisha vipengele vingi. Na kutoka kwa mtazamo wa hisia za kibinafsi, kwamba kesi hii ilikuwa ngumu kwangu, ilikuwa vigumu kuitenganisha ... na kinyume chake, kesi fulani ilikuwa nyepesi na ilikuwa rahisi kuitenganisha.

Na kesi ya kwanza ni rahisi zaidi. Hivi ndivyo ilivyokuwa tulipochukua mkusanyiko wa hifadhidata na kusambaza hifadhi yetu ya DCS kwenye nguzo moja. Hili ndilo kosa la kawaida zaidi. Hili ni kosa katika kujenga usanifu, yaani, kuchanganya vipengele tofauti katika sehemu moja.

Kwa hivyo, kulikuwa na faili, wacha tuende kushughulikia kile kilichotokea.

Na hapa tunavutiwa na wakati faili ilifanyika. Hiyo ni, tunavutiwa na wakati huu wakati hali ya nguzo ilibadilika.

Lakini faili sio mara zote mara moja, i.e. haichukui kitengo chochote cha wakati, inaweza kucheleweshwa. Inaweza kudumu kwa muda mrefu.

Kwa hiyo, ina wakati wa kuanza na wakati wa mwisho, yaani, ni tukio la kuendelea. Na tunagawanya matukio yote katika vipindi vitatu: tuna muda kabla ya filer, wakati wa filer na baada ya filer. Hiyo ni, tunazingatia matukio yote katika kalenda hii ya matukio.

Na jambo la kwanza, wakati filer ilitokea, tunatafuta sababu ya kile kilichotokea, ni nini sababu ya kile kilichosababisha filer.

Ikiwa tunatazama magogo, watakuwa magogo ya Patroni ya kawaida. Anatuambia ndani yao kwamba seva imekuwa bwana, na jukumu la bwana limepita kwenye node hii. Hapa imeangaziwa.

Ifuatayo, tunahitaji kuelewa kwa nini kiweka faili kilitokea, i.e. ni matukio gani yalitokea ambayo yalisababisha jukumu kuu kuhama kutoka nodi moja hadi nyingine. Na katika kesi hii, kila kitu ni rahisi. Tuna hitilafu katika kuingiliana na mfumo wa hifadhi. Bwana aligundua kuwa hangeweza kufanya kazi na DCS, ambayo ni, kulikuwa na aina fulani ya shida na mwingiliano. Na anasema kwamba hawezi tena kuwa bwana na kujiuzulu. Mstari huu "kujishusha cheo" unasema hivyo haswa.

Ikiwa tunatazama matukio yaliyotangulia mtayarishaji, tunaweza kuona huko sababu ambazo zilikuwa tatizo la kuendelea kwa mchawi.

Ikiwa tunatazama kumbukumbu za Patroni, tutaona kwamba tuna makosa mengi, muda wa muda, yaani wakala wa Patroni hawezi kufanya kazi na DCS. Katika kesi hii, huyu ni wakala wa Balozi, ambaye anawasiliana kwenye bandari 8500.

Na shida hapa ni kwamba Patroni na hifadhidata zinaendesha kwa mwenyeji mmoja. Na seva za Balozi zilizinduliwa kwenye nodi sawa. Kwa kuunda mzigo kwenye seva, tuliunda matatizo kwa seva za Consul pia. Hawakuweza kuwasiliana vizuri.

Baada ya muda, mzigo ulipopungua, Patroni wetu aliweza kuwasiliana na mawakala tena. Kazi ya kawaida ilianza tena. Na seva hiyo hiyo ya Pgdb-2 ikawa bwana tena. Hiyo ni, kulikuwa na flip ndogo, kutokana na ambayo node ilijiuzulu nguvu za bwana, na kisha ikawachukua tena, yaani, kila kitu kilirudi kama ilivyokuwa.

Na hii inaweza kuzingatiwa kama kengele ya uwongo, au inaweza kuzingatiwa kuwa Patroni alifanya kila kitu sawa. Hiyo ni, alitambua kwamba hawezi kudumisha hali ya nguzo na akaondoa mamlaka yake.

Na hapa shida ilitokea kwa sababu ya ukweli kwamba seva za Consul ziko kwenye vifaa sawa na besi. Ipasavyo, mzigo wowote: iwe ni mzigo kwenye diski au wasindikaji, pia huathiri mwingiliano na nguzo ya Consul.

Na tuliamua kwamba haipaswi kuishi pamoja, tulitenga nguzo tofauti kwa Balozi. Na Patroni alikuwa tayari akifanya kazi na Balozi tofauti, yaani, kulikuwa na nguzo tofauti ya Postgres, nguzo tofauti ya Balozi. Haya ni maagizo ya msingi ya jinsi ya kubeba na kuweka vitu hivi vyote ili visiishi pamoja.

Kama chaguo, unaweza kugeuza vigezo ttl, loop_wait, retry_timeout, yaani, jaribu kustahimili vilele vya upakiaji wa muda mfupi kwa kuongeza vigezo hivi. Lakini hii sio chaguo inayofaa zaidi, kwa sababu mzigo huu unaweza kuwa mrefu kwa wakati. Na tutaenda zaidi ya mipaka hii ya vigezo hivi. Na hiyo inaweza isisaidie sana.

Tatizo la kwanza, kama unavyoelewa, ni rahisi. Tulichukua na kuweka DCS pamoja na msingi, tulipata tatizo.

Tatizo la pili ni sawa na la kwanza. Ni sawa kwa kuwa tuna matatizo ya ushirikiano tena na mfumo wa DCS.

Ikiwa tunatazama magogo, tutaona kwamba tuna tena kosa la mawasiliano. Na Patroni anasema siwezi kuingiliana na DCS kwa hivyo bwana wa sasa anaingia kwenye hali ya replica.

Bwana wa zamani anakuwa replica, hapa Patroni anafanya kazi, kama inavyopaswa kuwa. Inaendesha pg_rewind ili kurudisha nyuma kumbukumbu ya muamala na kisha kuunganisha kwa bwana mpya ili kupata bwana mpya. Hapa Patroni anafanya kazi kama inavyopaswa.

Hapa lazima tutafute mahali palipotangulia kiweka faili, yaani makosa yale yaliyotufanya tuwe na faili. Na katika suala hili, magogo ya Patroni ni rahisi kufanya kazi nayo. Anaandika ujumbe sawa kwa muda fulani. Na ikiwa tunaanza kupitia magogo haya haraka, basi tutaona kutoka kwa magogo ambayo magogo yamebadilika, ambayo ina maana kwamba matatizo fulani yameanza. Tunarudi haraka mahali hapa, tuone kinachotokea.

Na katika hali ya kawaida, magogo yanaonekana kama hii. Mmiliki wa kufuli ameangaliwa. Na ikiwa mmiliki, kwa mfano, amebadilika, basi matukio fulani yanaweza kutokea ambayo Patroni lazima ajibu. Lakini katika kesi hii, sisi ni sawa. Tunatafuta mahali makosa yalipoanzia.

Na baada ya kusogeza hadi pale ambapo makosa yalianza kuonekana, tunaona kwamba tumekuwa na faili-otomatiki. Na kwa kuwa makosa yetu yalihusiana na mwingiliano na DCS na kwa upande wetu tulitumia Balozi, pia tunaangalia kumbukumbu za Balozi, nini kilifanyika huko.

Takribani tukilinganisha wakati wa mleta faili na wakati katika kumbukumbu za Balozi, tunaona kwamba majirani zetu katika nguzo ya Ubalozi walianza kutilia shaka kuwepo kwa wanachama wengine wa nguzo ya Ubalozi.

Na ukiangalia pia kumbukumbu za mawakala wengine wa Balozi, unaweza pia kuona kwamba aina fulani ya kuanguka kwa mtandao kunafanyika hapo. Na wanachama wote wa nguzo ya Consul wanatilia shaka kuwepo kwa kila mmoja. Na hii ilikuwa msukumo kwa filer.

Ukiangalia kile kilichotokea kabla ya makosa haya, unaweza kuona kuwa kuna makosa ya kila aina, kwa mfano, tarehe ya mwisho, RPC ilianguka, ambayo ni, ni wazi kuna aina fulani ya shida katika mwingiliano wa washiriki wa nguzo ya Consul na kila mmoja. .

Jibu rahisi ni kutengeneza mtandao. Lakini kwangu, nimesimama kwenye podium, ni rahisi kusema hivi. Lakini hali ni kwamba si mara zote mteja anaweza kumudu kutengeneza mtandao. Anaweza kuishi katika DC na hawezi kuwa na uwezo wa kutengeneza mtandao, kuathiri vifaa. Na kwa hivyo chaguzi zingine zinahitajika.

Kuna chaguzi:

• Chaguo rahisi zaidi, ambayo imeandikwa, kwa maoni yangu, hata katika nyaraka, ni kuzima ukaguzi wa Consul, yaani, tu kupitisha safu tupu. Na tunamwambia ajenti wa Balozi asitumie hundi yoyote. Kwa ukaguzi huu, tunaweza kupuuza dhoruba hizi za mtandao na sio kuanzisha kiweka faili.
• Chaguo jingine ni kuangalia mara mbili raft_multiplier. Hii ni kigezo cha seva ya Consul yenyewe. Kwa chaguo-msingi, imewekwa kuwa 5. Thamani hii inapendekezwa na nyaraka za mazingira ya jukwaa. Kwa kweli, hii inathiri mzunguko wa ujumbe kati ya wanachama wa mtandao wa Consul. Kwa kweli, parameter hii inathiri kasi ya mawasiliano ya huduma kati ya wanachama wa kikundi cha Consul. Na kwa ajili ya uzalishaji, tayari inashauriwa kupunguza ili nodes kubadilishana ujumbe mara nyingi zaidi.
• Chaguo jingine ambalo tumekuja nalo ni kuongeza kipaumbele cha michakato ya Balozi kati ya michakato mingine ya kipanga ratiba cha mfumo wa uendeshaji. Kuna parameter hiyo "nzuri", huamua tu kipaumbele cha michakato ambayo inazingatiwa na mpangilio wa OS wakati wa kupanga. Pia tumepunguza thamani nzuri kwa mawakala wa Balozi, i.e. iliongeza kipaumbele ili mfumo wa uendeshaji upe michakato ya Balozi muda zaidi wa kufanya kazi na kutekeleza nambari zao. Kwa upande wetu, hii ilitatua shida yetu.
• Chaguo jingine sio kutumia Consul. Nina rafiki ambaye ni mfuasi mkubwa wa Etcd. Na huwa tunabishana naye mara kwa mara kipi ni bora Etcd au Consul. Lakini kwa suala la ambayo ni bora zaidi, kwa kawaida tunakubaliana naye kwamba Balozi ana wakala anayepaswa kufanya kazi kwenye kila nodi yenye hifadhidata. Hiyo ni, mwingiliano wa Patroni na nguzo ya Consul unapitia wakala huyu. Na wakala huyu anakuwa kizuizi. Ikiwa kitu kitatokea kwa wakala, basi Patroni hawezi tena kufanya kazi na kikundi cha Consul. Na hili ndilo tatizo. Hakuna wakala katika mpango Etcd. Patroni anaweza kufanya kazi moja kwa moja na orodha ya seva za Etcd na tayari kuwasiliana nao. Katika suala hili, ikiwa unatumia Etcd katika kampuni yako, basi Etcd labda itakuwa chaguo bora kuliko Consul. Lakini sisi kwa wateja wetu huwa tunadhibitiwa na kile mteja amechagua na kutumia. Na tuna Balozi kwa sehemu kubwa kwa wateja wote.
• Na hatua ya mwisho ni kurekebisha maadili ya parameta. Tunaweza kuinua vigezo hivi kwa matumaini kwamba matatizo yetu ya mtandao ya muda mfupi yatakuwa mafupi na yasitoke nje ya anuwai ya vigezo hivi. Kwa njia hii tunaweza kupunguza uchokozi wa Patroni kuweka faili kiotomatiki ikiwa baadhi ya matatizo ya mtandao yatatokea.

Nadhani wengi wanaotumia Patroni wanaifahamu amri hii.

Amri hii inaonyesha hali ya sasa ya nguzo. Na kwa mtazamo wa kwanza, picha hii inaweza kuonekana kuwa ya kawaida. Tuna bwana, tuna replica, hakuna lag replication. Lakini picha hii ni ya kawaida hadi tujue kuwa nguzo hii inapaswa kuwa na nodi tatu, sio mbili.

Ipasavyo, kulikuwa na faili otomatiki. Na baada ya faili hii kiotomatiki, nakala yetu ilitoweka. Tunahitaji kujua kwa nini alitoweka na kumrudisha, mrejeshe. Na sisi tena kwenda magogo na kuona kwa nini tulikuwa auto-fileover.

Katika kesi hii, replica ya pili ikawa bwana. Ni sawa hapa.

Na tunahitaji kuangalia nakala iliyoanguka na ambayo haiko kwenye nguzo. Tunafungua magogo ya Patroni na kuona kwamba tulikuwa na tatizo wakati wa mchakato wa kuunganisha kwenye nguzo kwenye hatua ya pg_rewind. Ili kuunganisha kwenye kikundi, unahitaji kurejesha logi ya shughuli, omba logi inayohitajika ya shughuli kutoka kwa bwana, na uitumie ili kupatana na bwana.

Katika kesi hii, hatuna kumbukumbu ya muamala na nakala haiwezi kuanza. Ipasavyo, tunasimamisha Postgres na kosa. Na kwa hivyo haiko kwenye nguzo.

Tunahitaji kuelewa kwa nini haiko kwenye nguzo na kwa nini hapakuwa na magogo. Tunakwenda kwa bwana mpya na kuangalia kile anacho kwenye magogo. Inabadilika kuwa wakati pg_rewind ilifanywa, kituo cha ukaguzi kilitokea. Na baadhi ya kumbukumbu za zamani za shughuli zilibadilishwa jina tu. Wakati bwana wa zamani alijaribu kuunganishwa na bwana mpya na kuuliza magogo haya, tayari yalibadilishwa jina, hayakuwepo tu.

Nililinganisha muhuri wa nyakati matukio haya yalipotokea. Na hapo tofauti ni milisekunde 150, ambayo ni, kituo cha ukaguzi kilikamilishwa katika milliseconds 369, sehemu za WAL zilibadilishwa jina. Na kihalisi mnamo 517, baada ya milisekunde 150, kurudi nyuma kulianza kwenye nakala ya zamani. Hiyo ni, milisekunde 150 zilitutosha ili nakala haikuweza kuunganishwa na kupata mapato.

Je, ni chaguzi gani?

Hapo awali tulitumia nafasi za kurudia. Tulidhani ni nzuri. Ingawa katika hatua ya kwanza ya operesheni tulizima inafaa. Ilionekana kwetu kwamba ikiwa inafaa kujilimbikiza sehemu nyingi za WAL, tunaweza kuacha bwana. Ataanguka. Tuliteseka kwa muda bila nafasi. Na tuligundua kuwa tunahitaji inafaa, tulirudisha nafasi.

Lakini kuna shida hapa, kwamba wakati bwana anaenda kwenye nakala, inafuta nafasi na kufuta sehemu za WAL pamoja na inafaa. Na ili kuondoa tatizo hili, tuliamua kuongeza wal_keep_segments parameter. Ni chaguo-msingi kwa sehemu 8. Tulipandisha hadi 1 na tukaangalia ni nafasi ngapi tuliyokuwa nayo. Na tulitoa gigabytes 000 kwa wal_keep_segments. Hiyo ni, wakati wa kubadili, sisi daima tuna hifadhi ya gigabytes 16 ya magogo ya shughuli kwenye nodes zote.

Na pamoja - bado ni muhimu kwa kazi za matengenezo ya muda mrefu. Wacha tuseme tunahitaji kusasisha moja ya nakala. Na tunataka kuizima. Tunahitaji kusasisha programu, labda mfumo wa uendeshaji, kitu kingine. Na tunapozima nakala, nafasi ya nakala hiyo pia huondolewa. Na ikiwa tunatumia wal_keep_segments ndogo, basi kwa kutokuwepo kwa muda mrefu kwa replica, kumbukumbu za shughuli zitapotea. Tutainua nakala, itaomba kumbukumbu hizo za muamala ambapo ilisimama, lakini zinaweza zisiwe kwenye bwana. Na replica haitaweza kuunganishwa pia. Kwa hiyo, tunahifadhi akiba kubwa ya magazeti.

Tuna msingi wa uzalishaji. Tayari kuna miradi inayoendelea.

Kulikuwa na faili. Tuliingia na kuangalia - kila kitu kiko sawa, nakala ziko mahali, hakuna lagi ya kuiga. Hakuna makosa katika kumbukumbu pia, kila kitu kiko katika mpangilio.

Timu ya bidhaa inasema kwamba kunapaswa kuwa na data fulani, lakini tunaiona kutoka kwa chanzo kimoja, lakini hatuioni kwenye hifadhidata. Na tunahitaji kuelewa kilichotokea kwao.

Ni wazi kuwa pg_rewind iliwakosa. Mara moja tulielewa hili, lakini tulikwenda kuona nini kinatokea.

Katika kumbukumbu, tunaweza kupata kila wakati faili ilifanyika, ambaye alikua bwana, na tunaweza kuamua ni nani alikuwa bwana wa zamani na wakati alitaka kuwa nakala, i.e. tunahitaji kumbukumbu hizi ili kujua kiasi cha magogo ya shughuli ambayo ilipotea.

Bwana wetu wa zamani ameanzisha tena. Na Patroni alisajiliwa katika autorun. Ilizinduliwa Patroni. Kisha akaanza Postgres. Kwa usahihi, kabla ya kuanza Postgres na kabla ya kuifanya nakala, Patroni alizindua mchakato wa pg_rewind. Ipasavyo, alifuta sehemu ya kumbukumbu za shughuli, kupakua mpya na kuunganishwa. Hapa Patroni alifanya kazi kwa busara, ambayo ni, kama inavyotarajiwa. Nguzo imerejeshwa. Tulikuwa na nodes 3, baada ya filer nodes 3 - kila kitu ni baridi.

Tumepoteza baadhi ya data. Na tunahitaji kuelewa ni kiasi gani tumepoteza. Tunatafuta wakati tu tuliporejesha nyuma. Tunaweza kuipata katika maingizo kama haya ya jarida. Rudisha nyuma ilianza, ilifanya kitu hapo na ikaisha.

Tunahitaji kupata nafasi katika logi ya ununuzi ambapo bwana wa zamani aliacha. Katika kesi hii, hii ndio alama. Na tunahitaji alama ya pili, ambayo ni, umbali ambao bwana wa zamani hutofautiana na mpya.

Tunachukua pg_wal_lsn_diff ya kawaida na kulinganisha alama hizi mbili. Na katika kesi hii, tunapata megabytes 17. Mengi au kidogo, kila mtu anaamua mwenyewe. Kwa sababu kwa mtu megabytes 17 sio nyingi, kwa mtu ni mengi na haikubaliki. Hapa, kila mtu huamua mwenyewe kulingana na mahitaji ya biashara.

Lakini sisi wenyewe tumegundua nini?

Kwanza, lazima tujiamulie wenyewe - je, tunahitaji Patroni kila wakati kuanzisha kiotomatiki baada ya kuwasha upya mfumo? Mara nyingi hutokea kwamba tunapaswa kwenda kwa bwana wa zamani, kuona jinsi amekwenda mbali. Labda kagua sehemu za logi ya muamala, angalia kilichopo. Na kuelewa ikiwa tunaweza kupoteza data hii au ikiwa tunahitaji kuendesha programu kuu ya zamani katika hali ya pekee ili kutoa data hii nje.

Na tu baada ya hapo ni lazima tuamue ikiwa tunaweza kutupa data hii au tunaweza kuirejesha, unganisha nodi hii kama nakala kwenye nguzo yetu.

Kwa kuongeza, kuna kigezo cha "maximum_lag_on_failover". Kwa chaguo-msingi, ikiwa kumbukumbu yangu inanitumikia, parameta hii ina thamani ya megabyte 1.

Anafanyaje kazi? Ikiwa nakala yetu iko nyuma kwa megabaiti 1 ya data katika muda wa kurudia, basi nakala hii haishiriki katika uchaguzi. Na ikiwa ghafla kuna faili ya kupita, Patroni anaangalia ni nakala zipi ziko nyuma. Ikiwa wako nyuma na idadi kubwa ya magogo ya shughuli, hawawezi kuwa bwana. Hiki ni kipengele kizuri sana cha usalama kinachokuzuia kupoteza data nyingi.

Lakini kuna tatizo kwa kuwa bakia ya urudufishaji katika nguzo ya Patroni na DCS inasasishwa kwa muda fulani. Nadhani sekunde 30 ndio dhamana ya ttl chaguo-msingi.

Ipasavyo, kunaweza kuwa na hali ambapo kuna lagi moja ya replicas katika DCS, lakini kwa kweli kunaweza kuwa na lagi tofauti kabisa au kunaweza kuwa hakuna lag hata kidogo, i.e. jambo hili sio wakati halisi. Na haiakisi picha halisi kila wakati. Na haifai kufanya mantiki ya dhana juu yake.

Na hatari ya kupoteza daima inabakia. Na katika hali mbaya zaidi, formula moja, na katika kesi ya wastani, formula nyingine. Hiyo ni, tunapopanga utekelezaji wa Patroni na kutathmini ni data ngapi tunaweza kupoteza, lazima tutegemee fomula hizi na takriban kufikiria ni data ngapi tunaweza kupoteza.

Na kuna habari njema. Wakati bwana wa zamani ameenda mbele, anaweza kwenda mbele kwa sababu ya michakato kadhaa ya nyuma. Hiyo ni, kulikuwa na aina fulani ya autovacuum, aliandika data, akawahifadhi kwenye logi ya manunuzi. Na tunaweza kupuuza na kupoteza data hii kwa urahisi. Hakuna tatizo katika hili.

Na hivi ndivyo kumbukumbu zinavyoonekana ikiwa maximum_lag_on_failover imewekwa na faili imetokea, na unahitaji kuchagua bwana mpya. Nakala hii inajitathmini kuwa haiwezi kushiriki katika uchaguzi. Na anakataa kushiriki katika mbio za kiongozi. Na anasubiri bwana mpya achaguliwe, ili aweze kuunganishwa nayo. Hii ni hatua ya ziada dhidi ya upotezaji wa data.

Hapa tuna timu ya bidhaa ambao waliandika kwamba bidhaa zao zina matatizo na Postgres. Wakati huo huo, bwana yenyewe hawezi kupatikana, kwa sababu haipatikani kupitia SSH. Na faili otomatiki haifanyiki pia.

Mwenyeji huyu alilazimika kuwasha upya. Kwa sababu ya kuwasha upya, faili-otomatiki ilitokea, ingawa iliwezekana kufanya faili ya mwongozo, kama ninavyoelewa sasa. Na baada ya kuanza upya, tayari tutaona kile tulichokuwa nacho na bwana wa sasa.

Wakati huo huo, tulijua mapema kwamba tulikuwa na matatizo na disks, yaani, tulijua tayari kutoka kwa ufuatiliaji wapi kuchimba na nini cha kuangalia.

Tuliingia kwenye logi ya postgres, tukaanza kuona kinachoendelea huko. Tuliona ahadi za mwisho hapo kwa sekunde moja, mbili, tatu, ambayo sio kawaida kabisa. Tuliona kuwa otomatiki yetu inaanza polepole sana na ya kushangaza. Na tuliona faili za muda kwenye diski. Hiyo ni, haya yote ni viashiria vya matatizo na disks.

Tuliangalia kwenye mfumo dmesg (logi ya kernel). Na tuliona kwamba tuna matatizo na moja ya disks. Mfumo mdogo wa diski ulikuwa uvamizi wa programu. Tuliangalia /proc/mdstat na tukaona kwamba tunakosa gari moja. Hiyo ni, kuna Raid ya disks 8, tunakosa moja. Ikiwa unatazama kwa makini slide, basi katika pato unaweza kuona kwamba hatuna sde huko. Kwetu, kwa kusema kwa masharti, diski imeshuka. Hii ilisababisha shida za diski, na programu pia zilipata shida wakati wa kufanya kazi na nguzo ya Postgres.

Na katika kesi hii, Patroni hawezi kutusaidia kwa njia yoyote, kwa sababu Patroni hawana kazi ya kufuatilia hali ya seva, hali ya disk. Na lazima tufuatilie hali kama hizi kwa ufuatiliaji wa nje. Tuliongeza haraka ufuatiliaji wa diski kwa ufuatiliaji wa nje.

Na kulikuwa na wazo kama hilo - je, uzio au programu ya walinzi inaweza kutusaidia? Tulifikiri kwamba hangetusaidia katika kesi hii, kwa sababu wakati wa matatizo Patroni aliendelea kuingiliana na nguzo ya DCS na hakuona tatizo lolote. Hiyo ni, kutoka kwa mtazamo wa DCS na Patroni, kila kitu kilikuwa sawa na nguzo, ingawa kwa kweli kulikuwa na shida na diski, kulikuwa na shida na upatikanaji wa hifadhidata.

Kwa maoni yangu, hii ni moja ya shida za kushangaza ambazo nimefanya utafiti kwa muda mrefu sana, nimesoma magogo mengi, nikachukua tena na kuiita simulator ya nguzo.

Shida ilikuwa kwamba bwana wa zamani hakuweza kuwa replica ya kawaida, i.e. Patroni aliianzisha, Patroni alionyesha kuwa nodi hii ilikuwepo kama nakala, lakini wakati huo huo haikuwa nakala ya kawaida. Sasa utaona kwa nini. Hiki ndicho nimekiweka kutokana na uchambuzi wa tatizo hilo.

Na yote yalianzaje? Ilianza, kama katika shida iliyopita, na breki za diski. Tulikuwa na ahadi kwa sekunde moja, mbili.

Kulikuwa na mapumziko katika viunganisho, yaani, wateja walipasuka.

Kulikuwa na vizuizi vya ukali tofauti.

Na, ipasavyo, mfumo mdogo wa diski sio msikivu sana.

Na jambo la kushangaza zaidi kwangu ni ombi la kuzima mara moja ambalo lilifika. Postgres ina njia tatu za kuzima:

• Inapendeza tunaposubiri wateja wote watenganishe wenyewe.
• Kuna haraka tunapolazimisha wateja kukata muunganisho kwa sababu tutazima.
• Na mara moja. Katika kesi hii, mara moja haiambii wateja kuzima, inazima tu bila onyo. Na kwa wateja wote, mfumo wa uendeshaji tayari hutuma ujumbe wa RST (ujumbe wa TCP kwamba uunganisho umeingiliwa na mteja hana chochote zaidi cha kukamata).

Nani alituma ishara hii? Michakato ya mandharinyuma ya Postgres haitumii ishara kama hizo kwa kila mmoja, i.e. hii ni kill-9. Hawatumii vitu kama hivyo kwa kila mmoja, wao huguswa tu na vitu kama hivyo, i.e. hii ni kuanza tena kwa dharura kwa Postgres. Nani aliituma, sijui.

Niliangalia amri ya "mwisho" na nikaona mtu mmoja ambaye pia aliingia kwenye seva hii na sisi, lakini nilikuwa na aibu sana kuuliza swali. Labda ilikuwa kuua -9. Ningeona kuua -9 kwenye magogo, kwa sababu Postgres inasema ilichukua kill -9, lakini sikuiona kwenye magogo.

Kuangalia zaidi, niliona kuwa Patroni hakuandika kwa logi kwa muda mrefu - sekunde 54. Na tukilinganisha mihuri miwili ya muda, hakukuwa na ujumbe kwa takriban sekunde 54.

Na wakati huu kulikuwa na faili otomatiki. Patroni alifanya kazi nzuri hapa tena. Bwana wetu mzee hakupatikana, kuna kitu kilimtokea. Na uchaguzi wa bwana mpya ulianza. Kila kitu kilikwenda vizuri hapa. pgsql01 yetu imekuwa kiongozi mpya.

Tunayo nakala ambayo imekuwa bwana. Na kuna jibu la pili. Na kulikuwa na shida na nakala ya pili. Alijaribu kusanidi upya. Ninavyoielewa, alijaribu kubadilisha recovery.conf, kuanzisha upya Postgres na kuunganisha kwa bwana mpya. Anaandika ujumbe kila baada ya sekunde 10 anazojaribu, lakini hafaulu.

Na wakati wa majaribio haya, ishara ya kuzima mara moja inafika kwa bwana wa zamani. Bwana ameanza tena. Na pia urejeshaji huacha kwa sababu bwana wa zamani huenda kwenye kuwasha upya. Hiyo ni, replica haiwezi kuunganishwa nayo, kwa sababu iko katika hali ya kuzima.

Wakati fulani, ilifanya kazi, lakini uigaji haukuanza.

Nadhani yangu pekee ni kwamba kulikuwa na anwani kuu ya zamani katika recovery.conf. Na wakati bwana mpya alionekana, replica ya pili bado ilijaribu kuunganishwa na bwana wa zamani.

Wakati Patroni alianza kwenye nakala ya pili, nodi ilianza lakini haikuweza kuiga. Na bakia ya kurudia iliundwa, ambayo ilionekana kama hii. Hiyo ni, nodi zote tatu zilikuwa mahali, lakini nodi ya pili ilibaki nyuma.

Wakati huo huo, ukiangalia magogo yaliyoandikwa, unaweza kuona kwamba replication haikuweza kuanza kwa sababu kumbukumbu za shughuli zilikuwa tofauti. Na kumbukumbu hizo za muamala ambazo bwana hutoa, ambazo zimebainishwa katika recovery.conf, haziendani na nodi yetu ya sasa.

Na hapa nilifanya makosa. Ilinibidi nije kuona ni nini kilikuwa kwenye recovery.conf ili kupima hypothesis yangu kwamba tulikuwa tunaunganisha na bwana mbaya. Lakini basi nilikuwa nikishughulika na hii tu na haikutokea kwangu, au niliona kuwa nakala hiyo ilikuwa nyuma na ingelazimika kujazwa tena, ambayo ni, kwa namna fulani nilifanya kazi bila uangalifu. Hiki kilikuwa kiungo changu.

Baada ya dakika 30, msimamizi tayari alikuja, i.e. nilianza tena Patroni kwenye nakala. Tayari nilikomesha, nilidhani kwamba italazimika kujazwa tena. Na nilidhani - nitaanzisha tena Patroni, labda kitu kizuri kitatokea. Urejeshaji umeanza. Na msingi hata ulifunguliwa, ilikuwa tayari kukubali miunganisho.

Uigaji umeanza. Lakini dakika moja baadaye, alianguka na hitilafu kwamba kumbukumbu za shughuli hazifai kwake.

Nilidhani ningeanzisha tena. Nilianzisha tena Patroni tena, na sikuanzisha tena Postgres, lakini nilianza tena Patroni kwa matumaini kwamba ingeanzisha hifadhidata kichawi.

Replication ilianza tena, lakini alama katika logi ya shughuli zilikuwa tofauti, hazikuwa sawa na jaribio la awali la kuanza. Kurudia kumesimamishwa tena. Na ujumbe ulikuwa tayari tofauti kidogo. Na haikuwa habari sana kwangu.

Na kisha inanitokea - ni nini ikiwa nitaanzisha tena Postgres, kwa wakati huu ninaweka kituo cha ukaguzi kwa bwana wa sasa ili kusonga mbele kidogo hatua kwenye logi ya ununuzi ili urejeshaji uanze kutoka wakati mwingine? Zaidi ya hayo, bado tulikuwa na hisa za WAL.

Nilianzisha tena Patroni, nilifanya vizuizi kadhaa kwa bwana, alama kadhaa za kuanza tena kwenye nakala ilipofunguliwa. Na ilisaidia. Nilifikiria kwa muda mrefu kwa nini ilisaidia na jinsi ilifanya kazi. Na replica ilianza. Na uigaji haukuchanwa tena.

Shida kama hii kwangu ni moja wapo ya kushangaza zaidi, ambayo bado ninashangaa juu ya kile kilichotokea huko.

Je, ni madhara gani hapa? Patroni inaweza kufanya kazi kama ilivyokusudiwa na bila makosa yoyote. Lakini wakati huo huo, hii sio dhamana ya 100% kwamba kila kitu ni sawa na sisi. Replica inaweza kuanza, lakini inaweza kuwa katika hali ya nusu ya kufanya kazi, na programu haiwezi kufanya kazi na nakala kama hiyo, kwa sababu kutakuwa na data ya zamani.

Na baada ya filer, daima unahitaji kuangalia kwamba kila kitu kiko katika mpangilio na nguzo, yaani, kuna idadi inayotakiwa ya replicas, hakuna lag replication.

Na tunapopitia masuala haya, nitatoa mapendekezo. Nilijaribu kuzichanganya katika slaidi mbili. Pengine, hadithi zote zinaweza kuunganishwa katika slaidi mbili na kuambiwa tu.

Unapotumia Patroni, lazima uwe na ufuatiliaji. Unapaswa kujua kila wakati kiotomatiki kilitokea, kwa sababu ikiwa haujui ulikuwa na faili ya kiotomatiki, huna udhibiti wa nguzo. Na hiyo ni mbaya.

Baada ya kila faili, lazima tuangalie kwa mikono nguzo. Tunahitaji kuhakikisha kuwa tunakuwa na idadi iliyosasishwa ya nakala, hakuna kurudi nyuma, hakuna hitilafu katika kumbukumbu zinazohusiana na urudufishaji wa utiririshaji, na Patroni, na mfumo wa DCS.

Automation inaweza kufanya kazi kwa mafanikio, Patroni ni chombo kizuri sana. Inaweza kufanya kazi, lakini hii haitaleta nguzo kwa hali inayotaka. Na ikiwa hatutagundua juu yake, tutakuwa kwenye shida.

Na Patroni sio risasi ya fedha. Bado tunahitaji kuelewa jinsi Postgres inavyofanya kazi, jinsi replication inavyofanya kazi na jinsi Patroni hufanya kazi na Postgres, na jinsi mawasiliano kati ya nodi hutolewa. Hii ni muhimu ili uweze kurekebisha matatizo kwa mikono yako.

Ninashughulikiaje suala la utambuzi? Ilifanyika kwamba tunafanya kazi na wateja tofauti na hakuna mtu aliye na stack ya ELK, na tunapaswa kutatua magogo kwa kufungua consoles 6 na tabo 2. Katika kichupo kimoja, hizi ni kumbukumbu za Patroni kwa kila nodi, kwenye kichupo kingine, hizi ni kumbukumbu za Consul, au Postgres ikiwa ni lazima. Ni vigumu sana kutambua hili.

Je, ni mbinu gani nimeanzisha? Kwanza, mimi hutazama wakati faili imefika. Na kwa ajili yangu hii ni bwawa la maji. Ninaangalia kile kilichotokea kabla ya faili, wakati wa faili na baada ya faili. Uboreshaji wa faili una alama mbili: huu ni wakati wa kuanza na mwisho.

Ifuatayo, mimi hutafuta magogo kwa matukio kabla ya faili, ambayo yalitangulia faili, i.e. natafuta sababu kwa nini faili ilitokea.

Na hii inatoa picha ya kuelewa kile kilichotokea na nini kinaweza kufanywa katika siku zijazo ili hali kama hizo zisitokee (na kwa sababu hiyo, hakuna filer).

Na kwa kawaida tunaangalia wapi? Natazama:

• Kwanza, kwa magogo ya Patroni.
• Ifuatayo, ninaangalia magogo ya Postgres, au kumbukumbu za DCS, kulingana na kile kilichopatikana kwenye kumbukumbu za Patroni.
• Na kumbukumbu za mfumo pia wakati mwingine hutoa ufahamu wa nini kilisababisha faili.

Je, ninahisije kuhusu Patroni? Nina uhusiano mzuri sana na Patroni. Kwa maoni yangu, hii ndiyo bora zaidi iliyopo leo. Ninajua bidhaa zingine nyingi. Hizi ni Stolon, Repmgr, Pg_auto_failover, PAF. 4 zana. Nilijaribu zote. Patroni ndiye ninayempenda zaidi.

Ikiwa wananiuliza: "Je! ninapendekeza Patroni?". Nitasema ndiyo, kwa sababu napenda Patroni. Na nadhani nilijifunza jinsi ya kupika.

Ikiwa una nia ya kuona ni shida gani zingine zilizo na Patroni kando na shida ambazo nimetaja, unaweza kuangalia ukurasa kila wakati. masuala ya kwenye GitHub. Kuna hadithi nyingi tofauti na masuala mengi ya kuvutia yanajadiliwa hapo. Na matokeo yake, baadhi ya mende zilianzishwa na kutatuliwa, yaani, hii ni kusoma kwa kuvutia.

Kuna baadhi ya hadithi za kuvutia kuhusu watu kujipiga risasi kwenye mguu. Taarifa sana. Unasoma na kuelewa kwamba si lazima kufanya hivyo. nilijikaza.

Na ningependa kusema asante kubwa kwa Zalando kwa kuendeleza mradi huu, yaani kwa Alexander Kukushkin na Alexey Klyukin. Aleksey Klyukin ni mmoja wa waandishi mwenza, hafanyi kazi tena katika Zalando, lakini hawa ni watu wawili ambao walianza kufanya kazi na bidhaa hii.

Na nadhani kwamba Patroni ni jambo baridi sana. Nina furaha kuwa yuko, inavutia naye. Na asante sana kwa wachangiaji wote wanaoandika viraka kwa Patroni. Natumai kuwa Patroni atakua zaidi, mtulivu na afaulu kadiri umri unavyoendelea. Tayari inafanya kazi, lakini natumai itakuwa bora zaidi. Kwa hiyo, ikiwa unapanga kutumia Patroni, basi usiogope. Hii ni suluhisho nzuri, inaweza kutekelezwa na kutumika.

Ni hayo tu. Ikiwa una maswali, uliza.

maswali

Asante kwa ripoti! Ikiwa baada ya faili bado unahitaji kuangalia huko kwa uangalifu sana, basi kwa nini tunahitaji faili moja kwa moja?

Kwa sababu ni mambo mapya. Tumekuwa naye kwa mwaka mmoja tu. Bora kuwa salama. Tunataka kuingia na kuona kwamba kila kitu kilifanya kazi jinsi inavyopaswa. Hii ndio kiwango cha kutoaminiana kwa watu wazima - ni bora kuangalia mara mbili na kuona.

Kwa mfano, tulikwenda asubuhi na kuangalia, sawa?

Sio asubuhi, kwa kawaida tunajifunza kuhusu faili otomatiki mara moja. Tunapokea arifa, tunaona kwamba faili otomatiki imetokea. Sisi karibu mara moja kwenda na kuangalia. Lakini hundi hizi zote zinapaswa kuletwa kwenye ngazi ya ufuatiliaji. Ukipata Patroni kupitia REST API, kuna historia. Kwa historia unaweza kuona mihuri ya muda wakati kiweka faili kilifanyika. Kulingana na hili, ufuatiliaji unaweza kufanywa. Unaweza kuona historia, jinsi matukio mengi yalikuwepo. Ikiwa tuna matukio zaidi, basi faili otomatiki imetokea. Unaweza kwenda na kuona. Au otomatiki yetu ya ufuatiliaji ilikagua kuwa tuna nakala zote mahali, hakuna lag na kila kitu kiko sawa.

Asante!

Asante sana kwa hadithi nzuri! Ikiwa tulihamisha nguzo ya DCS mahali fulani mbali na nguzo ya Postgres, basi nguzo hii pia inahitaji kuhudumiwa mara kwa mara? Je, ni mbinu gani bora ambazo baadhi ya vipande vya nguzo ya DCS vinahitaji kuzimwa, kitu cha kufanya navyo, n.k.? Je, muundo huu wote unaishije? Na unafanyaje mambo haya?

Kwa kampuni moja, ilikuwa ni lazima kufanya matrix ya matatizo, nini kinatokea ikiwa moja ya vipengele au vipengele kadhaa vinashindwa. Kulingana na matrix hii, tunapitia sehemu zote kwa mpangilio na kuunda hali ikiwa vifaa hivi vitashindwa. Ipasavyo, kwa kila hali ya kutofaulu, unaweza kuwa na mpango wa utekelezaji wa kupona. Na kwa upande wa DCS, inakuja kama sehemu ya miundombinu ya kawaida. Na wasimamizi wanaisimamia, na tayari tunategemea wasimamizi wanaoisimamia na uwezo wao wa kuirekebisha ikitokea ajali. Ikiwa hakuna DCS kabisa, basi tunaipeleka, lakini wakati huo huo hatuifuatilii hasa, kwa sababu hatuwajibiki kwa miundombinu, lakini tunatoa mapendekezo juu ya jinsi na nini cha kufuatilia.

Hiyo ni, nilielewa kwa usahihi kwamba ninahitaji kuzima Patroni, kuzima faili ya faili, kuzima kila kitu kabla ya kufanya chochote na majeshi?

Inategemea ni nodi ngapi tunazo katika nguzo ya DCS. Ikiwa kuna nodi nyingi na ikiwa tutazima nodi moja tu (nakili), basi nguzo hudumisha akidi. Na Patroni bado inafanya kazi. Na hakuna kitu kinachosababishwa. Ikiwa tuna shughuli ngumu zinazoathiri nodi zaidi, kutokuwepo kwa ambayo inaweza kuharibu akidi, basi - ndio, inaweza kuwa na maana kuweka Patroni kwenye pause. Ina amri sambamba - patronictl pause, patronictl resume. Tunasitisha tu na kiweka faili kiotomatiki hakifanyi kazi wakati huo. Tunafanya matengenezo kwenye nguzo ya DCS, kisha tunaondoa pause na kuendelea kuishi.

Asante sana!

Asante sana kwa ripoti yako! Je, timu ya bidhaa inahisije kuhusu data kupotea?

Timu za bidhaa hazijali, na viongozi wa timu wana wasiwasi.

Kuna dhamana gani?

Dhamana ni ngumu sana. Alexander Kukushkin ana ripoti "Jinsi ya kuhesabu RPO na RTO", yaani wakati wa kurejesha na ni data ngapi tunaweza kupoteza. Nadhani tunahitaji kutafuta slaidi hizi na kuzisoma. Kwa kadiri ninavyokumbuka, kuna hatua maalum za jinsi ya kuhesabu vitu hivi. Ni shughuli ngapi tunaweza kupoteza, ni data ngapi tunaweza kupoteza. Kama chaguo, tunaweza kutumia urudufishaji wa kisawazishaji katika kiwango cha Patroni, lakini huu ni upanga wenye makali kuwili: ama tuna uaminifu wa data, au tunapoteza kasi. Kuna urudufishaji wa usawazishaji, lakini pia hauhakikishi ulinzi wa 100% dhidi ya upotezaji wa data.

Alexey, asante kwa ripoti nzuri! Uzoefu wowote wa kutumia Patroni kwa ulinzi wa kiwango cha sifuri? Hiyo ni, kwa kushirikiana na kusubiri kwa synchronous? Hili ni swali la kwanza. Na swali la pili. Umetumia suluhu tofauti. Tulitumia Repmgr, lakini bila kiotomatiki, na sasa tunapanga kujumuisha kiotomatiki. Na tunamchukulia Patroni kama suluhisho mbadala. Unaweza kusema nini kama faida ikilinganishwa na Repmgr?

Swali la kwanza lilikuwa juu ya nakala za synchronous. Hakuna mtu anayetumia urudufishaji hapa, kwa sababu kila mtu anaogopa (Wateja kadhaa tayari wanaitumia, kimsingi, hawakugundua shida za utendaji - Ujumbe wa Spika) Lakini tumejitengenezea sheria kwamba kunapaswa kuwa na angalau nodi tatu kwenye nguzo ya urudufishaji inayolingana, kwa sababu ikiwa tuna nodi mbili na ikiwa bwana au nakala itashindwa, basi Patroni hubadilisha nodi hii kwa hali ya Standalone ili programu iendelee. kazi. Katika kesi hii, kuna hatari ya kupoteza data.

Kuhusu swali la pili, tumetumia Repmgr na bado tunafanya na baadhi ya wateja kwa sababu za kihistoria. Nini kinaweza kusemwa? Patroni huja na kiotomatiki nje ya kisanduku, Repmgr inakuja na kiotomatiki kama kipengele cha ziada kinachohitaji kuwezeshwa. Tunahitaji kuendesha daemon ya Repmgr kwenye kila nodi na kisha tunaweza kusanidi kiotomatiki.

Repmgr hukagua ikiwa nodi za Postgres ziko hai. Michakato ya Repmgr angalia uwepo wa kila mmoja, hii sio njia bora sana. kunaweza kuwa na matukio changamano ya kutengwa kwa mtandao ambapo nguzo kubwa ya Repmgr inaweza kutengana na kuwa kadhaa ndogo na kuendelea kufanya kazi. Sijafuata Repmgr kwa muda mrefu, labda ilirekebishwa ... au labda sivyo. Lakini kuondolewa kwa taarifa kuhusu hali ya nguzo katika DCS, kama Stolon, Patroni anavyofanya, ndilo chaguo linalofaa zaidi.

Alexey, nina swali, labda lalemavu. Katika mojawapo ya mifano ya kwanza, ulihamisha DCS kutoka kwa mashine ya ndani hadi kwa seva pangishi ya mbali. Tunaelewa kuwa mtandao ni kitu ambacho kina sifa zake, kinaishi peke yake. Na nini kitatokea ikiwa kwa sababu fulani nguzo ya DCS itakosekana? Sitasema sababu, kunaweza kuwa na mengi yao: kutoka kwa mikono iliyopotoka ya wanamtandao hadi matatizo halisi.

Sikusema kwa sauti kubwa, lakini nguzo ya DCS lazima pia isifanikiwe, yaani, ni idadi isiyo ya kawaida ya nodi, ili akidi itimizwe. Nini kitatokea ikiwa nguzo ya DCS haitapatikana, au akidi haiwezi kufikiwa, yaani, aina fulani ya mgawanyiko wa mtandao au kushindwa kwa nodi? Katika kesi hii, nguzo ya Patroni huenda kwenye hali ya kusoma tu. Nguzo ya Patroni haiwezi kuamua hali ya nguzo na nini cha kufanya. Haiwezi kuwasiliana na DCS na kuhifadhi hali mpya ya nguzo hapo, kwa hivyo nguzo nzima inasomwa tu. Na hungoja uingiliaji kati wa kibinafsi kutoka kwa opereta au kwa DCS kurejesha.

Kwa kusema, DCS inakuwa huduma kwetu muhimu kama msingi yenyewe?

Ndiyo ndiyo. Katika makampuni mengi ya kisasa, Ugunduzi wa Huduma ni sehemu muhimu ya miundombinu. Inatekelezwa hata kabla ya kuwa na hifadhidata katika miundombinu. Kwa ulinganifu, miundombinu ilizinduliwa, ikatumwa katika DC, na mara moja tuna Ugunduzi wa Huduma. Ikiwa ni Balozi, basi DNS inaweza kujengwa juu yake. Ikiwa hii ni Etcd, basi kunaweza kuwa na sehemu kutoka kwa nguzo ya Kubernetes, ambayo kila kitu kingine kitawekwa. Inaonekana kwangu kuwa Ugunduzi wa Huduma tayari ni sehemu muhimu ya miundombinu ya kisasa. Na wanafikiria juu yake mapema zaidi kuliko hifadhidata.

Asante!

Chanzo: mapenzi.com