Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Anns an artaigil innsidh mi dhut mar a dhèilig sinn ri cùis fulangas locht PostgreSQL, carson a dh’ fhàs e cudromach dhuinn agus dè thachair aig a ’cheann thall.

Tha seirbheis làn luchdaichte againn: 2,5 millean neach-cleachdaidh air feadh an t-saoghail, 50K+ neach-cleachdaidh gnìomhach gach latha. Tha na frithealaichean suidhichte ann an Amazone ann an aon roinn de Èirinn: tha 100+ frithealaiche eadar-dhealaichte an-còmhnaidh ag obair, agus tha faisg air 50 dhiubh le stòran-dàta.

Tha an backend gu lèir na thagradh Java stàiteil monolithic mòr a chumas ceangal cunbhalach websocket ris an neach-dèiligidh. Nuair a bhios grunn luchd-cleachdaidh ag obair air an aon bhòrd aig an aon àm, bidh iad uile a 'faicinn nan atharrachaidhean ann an àm fìor, oir bidh sinn a' sgrìobhadh gach atharrachadh air an stòr-dàta. Tha timcheall air 10K iarrtas gach diog gu ar stòran-dàta. Aig an ìre as àirde ann an Redis, bidh sinn a’ sgrìobhadh 80-100K iarrtasan gach diog.
Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Carson a thionndaidh sinn bho Redis gu PostgreSQL

An toiseach, bha an t-seirbheis againn ag obair còmhla ri Redis, stòr le prìomh luach a bhios a’ stòradh a h-uile dàta ann an RAM an fhrithealaiche.

Buannachdan Redis:

  1. Àrd-astar freagairt, air sgàth tha a h-uile dad air a stòradh ann an cuimhne;
  2. Furasta cùl-taic agus ath-riochdachadh.

Cons of Redis dhuinne:

  1. Chan eil fìor ghnothaichean ann. Dh’ fheuch sinn ri atharrais orra aig ìre an tagraidh againn. Gu mì-fhortanach, cha robh seo daonnan ag obair gu math agus dh'fheumadh e còd fìor iom-fhillte a sgrìobhadh.
  2. Tha an àireamh de dhàta air a chuingealachadh leis an ìre de chuimhne. Mar a bhios an àireamh de dhàta a’ dol am meud, fàsaidh an cuimhne, agus, aig a’ cheann thall, ruithidh sinn a-steach do fheartan an t-eisimpleir a chaidh a thaghadh, a dh’ fheumas ann an AWS stad a chuir air ar seirbheis gus an seòrsa eisimpleir atharrachadh.
  3. Feumar ìre latency ìosal a chumail gu cunbhalach, oir. tha àireamh mhòr de dh'iarrtasan againn. Is e an ìre dàil as fheàrr dhuinn 17-20 ms. Aig ìre 30-40 ms, gheibh sinn freagairtean fada do dh'iarrtasan bhon iarrtas againn agus truailleadh na seirbheis. Gu mì-fhortanach, thachair seo dhuinn san t-Sultain 2018, nuair a fhuair aon de na cùisean le Redis airson adhbhar air choireigin latency 2 tursan nas motha na an àbhaist. Gus a’ chùis fhuasgladh, chuir sinn stad air an t-seirbheis meadhan-latha airson cumail suas neo-eagraichte agus chuir sinn an àite an duilgheadas Redis eisimpleir.
  4. Tha e furasta neo-chunbhalachd dàta fhaighinn eadhon le mearachdan beaga sa chòd agus an uairsin cuir seachad tòrr ùine a’ sgrìobhadh còd gus an dàta seo a cheartachadh.

Thug sinn aire do na h-eas-bhuannachdan agus thuig sinn gum feumadh sinn gluasad gu rudeigin nas goireasaiche, le gnothaichean àbhaisteach agus nas lugha an urra ri latency. Rinn mi rannsachadh, rinn mi mion-sgrùdadh air mòran roghainnean agus thagh mi PostgreSQL.

Tha sinn air a bhith a’ gluasad gu stòr-dàta ùr airson 1,5 bliadhna mar-thà agus cha do ghluais sinn ach pàirt bheag den dàta, agus mar sin a-nis tha sinn ag obair aig an aon àm le Redis agus PostgreSQL. Tha barrachd fiosrachaidh mu na h-ìrean de ghluasad agus atharrachadh dàta eadar stòran-dàta air a sgrìobhadh a-steach artaigil mo cho-obraiche.

