Kundi la Failover PostgreSQL + Patroni. Uzoefu wa utekelezaji

Katika makala nitakuambia jinsi tulivyokaribia suala la uvumilivu wa kosa la PostgreSQL, kwa nini ikawa muhimu kwetu na kile kilichotokea mwishoni.

Tuna huduma iliyopakiwa sana: watumiaji milioni 2,5 duniani kote, watumiaji 50K+ wanaotumia kila siku. Seva ziko Amazone katika eneo moja la Ayalandi: Seva 100+ tofauti zinafanya kazi kila mara, ambazo karibu 50 ziko na hifadhidata.

Mazingira yote ya nyuma ni programu kubwa ya hali ya juu ya Java ambayo huweka muunganisho wa soketi ya wavuti na mteja. Wakati watumiaji kadhaa wanafanya kazi kwenye ubao mmoja kwa wakati mmoja, wote wanaona mabadiliko kwa wakati halisi, kwa sababu tunaandika kila mabadiliko kwenye hifadhidata. Tuna takriban maombi 10K kwa sekunde kwenye hifadhidata zetu. Katika mzigo wa kilele katika Redis, tunaandika maombi 80-100K kwa sekunde.

Kwa nini tulibadilisha kutoka Redis hadi PostgreSQL

Hapo awali, huduma yetu ilifanya kazi na Redis, duka la thamani kuu ambalo huhifadhi data zote kwenye RAM ya seva.

Faida za Redis:

1. Kasi ya majibu ya juu, kwa sababu kila kitu kinahifadhiwa kwenye kumbukumbu;
2. Urahisi wa kuhifadhi na kurudia.

Hasara za Redis kwetu:

1. Hakuna shughuli za kweli. Tulijaribu kuziiga katika kiwango cha maombi yetu. Kwa bahati mbaya, hii haikufanya kazi vizuri kila wakati na ilihitaji kuandika nambari ngumu sana.
2. Kiasi cha data kinapunguzwa na kiasi cha kumbukumbu. Kadiri idadi ya data inavyoongezeka, kumbukumbu itakua, na, mwishowe, tutaingia kwenye sifa za mfano uliochaguliwa, ambao katika AWS unahitaji kusimamisha huduma yetu ili kubadilisha aina ya mfano.
3. Inahitajika kudumisha kiwango cha chini cha latency kila wakati, kwa sababu. tuna idadi kubwa sana ya maombi. Kiwango bora cha kuchelewa kwetu ni 17-20 ms. Katika kiwango cha 30-40 ms, tunapata majibu marefu kwa maombi kutoka kwa maombi yetu na uharibifu wa huduma. Kwa bahati mbaya, hii ilitutokea mnamo Septemba 2018, wakati moja ya matukio na Redis kwa sababu fulani ilipokea latency mara 2 zaidi kuliko kawaida. Ili kusuluhisha suala hilo, tulisimamisha huduma katikati ya siku kwa ajili ya matengenezo ambayo hayajaratibiwa na kuchukua nafasi ya tukio lenye matatizo la Redis.
4. Ni rahisi kupata utofauti wa data hata na makosa madogo kwenye msimbo na kisha kutumia muda mwingi kuandika msimbo kusahihisha data hii.

Tulizingatia hasara na kutambua kwamba tulihitaji kuhamia kitu rahisi zaidi, na shughuli za kawaida na utegemezi mdogo wa latency. Utafiti uliofanywa, kuchambua chaguzi nyingi na kuchagua PostgreSQL.

Tumekuwa tukihamia hifadhidata mpya kwa miaka 1,5 tayari na tumehamisha sehemu ndogo tu ya data, kwa hivyo sasa tunafanya kazi kwa wakati mmoja na Redis na PostgreSQL. Taarifa zaidi kuhusu hatua za kuhamisha na kubadili data kati ya hifadhidata zimeandikwa ndani makala na mwenzangu.

Tulipoanza kusonga, programu yetu ilifanya kazi moja kwa moja na hifadhidata na kufikia Redis kuu na PostgreSQL. Kundi la PostgreSQL lilijumuisha bwana na nakala iliyo na urudufishaji wa asynchronous. Hivi ndivyo mpango wa hifadhidata ulivyoonekana kama:

