San alt inseoidh mé duit conas a chuaigh muid i ngleic le ceist lamháltais locht PostgreSQL, cén fáth go raibh sé tábhachtach dúinn agus cad a tharla sa deireadh.
Tá seirbhís an-lódáilte againn: 2,5 milliún úsáideoir ar fud an domhain, 50K+ úsáideoir gníomhach gach lá. Tá na freastalaithe lonnaithe in Amazone i réigiún amháin in Éirinn: bíonn 100+ freastalaí éagsúil i bhfeidhm i gcónaí, agus tá bunachair shonraí ag beagnach 50 díobh sin.
Is feidhmchlár mór monailiteach Java státmhar é an t-inneall iomlán a choinníonn nasc seasta gréasáin leis an gcliant. Nuair a oibríonn roinnt úsáideoirí ar an mbord céanna ag an am céanna, feiceann siad go léir na hathruithe i bhfíor-am, toisc go scríobhaimid gach athrú ar an mbunachar sonraí. Tá thart ar 10K iarratas in aghaidh an tsoicind ar ár mbunachair shonraí. Ag buaicualach i Redis, scríobhaimid 80-100K iarratas in aghaidh an tsoicind.
Cén fáth ar athraigh muid ó Redis go PostgreSQL
Ar dtús, d'oibrigh ár seirbhís le Redis, stór eochairluacha a stórálann na sonraí go léir i RAM an fhreastalaí.
Buntáistí Redis:
- Luas freagartha ard, mar gheall ar stóráiltear gach rud i gcuimhne;
- Éascaíocht cúltaca agus macasamhlú.
Cons of Redis dúinn:
- Níl aon idirbhearta fíor. Rinneamar iarracht iad a insamhladh ag leibhéal ár n-iarratas. Ar an drochuair, níor oibrigh sé seo go maith i gcónaí agus bhí gá le cód an-chasta a scríobh.
- Tá méid na sonraí teoranta ag an méid cuimhne. De réir mar a mhéadaíonn an méid sonraí, tiocfaidh méadú ar an gcuimhne, agus, sa deireadh, rachaidh muid isteach i saintréithe an ásc roghnaithe, rud a éilíonn in AWS stop a chur lenár seirbhís chun an cineál ásc a athrú.
- Is gá a choimeád ar bun i gcónaí ar leibhéal íseal latency, mar gheall ar. tá líon an-mhór iarratas againn. Is é an leibhéal moille is fearr dúinn ná 17-20 ms. Ag leibhéal 30-40 ms, faighimid freagraí fada ar iarratais ónár bhfeidhmchlár agus díghrádú na seirbhíse. Ar an drochuair, tharla sé seo dúinn i Meán Fómhair 2018, nuair a fuair ceann de na cásanna le Redis ar chúis éigin latency 2 uair níos mó ná mar is gnách. Chun an cheist a réiteach, chuireamar stop leis an tseirbhís i lár an lae le haghaidh cothabhála neamhsceidealta agus chuireamar an t-ionad fadhbach Redis in ionad.
- Tá sé éasca neamhréireacht sonraí a fháil fiú le mionearráidí sa chód agus ansin go leor ama a chaitheamh ag scríobh cód chun na sonraí seo a cheartú.
Chuireamar na míbhuntáistí san áireamh agus thuig muid go gcaithfimid bogadh chuig rud éigin níos áisiúla, le gnáth-idirbhearta agus níos lú spleáchais ar latency. Rinne mé taighde, rinne anailís ar go leor roghanna agus roghnaigh PostgreSQL.
Táimid tar éis bogadh go dtí bunachar sonraí nua le 1,5 bliain cheana féin agus níl ach cuid bheag de na sonraí aistrithe againn, agus mar sin táimid ag obair go comhuaineach anois le Redis agus PostgreSQL. Tá tuilleadh eolais faoi na céimeanna a bhaineann le sonraí a bhogadh agus a aistriú idir bunachair shonraí scríofa isteach .
Nuair a thosaigh muid ag bogadh ar dtús, d'oibrigh ár n-iarratas go díreach leis an mbunachar sonraí agus fuair sé rochtain ar an máistir Redis agus PostgreSQL. Is éard a bhí sa bhraisle PostgreSQL máistir agus macasamhail le macasamhlú asincrónach. Seo an chuma a bhí ar scéim an bhunachair shonraí:
PgBouncer á chur i bhfeidhm
Agus muid ag bogadh, bhí an táirge ag forbairt freisin: tháinig méadú ar líon na n-úsáideoirí agus ar líon na bhfreastalaithe a d'oibrigh le PostgreSQL, agus thosaigh muid ag easpa naisc. Cruthaíonn PostgreSQL próiseas ar leith do gach nasc agus ídíonn sé acmhainní. Is féidir leat líon na nasc a mhéadú suas go pointe áirithe, ar shlí eile tá seans ann feidhmíocht bhunachar sonraí suboptimal a fháil. Is é an rogha idéalach i gcás den sórt sin ná bainisteoir nasc a roghnú a sheasfaidh os comhair an bhoinn.
Bhí dhá rogha againn don bhainisteoir ceangail: Pgpool agus PgBouncer. Ach ní thacaíonn an chéad cheann leis an modh idirbheartaíochta a bhaineann le bheith ag obair leis an mbunachar sonraí, mar sin roghnaigh muid PgBouncer.
Tá an scéim oibre seo a leanas curtha ar bun againn: tá rochtain ag ár bhfeidhmchlár ar PgBouncer amháin, a bhfuil máistrí PostgreSQL taobh thiar de, agus taobh thiar de gach máistir tá macasamhail amháin le macasamhlú asincrónach.
Ag an am céanna, níorbh fhéidir linn an méid iomlán sonraí a stóráil i PostgreSQL agus bhí an luas oibriú leis an mbunachar sonraí tábhachtach dúinn, agus mar sin thosaigh muid ag roinnt PostgreSQL ag leibhéal an iarratais. Tá an scéim a thuairiscítear thuas sách áisiúil le haghaidh seo: nuair a chuirtear shard PostgreSQL nua leis, is leor an chumraíocht PgBouncer a nuashonrú agus is féidir leis an iarratas oibriú láithreach leis an shard nua.
Teip PgBouncer
D'oibrigh an scéim seo go dtí an nóiméad a fuair an t-aon chás PgBouncer bás. Táimid in AWS, áit a bhfuil gach cás ag rith ar chrua-earraí a fhaigheann bás go tréimhsiúil. I gcásanna den sórt sin, bogann an cás go crua-earraí nua agus oibríonn sé arís. Tharla sé seo le PgBouncer, ach ní raibh sé ar fáil. Ba é an toradh a bhí ar an titim seo ná nach raibh ár seirbhís ar fáil ar feadh 25 nóiméad. Molann AWS úsáid a bhaint as iomarcaíocht ar thaobh an úsáideora le haghaidh cásanna den sórt sin, nár cuireadh i bhfeidhm inár dtír ag an am sin.
Ina dhiaidh sin, rinneamar machnamh dáiríre faoi lamháltas locht na mbraislí PgBouncer agus PostgreSQL, toisc go bhféadfadh cás den chineál céanna tarlú in aon chás inár gcuntas AWS.
Thógamar an scéim lamháltais locht PgBouncer mar seo a leanas: faigheann gach freastalaí feidhmchláir rochtain ar an Líonra Luchtaithe Comhardaithe, a bhfuil dhá PgBouncer taobh thiar de. Breathnaíonn gach PgBouncer ar an máistir PostgreSQL céanna de gach shard. Má tharlaíonn timpiste shampla AWS arís, atreoraítear an trácht ar fad trí PgBouncer eile. Soláthraíonn AWS mainneachtain an Chomhardú Ualaigh Líonra.
Éascaíonn an scéim seo freastalaithe nua PgBouncer a chur leis.
Cruthaigh Cnuasach Teip PostgreSQL
Agus an fhadhb seo á réiteach againn, rinneamar machnamh ar roghanna éagsúla: failover féinscríofa, repmgr, AWS RDS, Patroni.
Scripteanna féin-scríofa
Is féidir leo monatóireacht a dhéanamh ar obair an mháistir agus, má theipeann air, an macasamhail a chur chun cinn chuig an máistir agus an chumraíocht PgBouncer a nuashonrú.
Is iad na buntáistí a bhaineann leis an gcur chuige seo ná simplíocht uasta, toisc go scríobhann tú scripteanna duit féin agus go dtuigeann tú go díreach conas a oibríonn siad.
CONS:
- Seans nach bhfuair an máistir bás, d’fhéadfadh teip líonra a bheith ann ina ionad sin. Cuirfidh Failover, aineolach air seo, an macasamhail chun cinn don mháistir, agus leanfaidh an seanmháistir ag obair. Mar thoradh air sin, gheobhaidh muid dhá fhreastalaí i ról an mháistir agus ní bheidh a fhios againn cé acu acu a bhfuil na sonraí cothrom le dáta is déanaí. Tugtar scoilt-inchinn ar an gcás seo freisin;
- Fágadh muid gan freagra. Inár gcumraíocht, an máistir agus macasamhail amháin, tar éis athrú, bogann an macasamhail suas go dtí an máistir agus níl macasamhla againn a thuilleadh, agus mar sin ní mór dúinn macasamhail nua a chur leis de láimh;
- Ní mór dúinn monatóireacht bhreise a dhéanamh ar an oibríocht teip, cé go bhfuil 12 shards PostgreSQL againn, rud a chiallaíonn go gcaithfimid monatóireacht a dhéanamh ar 12 bhraisle. Le méadú ar líon na shards, ní mór duit cuimhneamh freisin an teip a nuashonrú.
Tá cuma an-chasta ar failover féinscríofa agus teastaíonn tacaíocht neamhfhánach. Le braisle amháin PostgreSQL, bheadh sé seo ar an rogha is éasca, ach ní scála, mar sin níl sé oiriúnach dúinn.
Repmgr
Bainisteoir Macasamhlaithe do bhraislí PostgreSQL, ar féidir leo oibriú braisle PostgreSQL a bhainistiú. Ag an am céanna, ní bhíonn teiptheorainn uathoibríoch as an mbosca, mar sin le haghaidh oibre beidh ort do “fhillteán” féin a scríobh ar bharr an réitigh chríochnaithe. Mar sin is féidir go dtiocfaidh gach rud amach níos casta ná le scripteanna féinscríofa, mar sin níor bhain muid triail as Repmgr fiú.
AWS RDS
Tacaíonn sé le gach rud a theastaíonn uainn, tá a fhios aige conas cúltacaí a dhéanamh agus coinníonn sé linn nasc. Tá athrú uathoibríoch aige: nuair a fhaigheann an máistir bás, déantar an macasamhail ina mháistir nua, agus athraíonn AWS an taifead dns go dtí an máistir nua, agus is féidir na macasamhla a shuíomh i AZ éagsúla.
Áirítear ar na míbhuntáistí an easpa coigeartuithe fíneáil. Mar shampla de mhionchoigeartú: tá srianta ag ár gcásanna ar naisc tcp, rud nach féidir, ar an drochuair, a dhéanamh san RDS:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
Ina theannta sin, tá AWS RDS beagnach dhá uair chomh costasach leis an bpraghas ásc rialta, agus ba é sin an phríomhchúis leis an réiteach seo a thréigean.
Pátrúin
Teimpléad python é seo chun PostgreSQL a bhainistiú le doiciméadú maith, teip ar ais go huathoibríoch agus cód foinse ar github.
Buntáistí Patroni:
- Déantar cur síos ar gach paraiméadar cumraíochta, tá sé soiléir conas a oibríonn sé;
- Oibríonn teip uathoibríoch amach as an mbosca;
- Scríofa i python, agus ós rud é go scríobhann muid féin go leor i python, beidh sé níos éasca dúinn chun déileáil le fadhbanna agus, b'fhéidir, fiú cabhrú le forbairt an tionscadail;
- Bainistíonn PostgreSQL go hiomlán, ligeann duit an chumraíocht ar gach nóid den bhraisle a athrú ag an am céanna, agus más gá an braisle a atosú chun an chumraíocht nua a chur i bhfeidhm, is féidir é seo a dhéanamh arís ag baint úsáide as Patroni.
CONS:
- Níl sé soiléir ó na doiciméid conas oibriú i gceart le PgBouncer. Cé go bhfuil sé deacair lúide a thabhairt air, toisc gurb é tasc Patroni PostgreSQL a bhainistiú, agus is é an fhadhb atá againn cheana féin conas a rachaidh naisc le Patroni;
- Is beag samplaí de chur i bhfeidhm Patroni ar líon mór, cé go bhfuil go leor samplaí de chur i bhfeidhm ón tús.
Mar thoradh air sin, roghnaigh muid Patroni chun braisle failover a chruthú.
Próiseas Forfheidhmithe Patroni
Roimh Patroni, bhí 12 shards PostgreSQL againn i gcumraíocht de mháistir amháin agus macasamhail amháin le macasamhlú asincrónach. Fuair na freastalaithe feidhmchláir rochtain ar na bunachair shonraí tríd an Líonra Luchtaithe Balancer, taobh thiar de a raibh dhá chás le PgBouncer, agus taobh thiar dóibh bhí na freastalaithe PostgreSQL go léir.
Chun Patroni a chur i bhfeidhm, bhí orainn cumraíocht braisle stórála dáilte a roghnú. Oibríonn Patroni le córais stórála cumraíochta dáilte ar nós srld, Zookeeper, Consal. Níl ach braisle Consal lán-chuimsitheach againn ar an margadh, a oibríonn i gcomhar le Vault agus ní úsáidimid é a thuilleadh. Cúis iontach le tosú ag baint úsáide as Consal dá chuspóir beartaithe.
Conas a oibríonn Patroni le Consal
Tá cnuasach Consal againn, atá comhdhéanta de thrí nód, agus cnuasach Patroni, atá comhdhéanta de cheannaire agus macasamhail (i Patroni, tugtar an ceannaire braisle ar an máistir, agus tugtar macasamhla ar na sclábhaithe). Cuireann gach cás de bhraisle Patroni faisnéis faoi staid an bhraisle chuig an gConsal i gcónaí. Mar sin, ó Chonsal is féidir leat a fháil amach i gcónaí cumraíocht reatha bhraisle Patroni agus cé hé an ceannaire i láthair na huaire.
Chun Patroni a nascadh leis an gConsal, is leor staidéar a dhéanamh ar an gcáipéisíocht oifigiúil, a deir go gcaithfidh tú óstach a shonrú san fhormáid http nó https, ag brath ar an gcaoi a n-oibrímid le Consal, agus an scéim nasctha, go roghnach:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpBreathnaíonn sé simplí, ach anseo a thosaíonn na gaistí. Le Consal, oibrímid thar nasc slán trí https agus beidh cuma mar seo ar ár gcumraíocht naisc:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Ach ní oibríonn sé sin. Ag am tosaithe, ní féidir le Patroni ceangal leis an gConsal, mar déanann sé iarracht dul trí http ar aon nós.
Chuidigh cód foinse Patroni chun déileáil leis an bhfadhb. Dea-rud go bhfuil sé scríofa i python. Tarlaíonn sé nach ndéantar paraiméadar an ósta a pharsáil ar bhealach ar bith, agus ní mór an prótacal a shonrú sa scéim. Seo mar atá an bloc cumraíochta oibre le haghaidh oibriú le Consal cosúil dúinne:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}consal-teimpléad
Mar sin, roghnaigh muid an stóráil don chumraíocht. Anois ní mór dúinn a thuiscint conas a athróidh PgBouncer a chumraíocht agus an ceannaire i mbraisle Patroni á athrú. Níl aon fhreagra ar an gceist seo sa doiciméadú, mar gheall ar. ann, i bprionsabal, ní dhéantar cur síos ar an obair le PgBouncer.
Agus réiteach á lorg againn, fuaireamar alt (ar an drochuair ní cuimhin liom an teideal) inar scríobhadh gur chuidigh Сonsul-template go mór le PgBouncer agus Patroni a phéireáil. Spreag sé seo sinn chun iniúchadh a dhéanamh ar conas a oibríonn Consal-template.
Tharla sé go ndéanann Consal-template monatóireacht leanúnach ar chumraíocht bhraisle PostgreSQL sa Chonsal. Nuair a athraíonn an ceannaire, déanann sé an chumraíocht PgBouncer a nuashonrú agus cuireann sé ordú chun é a athlódáil.
Buntáiste mór an teimpléid ná go bhfuil sé stóráilte mar chód, mar sin nuair a chuirtear shard nua leis, is leor gealltanas nua a dhéanamh agus an teimpléad a nuashonrú go huathoibríoch, ag tacú leis an mBonneagar mar phrionsabal an chóid.
Ailtireacht nua le Patroni
Mar thoradh air sin, fuaireamar an scéim oibre seo a leanas:
Faigheann gach freastalaí feidhmchláir rochtain ar an balancer → tá dhá chás de PgBouncer taobh thiar dó → ar gach cás, seoltar Consal-teimpléad, a dhéanann monatóireacht ar stádas gach braisle Patroni agus a dhéanann monatóireacht ar ábharthacht an chumraíocht PgBouncer, a sheolann iarratais chuig an gceannaire reatha de gach braisle.
Tástáil láimhe
Reáchtáileamar an scéim seo sular seoladh í ar thimpeallacht bheag tástála agus rinneamar seiceáil ar oibriú an aistrithe uathoibríoch. D’oscail siad an clár, bhog siad an greamán, agus ag an nóiméad sin “mharaigh” siad ceannaire an bhraisle. In AWS, tá sé seo chomh simplí leis an sampla a dhúnadh tríd an consól.
D'fhill an greamán ar ais laistigh de 10-20 soicind, agus ansin thosaigh sé ag bogadh de ghnáth arís. Ciallaíonn sé seo gur oibrigh braisle Patroni i gceart: d’athraigh sé an ceannaire, chuir sé an fhaisnéis chuig Сonsul, agus phioc Сonsul-template an fhaisnéis seo láithreach, chuir sé cumraíocht PgBouncer in ionad agus chuir sé an t-ordú chun athlódáil.
Conas maireachtáil faoi ualach ard agus an downtime a choinneáil íosta?
Oibríonn gach rud go foirfe! Ach tá ceisteanna nua ann: Conas a oibreoidh sé faoi ualach ard? Conas gach rud i dtáirgeadh a rolladh amach go tapa agus go sábháilte?
Cuidíonn an timpeallacht tástála ar a ndéanaimid tástáil ualaigh linn an chéad cheist a fhreagairt. Tá sé go hiomlán comhionann le táirgeadh i dtéarmaí ailtireachta agus tá sonraí tástála ginte aige atá comhionann beagnach ó thaobh toirte le táirgeadh. Déanaimid cinneadh gan ach duine de na máistrí PostgreSQL a “mharú” le linn na tástála agus féach cad a tharlaíonn. Ach roimhe sin, tá sé tábhachtach an rollta uathoibríoch a sheiceáil, mar gheall ar an timpeallacht seo tá roinnt shards PostgreSQL againn, agus mar sin gheobhaidh muid tástáil den scoth ar scripteanna cumraíochta roimh tháirgeadh.
Breathnaíonn an dá thasc uaillmhianach, ach tá PostgreSQL 9.6 againn. An féidir linn a uasghrádú láithreach go 11.2?
Socraímid é a dhéanamh i 2 chéim: uasghrádú go 11.2 ar dtús, ansin Patroni a sheoladh.
Nuashonrú PostgreSQL
Chun an leagan PostgreSQL a nuashonrú go tapa, bain úsáid as an rogha -k, ina gcruthaítear naisc chrua ar dhiosca agus ní gá do shonraí a chóipeáil. Ar bhoinn 300-400 GB, tógann an nuashonrú 1 soicind.
Tá go leor shards againn, mar sin ní mór an nuashonrú a dhéanamh go huathoibríoch. Chun seo a dhéanamh, scríobhamar leabhar súgartha Ansible a láimhseálann an próiseas nuashonraithe iomlán dúinn:
/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='Tá sé tábhachtach a thabhairt faoi deara anseo, sula dtosaíonn tú ar an uasghrádú, ní mór duit é a dhéanamh leis an bparaiméadar --seiceáilchun a chinntiú gur féidir leat a uasghrádú. Déanann ár script freisin configs a ionadú ar feadh ré an uasghrádaithe. Chríochnaigh ár script i 30 soicind, agus is toradh iontach é sin.
Seoladh Patroni
Chun an dara fadhb a réiteach, níl le déanamh ach breathnú ar chumraíocht Patroni. Tá cumraíocht shamplach ag an stór oifigiúil le initdb, atá freagrach as bunachar sonraí nua a thosú nuair a thosaíonn tú Patroni ar dtús. Ach ós rud é go bhfuil bunachar sonraí réidh againn cheana féin, ní raibh ach an chuid seo bainte den chumraíocht againn.
Nuair a thosaigh muid ag suiteáil Patroni ar bhraisle PostgreSQL a bhí ann cheana féin agus á rith, bhí fadhb nua againn: thosaigh an dá fhreastalaí mar cheannaire. Níl aon rud ar eolas ag Patroni faoi staid luath an bhraisle agus déanann sé iarracht an dá fhreastalaí a thosú mar dhá bhraisle ar leith leis an ainm céanna. Chun an fhadhb seo a réiteach, ní mór duit an t-eolaire a scriosadh le sonraí ar an sclábhaí:
rm -rf /var/lib/postgresql/Ní mór é seo a dhéanamh ach amháin ar an daor!
Nuair a bhíonn macasamhail glan ceangailte, déanann Patroni ceannaire basebackup agus cuireann sé ar ais go dtí an macasamhail é, agus ansin glacann sé suas leis an staid reatha de réir na logaí balla.
Deacracht eile a bhí againn ná go n-ainmnítear príomhchnuasaigh PostgreSQL de réir réamhshocraithe. Nuair nach mbíonn aon rud ar eolas ag gach braisle faoin gceann eile, is gnách é seo. Ach nuair is mian leat Patroni a úsáid, ansin caithfidh ainm uathúil a bheith ag gach braisle. Is é an réiteach ná an t-ainm braisle a athrú i gcumraíocht PostgreSQL.
tástáil ualach
Tá tástáil seolta againn a shamhlaíonn taithí úsáideora ar chláir. Nuair a shroich an t-ualach ár meánluach laethúil, rinneamar an tástáil chéanna arís agus arís eile, chuamar as cás amháin le ceannaire PostgreSQL. D'oibrigh an teip uathoibríoch mar a bhí súil againn: d'athraigh Patroni an ceannaire, nuashonraigh Consal-teimpléad an chumraíocht PgBouncer agus chuir sé ordú chun athlódáil. De réir ár ngraif i Grafana, ba léir go bhfuil moill 20-30 soicind agus méid beag earráidí ó na freastalaithe a bhaineann leis an nasc leis an mbunachar sonraí. Is gnáthchás é seo, tá luachanna den sórt sin inghlactha le haghaidh ár teipeanna agus is cinnte go bhfuil siad níos fearr ná an t-am aga seirbhíse.
Patroni a thabhairt chuig táirgeadh
Mar thoradh air sin, tháinig muid suas leis an bplean seo a leanas:
- Teimpléad Consal a imscaradh chuig freastalaithe PgBouncer agus seoladh;
- Nuashonruithe PostgreSQL go leagan 11.2;
- Athraigh ainm an bhraisle;
- Ag cur tús le Braisle Patroni.
Ag an am céanna, ligeann ár scéim dúinn an chéad phointe a dhéanamh beagnach ag am ar bith, is féidir linn gach PgBouncer a bhaint as an obair ar a seal agus teimpléad consal a imscaradh agus a reáchtáil air. Mar sin rinne muid.
Le haghaidh imscaradh tapa, d'úsáideamar Ansible, ós rud é go bhfuil tástáil déanta againn ar na leabhair súgartha go léir ar thimpeallacht tástála cheana féin, agus bhí am forghníomhaithe na scripte iomlán ó 1,5 go 2 nóiméad do gach shard. D'fhéadfaimis gach rud a rolladh amach ar a seal chuig gach shard gan stop a chur lenár seirbhís, ach bheadh orainn gach PostgreSQL a mhúchadh ar feadh roinnt nóiméad. Sa chás seo, ní fhéadfadh úsáideoirí a bhfuil a gcuid sonraí ar an shard seo oibriú go hiomlán ag an am seo, agus tá sé seo do-ghlactha dúinn.
Ba é an bealach amach as an staid seo ná an chothabháil phleanáilte, a dhéantar gach 3 mhí. Is fuinneog é seo don obair sceidealaithe, nuair a dhúnaimid ár seirbhís go hiomlán agus nuair a uasghrádaímid ár gcásanna bunachair shonraí. Bhí seachtain amháin fágtha go dtí an chéad fhuinneog eile, agus shocraigh muid gan ach fanacht agus tuilleadh ullmhúcháin a dhéanamh. Le linn an ama feithimh, rinneamar slán freisin: do gach shard PostgreSQL, d'ardaigh muid macasamhail breise i gcás teipe na sonraí is déanaí a choinneáil, agus chuireamar cás nua le haghaidh gach shard, ba cheart a bheith ina macasamhail nua i mbraisle Patroni, ionas nach ndéanfar ordú chun sonraí a scriosadh . Chuidigh sé seo go léir leis an riosca earráide a íoslaghdú.
D'atosaigh muid ár seirbhís, d'oibrigh gach rud mar ba chóir, lean úsáideoirí ag obair, ach ar na graif thugamar faoi deara ualach thar a bheith ard ar na freastalaithe Consal.
Cén fáth nach bhfaca muid é seo sa timpeallacht tástála? Léiríonn an fhadhb seo go han-mhaith gur gá an Bonneagar a leanúint mar phrionsabal an chóid agus an bonneagar iomlán a bheachtú, ó thimpeallachtaí tástála go dtí táirgeadh. Seachas sin, tá sé an-éasca an fhadhb a fuair muid a fháil. Cad a tharla? Chonsal le feiceáil ar dtús ar tháirgeadh, agus ansin ar thimpeallachtaí tástála, mar thoradh air sin, ar thimpeallachtaí tástála, bhí an leagan Consal níos airde ná ar tháirgeadh. Díreach i gceann de na heisiúintí, réitíodh sceitheadh LAP agus é ag obair le teimpléad consal. Dá bhrí sin, rinneamar nuashonrú simplí ar Chonsal, agus mar sin an fhadhb a réiteach.
Atosaigh braisle Patroni
Mar sin féin, fuaireamar fadhb nua, rud nach raibh amhras orainn fiú. Agus an Consal á nuashonrú, ní dhéanaimid ach an nód Consal a bhaint as an mbraisle ag baint úsáide as an ordú saoire consal → nascann Patroni le freastalaí Consal eile → oibríonn gach rud. Ach nuair a shroicheamar an áit dheireanach den bhraisle Consal agus nuair a chuireamar an t-ordú saoire consal chuige, d’atosaigh gach braisle Patroni go simplí, agus sna logaí chonaiceamar an earráid seo a leanas:
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>Ní raibh cnuasach Patroni in ann faisnéis a fháil faoina bhraisle agus d’atosaíodh é.
Chun teacht ar réiteach, chuamar i dteagmháil le húdair Patroni trí cheist ar github. Mhol siad feabhsuithe ar ár gcomhaid chumraíochta:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Bhíomar in ann an fhadhb a mhacasamhlú ar thimpeallacht tástála agus rinneamar na roghanna seo a thástáil ann, ach ar an drochuair níor oibrigh siad.
Tá an fhadhb fós gan réiteach. Tá sé beartaithe againn na réitigh seo a leanas a thriail:
- Úsáid Gníomhaire Consal ar gach cás braisle Patroni;
- Deisigh an cheist sa chód.
Tuigimid cá háit a tharla an earráid: is dócha gurb é an fhadhb atá ann ná an teorainn ama réamhshocraithe a úsáid, rud nach ndéantar a shárú sa chomhad cumraíochta. Nuair a bhaintear an freastalaí Consal deireanach den bhraisle, bíonn an braisle Consal iomlán ar crochadh ar feadh níos mó ná soicind, mar gheall air seo, ní féidir le Patroni stádas an bhraisle a fháil agus atosóidh sé an braisle iomlán go hiomlán.
Ar ámharaí an tsaoil, níor thángamar ar a thuilleadh earráidí.
Torthaí úsáid Patroni
Tar éis seoladh rathúil Patroni, chuireamar macasamhail breise leis i ngach braisle. Anois tá cuma córam i ngach braisle: ceannaire amháin agus dhá mhacasamhail, mar líontán sábhála i gcás inchinn scoilte nuair a bhíonn athrú á dhéanamh.
Tá Patroni ag obair ar tháirgeadh le níos mó ná trí mhí. Le linn an ama seo, d'éirigh leis cabhrú linn cheana féin. Le déanaí, fuair ceannaire ceann de na braislí bás in AWS, d'oibrigh teip uathoibríoch agus lean úsáideoirí ag obair. Chomhlíon Patroni a phríomhthasc.
Achoimre bheag ar úsáid Patroni:
- Éascaíocht athruithe cumraíochta. Is leor an chumraíocht a athrú ar chás amháin agus tarraingeofar suas go dtí an braisle ar fad é. Má tá gá le atosaigh chun an chumraíocht nua a chur i bhfeidhm, cuirfidh Patroni in iúl duit. Is féidir le Patroni an braisle iomlán a atosú le hordú amháin, atá an-áisiúil freisin.
- Oibríonn teip uathoibríoch agus d'éirigh leis cabhrú linn cheana féin.
- Nuashonrú PostgreSQL gan aga neamhfhónaimh feidhmchláir. Ní mór duit na macasamhla a nuashonrú go dtí an leagan nua ar dtús, ansin an ceannaire sa bhraisle Patroni a athrú agus an seancheannaire a nuashonrú. Sa chás seo, tarlaíonn an tástáil riachtanach ar theipeann uathoibríoch.
Foinse: will.com