Nuair a thòisich sinn a’ gluasad an toiseach, dh’ obraich an tagradh againn gu dìreach leis an stòr-dàta agus fhuair sinn cothrom air a’ mhaighstir Redis agus PostgreSQL. Anns a’ bhuidheann PostgreSQL bha maighstir agus mac-samhail le mac-samhail asyncronach. Seo mar a bha sgeama an stòr-dàta coltach:
Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

A' cur an gnìomh PgBouncer

Fhad ‘s a bha sinn a’ gluasad, bha an toradh cuideachd a ’leasachadh: mheudaich an àireamh de luchd-cleachdaidh agus an àireamh de luchd-frithealaidh a bha ag obair le PostgreSQL, agus thòisich sinn air dìth cheanglaichean. Bidh PostgreSQL a’ cruthachadh pròiseas air leth airson gach ceangal agus a’ caitheamh ghoireasan. Faodaidh tu an àireamh de cheanglaichean àrdachadh gu ìre sònraichte, air neo bidh cothrom ann coileanadh stòr-dàta suboptimal fhaighinn. Is e an roghainn as fheàrr ann an suidheachadh mar sin manaidsear ceangail a thaghadh a sheasas air beulaibh a’ bhunait.

Bha dà roghainn againn airson a’ mhanaidsear ceangail: Pgpool agus PgBouncer. Ach chan eil a’ chiad fhear a’ toirt taic don mhodh obrachaidh a bhith ag obair leis an stòr-dàta, agus mar sin thagh sinn PgBouncer.

Tha sinn air an sgeama obrach a leanas a stèidheachadh: tha an tagradh againn a’ faighinn cothrom air aon PgBouncer, air a chùlaibh tha maighstirean PostgreSQL, agus air cùl gach maighstir tha aon mac-samhail le mac-samhail asyncronach.
Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Aig an aon àm, cha b 'urrainn dhuinn an dàta gu lèir a stòradh ann am PostgreSQL agus bha astar a bhith ag obair leis an stòr-dàta cudromach dhuinn, agus mar sin thòisich sinn a' roinneadh PostgreSQL aig ìre an tagraidh. Tha an sgeama a tha air a mhìneachadh gu h-àrd gu ìre mhath goireasach airson seo: nuair a chuireas tu shard PostgreSQL ùr ris, tha e gu leòr an rèiteachadh PgBouncer ùrachadh agus faodaidh an aplacaid obrachadh leis a’ shard ùr sa bhad.

Dh'fhàillig PgBouncer

Dh’obraich an sgeama seo gus an do chaochail an aon eisimpleir PgBouncer. Tha sinn ann an AWS, far a bheil a h-uile suidheachadh a’ ruith air bathar-cruaidh a gheibh bàs bho àm gu àm. Ann an leithid de chùisean, bidh an eisimpleir dìreach a’ gluasad gu bathar-cruaidh ùr agus ag obair a-rithist. Thachair seo le PgBouncer, ach cha robh e ri fhaighinn. B’ e toradh an tuiteam seo nach robh an t-seirbheis againn ri fhaighinn airson 25 mionaidean. Tha AWS a’ moladh a bhith a’ cleachdadh call dreuchd taobh luchd-cleachdaidh airson suidheachaidhean mar sin, nach deach a chuir an gnìomh san dùthaich againn aig an àm sin.

Às deidh sin, smaoinich sinn gu mòr air fulangas lochdan cruinneachaidhean PgBouncer agus PostgreSQL, oir dh’ fhaodadh suidheachadh coltach ris tachairt le suidheachadh sam bith nar cunntas AWS.

Thog sinn an sgeama fulangas lochdan PgBouncer mar a leanas: bidh gach seirbheisiche tagraidh a’ faighinn cothrom air Network Load Balancer, agus air a chùlaibh tha dà PgBouncers. Bidh gach PgBouncer a’ coimhead air an aon mhaighstir PostgreSQL de gach shard. Ma thachras tubaist eisimpleir AWS a-rithist, thèid an trafaic gu lèir ath-stiùireadh tro PgBouncer eile. Tha fàilligeadh Network Load Balancer air a thoirt seachad le AWS.

Tha an sgeama seo ga dhèanamh furasta frithealaichean PgBouncer ùra a chur ris.
Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Cruthaich Buidheann Failover PostgreSQL