Utekelezaji wa PgBouncer

Tulipokuwa tunasonga, bidhaa pia ilikuwa ikitengenezwa: idadi ya watumiaji na idadi ya seva zilizofanya kazi na PostgreSQL iliongezeka, na tukaanza kukosa miunganisho. PostgreSQL huunda mchakato tofauti kwa kila unganisho na hutumia rasilimali. Unaweza kuongeza idadi ya miunganisho hadi hatua fulani, vinginevyo kuna nafasi ya kupata utendaji wa hifadhidata ndogo. Chaguo bora katika hali kama hiyo itakuwa kuchagua meneja wa uunganisho ambaye atasimama mbele ya msingi.

Tulikuwa na chaguzi mbili kwa meneja wa unganisho: Pgpool na PgBouncer. Lakini ya kwanza haiungi mkono hali ya shughuli ya kufanya kazi na hifadhidata, kwa hivyo tulichagua PgBouncer.

Tumeweka mpango wa kazi ufuatao: programu yetu inafikia PgBouncer moja, ambayo nyuma yake kuna masters za PostgreSQL, na nyuma ya kila bwana kuna nakala moja yenye urudufishaji wa asynchronous.


Wakati huo huo, hatukuweza kuhifadhi kiasi kizima cha data katika PostgreSQL na kasi ya kufanya kazi na hifadhidata ilikuwa muhimu kwetu, kwa hiyo tulianza kugawa PostgreSQL kwenye kiwango cha maombi. Mpango ulioelezwa hapo juu ni rahisi kwa hili: wakati wa kuongeza shard mpya ya PostgreSQL, inatosha kusasisha usanidi wa PgBouncer na programu inaweza kufanya kazi mara moja na shard mpya.

Kushindwa kwa PgBouncer

Mpango huu ulifanya kazi hadi wakati ambapo mfano pekee wa PgBouncer ulikufa. Tuko katika AWS, ambapo matukio yote yanatumia maunzi ambayo hufa mara kwa mara. Katika hali kama hizi, mfano huhamia kwa vifaa vipya na hufanya kazi tena. Hii ilifanyika na PgBouncer, lakini haikupatikana. Matokeo ya anguko hili yalikuwa kutopatikana kwa huduma yetu kwa dakika 25. AWS inapendekeza kutumia upunguzaji wa upande wa watumiaji kwa hali kama hizi, ambazo hazikutekelezwa katika nchi yetu wakati huo.

Baada ya hapo, tulifikiria kwa uzito juu ya uvumilivu wa makosa wa nguzo za PgBouncer na PostgreSQL, kwa sababu hali kama hiyo inaweza kutokea kwa mfano wowote katika akaunti yetu ya AWS.

Tuliunda mpango wa kuvumilia hitilafu wa PgBouncer kama ifuatavyo: seva zote za programu hufikia Kisawazisho cha Upakiaji wa Mtandao, ambacho nyuma yake kuna PgBouncers mbili. Kila PgBouncer hutazama bwana sawa wa PostgreSQL wa kila shard. Ikiwa tukio la ajali la AWS litatokea tena, trafiki yote itaelekezwa kupitia PgBouncer nyingine. Kushindwa kwa Kisawazisho cha Upakiaji wa Mtandao hutolewa na AWS.

Mpango huu hurahisisha kuongeza seva mpya za PgBouncer.

Unda Kundi la Kushindwa la PostgreSQL

Wakati wa kutatua tatizo hili, tulizingatia chaguo tofauti: kushindwa kwa kujitegemea, repmgr, AWS RDS, Patroni.

Maandishi ya kujiandikisha

Wanaweza kufuatilia kazi ya bwana na, ikiwa itashindwa, kukuza replica kwa bwana na kusasisha usanidi wa PgBouncer.

Faida za njia hii ni unyenyekevu mkubwa, kwa sababu unaandika maandishi mwenyewe na kuelewa jinsi inavyofanya kazi.

Minus:

