Yn yr erthygl dywedaf wrthych sut yr aethom i'r afael â mater goddefgarwch namau PostgreSQL, pam y daeth yn bwysig i ni a beth ddigwyddodd yn y diwedd.
Mae gennym wasanaeth llawn llwyth: 2,5 miliwn o ddefnyddwyr ledled y byd, 50K+ o ddefnyddwyr gweithredol bob dydd. Mae'r gweinyddion wedi'u lleoli yn Amazone mewn un rhanbarth yn Iwerddon: mae 100+ o weinyddion gwahanol yn gweithio'n gyson, gyda bron i 50 ohonynt gyda chronfeydd data.
Mae'r ôl-wyneb cyfan yn gymhwysiad Java urddasol monolithig mawr sy'n cadw cysylltiad websoced cyson â'r cleient. Pan fydd sawl defnyddiwr yn gweithio ar yr un bwrdd ar yr un pryd, maen nhw i gyd yn gweld y newidiadau mewn amser real, oherwydd rydyn ni'n ysgrifennu pob newid i'r gronfa ddata. Mae gennym tua 10K o geisiadau yr eiliad i'n cronfeydd data. Ar y llwyth brig yn Redis, rydym yn ysgrifennu 80-100K o geisiadau yr eiliad.
Pam wnaethon ni newid o Redis i PostgreSQL
I ddechrau, bu ein gwasanaeth yn gweithio gyda Redis, storfa gwerth allweddol sy'n storio'r holl ddata yn RAM y gweinydd.
Manteision Redis:
- Cyflymder ymateb uchel, oherwydd mae popeth yn cael ei storio yn y cof;
- Rhwyddineb gwneud copi wrth gefn ac atgynhyrchu.
Anfanteision Redis i ni:
- Nid oes unrhyw drafodion gwirioneddol. Fe wnaethon ni geisio eu hefelychu ar lefel ein cais. Yn anffodus, nid oedd hyn bob amser yn gweithio'n dda ac roedd angen ysgrifennu cod cymhleth iawn.
- Mae faint o ddata yn cael ei gyfyngu gan faint o gof. Wrth i faint o ddata gynyddu, bydd y cof yn tyfu, ac, yn y diwedd, byddwn yn rhedeg i mewn i nodweddion yr enghraifft a ddewiswyd, sydd yn AWS yn gofyn am atal ein gwasanaeth i newid y math o enghraifft.
- Mae angen cynnal lefel hwyrni isel yn gyson, oherwydd. mae gennym nifer fawr iawn o geisiadau. Y lefel oedi optimaidd i ni yw 17-20 ms. Ar lefel o 30-40 ms, rydym yn cael ymatebion hir i geisiadau o'n cymhwysiad a dirywiad y gwasanaeth. Yn anffodus, digwyddodd hyn i ni ym mis Medi 2018, pan dderbyniodd un o'r achosion gyda Redis am ryw reswm hwyrni 2 gwaith yn fwy nag arfer. I ddatrys y mater, fe wnaethom stopio'r gwasanaeth ganol dydd ar gyfer gwaith cynnal a chadw heb ei drefnu a disodli'r enghraifft problemus Redis.
- Mae'n hawdd cael anghysondeb data hyd yn oed gyda mân wallau yn y cod ac yna treulio llawer o amser yn ysgrifennu cod i gywiro'r data hwn.
Fe wnaethom gymryd yr anfanteision i ystyriaeth a sylweddoli bod angen i ni symud i rywbeth mwy cyfleus, gyda thrafodion arferol a llai o ddibyniaeth ar hwyrni. Cynnal ymchwil, dadansoddi llawer o opsiynau a dewis PostgreSQL.
Rydym wedi bod yn symud i gronfa ddata newydd ers 1,5 mlynedd eisoes ac wedi symud dim ond rhan fach o'r data, felly nawr rydym yn gweithio ar yr un pryd â Redis a PostgreSQL. Mae rhagor o wybodaeth am gamau symud a newid data rhwng cronfeydd data wedi’i hysgrifennu yn .
Pan ddechreuon ni symud gyntaf, gweithiodd ein cais yn uniongyrchol gyda'r gronfa ddata a chyrchu'r meistr Redis a PostgreSQL. Roedd clwstwr PostgreSQL yn cynnwys meistr a replica gydag atgynhyrchiad asyncronaidd. Dyma sut olwg oedd ar y cynllun cronfa ddata:
Gweithredu PgBouncer
Tra roeddem yn symud, roedd y cynnyrch hefyd yn datblygu: cynyddodd nifer y defnyddwyr a nifer y gweinyddwyr a oedd yn gweithio gyda PostgreSQL, a dechreuasom ddiffyg cysylltiadau. Mae PostgreSQL yn creu proses ar wahân ar gyfer pob cysylltiad ac yn defnyddio adnoddau. Gallwch gynyddu nifer y cysylltiadau hyd at bwynt penodol, fel arall mae cyfle i gael perfformiad cronfa ddata is-optimaidd. Yr opsiwn delfrydol mewn sefyllfa o'r fath fyddai dewis rheolwr cysylltiad a fydd yn sefyll o flaen y sylfaen.
Roedd gennym ddau opsiwn ar gyfer y rheolwr cysylltiad: Pgpool a PgBouncer. Ond nid yw'r un cyntaf yn cefnogi'r modd trafodol o weithio gyda'r gronfa ddata, felly fe wnaethom ddewis PgBouncer.
Rydym wedi sefydlu'r cynllun gwaith a ganlyn: mae ein cymhwysiad yn cyrchu un PgBouncer, y tu ôl i'r rhain mae meistri PostgreSQL, a thu ôl i bob meistr mae un replica gydag atgynhyrchiad asyncronaidd.
Ar yr un pryd, ni allem storio'r swm cyfan o ddata yn PostgreSQL ac roedd cyflymder gweithio gyda'r gronfa ddata yn bwysig i ni, felly fe wnaethom ddechrau rhannu PostgreSQL ar lefel y cais. Mae'r cynllun a ddisgrifir uchod yn gymharol gyfleus ar gyfer hyn: wrth ychwanegu shard PostgreSQL newydd, mae'n ddigon i ddiweddaru'r cyfluniad PgBouncer a gall y cais weithio ar unwaith gyda'r shard newydd.
Methiant PgBouncer
Bu'r cynllun hwn yn gweithio tan yr eiliad pan fu farw'r unig enghraifft PgBouncer. Rydym yn AWS, lle mae pob achos yn rhedeg ar galedwedd sy'n marw o bryd i'w gilydd. Mewn achosion o'r fath, mae'r enghraifft yn symud i galedwedd newydd ac yn gweithio eto. Digwyddodd hyn gyda PgBouncer, ond nid oedd ar gael. Canlyniad y cwymp hwn oedd nad oedd ein gwasanaeth ar gael am 25 munud. Mae AWS yn argymell defnyddio dileu swydd ar ochr y defnyddiwr ar gyfer sefyllfaoedd o'r fath, na chafodd ei weithredu yn ein gwlad ar y pryd.
Ar ôl hynny, fe wnaethon ni feddwl o ddifrif am oddefgarwch bai clystyrau PgBouncer a PostgreSQL, oherwydd gallai sefyllfa debyg ddigwydd gydag unrhyw achos yn ein cyfrif AWS.
Fe wnaethom adeiladu'r cynllun goddefgarwch namau PgBouncer fel a ganlyn: mae holl weinyddion y cais yn cyrchu'r Network Load Balancer, ac mae dau PgBouncer y tu ôl iddo. Mae pob PgBouncer yn edrych ar yr un meistr PostgreSQL o bob shard. Os bydd damwain enghraifft AWS yn digwydd eto, caiff yr holl draffig ei ailgyfeirio trwy PgBouncer arall. Darperir methiant Cydbwyso Llwyth Rhwydwaith gan AWS.
Mae'r cynllun hwn yn ei gwneud hi'n hawdd ychwanegu gweinyddwyr PgBouncer newydd.
Creu Clwstwr Methiant PostgreSQL
Wrth ddatrys y broblem hon, fe wnaethom ystyried gwahanol opsiynau: methiant hunan-ysgrifenedig, repmgr, AWS RDS, Patroni.
Sgriptiau hunan-ysgrifenedig
Gallant fonitro gwaith y meistr ac, os bydd yn methu, hyrwyddo'r replica i'r meistr a diweddaru'r cyfluniad PgBouncer.
Manteision y dull hwn yw'r symlrwydd mwyaf, oherwydd rydych chi'n ysgrifennu sgriptiau eich hun ac yn deall yn union sut maen nhw'n gweithio.
Cons:
- Efallai na fyddai'r meistr wedi marw, yn lle hynny efallai y byddai methiant rhwydwaith wedi digwydd. Bydd Failover, yn anymwybodol o hyn, yn hyrwyddo'r replica i'r meistr, tra bydd yr hen feistr yn parhau i weithio. O ganlyniad, byddwn yn cael dau weinyddwr yn rôl meistr ac ni fyddwn yn gwybod pa un ohonynt sydd â'r data diweddaraf. Gelwir y sefyllfa hon hefyd yn hollt-ymennydd;
- Gadawyd ni heb ateb. Yn ein cyfluniad, mae'r meistr ac un replica, ar ôl newid, mae'r replica yn symud i fyny at y meistr ac nid oes gennym ni gopïau bellach, felly mae'n rhaid i ni ychwanegu replica newydd â llaw;
- Mae angen monitro ychwanegol ar y gweithrediad methu, tra bod gennym 12 darn PostgreSQL, sy'n golygu bod yn rhaid inni fonitro 12 clwstwr. Gyda chynnydd yn nifer y darnau darnau, rhaid i chi hefyd gofio diweddaru'r methiant.
Mae methiant hunan-ysgrifenedig yn edrych yn gymhleth iawn ac mae angen cefnogaeth nad yw'n ddibwys. Gyda chlwstwr PostgreSQL sengl, hwn fyddai'r opsiwn hawsaf, ond nid yw'n graddio, felly nid yw'n addas i ni.
Repmgr
Rheolwr Dyblygu ar gyfer clystyrau PostgreSQL, a all reoli gweithrediad clwstwr PostgreSQL. Ar yr un pryd, nid oes ganddo fethiant awtomatig allan o'r bocs, felly ar gyfer gwaith bydd angen i chi ysgrifennu eich “lapiwr” eich hun ar ben y datrysiad gorffenedig. Felly gall popeth droi allan hyd yn oed yn fwy cymhleth na gyda sgriptiau hunan-ysgrifenedig, felly ni wnaethom hyd yn oed roi cynnig ar Repmgr.
AWS RDS
Yn cefnogi popeth sydd ei angen arnom, yn gwybod sut i wneud copïau wrth gefn ac yn cynnal cronfa o gysylltiadau. Mae ganddo newid awtomatig: pan fydd y meistr yn marw, daw'r replica yn feistr newydd, ac mae AWS yn newid y cofnod dns i'r meistr newydd, tra gellir lleoli'r atgynyrchiadau mewn gwahanol AZs.
Mae'r anfanteision yn cynnwys diffyg addasiadau mân. Fel enghraifft o fireinio: mae gan ein hachosion gyfyngiadau ar gysylltiadau tcp, na ellir, yn anffodus, eu gwneud yn RDS:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
Yn ogystal, mae AWS RDS bron ddwywaith yn ddrytach na'r pris enghraifft arferol, sef y prif reswm dros roi'r gorau i'r ateb hwn.
Patroni
Templed python yw hwn ar gyfer rheoli PostgreSQL gyda dogfennaeth dda, methiant awtomatig a chod ffynhonnell ar github.
Manteision Patroni:
- Disgrifir pob paramedr cyfluniad, mae'n amlwg sut mae'n gweithio;
- Mae methiant awtomatig yn gweithio allan o'r blwch;
- Wedi'i ysgrifennu yn python, a chan ein bod ni ein hunain yn ysgrifennu llawer mewn python, bydd yn haws i ni ddelio â phroblemau ac, efallai, hyd yn oed helpu datblygiad y prosiect;
- Yn rheoli PostgreSQL yn llawn, yn caniatáu ichi newid y cyfluniad ar bob nod o'r clwstwr ar unwaith, ac os oes angen ailgychwyn y clwstwr i gymhwyso'r cyfluniad newydd, yna gellir gwneud hyn eto gan ddefnyddio Patroni.
Cons:
- Nid yw'n glir o'r ddogfennaeth sut i weithio'n gywir gyda PgBouncer. Er ei bod yn anodd ei alw'n minws, oherwydd tasg Patroni yw rheoli PostgreSQL, a sut y bydd cysylltiadau â Patroni yn mynd yw ein problem eisoes;
- Prin yw'r enghreifftiau o weithredu Patroni ar niferoedd mawr, tra bod llawer o enghreifftiau o weithredu o'r dechrau.
O ganlyniad, dewison ni Patroni i greu clwstwr methu.
Proses Weithredu Patroni
Cyn Patroni, roedd gennym ni 12 darn PostgreSQL mewn cyfluniad o un meistr ac un replica gyda dyblygu asyncronaidd. Roedd gweinyddwyr y rhaglen yn cyrchu'r cronfeydd data trwy'r Network Load Balancer, y tu ôl i ddau achos gyda PgBouncer, ac y tu ôl iddynt roedd yr holl weinyddion PostgreSQL.
Er mwyn gweithredu Patroni, roedd angen i ni ddewis cyfluniad clwstwr storio dosbarthedig. Mae Patroni yn gweithio gyda systemau storio cyfluniad dosbarthedig fel ac ati, Zookeeper, Consul. Dim ond clwstwr Conswl llawn sydd gennym ar y farchnad, sy'n gweithio ar y cyd â Vault ac nid ydym yn ei ddefnyddio mwyach. Rheswm gwych i ddechrau defnyddio Conswl at ei ddiben bwriadedig.
Sut mae Patroni yn gweithio gyda Chonswl
Mae gennym glwstwr Conswl, sy'n cynnwys tri nod, a chlwstwr Patroni, sy'n cynnwys arweinydd a replica (yn Patroni, gelwir y meistr yn arweinydd y clwstwr, a gelwir y caethweision yn replicas). Mae pob achos o glwstwr Patroni yn anfon gwybodaeth am gyflwr y clwstwr yn gyson at Gonswl. Felly, gan Gonswl gallwch chi bob amser ddarganfod cyfluniad presennol clwstwr Patroni a phwy yw'r arweinydd ar hyn o bryd.
I gysylltu Patroni â Conswl, mae'n ddigon astudio'r ddogfennaeth swyddogol, sy'n dweud bod angen i chi nodi gwesteiwr yn y fformat http neu https, yn dibynnu ar sut rydym yn gweithio gyda Conswl, a'r cynllun cysylltu, yn ddewisol:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpMae'n edrych yn syml, ond yma mae'r peryglon yn dechrau. Gyda Consul, rydym yn gweithio dros gysylltiad diogel trwy https a bydd ein cyfluniad cysylltiad yn edrych fel hyn:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Ond nid yw hynny'n gweithio. Wrth gychwyn, ni all Patroni gysylltu â Conswl, oherwydd mae'n ceisio mynd trwy http beth bynnag.
Helpodd cod ffynhonnell Patroni i ddelio â'r broblem. Peth da ei fod wedi ei ysgrifennu yn python. Mae'n ymddangos nad yw'r paramedr gwesteiwr wedi'i ddosrannu mewn unrhyw ffordd, a rhaid nodi'r protocol yn y cynllun. Dyma sut olwg sydd ar y bloc cyfluniad gweithio ar gyfer gweithio gyda Chonswl i ni:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}conswl-templed
Felly, rydym wedi dewis y storfa ar gyfer y ffurfweddiad. Nawr mae angen i ni ddeall sut y bydd PgBouncer yn newid ei ffurfweddiad wrth newid yr arweinydd yn y clwstwr Patroni. Nid oes ateb i'r cwestiwn hwn yn y ddogfennaeth, oherwydd. yno, mewn egwyddor, ni chaiff gwaith gyda PgBouncer ei ddisgrifio.
Wrth chwilio am ateb, daethom o hyd i erthygl (yn anffodus nid wyf yn cofio'r teitl) lle ysgrifennwyd bod templed Сonsul wedi helpu llawer wrth baru PgBouncer a Patroni. Fe'n hysgogodd hyn i ymchwilio i sut mae Templed Conswl yn gweithio.
Daeth i'r amlwg bod templed Conswl yn monitro cyfluniad clwstwr PostgreSQL yn Conswl yn gyson. Pan fydd yr arweinydd yn newid, mae'n diweddaru'r cyfluniad PgBouncer ac yn anfon gorchymyn i'w ail-lwytho.
Mantais fawr o dempled yw ei fod yn cael ei storio fel cod, felly wrth ychwanegu shard newydd, mae'n ddigon i wneud ymrwymiad newydd a diweddaru'r templed yn awtomatig, gan gefnogi'r Isadeiledd fel egwyddor cod.
Pensaernïaeth newydd gyda Patroni
O ganlyniad, cawsom y cynllun gwaith canlynol:
Mae pob gweinydd cymhwysiad yn cyrchu'r balancer → mae dau achos o PgBouncer y tu ôl iddo → ar bob achos, mae Consul-template yn cael ei lansio, sy'n monitro statws pob clwstwr Patroni ac yn monitro perthnasedd y ffurfwedd PgBouncer, sy'n anfon ceisiadau at yr arweinydd presennol o bob clwstwr.
Profi â llaw
Cynhaliom y cynllun hwn cyn ei lansio ar amgylchedd prawf bach a gwirio gweithrediad y newid awtomatig. Fe wnaethon nhw agor y bwrdd, symud y sticer, ac ar y foment honno fe wnaethon nhw “ladd” arweinydd y clwstwr. Yn AWS, mae hyn mor syml â chau'r enghraifft trwy'r consol.
Dychwelodd y sticer yn ôl o fewn 10-20 eiliad, ac yna eto dechreuodd symud fel arfer. Mae hyn yn golygu bod clwstwr Patroni wedi gweithio'n gywir: newidiodd yr arweinydd, anfonodd y wybodaeth at Сonsul, a chododd Сonsul-template y wybodaeth hon ar unwaith, disodlwyd y ffurfwedd PgBouncer ac anfonodd y gorchymyn i ail-lwytho.
Sut i oroesi o dan lwyth uchel a chadw'r amser segur yn fach iawn?
Mae popeth yn gweithio'n berffaith! Ond mae cwestiynau newydd: Sut y bydd yn gweithio o dan lwyth uchel? Sut i gyflwyno popeth ym maes cynhyrchu yn gyflym ac yn ddiogel?
Mae'r amgylchedd prawf yr ydym yn cynnal profion llwyth arno yn ein helpu i ateb y cwestiwn cyntaf. Mae'n hollol union yr un fath â chynhyrchu o ran pensaernïaeth ac mae wedi cynhyrchu data prawf sydd fwy neu lai yn gyfartal o ran cyfaint â chynhyrchiad. Rydyn ni'n penderfynu “lladd” un o feistri PostgreSQL yn ystod y prawf a gweld beth sy'n digwydd. Ond cyn hynny, mae'n bwysig gwirio'r treigl awtomatig, oherwydd ar yr amgylchedd hwn mae gennym nifer o ddarnau PostgreSQL, felly byddwn yn cael prawf ardderchog o sgriptiau cyfluniad cyn cynhyrchu.
Mae'r ddwy dasg yn edrych yn uchelgeisiol, ond mae gennym PostgreSQL 9.6. A allwn ni uwchraddio ar unwaith i 11.2?
Rydyn ni'n penderfynu ei wneud mewn 2 gam: uwchraddio i 11.2 yn gyntaf, yna lansio Patroni.
Diweddariad PostgreSQL
I ddiweddaru'r fersiwn PostgreSQL yn gyflym, defnyddiwch yr opsiwn -k, lle mae dolenni caled yn cael eu creu ar ddisg ac nid oes angen copïo'ch data. Ar seiliau 300-400 GB, mae'r diweddariad yn cymryd 1 eiliad.
Mae gennym lawer o ddarnau, felly mae angen gwneud y diweddariad yn awtomatig. I wneud hyn, fe wnaethon ni ysgrifennu llyfr chwarae Ansible sy'n delio â'r broses ddiweddaru gyfan i ni:
/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='Mae'n bwysig nodi yma, cyn dechrau'r uwchraddio, bod yn rhaid i chi ei berfformio gyda'r paramedr --gwirioi wneud yn siŵr eich bod yn gallu uwchraddio. Mae ein sgript hefyd yn gwneud amnewid cyfluniadau am gyfnod yr uwchraddio. Cwblhawyd ein sgript mewn 30 eiliad, sy'n ganlyniad rhagorol.
Lansio Patroni
I ddatrys yr ail broblem, edrychwch ar y ffurfwedd Patroni. Mae gan yr ystorfa swyddogol ffurfweddiad enghreifftiol gydag initdb, sy'n gyfrifol am gychwyn cronfa ddata newydd pan ddechreuwch Patroni am y tro cyntaf. Ond gan fod gennym gronfa ddata barod eisoes, rydym yn syml wedi tynnu'r adran hon o'r ffurfweddiad.
Pan ddechreuon ni osod Patroni ar glwstwr PostgreSQL a oedd eisoes yn bodoli a'i redeg, fe wnaethom redeg i mewn i broblem newydd: dechreuodd y ddau weinydd fel arweinydd. Nid yw Patroni yn gwybod dim am gyflwr cynnar y clwstwr ac mae'n ceisio cychwyn y ddau weinydd fel dau glwstwr ar wahân gyda'r un enw. I ddatrys y broblem hon, mae angen i chi ddileu'r cyfeiriadur gyda data ar y caethwas:
rm -rf /var/lib/postgresql/Mae angen gwneud hyn ar y caethwas yn unig!
Pan gysylltir replica glân, mae Patroni yn gwneud arweinydd basebackup a'i adfer i'r replica, ac yna'n dal i fyny â'r cyflwr presennol yn ôl y boncyffion wal.
Anhawster arall y daethom ar ei draws yw bod holl glystyrau PostgreSQL yn cael eu henwi'n brif glystyrau yn ddiofyn. Pan nad yw pob clwstwr yn gwybod dim am y llall, mae hyn yn normal. Ond pan fyddwch chi eisiau defnyddio Patroni, yna mae'n rhaid bod gan bob clwstwr enw unigryw. Yr ateb yw newid enw'r clwstwr yn y ffurfweddiad PostgreSQL.
prawf llwyth
Rydym wedi lansio prawf sy'n efelychu profiad defnyddwyr ar fyrddau. Pan gyrhaeddodd y llwyth ein gwerth dyddiol cyfartalog, fe wnaethon ni ailadrodd yr un prawf yn union, fe wnaethon ni ddiffodd un achos gydag arweinydd PostgreSQL. Gweithiodd y methiant awtomatig fel y disgwyliwyd: newidiodd Patroni yr arweinydd, diweddarodd Consul-template y cyfluniad PgBouncer ac anfonodd orchymyn i'w ail-lwytho. Yn ôl ein graffiau yn Grafana, roedd yn amlwg bod oedi o 20-30 eiliad ac ychydig bach o wallau o'r gweinyddwyr sy'n gysylltiedig â'r cysylltiad â'r gronfa ddata. Mae hon yn sefyllfa arferol, mae gwerthoedd o'r fath yn dderbyniol ar gyfer ein methiant ac yn bendant yn well na'r amser segur gwasanaeth.
Dod â Patroni i'r cynhyrchiad
O ganlyniad, lluniwyd y cynllun canlynol gennym:
- Defnyddio templed Conswl i weinyddion PgBouncer a'i lansio;
- Diweddariadau PostgreSQL i fersiwn 11.2;
- Newid enw'r clwstwr;
- Cychwyn y Clwstwr Patroni.
Ar yr un pryd, mae ein cynllun yn caniatáu i ni wneud y pwynt cyntaf bron ar unrhyw adeg, gallwn dynnu pob PgBouncer o'r gwaith yn ei dro a defnyddio a rhedeg templed conswl arno. Felly gwnaethom.
Ar gyfer defnydd cyflym, fe wnaethom ddefnyddio Ansible, gan ein bod eisoes wedi profi'r holl lyfrau chwarae ar amgylchedd prawf, ac roedd amser gweithredu'r sgript lawn rhwng 1,5 a 2 funud ar gyfer pob darn. Gallem gyflwyno popeth yn ei dro i bob darn heb atal ein gwasanaeth, ond byddai'n rhaid i ni ddiffodd pob PostgreSQL am sawl munud. Yn yr achos hwn, ni allai defnyddwyr y mae eu data ar y darn hwn weithio'n llawn ar hyn o bryd, ac mae hyn yn annerbyniol i ni.
Y ffordd allan o'r sefyllfa hon oedd y gwaith cynnal a chadw wedi'i gynllunio, sy'n digwydd bob 3 mis. Mae hon yn ffenestr ar gyfer gwaith wedi'i amserlennu, pan fyddwn yn cau ein gwasanaeth yn gyfan gwbl ac yn uwchraddio achosion ein cronfa ddata. Roedd wythnos ar ôl tan y ffenestr nesaf, a phenderfynon ni aros a pharatoi ymhellach. Yn ystod yr amser aros, fe wnaethom hefyd sicrhau ein hunain: ar gyfer pob darn PostgreSQL, fe wnaethom godi replica sbâr rhag ofn na fyddai'r data diweddaraf yn cael ei gadw, ac ychwanegu enghraifft newydd ar gyfer pob darn, a ddylai ddod yn atgynhyrchiad newydd yn y clwstwr Patroni, er mwyn peidio â gweithredu gorchymyn i ddileu data . Roedd hyn i gyd yn helpu i leihau'r risg o gamgymeriadau.
Fe wnaethom ailgychwyn ein gwasanaeth, gweithiodd popeth fel y dylai, parhaodd defnyddwyr i weithio, ond ar y graffiau fe wnaethom sylwi ar lwyth anarferol o uchel ar y gweinyddwyr Conswl.
Pam na welsom ni hyn yn yr amgylchedd prawf? Mae'r broblem hon yn dangos yn dda iawn bod angen dilyn yr Isadeiledd fel egwyddor cod a mireinio'r seilwaith cyfan, o amgylcheddau prawf i gynhyrchu. Fel arall, mae'n hawdd iawn cael y broblem a gawsom. Beth ddigwyddodd? Ymddangosodd Conswl yn gyntaf ar gynhyrchu, ac yna ar amgylcheddau prawf, o ganlyniad, ar amgylcheddau prawf, roedd fersiwn Conswl yn uwch nag ar gynhyrchu. Dim ond yn un o'r datganiadau, cafodd gollyngiad CPU ei ddatrys wrth weithio gyda thempled conswl. Felly, yn syml iawn, fe wnaethom ddiweddaru Conswl, a thrwy hynny ddatrys y broblem.
Ailgychwyn clwstwr Patroni
Fodd bynnag, cawsom broblem newydd, nad oeddem hyd yn oed yn ei hamau. Wrth ddiweddaru Conswl, rydym yn syml yn tynnu'r nod Conswl o'r clwstwr gan ddefnyddio'r gorchymyn gadael conswl → Mae Patroni yn cysylltu â gweinydd Conswl arall → mae popeth yn gweithio. Ond pan gyrhaeddon ni'r enghraifft olaf o'r clwstwr Conswl ac anfon y gorchymyn gadael conswl ato, ailgychwynnodd holl glystyrau Patroni, ac yn y logiau gwelsom y gwall canlynol:
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>Nid oedd clwstwr Patroni yn gallu adalw gwybodaeth am ei glwstwr ac ailddechreuodd.
I ddod o hyd i ateb, fe wnaethom gysylltu ag awduron Patroni trwy rifyn ar github. Fe wnaethon nhw awgrymu gwelliannau i'n ffeiliau ffurfweddu:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Roeddem yn gallu ailadrodd y broblem ar amgylchedd prawf a phrofi'r opsiynau hyn yno, ond yn anffodus nid oeddent yn gweithio.
Mae'r broblem yn dal i fod heb ei datrys. Rydym yn bwriadu rhoi cynnig ar yr atebion canlynol:
- Defnyddiwch asiant Conswl ar bob enghraifft o glwstwr Patroni;
- Trwsiwch y mater yn y cod.
Rydym yn deall lle digwyddodd y gwall: mae'n debyg mai'r broblem yw defnyddio terfyn amser rhagosodedig, nad yw'n cael ei ddiystyru trwy'r ffeil ffurfweddu. Pan fydd y gweinydd Conswl olaf yn cael ei dynnu o'r clwstwr, mae'r clwstwr Conswl cyfan yn hongian am fwy nag eiliad, oherwydd hyn, ni all Patroni gael statws y clwstwr ac mae'n ailgychwyn y clwstwr cyfan yn llwyr.
Yn ffodus, ni ddaethom ar draws mwy o wallau.
Canlyniadau defnyddio Patroni
Ar ôl lansiad llwyddiannus Patroni, fe wnaethom ychwanegu atgynhyrchiad ychwanegol ym mhob clwstwr. Erbyn hyn mae cworwm ym mhob clwstwr: un arweinydd a dau atgynhyrchiad, ar gyfer rhwyd ddiogelwch rhag ofn y bydd ymennydd hollt wrth newid.
Mae Patroni wedi bod yn gweithio ar gynhyrchu ers mwy na thri mis. Yn ystod y cyfnod hwn, mae eisoes wedi llwyddo i'n helpu ni. Yn ddiweddar, bu farw arweinydd un o'r clystyrau yn AWS, bu methiant awtomatig yn gweithio a pharhaodd defnyddwyr i weithio. Cyflawnodd Patroni ei phrif orchwyl.
Crynodeb bach o'r defnydd o Patroni:
- Rhwyddineb newidiadau cyfluniad. Mae'n ddigon i newid y ffurfweddiad ar un achos a bydd yn cael ei dynnu i fyny i'r clwstwr cyfan. Os oes angen ailgychwyn i gymhwyso'r cyfluniad newydd, yna bydd Patroni yn rhoi gwybod i chi. Gall Patroni ailgychwyn y clwstwr cyfan gydag un gorchymyn, sydd hefyd yn gyfleus iawn.
- Mae methiant awtomatig yn gweithio ac mae eisoes wedi llwyddo i'n helpu ni.
- Diweddariad PostgreSQL heb amser segur cais. Rhaid i chi ddiweddaru'r replicas i'r fersiwn newydd yn gyntaf, yna newid yr arweinydd yn y clwstwr Patroni a diweddaru'r hen arweinydd. Yn yr achos hwn, mae'r profion angenrheidiol o fethiant awtomatig yn digwydd.
Ffynhonnell: hab.com