Nuair a bha sinn a’ fuasgladh na trioblaid seo, bheachdaich sinn air diofar roghainnean: failover fèin-sgrìobhte, repmgr, AWS RDS, Patroni.

Sgriobtaichean fèin-sgrìobhte

Faodaidh iad sùil a chumail air obair a’ mhaighstir agus, ma dh’ fhailicheas e, cuir am mac-samhail air adhart chun mhaighstir agus an rèiteachadh PgBouncer ùrachadh.

Is e buannachdan an dòigh-obrach seo an sìmplidheachd as motha, oir bidh thu a’ sgrìobhadh sgriobtaichean thu fhèin agus a’ tuigsinn gu dìreach mar a tha iad ag obair.

Cons:

  • Is dòcha nach robh am maighstir air bàsachadh, an àite sin is dòcha gu robh fàilligeadh lìonra air tachairt. Bidh fàiligeadh, gun fhios air seo, ag adhartachadh mac-samhail don mhaighstir, fhad ‘s a chumas an seann mhaighstir ag obair. Mar thoradh air an sin, gheibh sinn dà sheirbheisiche ann an dreuchd maighstir agus cha bhi fios againn cò dhiubh aig a bheil an dàta as ùire. Canar split-brain ris an t-suidheachadh seo cuideachd;
  • Dh'fhàgadh sinn gun fhreagairt. Anns an rèiteachadh againn, am maighstir agus aon mac-samhail, às deidh atharrachadh, gluaisidh am mac-samhail suas chun mhaighstir agus chan eil mac-samhail againn tuilleadh, agus mar sin feumaidh sinn mac-samhail ùr a chuir ris le làimh;
  • Feumaidh sinn sgrùdadh a bharrachd air an obair fàiligeadh, fhad ‘s a tha 12 shards PostgreSQL againn, a tha a’ ciallachadh gum feum sinn sùil a chumail air 12 cruinneachaidhean. Le àrdachadh anns an àireamh de shards, feumaidh tu cuideachd cuimhneachadh gun ùraich thu an teip.

Tha fàilligeadh fèin-sgrìobhte a’ coimhead gu math toinnte agus feumach air taic nach eil cho beag. Le aon bhuidheann PostgreSQL, bhiodh seo mar an roghainn as fhasa, ach chan eil e a’ sgèile, agus mar sin chan eil e freagarrach dhuinn.

Repmgr

Manaidsear ath-riochdachadh airson cruinneachaidhean PostgreSQL, as urrainn obrachadh buidheann PostgreSQL a riaghladh. Aig an aon àm, chan eil fàiligeadh fèin-ghluasadach a-mach às a’ bhogsa, agus mar sin airson obair feumaidh tu an “còmhdaiche” agad fhèin a sgrìobhadh air mullach an fhuasglaidh chrìochnaichte. Mar sin faodaidh a h-uile dad tionndadh a-mach eadhon nas toinnte na le sgriobtaichean fèin-sgrìobhte, agus mar sin cha do dh’ fheuch sinn eadhon ri Repmgr.

AWS RDS

A’ toirt taic do na tha a dhìth oirnn, eòlach air mar a nì thu cùl-taic agus a’ cumail suas cruinneachadh de cheanglaichean. Tha tionndadh fèin-ghluasadach aige: nuair a gheibh am maighstir bàs, bidh am mac-samhail na mhaighstir ùr, agus bidh AWS ag atharrachadh a’ chlàr dns chun mhaighstir ùr, agus faodar na mac-samhail a lorg ann an diofar AZ.

Tha eas-bhuannachdan a’ toirt a-steach dìth rèiteachaidhean grinn. Mar eisimpleir de ghleusadh grinn: tha cuingealachaidhean aig na h-eisimpleirean againn airson ceanglaichean tcp, nach gabh, gu mì-fhortanach, a dhèanamh ann an RDS:

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

A bharrachd air an sin, tha AWS RDS cha mhòr dà uair cho daor ris a’ phrìs àbhaisteach àbhaisteach, agus b’ e sin am prìomh adhbhar airson am fuasgladh seo a thrèigsinn.

Pàtran

Is e seo teamplaid python airson PostgreSQL a riaghladh le deagh sgrìobhainnean, fàilligeadh fèin-ghluasadach agus còd stòr air github.