• Huenda bwana hakufa, badala yake hitilafu ya mtandao inaweza kuwa imetokea. Failover, bila kujua hili, itakuza replica kwa bwana, wakati bwana wa zamani ataendelea kufanya kazi. Kama matokeo, tutapata seva mbili katika jukumu la bwana na hatutajua ni nani kati yao aliye na data ya hivi punde. Hali hii pia inaitwa ubongo uliogawanyika;
• Tuliachwa bila majibu. Katika usanidi wetu, bwana na nakala moja, baada ya kubadili, nakala husogea hadi kwa bwana na hatuna nakala tena, kwa hivyo lazima tuongeze nakala mpya;
• Tunahitaji ufuatiliaji wa ziada wa operesheni ya kushindwa, wakati tunayo shadi 12 za PostgreSQL, ambayo ina maana kwamba tunapaswa kufuatilia makundi 12. Kwa kuongezeka kwa idadi ya shards, lazima pia ukumbuke kusasisha failover.

Kushindwa kwa maandishi ya kibinafsi inaonekana ngumu sana na inahitaji usaidizi usio na maana. Na nguzo moja ya PostgreSQL, hii itakuwa chaguo rahisi zaidi, lakini haina kiwango, kwa hivyo haifai kwetu.

Repmgr

Kidhibiti cha Kurudiarudia kwa nguzo za PostgreSQL, ambazo zinaweza kudhibiti utendakazi wa nguzo ya PostgreSQL. Wakati huo huo, haina kushindwa kwa moja kwa moja nje ya sanduku, kwa hiyo kwa kazi utahitaji kuandika "wrapper" yako mwenyewe juu ya suluhisho la kumaliza. Kwa hivyo kila kitu kinaweza kugeuka kuwa ngumu zaidi kuliko kwa maandishi yaliyoandikwa kibinafsi, kwa hivyo hatukujaribu hata Repmgr.

AWS RDS

Inaauni kila kitu tunachohitaji, inajua jinsi ya kutengeneza nakala rudufu na hudumisha kundi la miunganisho. Ina kubadili kiotomatiki: wakati bwana akifa, replica inakuwa bwana mpya, na AWS inabadilisha rekodi ya dns kwa bwana mpya, wakati replicas inaweza kupatikana katika AZ tofauti.

Hasara ni pamoja na ukosefu wa marekebisho ya faini. Kama mfano wa urekebishaji mzuri: hali zetu zina vizuizi vya miunganisho ya tcp, ambayo, kwa bahati mbaya, haiwezi kufanywa katika RDS:

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

Kwa kuongezea, AWS RDS ni ghali karibu mara mbili kuliko bei ya kawaida ya mfano, ambayo ilikuwa sababu kuu ya kuachana na suluhisho hili.

Mchungaji

Hii ni kiolezo cha python cha kusimamia PostgreSQL na nyaraka nzuri, kushindwa kiotomatiki na msimbo wa chanzo kwenye github.

Faida za Patroni:

• Kila parameter ya usanidi imeelezwa, ni wazi jinsi inavyofanya kazi;
• Kushindwa kiotomatiki hufanya kazi nje ya boksi;
• Imeandikwa katika python, na kwa kuwa sisi wenyewe tunaandika mengi katika python, itakuwa rahisi kwetu kukabiliana na matatizo na, labda, hata kusaidia maendeleo ya mradi huo;
• Inasimamia kikamilifu PostgreSQL, hukuruhusu kubadilisha usanidi kwenye nodi zote za nguzo mara moja, na ikiwa nguzo inahitaji kuanzishwa upya ili kutumia usanidi mpya, basi hii inaweza kufanyika tena kwa kutumia Patroni.

Minus:

• Sio wazi kutoka kwa nyaraka jinsi ya kufanya kazi na PgBouncer kwa usahihi. Ingawa ni vigumu kuiita minus, kwa sababu kazi ya Patroni ni kusimamia PostgreSQL, na jinsi miunganisho ya Patroni itaenda tayari ni tatizo letu;
• Kuna mifano michache ya utekelezaji wa Patroni kwa kiasi kikubwa, wakati kuna mifano mingi ya utekelezaji kutoka mwanzo.

Kama matokeo, tulichagua Patroni kuunda nguzo ya kushindwa.

Mchakato wa Utekelezaji wa Patroni

Kabla ya Patroni, tulikuwa na shadi 12 za PostgreSQL katika usanidi wa bwana mmoja na nakala moja yenye urudufishaji wa asynchronous. Seva za programu zilifikia hifadhidata kupitia Kisawazisha cha Mizigo ya Mtandao, ambacho nyuma yake kulikuwa na visa viwili vya PgBouncer, na nyuma yao kulikuwa na seva zote za PostgreSQL.


Ili kutekeleza Patroni, tulihitaji kuchagua usanidi wa nguzo ya hifadhi iliyosambazwa. Patroni hufanya kazi na mifumo iliyosambazwa ya uhifadhi wa usanidi kama vile etcd, Zookeeper, Consul. Tuna kundi kamili la Ubalozi kwenye soko, ambalo linafanya kazi kwa kushirikiana na Vault na hatutumii tena. Sababu kubwa ya kuanza kutumia Balozi kwa madhumuni yaliyokusudiwa.

Jinsi Patroni anavyofanya kazi na Balozi

Tuna kikundi cha Consul, ambacho kinajumuisha nodes tatu, na kikundi cha Patroni, ambacho kina kiongozi na replica (katika Patroni, bwana anaitwa kiongozi wa nguzo, na watumwa huitwa replicas). Kila mfano wa nguzo ya Patroni hutuma kila mara habari kuhusu hali ya nguzo kwa Balozi. Kwa hivyo, kutoka kwa Balozi unaweza kujua kila wakati usanidi wa sasa wa nguzo ya Patroni na ni nani kiongozi kwa sasa.

Ili kuunganisha Patroni kwa Consul, inatosha kusoma hati rasmi, ambayo inasema kwamba unahitaji kutaja mwenyeji katika muundo wa http au https, kulingana na jinsi tunavyofanya kazi na Consul, na mpango wa unganisho, kwa hiari:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

Inaonekana rahisi, lakini hapa mitego huanza. Kwa Mshauri, tunafanyia kazi muunganisho salama kupitia https na usanidi wetu wa muunganisho utaonekana kama hii:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

Lakini hiyo haifanyi kazi. Wakati wa kuanza, Patroni hawezi kuunganisha kwa Balozi, kwa sababu inajaribu kupitia http hata hivyo.

Nambari ya chanzo ya Patroni ilisaidia kushughulikia shida. Jambo jema imeandikwa katika python. Inatokea kwamba parameter ya mwenyeji haijachanganuliwa kwa njia yoyote, na itifaki lazima ielezwe katika mpango. Hivi ndivyo kizuizi cha usanidi kinachofanya kazi cha kufanya kazi na Balozi kinaonekana kama kwetu:

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

balozi-template

Kwa hiyo, tumechagua hifadhi kwa ajili ya usanidi. Sasa tunahitaji kuelewa jinsi PgBouncer itabadilisha usanidi wake wakati wa kubadilisha kiongozi katika nguzo ya Patroni. Hakuna jibu la swali hili katika nyaraka, kwa sababu. hapo, kimsingi, kazi na PgBouncer haijaelezewa.

Katika kutafuta suluhu, tulipata makala (kwa bahati mbaya sikumbuki kichwa) ambapo iliandikwa kwamba Сonsul-template ilisaidia sana katika kuoanisha PgBouncer na Patroni. Hii ilitusukuma kuchunguza jinsi Consul-template inavyofanya kazi.

Ilibadilika kuwa kiolezo cha Balozi hufuatilia kila mara usanidi wa nguzo ya PostgreSQL katika Balozi. Wakati kiongozi anabadilika, inasasisha usanidi wa PgBouncer na kutuma amri ili kuipakia upya.

Kiolezo kikubwa zaidi ni kwamba kinahifadhiwa kama msimbo, kwa hivyo unapoongeza kipande kipya, inatosha kufanya ahadi mpya na kusasisha kiolezo kiotomatiki, ikisaidia Miundombinu kama kanuni ya msimbo.

Usanifu mpya na Patroni

Kama matokeo, tulipata mpango wa kazi ufuatao:


Seva zote za programu hufikia mizani → kuna matukio mawili ya PgBouncer nyuma yake → kwa kila mfano, Consul-template inazinduliwa, ambayo inafuatilia hali ya kila nguzo ya Patroni na kufuatilia umuhimu wa usanidi wa PgBouncer, ambao hutuma maombi kwa kiongozi wa sasa. ya kila nguzo.