Nithean matha Patroni:

  • Tha gach paramadair rèiteachaidh air a mhìneachadh, tha e soilleir mar a tha e ag obair;
  • Bidh fàilligeadh fèin-ghluasadach ag obair a-mach às a’ bhogsa;
  • Sgrìobhte ann am python, agus leis gu bheil sinn fhìn a’ sgrìobhadh tòrr ann am python, bidh e nas fhasa dhuinn dèiligeadh ri duilgheadasan agus, is dòcha, eadhon cuideachadh le leasachadh a’ phròiseict;
  • A’ riaghladh PostgreSQL gu h-iomlan, a’ leigeil leat an rèiteachadh atharrachadh air a h-uile nod den bhuidheann aig an aon àm, agus ma dh’ fheumar am brabhsair ath-thòiseachadh gus an rèiteachadh ùr a chuir an sàs, faodar seo a dhèanamh a-rithist le bhith a’ cleachdadh Patroni.

Cons:

  • Chan eil e soilleir bho na sgrìobhainnean ciamar a dh’ obraicheas tu gu ceart le PgBouncer. Ged a tha e duilich a ràdh gu bheil e nas lugha, oir is e obair Patroni PostgreSQL a riaghladh, agus mar a thèid ceanglaichean ri Patroni mar-thà na dhuilgheadas dhuinn;
  • Chan eil mòran eisimpleirean ann de bhuileachadh Patroni air meudan mòra, agus tha mòran eisimpleirean ann de bhuileachadh bhon fhìor thoiseach.

Mar thoradh air an sin, thagh sinn Patroni gus cruinneachadh fàilligeadh a chruthachadh.

Pròiseas Gnìomhachaidh Patroni

Ro Patroni, bha 12 shards PostgreSQL againn ann an rèiteachadh aon mhaighstir agus aon mac-samhail le mac-samhail asyncronach. Fhuair na frithealaichean tagraidh cothrom air na stòran-dàta tron ​​Network Load Balancer, air a chùlaibh bha dà shuidheachadh le PgBouncer, agus air an cùlaibh bha na frithealaichean PostgreSQL uile.
Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Gus Patroni a chuir an gnìomh, dh'fheumadh sinn rèiteachadh brabhsair stòraidh sgaoilte a thaghadh. Bidh Patroni ag obair le siostaman stòraidh rèiteachaidh sgaoilte leithid msaa, Zookeeper, Consul. Tha dìreach cruinneachadh Consail làn-chuimseach againn air a’ mhargaidh, a bhios ag obair ann an co-bhonn le Vault agus cha bhith sinn ga chleachdadh tuilleadh. Deagh adhbhar airson tòiseachadh air Consul a chleachdadh airson an adhbhar a tha san amharc.

Mar a tha Patroni ag obair le Consul

Tha buidheann Consul againn, anns a bheil trì nodan, agus buidheann de Patroni, anns a bheil stiùiriche agus mac-samhail (ann am Patroni, canar ceannard na buidhne ris a’ mhaighstir, agus canar mac-samhail ris na tràillean). Bidh a h-uile eisimpleir de bhuidheann Patroni an-còmhnaidh a’ cur fiosrachadh mu staid a’ bhuidheann chun Chonsal. Mar sin, bhon Consul faodaidh tu an-còmhnaidh faighinn a-mach an rèiteachadh gnàthach de bhuidheann Patroni agus cò a tha na stiùiriche an-dràsta.

Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Gus Patroni a cheangal ri Consul, tha e gu leòr sgrùdadh a dhèanamh air na sgrìobhainnean oifigeil, a tha ag ràdh gum feum thu aoigheachd a shònrachadh ann an cruth http no https, a rèir mar a bhios sinn ag obair le Consul, agus an sgeama ceangail, gu roghnach:

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

Tha e a 'coimhead sìmplidh, ach an seo tha na duilgheadasan a' tòiseachadh. Le Consul, bidh sinn ag obair thairis air ceangal tèarainte tro https agus seallaidh an rèiteachadh ceangail againn mar seo:

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

Ach chan eil sin ag obair. Aig toiseach tòiseachaidh, chan urrainn dha Patroni ceangal a dhèanamh ris a’ Chonsal, oir bidh e a’ feuchainn ri dhol tro http co-dhiù.

Chuidich còd stòr Patroni gus dèiligeadh ris an duilgheadas. Deagh rud a tha e sgrìobhte ann am python. Tha e a 'tionndadh a-mach nach eil am paramadair aoigheachd air a pharsadh ann an dòigh sam bith, agus feumaidh am protocol a bhith air a shònrachadh san sgeama. Seo mar a tha am bloc rèiteachaidh obrach airson a bhith ag obair le Consul coltach dhuinne:

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