Mtihani wa mwongozo

Tuliendesha mpango huu kabla ya kuuzindua kwenye mazingira madogo ya majaribio na kukagua uendeshaji wa kubadili kiotomatiki. Walifungua ubao, wakasogeza kibandiko, na wakati huo "walimuua" kiongozi wa nguzo. Katika AWS, hii ni rahisi kama kuzima mfano kupitia koni.

Kibandiko kilirudi nyuma ndani ya sekunde 10-20, na kisha tena kikaanza kusonga kawaida. Hii ina maana kwamba nguzo ya Patroni ilifanya kazi kwa usahihi: ilibadilisha kiongozi, ikatuma taarifa kwa Сonsul, na Сonsul-template mara moja ilichukua habari hii, ikabadilisha usanidi wa PgBouncer na kutuma amri ya kupakia upya.

Jinsi ya kuishi chini ya mzigo mkubwa na kuweka wakati wa kupumzika kuwa mdogo?

Kila kitu hufanya kazi kikamilifu! Lakini kuna maswali mapya: Itafanyaje kazi chini ya mzigo mkubwa? Jinsi ya haraka na kwa usalama kusambaza kila kitu katika uzalishaji?

Mazingira ya majaribio ambayo tunafanyia majaribio ya upakiaji hutusaidia kujibu swali la kwanza. Inafanana kabisa na uzalishaji katika suala la usanifu na imetoa data ya majaribio ambayo ni takriban sawa na kiasi cha uzalishaji. Tunaamua tu "kuua" mmoja wa mabwana wa PostgreSQL wakati wa jaribio na kuona kitakachotokea. Lakini kabla ya hayo, ni muhimu kuangalia rolling moja kwa moja, kwa sababu kwenye mazingira haya tuna shards kadhaa za PostgreSQL, kwa hiyo tutapata upimaji bora wa maandiko ya usanidi kabla ya uzalishaji.

Kazi zote mbili zinaonekana kutamani, lakini tunayo PostgreSQL 9.6. Je, tunaweza kuboresha mara moja hadi 11.2?

Tunaamua kuifanya kwa hatua 2: kwanza kuboresha hadi 11.2, kisha uzindua Patroni.

Sasisho la PostgreSQL

Ili kusasisha haraka toleo la PostgreSQL, tumia chaguo -k, ambayo viungo ngumu huundwa kwenye diski na hakuna haja ya kunakili data yako. Kwa msingi wa 300-400 GB, sasisho huchukua sekunde 1.

Tuna shards nyingi, kwa hivyo sasisho linahitaji kufanywa moja kwa moja. Ili kufanya hivyo, tuliandika kitabu cha kucheza cha Ansible ambacho kinashughulikia mchakato mzima wa kusasisha kwa ajili yetu:

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

Ni muhimu kutambua hapa kwamba kabla ya kuanza kuboresha, lazima uifanye na parameter --angaliaili kuhakikisha kuwa unaweza kuboresha. Hati yetu pia hufanya ubadilishaji wa usanidi kwa muda wa uboreshaji. Hati yetu ilikamilika kwa sekunde 30, ambayo ni matokeo bora.

Uzinduzi Patroni

Ili kutatua tatizo la pili, angalia tu usanidi wa Patroni. Hifadhi rasmi ina usanidi wa mfano na initdb, ambayo ina jukumu la kuanzisha hifadhidata mpya unapoanza Patroni kwa mara ya kwanza. Lakini kwa kuwa tayari tuna hifadhidata iliyotengenezwa tayari, tuliondoa sehemu hii kutoka kwa usanidi.

Tulipoanza kusakinisha Patroni kwenye nguzo iliyopo tayari ya PostgreSQL na kuiendesha, tuliingia kwenye tatizo jipya: seva zote mbili zilianza kama kiongozi. Patroni hajui chochote kuhusu hali ya awali ya nguzo na anajaribu kuanzisha seva zote mbili kama makundi mawili tofauti yenye jina moja. Ili kutatua tatizo hili, unahitaji kufuta saraka na data kwenye mtumwa:

rm -rf /var/lib/postgresql/

Hii inahitaji kufanywa tu kwa mtumwa!

Wakati replica safi imeunganishwa, Patroni hufanya kiongozi wa msingi na kuirejesha kwenye nakala, na kisha kupata hali ya sasa kulingana na magogo ya ukuta.

Ugumu mwingine tuliokutana nao ni kwamba nguzo zote za PostgreSQL zimepewa jina kuu kwa chaguo-msingi. Wakati kila nguzo haijui chochote kuhusu nyingine, hii ni kawaida. Lakini unapotaka kutumia Patroni, basi nguzo zote lazima ziwe na jina la kipekee. Suluhisho ni kubadilisha jina la nguzo katika usanidi wa PostgreSQL.

mtihani wa mzigo

Tumezindua jaribio ambalo huiga uzoefu wa mtumiaji kwenye ubao. Wakati mzigo ulipofikia thamani yetu ya wastani ya kila siku, tulirudia jaribio lile lile, tulizima mfano mmoja na kiongozi wa PostgreSQL. Kushindwa kwa kiotomatiki kulifanya kazi kama tulivyotarajia: Patroni alibadilisha kiongozi, Kiolezo cha Balozi alisasisha usanidi wa PgBouncer na kutuma amri ya kupakia upya. Kwa mujibu wa grafu zetu katika Grafana, ilikuwa wazi kuwa kuna ucheleweshaji wa sekunde 20-30 na kiasi kidogo cha makosa kutoka kwa seva zinazohusiana na uunganisho kwenye hifadhidata. Hii ni hali ya kawaida, maadili kama haya yanakubalika kwa kushindwa kwetu na ni bora zaidi kuliko wakati wa huduma.

Kuleta Patroni kwa uzalishaji

Kama matokeo, tulikuja na mpango ufuatao:

• Sambaza kiolezo cha Mshauri kwa seva za PgBouncer na uzindue;
• sasisho za PostgreSQL kwa toleo la 11.2;
• Badilisha jina la kikundi;
• Kuanzisha Nguzo ya Patroni.

Wakati huo huo, mpango wetu unaturuhusu kufanya hatua ya kwanza karibu wakati wowote, tunaweza kuondoa kila PgBouncer kutoka kwa kazi kwa upande wake na kupeleka na kuendesha template ya balozi juu yake. Hivyo tulifanya.

Kwa upelekaji wa haraka, tulitumia Ansible, kwa kuwa tayari tumejaribu vitabu vyote vya kucheza kwenye mazingira ya mtihani, na muda wa utekelezaji wa hati kamili ulikuwa kutoka dakika 1,5 hadi 2 kwa kila shard. Tunaweza kusambaza kila kitu kwa zamu kwa kila shard bila kusimamisha huduma yetu, lakini tutalazimika kuzima kila PostgreSQL kwa dakika kadhaa. Katika kesi hii, watumiaji ambao data yao iko kwenye shard hii haikuweza kufanya kazi kikamilifu kwa wakati huu, na hii haikubaliki kwetu.

Njia ya nje ya hali hii ilikuwa matengenezo yaliyopangwa, ambayo hufanyika kila baada ya miezi 3. Hili ni dirisha la kazi iliyoratibiwa, tunapozima kabisa huduma zetu na kuboresha hali zetu za hifadhidata. Ilikuwa imesalia wiki moja hadi dirisha lijalo, na tuliamua tu kusubiri na kujiandaa zaidi. Wakati wa kusubiri, tulijilinda zaidi: kwa kila shadi ya PostgreSQL, tuliinua nakala ya ziada ikiwa tutashindwa kuweka data ya hivi punde, na tukaongeza mfano mpya kwa kila kipande, ambacho kinapaswa kuwa nakala mpya katika nguzo ya Patroni, ili usitekeleze amri ya kufuta data . Yote hii ilisaidia kupunguza hatari ya makosa.


Tulianza tena huduma yetu, kila kitu kilifanya kazi kama inavyopaswa, watumiaji waliendelea kufanya kazi, lakini kwenye grafu tuliona mzigo wa juu usio wa kawaida kwenye seva za Consul.