consul-template

Mar sin, tha sinn air an stòradh a thaghadh airson an rèiteachadh. A-nis feumaidh sinn tuigsinn mar a dh’ atharraicheas PgBouncer an rèiteachadh aige nuair a dh’ atharraicheas sinn an stiùiriche ann am brabhsair Patroni. Chan eil freagairt sam bith don cheist seo anns na sgrìobhainnean, oir. an sin, ann am prionnsabal, chan eil iomradh air obair le PgBouncer.

A’ lorg fuasgladh, lorg sinn artaigil (gu mì-fhortanach chan eil cuimhne agam air an tiotal) far an deach a sgrìobhadh gun do chuidich teamplaid Сonsul gu mòr ann a bhith a’ càradh PgBouncer agus Patroni. Bhrosnaich seo sinn gus sgrùdadh a dhèanamh air mar a tha Consul-template ag obair.

Thionndaidh e a-mach gu bheil teamplaid Consul an-còmhnaidh a ’cumail sùil air rèiteachadh cruinneachadh PostgreSQL ann an Consul. Nuair a dh'atharraicheas an stiùiriche, bidh e ag ùrachadh rèiteachadh PgBouncer agus a 'cur òrdugh airson ath-luchdachadh.

Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Is e buannachd mhòr de theamplaid gu bheil e air a stòradh mar chòd, agus mar sin nuair a chuireas tu shard ùr ris, tha e gu leòr gealltanas ùr a dhèanamh agus an teamplaid ùrachadh gu fèin-ghluasadach, a’ toirt taic don Bhun-structar mar phrionnsapal còd.

Ailtireachd ùr le Patroni

Mar thoradh air an sin, fhuair sinn an sgeama obrach a leanas:
Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Bidh a h-uile seirbheisiche tagraidh a’ faighinn cothrom air a ’chothromachadh → tha dà eisimpleir de PgBouncer air a chùlaibh → air gach suidheachadh, thèid teamplaid Consul a chuir air bhog, a bhios a’ cumail sùil air inbhe gach cruinneachadh Patroni agus a ’cumail sùil air iomchaidheachd config PgBouncer, a chuireas iarrtasan chun stiùiriche gnàthach de gach buidheann.

Deuchainn làimhe

Ruith sinn an sgeama seo mus do chuir sinn air bhog e air àrainneachd deuchainn bheag agus rinn sinn sgrùdadh air gnìomhachd tionndadh fèin-ghluasadach. Dh'fhosgail iad am bòrd, ghluais iad am stiogair, agus aig an àm sin "mharbh iad" ceannard a 'bhratha. Ann an AWS, tha seo cho sìmplidh ri bhith a’ dùnadh an t-eisimpleir tron ​​​​chonsól.

Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Thill an stiogair air ais taobh a-staigh 10-20 diogan, agus an uairsin thòisich e a-rithist air gluasad gu h-àbhaisteach. Tha seo a’ ciallachadh gun do dh’obraich buidheann Patroni gu ceart: dh’ atharraich e an stiùiriche, chuir e am fiosrachadh gu Сonsul, agus thog Сonsul-template am fiosrachadh seo sa bhad, chuir e an àite rèiteachadh PgBouncer agus chuir e an òrdugh ath-luchdachadh.

Ciamar a mhaireas tu fo eallach àrd agus an ùine downt as ìsle a chumail?

Bidh a h-uile dad ag obair gu foirfe! Ach tha ceistean ùra ann: Ciamar a dh'obraicheas e fo luchd àrd? Ciamar a chuireas tu a-mach a h-uile càil ann an cinneasachadh gu sgiobalta agus gu sàbhailte?

Bidh an àrainneachd deuchainn air am bi sinn a’ dèanamh deuchainn luchdan gar cuideachadh gus a’ chiad cheist a fhreagairt. Tha e gu tur co-ionann ri cinneasachadh a thaobh ailtireachd agus tha e air dàta deuchainn a chruthachadh a tha timcheall air an aon ìre ri cinneasachadh. Bidh sinn a’ co-dhùnadh dìreach “marbhadh” aon de na maighstirean PostgreSQL rè an deuchainn agus faicinn dè thachras. Ach roimhe sin, tha e cudromach sgrùdadh a dhèanamh air an roiligeadh fèin-ghluasadach, oir air an àrainneachd seo tha grunn shards PostgreSQL againn, agus mar sin gheibh sinn deuchainn sàr-mhath air sgriobtaichean rèiteachaidh mus tèid an riochdachadh.