Kwa nini hatukuona hii katika mazingira ya mtihani? Tatizo hili linaonyesha vyema kwamba ni muhimu kufuata Miundombinu kama kanuni ya kanuni na kuboresha miundombinu yote, kutoka kwa mazingira ya majaribio hadi uzalishaji. Vinginevyo, ni rahisi sana kupata shida tuliyopata. Nini kimetokea? Balozi alionekana kwanza kwenye uzalishaji, na kisha kwenye mazingira ya majaribio, kwa sababu hiyo, kwenye mazingira ya majaribio, toleo la Consul lilikuwa kubwa zaidi kuliko uzalishaji. Katika moja tu ya matoleo, uvujaji wa CPU ulitatuliwa wakati wa kufanya kazi na kiolezo cha balozi. Kwa hivyo, tulisasisha tu Balozi, na hivyo kutatua shida.

Anzisha tena nguzo ya Patroni

Walakini, tulipata shida mpya, ambayo hata hatukushuku. Wakati wa kusasisha Mshauri, tunaondoa tu nodi ya Balozi kutoka kwa nguzo kwa kutumia amri ya kuondoka kwa balozi → Patroni huunganisha kwa seva nyingine ya Balozi → kila kitu hufanya kazi. Lakini tulipofikia mfano wa mwisho wa nguzo ya Balozi na kutuma amri ya kuondoka kwa balozi kwake, nguzo zote za Patroni zilianza tena, na kwenye magogo tuliona makosa yafuatayo:

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

Nguzo ya Patroni haikuweza kupata taarifa kuhusu nguzo yake na ikaanza upya.

Ili kupata suluhisho, tuliwasiliana na waandishi wa Patroni kupitia suala kwenye github. Walipendekeza uboreshaji wa faili zetu za usanidi:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

Tuliweza kuiga tatizo kwenye mazingira ya majaribio na tukajaribu chaguo hizi hapo, lakini kwa bahati mbaya hazikufaulu.

Tatizo bado halijatatuliwa. Tunapanga kujaribu suluhisho zifuatazo:

• Tumia wakala wa Mshauri kwa kila mfano wa nguzo ya Patroni;
• Rekebisha suala katika msimbo.

Tunaelewa mahali ambapo hitilafu ilitokea: tatizo pengine ni matumizi ya muda chaguo-msingi ya kuisha, ambayo haijabatilishwa kupitia faili ya usanidi. Wakati seva ya Mshauri ya mwisho inapoondolewa kwenye nguzo, nguzo nzima ya Balozi hutegemea kwa zaidi ya sekunde, kwa sababu hii, Patroni hawezi kupata hali ya nguzo na kuanzisha upya kabisa nguzo nzima.

Kwa bahati nzuri, hatukukutana na makosa yoyote zaidi.

Matokeo ya kutumia Patroni

Baada ya uzinduzi wa mafanikio wa Patroni, tuliongeza nakala ya ziada katika kila nguzo. Sasa katika kila nguzo kuna mfano wa akidi: kiongozi mmoja na nakala mbili, kwa wavu wa usalama katika kesi ya mgawanyiko wa ubongo wakati wa kubadili.


Patroni amekuwa akifanya kazi katika uzalishaji kwa zaidi ya miezi mitatu. Wakati huu, tayari ameweza kutusaidia. Hivi karibuni, kiongozi wa mojawapo ya makundi alikufa katika AWS, kushindwa kwa moja kwa moja kulifanya kazi na watumiaji waliendelea kufanya kazi. Patroni alitimiza kazi yake kuu.

Muhtasari mdogo wa matumizi ya Patroni:

• Urahisi wa mabadiliko ya usanidi. Inatosha kubadilisha usanidi kwa mfano mmoja na itavutwa hadi kwenye nguzo nzima. Ikiwa reboot inahitajika kutumia usanidi mpya, basi Patroni atakujulisha. Patroni anaweza kuanzisha upya nguzo nzima kwa amri moja, ambayo pia ni rahisi sana.
• Kushindwa kiotomatiki hufanya kazi na tayari imeweza kutusaidia.
• Sasisho la PostgreSQL bila kukatika kwa programu. Lazima kwanza usasishe nakala kwa toleo jipya, kisha ubadilishe kiongozi kwenye nguzo ya Patroni na usasishe kiongozi wa zamani. Katika kesi hiyo, upimaji wa lazima wa kushindwa kwa moja kwa moja hutokea.

Chanzo: mapenzi.com