Tha coltas mòr-mhiannach air an dà ghnìomh, ach tha PostgreSQL 9.6 againn. An urrainn dhuinn àrdachadh gu 11.2 sa bhad?

Bidh sinn a’ co-dhùnadh a dhèanamh ann an ceumannan 2: an toiseach àrdaich gu 11.2, an uairsin cuir air bhog Patroni.

Ùrachadh luath air ìre PostgreSQL

Gus an tionndadh PostgreSQL ùrachadh gu sgiobalta, cleachd an roghainn -k, anns a bheil ceanglaichean cruaidh air an cruthachadh air diosc agus chan eil feum air lethbhreac a dhèanamh den dàta agad. Air bunaitean 300-400 GB, bheir an ùrachadh 1 diog.

Tha tòrr shards againn, agus mar sin feumar an ùrachadh a dhèanamh gu fèin-ghluasadach. Gus seo a dhèanamh, sgrìobh sinn leabhar-cluiche Ansible a làimhsicheas am pròiseas ùrachaidh gu lèir dhuinn:

/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='

Tha e cudromach cuimhneachadh an seo, mus tòisich thu air an ùrachadh, feumaidh tu a dhèanamh leis a’ pharamadair --seicgus dèanamh cinnteach gun urrainn dhut ùrachadh. Bidh an sgriobt againn cuideachd a’ toirt air configs a chuir an àite fad an ùrachaidh. Chrìochnaich an sgriobt againn ann an 30 diogan, a tha na thoradh math.

Cuir air bhog Patroni

Gus an dàrna duilgheadas fhuasgladh, dìreach thoir sùil air rèiteachadh Patroni. Tha eisimpleir de rèiteachadh aig an stòr oifigeil le initdb, a tha an urra ri stòr-dàta ùr a thòiseachadh nuair a thòisicheas tu air Patroni an toiseach. Ach leis gu bheil stòr-dàta deiseil againn mu thràth, tha sinn dìreach air an roinn seo a thoirt air falbh bhon rèiteachadh.

Nuair a thòisich sinn air Patroni a chuir a-steach air cruinneachadh PostgreSQL a bha ann mar-thà agus ga ruith, ruith sinn a-steach do dhuilgheadas ùr: thòisich an dà fhrithealaiche mar stiùiriche. Chan eil fios aig Patroni mu staid thràth a’ bhuidheann agus bidh i a’ feuchainn ris an dà sheirbheisiche a thòiseachadh mar dà bhuidheann fa leth leis an aon ainm. Gus an duilgheadas seo fhuasgladh, feumaidh tu an eòlaire a dhubhadh às le dàta mun tràill:

rm -rf /var/lib/postgresql/

Feumaidh seo a bhith air a dhèanamh a-mhàin air an tràill!

Nuair a tha mac-samhail glan ceangailte, bidh Patroni a’ dèanamh stiùiriche basebackup agus ga thoirt air ais don mhac-samhail, agus an uairsin a’ glacadh suas ris an t-suidheachadh làithreach a rèir nan logaichean balla.

Is e duilgheadas eile ris an do thachair sinn gu bheil a h-uile cruinneachaidhean PostgreSQL air an ainmeachadh prìomh gu bunaiteach. Nuair nach eil fios aig gach buidheann mun fhear eile, tha seo àbhaisteach. Ach nuair a tha thu airson Patroni a chleachdadh, feumaidh ainm sònraichte a bhith aig a h-uile buidheann. Is e am fuasgladh an t-ainm brabhsair atharrachadh ann an rèiteachadh PostgreSQL.

deuchainn luchd

Tha sinn air deuchainn a chuir air bhog a tha coltach ri eòlas luchd-cleachdaidh air bùird. Nuair a ràinig an luchd an luach làitheil cuibheasach againn, rinn sinn a-rithist an aon deuchainn, chuir sinn dheth aon eisimpleir le stiùiriche PostgreSQL. Dh’ obraich an teip fèin-ghluasadach mar a bha sinn an dùil: dh’ atharraich Patroni an stiùiriche, dh’ ùraich Consul-template an rèiteachadh PgBouncer agus chuir e òrdugh ath-luchdachadh. A rèir ar grafaichean ann an Grafana, bha e soilleir gu bheil dàil de 20-30 diogan agus àireamh bheag de mhearachdan bho na frithealaichean co-cheangailte ri ceangal ris an stòr-dàta. Is e suidheachadh àbhaisteach a tha seo, tha na luachan sin iomchaidh airson ar fàilligeadh agus gu cinnteach tha iad nas fheàrr na an ùine downt seirbheis.

A 'toirt Patroni gu riochdachadh

Mar thoradh air an sin, chruthaich sinn am plana a leanas:

  • Cleachd teamplaid Consul gu frithealaichean PgBouncer agus cuir air bhog;
  • Ùrachaidhean PostgreSQL gu dreach 11.2;
  • Atharraich ainm a 'chlàir;
  • A’ tòiseachadh air an Patroni Cluster.

Aig an aon àm, tha an sgeama againn a’ leigeil leinn a’ chiad phuing a dhèanamh cha mhòr aig àm sam bith, is urrainn dhuinn gach PgBouncer a thoirt air falbh bhon obair mu seach agus teamplaid consul a chleachdadh agus a ruith air. Mar sin rinn sinn.

Airson an cleachdadh gu sgiobalta, chleachd sinn Ansible, leis gu bheil sinn mu thràth air deuchainn a dhèanamh air na leabhraichean-cluiche gu lèir air àrainneachd deuchainn, agus bha ùine cur gu bàs an sgriobt slàn bho 1,5 gu 2 mionaidean airson gach shard. B’ urrainn dhuinn a h-uile càil a chuir a-mach aon às deidh aon gu gach shard gun stad a chuir air an t-seirbheis againn, ach dh’ fheumadh sinn gach PostgreSQL a chuir dheth airson grunn mhionaidean. Anns a 'chùis seo, cha b' urrainn do luchd-cleachdaidh aig a bheil dàta air a 'shard seo obrachadh gu h-iomlan aig an àm seo, agus tha seo neo-iomchaidh dhuinne.

B 'e an t-slighe a-mach às an t-suidheachadh seo an cumail suas dealbhaichte, a bhios a' tachairt a h-uile 3 mìosan. Is e uinneag a tha seo airson obair chlàraichte, nuair a dhùineas sinn ar seirbheis gu tur agus nuair a dh’ ùraicheas sinn ar suidheachaidhean stòr-dàta. Bha seachdain air fhàgail gus an ath uinneag, agus chuir sinn romhainn dìreach feitheamh agus ullachadh nas fhaide. Rè na h-ùine feitheimh, rinn sinn cinnteach cuideachd: airson gach shard PostgreSQL, thog sinn mac-samhail a bharrachd gun fhios nach cumar sinn air an dàta as ùire, agus chuir sinn eisimpleir ùr ris airson gach shard, a bu chòir a bhith na mac-samhail ùr ann am buidheann Patroni, gus nach cuir thu an gnìomh àithne airson dàta a sguabadh às. Chuidich seo uile gus an cunnart bho mhearachd a lughdachadh.
Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Thòisich sinn air an t-seirbheis againn a-rithist, dh’ obraich a h-uile càil mar a bu chòir, lean luchd-cleachdaidh ag obair, ach air na grafaichean mhothaich sinn eallach anabarrach àrd air na frithealaichean Consail.
Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Carson nach fhaca sinn seo san àrainneachd deuchainn? Tha an duilgheadas seo a’ nochdadh gu math gu bheil e riatanach am Bun-structair a leantainn mar phrionnsapal còd agus ùrachadh a dhèanamh air a’ bhun-structar gu lèir, bho àrainneachdan deuchainn gu cinneasachadh. Rud eile, tha e gu math furasta an duilgheadas a fhuair sinn fhaighinn. Dè a thachair? Nochd Consal an toiseach air cinneasachadh, agus an uairsin air àrainneachdan deuchainn, mar thoradh air an sin, air àrainneachdan deuchainn, bha an dreach de Consul nas àirde na ann an cinneasachadh. Dìreach ann an aon de na fiosan, chaidh aodion CPU fhuasgladh nuair a bha e ag obair le teamplaid consul. Mar sin, tha sinn dìreach air ùrachadh Consul, mar sin a 'fuasgladh na duilgheadas.

Ath-thòiseachadh cruinneachadh Patroni

Ach, fhuair sinn duilgheadas ùr, nach robh sinn eadhon fo amharas. Nuair a bhios sinn ag ùrachadh Consul, bidh sinn dìreach a’ toirt air falbh an nód Consul bhon bhuidheann a’ cleachdadh an àithne fàgail consul → Bidh Patroni a’ ceangal ri frithealaiche Consail eile → bidh a h-uile càil ag obair. Ach nuair a ràinig sinn an t-suidheachadh mu dheireadh den bhuidheann Consul agus a chuir sinn an àithne fòrladh consul thuige, thòisich a h-uile buidheann Patroni dìreach air ath-thòiseachadh, agus anns na logaichean chunnaic sinn a’ mhearachd 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>

Cha b’ urrainn do bhuidheann Patroni fiosrachadh fhaighinn air ais mun bhuidheann aca agus thòisich iad a-rithist.

Gus fuasgladh a lorg, chuir sinn fios gu ùghdaran Patroni tro chùis air github. Mhol iad leasachaidhean air na faidhlichean rèiteachaidh againn:

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

B' urrainn dhuinn an duilgheadas ath-aithris air àrainneachd deuchainn agus rinn sinn deuchainn air na roghainnean sin an sin, ach gu mì-fhortanach cha do dh'obraich iad.

Tha an duilgheadas fhathast gun fhuasgladh. Tha sinn an dùil feuchainn air na fuasglaidhean a leanas:

  • Cleachd Consul-àidseant air gach buidheann de Patroni eisimpleir;
  • Ceartaich a’ chùis sa chòd.

Tha sinn a’ tuigsinn far an do thachair a’ mhearachd: is dòcha gur e an duilgheadas a bhith a’ cleachdadh ùine-ama bunaiteach, nach eil air a chuir thairis tron ​​​​fhaidhle rèiteachaidh. Nuair a thèid am frithealaiche Consul mu dheireadh a thoirt a-mach às a’ bhuidheann, bidh an cruinneachadh Consul gu lèir a’ crochadh airson barrachd air diog, air sgàth seo, chan urrainn dha Patroni inbhe a’ bhuidheann fhaighinn agus ath-thòiseachadh a’ bhuidheann gu lèir gu tur.

Gu fortanach, cha do thachair sinn ri mearachdan sam bith eile.

Toraidhean bho bhith a’ cleachdadh Patroni

Às deidh Patroni a chuir air bhog gu soirbheachail, chuir sinn mac-samhail a bharrachd ris anns gach buidheann. A-nis anns gach buidheann tha coltas cuòram: aon stiùiriche agus dà mhac-samhail, airson lìon sàbhailteachd gun fhios nach bi eanchainn roinnte nuair a bhios tu ag atharrachadh.
Buidheann Failover PostgreSQL + Neach-taic. Eòlas buileachaidh

Tha Patroni air a bhith ag obair air cinneasachadh airson còrr air trì mìosan. Rè na h-ùine seo, tha e mar-thà air ar cuideachadh. O chionn ghoirid, bhàsaich ceannard aon de na cruinneachaidhean ann an AWS, dh’ obraich fàilligeadh fèin-ghluasadach agus lean luchd-cleachdaidh ag obair. Choilean Patroni a phrìomh obair.

Geàrr-chunntas beag air cleachdadh Patroni:

  • Furasta atharrachaidhean rèiteachaidh. Tha e gu leòr an rèiteachadh atharrachadh ann an aon eisimpleir agus thèid a tharraing suas chun bhuidheann gu lèir. Ma tha feum air ath-thòiseachadh gus an rèiteachadh ùr a chuir an sàs, leigidh Patroni fios dhut. Faodaidh Patroni an cruinneachadh gu lèir ath-thòiseachadh le aon àithne, a tha cuideachd gu math goireasach.
  • Bidh fàilligeadh fèin-ghluasadach ag obair agus tha e air ar cuideachadh mar-thà.
  • Ùrachadh PostgreSQL às aonais ùine downt tagraidh. Feumaidh tu an-toiseach na mac-samhail ùrachadh chun dreach ùr, an uairsin atharraich an stiùiriche ann am buidheann Patroni agus ùraich an seann stiùiriche. Anns a 'chùis seo, bidh an deuchainn riatanach air fàilligeadh fèin-ghluasadach a' tachairt.

Source: www.habr.com

Cuir beachd ann