Prif nod Patroni yw darparu Argaeledd Uchel ar gyfer PostgreSQL. Ond templed yn unig yw Patroni, nid offeryn parod (a ddywedir, yn gyffredinol, yn y ddogfennaeth). Ar yr olwg gyntaf, ar ôl sefydlu Patroni yn y labordy prawf, gallwch weld pa mor arf gwych ydyw a pha mor hawdd y mae'n delio â'n hymdrechion i dorri'r clwstwr. Fodd bynnag, yn ymarferol, mewn amgylchedd cynhyrchu, nid yw popeth bob amser yn digwydd mor hardd a chain ag mewn labordy prawf.
Fe ddywedaf ychydig wrthych amdanaf fy hun. Dechreuais fel gweinyddwr system. Wedi gweithio ym maes datblygu gwe. Rwyf wedi bod yn gweithio yn Data Egret ers 2014. Mae'r cwmni'n ymgynghori ym maes Postgres. Ac rydyn ni'n gwasanaethu Postgres yn union, ac rydyn ni'n gweithio gyda Postgres bob dydd, felly mae gennym ni arbenigedd gwahanol yn ymwneud â'r llawdriniaeth.
Ac ar ddiwedd 2018, dechreuon ni ddefnyddio Patroni yn araf. Ac mae rhywfaint o brofiad wedi'i gronni. Fe wnaethon ni ei ddiagnosio rywsut, ei diwnio, daeth i'n harferion gorau. Ac yn yr adroddiad hwn byddaf yn siarad amdanynt.
Ar wahân i Postgres, dwi'n caru Linux. Rwy'n hoffi procio o gwmpas ynddo ac archwilio, rwy'n hoffi casglu creiddiau. Rwyf wrth fy modd rhithwiroli, cynwysyddion, docwr, Kubernetes. Mae hyn i gyd o ddiddordeb i mi, oherwydd mae'r hen arferion gweinyddol yn effeithio. Rwy'n hoffi delio â monitro. Ac rwyf wrth fy modd â phethau postgres sy'n ymwneud â gweinyddu, h.y. atgynhyrchu, wrth gefn. Ac yn fy amser hamdden rwy'n ysgrifennu yn Go. Nid wyf yn beiriannydd meddalwedd, dim ond ysgrifennu drosof fy hun yn Go. Ac mae'n rhoi pleser i mi.
- Rwy'n meddwl bod llawer ohonoch yn gwybod nad oes gan Postgres HA (Argaeledd Uchel) allan o'r bocs. I gael HA, mae angen i chi osod rhywbeth, ei ffurfweddu, gwneud ymdrech a'i gael.
- Mae yna nifer o offer ac mae Patroni yn un ohonyn nhw sy'n datrys HA yn eithaf cŵl ac yn dda iawn. Ond trwy roi'r cyfan mewn labordy prawf a'i redeg, gallwn weld ei fod i gyd yn gweithio, gallwn atgynhyrchu rhai problemau, gweld sut mae Patroni yn eu gwasanaethu. A byddwn yn gweld bod y cyfan yn gweithio'n wych.
- Ond yn ymarferol, rydym yn wynebu problemau gwahanol. A byddaf yn siarad am y problemau hyn.
- Fe ddywedaf wrthych sut y gwnaethom ei ddiagnosio, yr hyn y gwnaethom ei newid - p'un a oedd wedi ein helpu ai peidio.
- Ni fyddaf yn dweud wrthych sut i osod Patroni, oherwydd gallwch chi google ar y Rhyngrwyd, gallwch edrych ar y ffeiliau cyfluniad i ddeall sut mae'r cyfan yn dechrau, sut mae wedi'i ffurfweddu. Gallwch ddeall y cynlluniau, pensaernïaeth, dod o hyd i wybodaeth amdano ar y Rhyngrwyd.
- Ni siaradaf am brofiad rhywun arall. Ni wnaf ond siarad am y problemau a oedd yn ein hwynebu.
- Ac ni siaradaf am broblemau sydd y tu allan i Patroni a PostgreSQL. Er enghraifft, os oes problemau’n gysylltiedig â chydbwyso, pan fydd ein clwstwr wedi dymchwel, ni siaradaf amdano.
Ac ymwadiad bach cyn i ni ddechrau ein hadroddiad.
Yr holl broblemau hyn y daethom ar eu traws, cawsom hwy yn ystod y 6-7-8 mis cyntaf o weithredu. Dros amser, daethom at ein harferion gorau mewnol. A diflannodd ein problemau. Felly, cyhoeddwyd yr adroddiad tua chwe mis yn ôl, pan oedd y cyfan yn ffres yn fy mhen a chofiais y cyfan yn berffaith.
Wrth baratoi’r adroddiad, codais hen bost mortem eisoes, edrychais ar y cofnodion. A gellid anghofio rhai o'r manylion, neu ni ellid ymchwilio'n llawn i rai o rai manylion yn ystod y dadansoddiad o'r problemau, felly ar rai adegau gall ymddangos nad yw'r problemau'n cael eu hystyried yn llawn, neu fod rhywfaint o ddiffyg gwybodaeth. Ac felly gofynnaf ichi fy esgusodi am y foment hon.
Beth yw Patroni?
- Mae hwn yn dempled ar gyfer adeiladu HA. Dyna mae'n ei ddweud yn y ddogfennaeth. Ac o'm safbwynt i, mae hwn yn eglurhad cywir iawn. Nid bwled arian yw Patroni a fydd yn datrys eich holl broblemau, hynny yw, mae angen ichi wneud ymdrech i wneud iddo weithio a dod â buddion.
- Mae hwn yn wasanaeth asiant sydd wedi'i osod ar bob gwasanaeth cronfa ddata ac mae'n fath o system init ar gyfer eich Postgres. Mae'n cychwyn Postgres, yn stopio, yn ailgychwyn, yn ail-gyflunio, ac yn newid topoleg eich clwstwr.
- Yn unol â hynny, er mwyn storio cyflwr y clwstwr, ei gynrychiolaeth bresennol, fel y mae'n edrych, mae angen rhyw fath o storio. Ac o'r safbwynt hwn, cymerodd Patroni y llwybr o storio cyflwr mewn system allanol. Mae'n system storio cyfluniad dosbarthedig. Gall fod yn Etcd, Conswl, ZooKeeper, neu kubernetes Etcd, h.y. un o'r opsiynau hyn.
- Ac un o nodweddion Patroni yw eich bod chi'n cael yr autofiler allan o'r bocs, dim ond trwy ei sefydlu. Os cymerwn Repmgr i'w gymharu, yna mae'r ffeiliwr wedi'i gynnwys yno. Gyda Repmgr, rydyn ni'n cael newid i ddigidol, ond os ydyn ni eisiau awtoffeiliwr, yna mae angen i ni ei ffurfweddu hefyd. Mae gan Patroni ffeil awtomatig allan o'r bocs yn barod.
- Ac mae llawer o bethau eraill. Er enghraifft, cynnal a chadw ffurfweddau, arllwys replicas newydd, wrth gefn, ac ati Ond mae hyn y tu hwnt i gwmpas yr adroddiad, ni fyddaf yn siarad amdano.
A chanlyniad bach yw mai prif dasg Patroni yw gwneud ffeil awtomatig yn dda ac yn ddibynadwy fel bod ein clwstwr yn parhau i fod yn weithredol ac nad yw'r cais yn sylwi ar newidiadau yn y topoleg clwstwr.
Ond pan fyddwn yn dechrau defnyddio Patroni, mae ein system yn mynd ychydig yn fwy cymhleth. Pe bai gennym Postgres yn gynharach, yna wrth ddefnyddio Patroni rydyn ni'n cael Patroni ei hun, rydyn ni'n cael DCS lle mae'r wladwriaeth yn cael ei storio. Ac mae'n rhaid i'r cyfan weithio rhywsut. Felly beth all fynd o'i le?
Gall dorri:
- Efallai y bydd postgres yn torri. Gall fod yn feistr neu'n replica, gall un ohonynt fethu.
- Efallai y bydd y Patroni ei hun yn torri.
- Gall y DCS lle mae cyflwr yn cael ei storio dorri.
- A gall y rhwydwaith dorri.
Yr holl bwyntiau hyn y byddaf yn eu hystyried yn yr adroddiad.
Byddaf yn ystyried achosion wrth iddynt ddod yn fwy cymhleth, nid o’r safbwynt bod yr achos yn ymwneud â llawer o gydrannau. Ac o safbwynt teimladau goddrychol, bod yr achos hwn yn anodd i mi, roedd yn anodd ei ddadosod ... ac i'r gwrthwyneb, roedd rhyw achos yn ysgafn ac roedd yn hawdd ei ddadosod.
A'r achos cyntaf yw'r hawsaf. Mae hyn yn wir pan wnaethom gymryd clwstwr cronfa ddata a defnyddio ein storfa DCS ar yr un clwstwr. Dyma'r camgymeriad mwyaf cyffredin. Mae hwn yn gamgymeriad wrth adeiladu pensaernïaeth, h.y., cyfuno gwahanol gydrannau mewn un lle.
Felly, roedd ffeiliwr, gadewch i ni fynd i ddelio â'r hyn a ddigwyddodd.
Ac yma mae gennym ddiddordeb mewn pryd y digwyddodd y ffeiliwr. Hynny yw, mae gennym ddiddordeb yn y foment hon mewn amser pan newidiodd y cyflwr clwstwr.
Ond nid yw'r ffeiliwr bob amser yn syth, h.y. nid yw'n cymryd unrhyw uned o amser, gellir ei ohirio. Gall fod yn para'n hir.
Felly, mae ganddo amser cychwyn ac amser gorffen, h.y. mae’n ddigwyddiad parhaus. Ac rydym yn rhannu pob digwyddiad yn dri chyfnod: mae gennym amser cyn y ffeiliwr, yn ystod y ffeiliwr ac ar ôl y ffeiliwr. Hynny yw, rydym yn ystyried yr holl ddigwyddiadau yn y llinell amser hon.
A'r peth cyntaf, pan ddigwyddodd ffeiliwr, rydym yn edrych am yr achos o'r hyn a ddigwyddodd, beth oedd achos yr hyn a arweiniodd at y ffeiliwr.
Os edrychwn ar y boncyffion, byddant yn foncyffion Patroni clasurol. Mae'n dweud wrthym ynddynt fod y gweinydd wedi dod yn feistr, ac mae rôl y meistr wedi trosglwyddo i'r nod hwn. Yma mae'n cael ei amlygu.
Nesaf, mae angen i ni ddeall pam y digwyddodd y ffeiliwr, h.y. pa ddigwyddiadau a ddigwyddodd a achosodd i'r prif rôl symud o un nod i'r llall. Ac yn yr achos hwn, mae popeth yn syml. Mae gennym gamgymeriad wrth ryngweithio â'r system storio. Sylweddolodd y meistr na allai weithio gyda DCS, hynny yw, roedd rhyw fath o broblem gyda'r rhyngweithio. Ac mae'n dweud na all fod yn feistr mwyach ac mae'n ymddiswyddo. Mae'r llinell hon “diraddio hunan” yn dweud yn union hynny.
Os edrychwn ar y digwyddiadau a ragflaenodd y ffeiliwr, gallwn weld yno yr union resymau a achosodd y broblem i barhau â'r dewin.
Os edrychwn ar logiau Patroni, fe welwn fod gennym lawer o wallau, seibiannau, h.y. ni all asiant Patroni weithio gyda DCS. Yn yr achos hwn, asiant Conswl yw hwn, sy'n cyfathrebu ar borthladd 8500.
A'r broblem yma yw bod Patroni a'r gronfa ddata yn rhedeg ar yr un gwesteiwr. A lansiwyd y gweinyddion Conswl ar yr un nod. Trwy greu llwyth ar y gweinydd, fe wnaethon ni greu problemau i'r gweinyddwyr Conswl hefyd. Nid oeddent yn gallu cyfathrebu'n iawn.
Ar ôl peth amser, pan ostyngodd y llwyth, roedd ein Patroni yn gallu cyfathrebu ag asiantau eto. Ailddechreuodd y gwaith arferol. A daeth yr un gweinydd Pgdb-2 yn feistr eto. Hynny yw, roedd fflip bach, oherwydd bod y nod yn ymddiswyddo pwerau'r meistr, ac yna'n eu cymryd drosodd eto, hynny yw, dychwelodd popeth fel yr oedd.
A gellir ystyried hyn yn gamrybudd, neu gellir ystyried bod Patroni wedi gwneud popeth yn iawn. Hynny yw, sylweddolodd na allai gynnal cyflwr y clwstwr a chael gwared ar ei awdurdod.
Ac yma cododd y broblem oherwydd bod gweinyddwyr y Conswl ar yr un caledwedd â'r canolfannau. Yn unol â hynny, unrhyw lwyth: boed yn y llwyth ar ddisgiau neu broseswyr, mae hefyd yn effeithio ar y rhyngweithio â'r clwstwr Conswl.
Ac fe wnaethom benderfynu na ddylai fyw gyda'i gilydd, fe wnaethom ddyrannu clwstwr ar wahân ar gyfer Conswl. Ac roedd Patroni eisoes yn gweithio gyda Chonswl ar wahân, hynny yw, roedd clwstwr Postgres ar wahân, clwstwr Conswl ar wahân. Mae hwn yn gyfarwyddyd sylfaenol ar sut i gario a chadw'r holl bethau hyn fel nad yw'n cyd-fyw.
Fel opsiwn, gallwch chi droelli'r paramedrau ttl, loop_wait, retry_timeout, h.y. ceisio goroesi'r uchafbwyntiau llwyth tymor byr hyn trwy gynyddu'r paramedrau hyn. Ond nid dyma'r opsiwn mwyaf addas, oherwydd gall y llwyth hwn fod yn hir mewn amser. A byddwn yn mynd y tu hwnt i derfynau'r paramedrau hyn. Ac efallai na fydd hynny'n helpu mewn gwirionedd.
Mae'r broblem gyntaf, fel y deallwch, yn syml. Fe wnaethon ni gymryd a rhoi'r DCS ynghyd â'r sylfaen, cawsom broblem.
Mae'r ail broblem yn debyg i'r un gyntaf. Mae'n debyg yn yr ystyr bod gennym eto broblemau rhyngweithredu gyda'r system DCS.
Os edrychwn ar y logiau, fe welwn fod gennym gamgymeriad cyfathrebu eto. Ac mae Patroni yn dweud na allaf ryngweithio â DCS felly mae'r meistr presennol yn mynd i'r modd replica.
Mae'r hen feistr yn dod yn replica, dyma Patroni yn gweithio allan, fel y dylai fod. Mae'n rhedeg pg_rewind i ailddirwyn y log trafodion ac yna cysylltu â'r meistr newydd i ddal i fyny â'r meistr newydd. Yma mae Patroni yn gweithio allan, fel y dylai.
Yma mae'n rhaid i ni ddod o hyd i'r lle a ragflaenodd y ffeiliwr, h.y. y gwallau hynny a achosodd i ni gael ffeiliwr. Ac yn hyn o beth, mae logiau Patroni yn eithaf cyfleus i weithio gyda nhw. Mae'n ysgrifennu'r un negeseuon ar gyfnod penodol. Ac os byddwn yn dechrau sgrolio trwy'r logiau hyn yn gyflym, yna fe welwn o'r logiau bod y logiau wedi newid, sy'n golygu bod rhai problemau wedi dechrau. Dychwelwn yn gyflym i'r lle hwn, gweld beth sy'n digwydd.
Ac mewn sefyllfa arferol, mae'r logiau'n edrych rhywbeth fel hyn. Mae perchennog y clo yn cael ei wirio. Ac os yw'r perchennog, er enghraifft, wedi newid, yna gall rhai digwyddiadau ddigwydd y mae'n rhaid i Patroni ymateb iddynt. Ond yn yr achos hwn, rydym yn iawn. Rydym yn chwilio am y man lle dechreuodd y gwallau.
Ac ar ôl sgrolio i'r pwynt lle dechreuodd y gwallau ymddangos, gwelwn ein bod wedi cael trosglwyddiad awtomatig. A chan fod ein gwallau'n gysylltiedig â rhyngweithio â DCS ac yn ein hachos ni fe wnaethom ddefnyddio Conswl, rydym hefyd yn edrych ar y logiau Conswl, beth ddigwyddodd yno.
Wrth gymharu’n fras amser y ffeiliwr a’r amser yn logiau’r Conswl, gwelwn fod ein cymdogion yn y clwstwr Conswl wedi dechrau amau bodolaeth aelodau eraill o’r clwstwr Conswl.
Ac os edrychwch hefyd ar logiau asiantau Conswl eraill, gallwch hefyd weld bod rhyw fath o gwymp rhwydwaith yn digwydd yno. Ac mae holl aelodau clwstwr y Conswl yn amau bodolaeth ei gilydd. A dyma oedd yr ysgogiad i'r ffeiliwr.
Os edrychwch ar yr hyn a ddigwyddodd cyn y gwallau hyn, gallwch weld bod pob math o wallau, er enghraifft, terfyn amser, disgynnodd RPC, hynny yw, mae'n amlwg bod rhyw fath o broblem yn y rhyngweithio rhwng aelodau clwstwr Conswl â'i gilydd. .
Yr ateb symlaf yw atgyweirio'r rhwydwaith. Ond i mi, wrth sefyll ar y podiwm, mae'n hawdd dweud hyn. Ond mae'r amgylchiadau'n golygu na all y cwsmer fforddio atgyweirio'r rhwydwaith bob amser. Efallai ei fod yn byw mewn DC ac efallai na fydd yn gallu atgyweirio'r rhwydwaith, effeithio ar yr offer. Ac felly mae angen rhai opsiynau eraill.
Mae yna opsiynau:
- Yr opsiwn symlaf, sydd wedi'i ysgrifennu, yn fy marn i, hyd yn oed yn y ddogfennaeth, yw analluogi gwiriadau Conswl, hynny yw, yn syml pasio amrywiaeth wag. Ac rydym yn dweud wrth yr asiant Conswl i beidio â defnyddio unrhyw wiriadau. Gyda'r gwiriadau hyn, gallwn anwybyddu'r stormydd rhwydwaith hyn a pheidio â chychwyn ffeiliwr.
- Opsiwn arall yw gwirio dwbl raft_multiplier. Mae hwn yn baramedr o'r gweinydd Conswl ei hun. Yn ddiofyn, fe'i gosodir i 5. Argymhellir y gwerth hwn gan y ddogfennaeth ar gyfer amgylcheddau llwyfannu. Mewn gwirionedd, mae hyn yn effeithio ar amlder y negeseuon rhwng aelodau'r rhwydwaith Conswl. Mewn gwirionedd, mae'r paramedr hwn yn effeithio ar gyflymder cyfathrebu gwasanaeth rhwng aelodau'r clwstwr Conswl. Ac ar gyfer cynhyrchu, argymhellir eisoes ei leihau fel bod y nodau'n cyfnewid negeseuon yn amlach.
- Opsiwn arall yr ydym wedi'i gynnig yw cynyddu blaenoriaeth prosesau Conswl ymhlith prosesau eraill ar gyfer amserlennydd prosesau'r system weithredu. Mae yna baramedr mor “neis”, mae'n pennu blaenoriaeth prosesau sy'n cael eu hystyried gan amserlennydd yr OS wrth amserlennu. Rydym hefyd wedi lleihau'r gwerth braf i asiantau Conswl, h.y. cynyddu'r flaenoriaeth fel bod y system weithredu yn rhoi mwy o amser i brosesau Conswl weithio a gweithredu eu cod. Yn ein hachos ni, roedd hyn yn datrys ein problem.
- Opsiwn arall yw peidio â defnyddio Conswl. Mae gen i ffrind sy'n gefnogwr mawr i Etcd. A dadleuwn ag ef yn gyson pa un sydd well Etcd or Consul. Ond o ran pa un sy'n well, rydym fel arfer yn cytuno ag ef bod gan Gonswl asiant a ddylai fod yn rhedeg ar bob nod gyda chronfa ddata. Hynny yw, mae rhyngweithio Patroni â'r clwstwr Conswl yn mynd trwy'r asiant hwn. Ac mae'r asiant hwn yn dod yn dagfa. Os bydd rhywbeth yn digwydd i'r asiant, yna ni all Patroni weithio gyda'r clwstwr Conswl mwyach. A dyma'r broblem. Nid oes asiant yn y cynllun Etcd. Gall Patroni weithio'n uniongyrchol gyda rhestr o weinyddion Etcd ac mae eisoes yn cyfathrebu â nhw. Yn hyn o beth, os ydych chi'n defnyddio Etcd yn eich cwmni, yna mae'n debyg y bydd Etcd yn well dewis na Conswl. Ond rydym ni yn ein cwsmeriaid bob amser yn gyfyngedig gan yr hyn y mae'r cleient wedi'i ddewis a'i ddefnyddio. Ac mae gennym Gonswl yn bennaf ar gyfer pob cleient.
- A'r pwynt olaf yw adolygu gwerthoedd y paramedr. Gallwn godi'r paramedrau hyn yn y gobaith y bydd ein problemau rhwydwaith tymor byr yn fyr ac na fyddant yn disgyn y tu allan i ystod y paramedrau hyn. Fel hyn gallwn leihau ymosodol Patroni i ffeilio'n awtomatig os bydd rhai problemau rhwydwaith yn digwydd.
Rwy'n credu bod llawer sy'n defnyddio Patroni yn gyfarwydd â'r gorchymyn hwn.
Mae'r gorchymyn hwn yn dangos cyflwr presennol y clwstwr. Ac ar yr olwg gyntaf, gall y llun hwn ymddangos yn normal. Mae gennym feistr, mae gennym atgynhyrchiad, nid oes oedi wrth ddyblygu. Ond mae'r llun hwn yn normal yn union nes ein bod yn gwybod y dylai fod gan y clwstwr hwn dri nod, nid dau.
Yn unol â hynny, roedd ffeil awtomatig. Ac ar ôl y ffeil auto hon, diflannodd ein replica. Mae angen inni ddarganfod pam y diflannodd hi a dod â hi yn ôl, ei hadfer. Ac rydyn ni eto'n mynd i'r logiau i weld pam roedd gennym ni drosglwyddiad ffeil awtomatig.
Yn yr achos hwn, daeth yr ail atgynhyrchiad yn feistr. Mae'r cyfan yn iawn yma.
Ac mae angen inni edrych ar y replica a ddisgynnodd ac nad yw yn y clwstwr. Rydym yn agor y logiau Patroni ac yn gweld bod gennym broblem yn ystod y broses o gysylltu â'r clwstwr yn y cam pg_rewind. I gysylltu â'r clwstwr, mae angen i chi ailddirwyn y log trafodion, gofyn am y log trafodion gofynnol gan y meistr, a'i ddefnyddio i ddal i fyny â'r meistr.
Yn yr achos hwn, nid oes gennym log trafodion ac ni all y replica ddechrau. Yn unol â hynny, rydym yn atal Postgres â gwall. Ac felly nid yw yn y clwstwr.
Mae angen inni ddeall pam nad yw yn y clwstwr a pham nad oedd unrhyw foncyffion. Rydyn ni'n mynd at y meistr newydd ac yn edrych beth sydd ganddo yn y logiau. Mae'n ymddangos bod pwynt gwirio wedi digwydd pan gafodd pg_rewind ei wneud. Ac ailenwyd rhai o'r hen logiau trafodion yn syml. Pan geisiodd yr hen feistr gysylltu â'r meistr newydd a chwestiynu'r logiau hyn, cawsant eu hail-enwi eisoes, nid oeddent yn bodoli.
Cymharais stampiau amser pan ddigwyddodd y digwyddiadau hyn. Ac yno mae'r gwahaniaeth yn llythrennol yn 150 milieiliad, hynny yw, y pwynt gwirio a gwblhawyd mewn 369 milieiliad, ailenwyd y segmentau WAL. Ac yn llythrennol yn 517, ar ôl 150 milieiliad, dechreuodd ailddirwyn ar yr hen replica. Hynny yw, yn llythrennol roedd 150 milieiliad yn ddigon i ni fel na allai'r replica gysylltu ac ennill.
Beth yw'r opsiynau?
Fe wnaethom ddefnyddio slotiau atgynhyrchu i ddechrau. Roeddem yn meddwl ei fod yn dda. Er ar y cam cyntaf, fe wnaethom ddiffodd y slotiau. Roedd yn ymddangos i ni, os bydd y slotiau'n cronni llawer o segmentau WAL, gallwn ollwng y meistr. Bydd yn cwympo. Buom yn dioddef am beth amser heb slotiau. A sylweddolon ni fod angen slotiau, fe wnaethon ni ddychwelyd y slotiau.
Ond mae yna broblem yma, pan fydd y meistr yn mynd i'r replica, mae'n dileu'r slotiau ac yn dileu'r segmentau WAL ynghyd â'r slotiau. Ac i ddileu'r broblem hon, fe benderfynon ni godi'r paramedr wal_keep_segments. Mae'n rhagosodedig i 8 segment. Fe wnaethom ei godi i 1 ac edrych ar faint o le rhydd oedd gennym ni. Ac fe wnaethom gyfrannu 000 gigabeit ar gyfer walk_keep_segments. Hynny yw, wrth newid, mae gennym bob amser gronfa wrth gefn o 16 gigabeit o logiau trafodion ar bob nod.
Ac yn ogystal - mae'n dal yn berthnasol ar gyfer tasgau cynnal a chadw hirdymor. Gadewch i ni ddweud bod angen inni ddiweddaru un o'r atgynyrchiadau. Ac rydym am ei ddiffodd. Mae angen i ni ddiweddaru'r meddalwedd, efallai y system weithredu, rhywbeth arall. A phan fyddwn yn diffodd replica, mae'r slot ar gyfer y replica hwnnw hefyd yn cael ei ddileu. Ac os byddwn yn defnyddio wal_keep_segments bach, yna gydag absenoldeb hir o atgynhyrchiad, bydd y logiau trafodion yn cael eu colli. Byddwn yn codi replica, bydd yn gofyn am y logiau trafodion hynny lle daeth i ben, ond efallai na fyddant ar y meistr. Ac ni fydd y replica yn gallu cysylltu ychwaith. Felly, rydym yn cadw stoc fawr o gylchgronau.
Mae gennym sylfaen gynhyrchu. Mae prosiectau ar y gweill eisoes.
Roedd ffeiliwr. Aethom i mewn ac edrych - mae popeth mewn trefn, mae'r atgynyrchiadau yn eu lle, nid oes oedi wrth ail-greu. Nid oes unrhyw wallau yn y logiau ychwaith, mae popeth mewn trefn.
Dywed y tîm cynnyrch y dylai fod rhywfaint o ddata, ond rydym yn ei weld o un ffynhonnell, ond nid ydym yn ei weld yn y gronfa ddata. Ac mae angen i ni ddeall beth ddigwyddodd iddyn nhw.
Mae’n amlwg bod pg_rewind wedi’u methu. Fe wnaethon ni ddeall hyn ar unwaith, ond aethon ni i weld beth oedd yn digwydd.
Yn y logiau, gallwn bob amser ddarganfod pryd y digwyddodd y ffeiliwr, pwy ddaeth yn feistr, a gallwn benderfynu pwy oedd yr hen feistr a phryd yr oedd am ddod yn replica, h.y. mae angen y logiau hyn arnom i ddarganfod faint o logiau trafodion sydd ei golli.
Mae ein hen feistr wedi ailgychwyn. Ac roedd Patroni wedi'i gofrestru yn yr autorun. Lansio Patroni. Yna dechreuodd Postgres. Yn fwy manwl gywir, cyn dechrau Postgres a chyn ei wneud yn atgynhyrchiad, lansiodd Patroni y broses pg_rewind. Yn unol â hynny, fe wnaeth ddileu rhan o'r logiau trafodion, lawrlwytho rhai newydd a'u cysylltu. Yma gweithiodd Patroni yn smart, hynny yw, yn ôl y disgwyl. Mae'r clwstwr wedi'i adfer. Cawsom 3 nod, ar ôl y ffeiliwr 3 nod - mae popeth yn cŵl.
Rydym wedi colli rhywfaint o ddata. Ac mae angen i ni ddeall faint rydyn ni wedi'i golli. Rydym yn chwilio am yr eiliad pan gawsom ailddirwyn. Gallwn ddod o hyd iddo mewn cofnodion dyddlyfr o'r fath. Dechreuodd ailddirwyn, gwneud rhywbeth yno a gorffen.
Mae angen inni ddod o hyd i'r sefyllfa yn y log trafodion lle gadawodd yr hen feistr i ffwrdd. Yn yr achos hwn, dyma'r marc. Ac mae arnom angen ail farc, hynny yw, y pellter y mae'r hen feistr yn wahanol i'r un newydd.
Rydym yn cymryd y pg_wal_lsn_diff arferol ac yn cymharu'r ddau farc hyn. Ac yn yr achos hwn, rydym yn cael 17 megabeit. Llawer neu ychydig, mae pawb yn penderfynu drosto'i hun. Oherwydd i rywun nid yw 17 megabeit yn llawer, i rywun mae'n llawer ac yn annerbyniol. Yma, mae pob unigolyn yn penderfynu drosto'i hun yn unol ag anghenion y busnes.
Ond beth ydyn ni wedi'i ddarganfod drosom ein hunain?
Yn gyntaf, mae'n rhaid i ni benderfynu drosom ein hunain - a oes angen Patroni bob amser i gychwyn yn awtomatig ar ôl ailgychwyn system? Mae'n digwydd yn aml bod yn rhaid i ni fynd at yr hen feistr, gweld pa mor bell y mae wedi mynd. Efallai archwilio segmentau o'r log trafodion, gweld beth sydd yno. Ac i ddeall a allwn golli'r data hwn neu a oes angen i ni redeg yr hen feistr yn y modd annibynnol er mwyn tynnu'r data hwn allan.
A dim ond ar ôl hynny y mae'n rhaid i ni benderfynu a allwn daflu'r data hwn neu a allwn ei adfer, cysylltu'r nod hwn fel replica i'n clwstwr.
Yn ogystal, mae paramedr "maximum_lag_on_failover". Yn ddiofyn, os yw fy nghof yn fy ngwasanaethu, mae gan y paramedr hwn werth 1 megabeit.
Sut mae e'n gweithio? Os yw ein hatgynhyrchiad ar ei hôl hi o 1 megabeit o ddata yn yr oedi wrth ailgynhyrchu, yna nid yw'r atgynhyrchiad hwn yn cymryd rhan yn yr etholiadau. Ac os yn sydyn mae yna ffeil drosodd, mae Patroni yn edrych ar ba atgynyrchiadau sydd ar ei hôl hi. Os ydynt ar ei hôl hi gan nifer fawr o logiau trafodion, ni allant ddod yn feistr. Mae hon yn nodwedd ddiogelwch dda iawn sy'n eich atal rhag colli llawer o ddata.
Ond mae problem gan fod yr oedi wrth ddyblygu yng nghlwstwr Patroni a DCS yn cael ei ddiweddaru ar gyfnod penodol. Rwy'n meddwl mai 30 eiliad yw'r gwerth ttl rhagosodedig.
Yn unol â hynny, efallai y bydd sefyllfa lle mae un oedi o ran dyblygu ar gyfer atgynyrchiadau yn y DCS, ond mewn gwirionedd gall fod oedi hollol wahanol neu efallai nad oes oedi o gwbl, h.y. nid yw’r peth hwn yn amser real. Ac nid yw bob amser yn adlewyrchu'r darlun go iawn. Ac nid yw'n werth gwneud rhesymeg ffansi arno.
Ac erys y risg o golled bob amser. Ac yn yr achos gwaethaf, un fformiwla, ac yn yr achos cyffredin, fformiwla arall. Hynny yw, pan fyddwn yn cynllunio gweithrediad Patroni ac yn gwerthuso faint o ddata y gallwn ei golli, rhaid inni ddibynnu ar y fformiwlâu hyn a dychmygu'n fras faint o ddata y gallwn ei golli.
Ac mae yna newyddion da. Pan fydd yr hen feistr wedi mynd yn ei flaen, gall fynd ymlaen oherwydd rhai prosesau cefndir. Hynny yw, roedd rhyw fath o autovacuum, ysgrifennodd y data, arbed nhw i'r log trafodion. A gallwn yn hawdd anwybyddu a cholli'r data hwn. Nid oes problem yn hyn.
A dyma sut mae'r logiau'n edrych fel pe bai maximum_lag_on_failover wedi'i osod a bod ffeiliwr wedi digwydd, a bod angen i chi ddewis meistr newydd. Mae'r replica yn asesu ei hun yn analluog i gymryd rhan yn yr etholiadau. Ac mae hi'n gwrthod cymryd rhan yn y ras am yr arweinydd. Ac mae hi'n aros i feistr newydd gael ei ddewis, fel y gall hi wedyn gysylltu ag ef. Mae hwn yn fesur ychwanegol yn erbyn colli data.
Yma mae gennym dîm cynnyrch a ysgrifennodd fod eu cynnyrch yn cael problemau gyda Postgres. Ar yr un pryd, ni ellir cyrchu'r meistr ei hun, oherwydd nid yw ar gael trwy SSH. Ac nid yw'r ffeil awtomatig yn digwydd ychwaith.
Gorfodwyd y gwesteiwr hwn i ailgychwyn. Oherwydd yr ailgychwyn, digwyddodd ffeil auto, er ei bod yn bosibl gwneud ffeil auto â llaw, fel yr wyf yn deall nawr. Ac ar ôl yr ailgychwyn, rydym eisoes yn mynd i weld beth oedd gennym gyda'r meistr presennol.
Ar yr un pryd, roeddem yn gwybod ymlaen llaw bod gennym broblemau gyda disgiau, hynny yw, roeddem eisoes yn gwybod o fonitro ble i gloddio a beth i'w chwilio.
Fe wnaethon ni fynd i mewn i'r log postgres, dechrau gweld beth oedd yn digwydd yno. Gwelsom ymrwymiadau sy'n para yno am un, dwy, tair eiliad, nad yw'n normal o gwbl. Gwelsom fod ein autovacuum yn cychwyn yn araf ac yn rhyfedd iawn. A gwelsom ffeiliau dros dro ar y ddisg. Hynny yw, mae'r rhain i gyd yn ddangosyddion o broblemau gyda disgiau.
Edrychon ni i mewn i'r system dmesg (log cnewyllyn). A gwelsom fod gennym broblemau gydag un o'r disgiau. Yr is-system ddisg oedd meddalwedd Raid. Edrychon ni ar /proc/mdstat a gweld ein bod ni'n methu un gyriant. Hynny yw, mae Cyrch o 8 disg, rydym yn colli un. Os edrychwch yn ofalus ar y sleid, yna yn yr allbwn gallwch weld nad oes gennym ni sde yno. Ynom ni, yn amodol, mae'r ddisg wedi gollwng. Sbardunodd hyn broblemau disg, a chafodd cymwysiadau broblemau hefyd wrth weithio gyda chlwstwr Postgres.
Ac yn yr achos hwn, ni fyddai Patroni yn ein helpu mewn unrhyw ffordd, oherwydd nid oes gan Patroni y dasg o fonitro cyflwr y gweinydd, cyflwr y ddisg. A rhaid inni fonitro sefyllfaoedd o'r fath drwy fonitro allanol. Fe wnaethom ychwanegu monitro disg yn gyflym at fonitro allanol.
Ac roedd cymaint o feddwl - a allai ffensio neu feddalwedd corff gwarchod ein helpu ni? Roeddem yn meddwl mai prin y byddai wedi ein helpu yn yr achos hwn, oherwydd yn ystod y problemau parhaodd Patroni i ryngweithio â chlwstwr y DCS ac ni welodd unrhyw broblem. Hynny yw, o safbwynt DCS a Patroni, roedd popeth yn iawn gyda'r clwstwr, er mewn gwirionedd roedd problemau gyda'r ddisg, roedd problemau gydag argaeledd y gronfa ddata.
Yn fy marn i, dyma un o'r problemau rhyfeddaf yr wyf wedi ymchwilio iddynt ers amser maith, rwyf wedi darllen llawer o logiau, wedi ail-ddewis a'i alw'n efelychydd clwstwr.
Y broblem oedd na allai'r hen feistr ddod yn atgynhyrchiad arferol, h.y. dechreuodd Patroni ef, dangosodd Patroni fod y nod hwn yn bresennol fel replica, ond ar yr un pryd nid oedd yn replica arferol. Nawr fe welwch pam. Dyma'r hyn yr wyf wedi'i gadw o'r dadansoddiad o'r broblem honno.
A sut ddechreuodd y cyfan? Dechreuodd, fel yn y broblem flaenorol, gyda breciau disg. Cawsom ymrwymiadau am eiliad, dau.
Roedd toriadau mewn cysylltiadau, h.y., roedd cleientiaid yn cael eu rhwygo.
Roedd rhwystrau o ddifrifoldeb amrywiol.
Ac, yn unol â hynny, nid yw'r is-system ddisg yn ymatebol iawn.
A'r peth mwyaf dirgel i mi yw'r cais cau i lawr ar unwaith a gyrhaeddodd. Mae gan Postgres dri dull cau:
- Mae'n osgeiddig pan fyddwn yn aros i bob cleient ddatgysylltu ar eu pen eu hunain.
- Mae yna gyflym pan rydyn ni'n gorfodi cleientiaid i ddatgysylltu oherwydd rydyn ni'n mynd i gau.
- Ac ar unwaith. Yn yr achos hwn, nid yw ar unwaith hyd yn oed yn dweud wrth gleientiaid am gau, mae'n cau i lawr heb rybudd. Ac i bob cleient, mae'r system weithredu eisoes yn anfon neges RST (neges TCP bod y cysylltiad yn cael ei dorri ac nad oes gan y cleient ddim mwy i'w ddal).
Pwy anfonodd y signal hwn? Nid yw prosesau cefndir Postgres yn anfon signalau o'r fath at ei gilydd, h.y. lladd-9 yw hwn. Nid ydyn nhw'n anfon pethau o'r fath at ei gilydd, dim ond i bethau o'r fath maen nhw'n ymateb, hy mae hwn yn ailgychwyn brys o Postgres. Pwy anfonodd, wn i ddim.
Edrychais ar y gorchymyn "olaf" a gwelais un person sydd hefyd wedi mewngofnodi i'r gweinydd hwn gyda ni, ond roeddwn i'n rhy swil i ofyn cwestiwn. Efallai mai lladd oedd -9. Byddwn yn gweld lladd -9 yn y logiau, oherwydd Dywed Postgres iddo gymryd lladd -9, ond ni welais ef yn y boncyffion.
Wrth edrych ymhellach, gwelais nad oedd Patroni wedi ysgrifennu at y log am gyfnod eithaf hir - 54 eiliad. Ac os ydym yn cymharu dau stamp amser, nid oedd unrhyw negeseuon am tua 54 eiliad.
Ac yn ystod y cyfnod hwn roedd ffeil awtomatig. Gwnaeth Patroni waith gwych yma eto. Nid oedd ein hen feistr ar gael, digwyddodd rhywbeth iddo. A dechreuodd ethol meistr newydd. Gweithiodd popeth yn dda yma. Mae ein pgsql01 wedi dod yn arweinydd newydd.
Mae gennym replica sydd wedi dod yn feistr. Ac mae ail ymateb. Ac roedd problemau gyda'r ail replica. Ceisiodd ad-drefnu. Fel y deallaf, ceisiodd newid recovery.conf, ailgychwyn Postgres a chysylltu â'r meistr newydd. Mae hi'n ysgrifennu negeseuon bob 10 eiliad y mae'n ceisio, ond nid yw'n llwyddo.
Ac yn ystod yr ymdrechion hyn, mae signal cau ar unwaith yn cyrraedd yr hen feistr. Mae'r meistr yn cael ei ailgychwyn. Ac mae adferiad hefyd yn stopio oherwydd bod yr hen feistr yn mynd i ailgychwyn. Hynny yw, ni all y replica gysylltu ag ef, oherwydd ei fod yn y modd diffodd.
Ar ryw adeg, fe weithiodd, ond ni ddechreuodd ail-greu.
Fy unig ddyfaliad yw bod hen gyfeiriad meistr yn recovery.conf. A phan ymddangosodd meistr newydd, roedd yr ail atgynhyrchiad yn dal i geisio cysylltu â'r hen feistr.
Pan ddechreuodd Patroni ar yr ail atgynhyrchiad, cychwynnodd y nod ond ni allai ddyblygu. A ffurfiwyd oedi atgynhyrchu, a oedd yn edrych yn debyg i hyn. Hynny yw, roedd y tri nod yn eu lle, ond roedd yr ail nod ar ei hôl hi.
Ar yr un pryd, os edrychwch ar y logiau a ysgrifennwyd, gallech weld na allai ail-greu ddechrau oherwydd bod y logiau trafodion yn wahanol. Ac nid yw'r logiau trafodion hynny y mae'r meistr yn eu cynnig, a nodir yn recovery.conf, yn cyd-fynd â'n nod cyfredol.
A dyma fi wedi gwneud camgymeriad. Roedd yn rhaid i mi ddod i weld beth oedd yn recovery.conf i brofi fy rhagdybiaeth ein bod yn cysylltu â'r meistr anghywir. Ond yna roeddwn i'n delio â hyn yn unig ac ni ddigwyddodd i mi, neu gwelais fod y replica ar ei hôl hi ac y byddai'n rhaid ei ail-lenwi, hynny yw, fe wnes i weithio'n ddiofal rywsut. Hwn oedd fy nghyd.
Ar ôl 30 munud, daeth y gweinyddwr eisoes, h.y. ailgychwynnais Patroni ar y replica. Rwyf eisoes wedi rhoi terfyn arno, roeddwn i'n meddwl y byddai'n rhaid ei ail-lenwi. Ac yr wyf yn meddwl - 'n annhymerus' ailddechrau Patroni, efallai y bydd rhywbeth da yn troi allan. Dechreuwyd adferiad. Ac agorodd y sylfaen hyd yn oed, roedd yn barod i dderbyn cysylltiadau.
Mae atgynhyrchu wedi dechrau. Ond funud yn ddiweddarach syrthiodd i ffwrdd gyda gwall nad yw logiau trafodion yn addas iddi.
Roeddwn i'n meddwl y byddwn i'n ailgychwyn eto. Fe wnes i ailgychwyn Patroni eto, ac ni wnes i ailgychwyn Postgres, ond ailgychwyn Patroni yn y gobaith y byddai'n cychwyn y gronfa ddata yn hudol.
Dechreuodd y dyblygu eto, ond roedd y marciau yn y log trafodion yn wahanol, nid oeddent yr un peth â'r ymgais gychwyn flaenorol. Stopiwyd dyblygu eto. Ac roedd y neges eisoes ychydig yn wahanol. Ac nid oedd yn addysgiadol iawn i mi.
Ac yna mae'n digwydd i mi - beth os byddaf yn ailgychwyn Postgres, ar yr adeg hon rwy'n gwneud pwynt gwirio ar y meistr presennol i symud y pwynt yn y log trafodion ychydig ymlaen fel bod adferiad yn dechrau o eiliad arall? Hefyd, roedd gennym stociau o WAL o hyd.
Fe wnes i ailgychwyn Patroni, gwneud cwpl o bwyntiau gwirio ar y meistr, cwpl o bwyntiau ailgychwyn ar y replica pan agorodd. Ac fe helpodd. Roeddwn i'n meddwl am amser hir pam ei fod wedi helpu a sut roedd yn gweithio. A dechreuodd y replica. Ac nid oedd atgynhyrchu bellach wedi'i rwygo.
Mae problem o'r fath i mi yn un o'r rhai mwyaf dirgel, ac rwy'n dal i bendroni dros yr hyn a ddigwyddodd yno mewn gwirionedd.
Beth yw'r goblygiadau yma? Gall Patroni weithio yn ôl y bwriad a heb unrhyw wallau. Ond ar yr un pryd, nid yw hyn yn warant 100% bod popeth yn iawn gyda ni. Gall y replica ddechrau, ond gall fod mewn cyflwr lled-weithio, ac ni all y cais weithio gyda replica o'r fath, oherwydd bydd hen ddata.
Ac ar ôl y ffeiliwr, mae angen i chi bob amser wirio bod popeth mewn trefn gyda'r clwstwr, hynny yw, mae'r nifer ofynnol o atgynyrchiadau, nid oes oedi wrth ailadrodd.
Ac wrth inni fynd drwy'r materion hyn, byddaf yn gwneud argymhellion. Ceisiais eu cyfuno'n ddwy sleid. Yn ôl pob tebyg, gellid cyfuno'r holl straeon yn ddwy sleid a'u hadrodd yn unig.
Pan fyddwch chi'n defnyddio Patroni, rhaid i chi gael monitro. Dylech bob amser wybod pryd y digwyddodd awtoffeiloverover, oherwydd os nad ydych yn gwybod eich bod wedi cael awtoffeil drosodd, nid oes gennych unrhyw reolaeth dros y clwstwr. Ac mae hynny'n ddrwg.
Ar ôl pob ffeiliwr, mae'n rhaid i ni wirio'r clwstwr â llaw bob amser. Mae angen i ni wneud yn siŵr bod gennym ni'r nifer gyfredol o atgynyrchiadau bob amser, nid oes oedi wrth ail-greu, nid oes unrhyw wallau yn y logiau sy'n ymwneud â ffrydio, gyda Patroni, gyda'r system DCS.
Gall awtomeiddio weithio'n llwyddiannus, mae Patroni yn offeryn da iawn. Gall weithio, ond ni fydd hyn yn dod â'r clwstwr i'r cyflwr dymunol. Ac os na fyddwn yn dod i wybod amdano, byddwn mewn trafferth.
Ac nid bwled arian yw Patroni. Mae angen i ni ddeall o hyd sut mae Postgres yn gweithio, sut mae atgynhyrchu'n gweithio a sut mae Patroni yn gweithio gyda Postgres, a sut mae cyfathrebu rhwng nodau yn cael ei ddarparu. Mae hyn yn angenrheidiol er mwyn gallu trwsio problemau gyda'ch dwylo.
Sut ydw i'n ymdrin â mater diagnosis? Digwyddodd felly ein bod ni'n gweithio gyda gwahanol gleientiaid ac nid oes gan neb bentwr ELK, ac mae'n rhaid i ni ddatrys y logiau trwy agor 6 consol a 2 dab. Mewn un tab, dyma'r logiau Patroni ar gyfer pob nod, yn y tab arall, dyma'r logiau Conswl, neu Postgres os oes angen. Mae'n anodd iawn gwneud diagnosis o hyn.
Pa ddulliau rwyf wedi'u cymryd? Yn gyntaf, rwyf bob amser yn edrych pan fydd y ffeiliwr wedi cyrraedd. Ac i mi dyma drothwy. Edrychaf ar yr hyn a ddigwyddodd cyn y ffeiliwr, yn ystod y ffeiliwr ac ar ôl y ffeiliwr. Mae gan y ffeil drosodd ddau farc: dyma'r amser dechrau a gorffen.
Nesaf, edrychaf yn y logiau am ddigwyddiadau cyn y ffeiliwr, a ragflaenodd y ffeiliwr, h.y. edrychaf am y rhesymau pam y digwyddodd y ffeiliwr.
Ac mae hyn yn rhoi darlun o ddeall beth ddigwyddodd a beth y gellir ei wneud yn y dyfodol fel na fydd amgylchiadau o'r fath yn digwydd (ac o ganlyniad, nid oes ffeiliwr).
A ble rydyn ni'n edrych fel arfer? Rwy'n edrych:
- Yn gyntaf, i logiau Patroni.
- Nesaf, edrychaf ar y logiau Postgres, neu'r logiau DCS, yn dibynnu ar yr hyn a ddarganfuwyd yn y logiau Patroni.
- Ac mae logiau'r system weithiau hefyd yn rhoi dealltwriaeth o'r hyn a achosodd y ffeiliwr.
Sut ydw i'n teimlo am Patroni? Mae gen i berthynas dda iawn gyda Patroni. Yn fy marn i, dyma'r gorau sydd yna heddiw. Rwy'n gwybod llawer o gynhyrchion eraill. Y rhain yw Stolon, Repmgr, Pg_auto_failover, PAF. 4 offer. Rhoddais gynnig arnynt i gyd. Patroni yw fy ffefryn.
Os ydyn nhw'n gofyn i mi: "Ydw i'n argymell Patroni?". Byddaf yn dweud ydw, oherwydd rwy'n hoffi Patroni. A dwi'n meddwl i mi ddysgu sut i'w goginio.
Os oes gennych ddiddordeb mewn gweld pa broblemau eraill sydd gyda Patroni ar wahân i'r problemau yr wyf wedi sôn amdanynt, gallwch chi bob amser edrych ar y dudalen ar GitHub. Mae llawer o straeon gwahanol a llawer o faterion diddorol yn cael eu trafod yno. Ac o ganlyniad, cyflwynwyd a datryswyd rhai chwilod, hynny yw, mae hwn yn ddarlleniad diddorol.
Mae yna rai straeon difyr am bobl yn saethu eu hunain yn eu traed. Addysgiadol iawn. Rydych chi'n darllen ac yn deall nad oes angen gwneud hynny. Fe wnes i dicio fy hun.
A hoffwn ddiolch yn fawr iawn i Zalando am ddatblygu'r prosiect hwn, sef i Alexander Kukushkin ac Alexey Klyukin. Mae Aleksey Klyukin yn un o'r cyd-awduron, nid yw bellach yn gweithio yn Zalando, ond dyma ddau berson a ddechreuodd weithio gyda'r cynnyrch hwn.
A dwi’n meddwl bod Patroni yn beth cwl iawn. Rwy'n hapus ei bod hi'n bodoli, mae'n ddiddorol gyda hi. A diolch yn fawr iawn i'r holl gyfranwyr sy'n ysgrifennu clytiau i Patroni. Gobeithio y daw Patroni yn fwy aeddfed, cŵl ac effeithlon gydag oedran. Mae eisoes yn weithredol, ond rwy'n gobeithio y bydd yn gwella hyd yn oed. Felly, os ydych chi'n bwriadu defnyddio Patroni, peidiwch â bod ofn. Mae hwn yn ateb da, gellir ei weithredu a'i ddefnyddio.
Dyna i gyd. Os oes gennych gwestiynau, gofynnwch.
cwestiynau
Diolch am yr adroddiad! Os bydd angen ichi edrych yn ofalus iawn ar ôl ffeiliwr, yna pam fod angen ffeiliwr awtomatig arnom?
Achos mae'n stwff newydd. Dim ond ers blwyddyn rydyn ni wedi bod gyda hi. Gwell bod yn ddiogel. Rydyn ni eisiau dod i mewn a gweld bod popeth wedi gweithio allan fel y dylai. Dyma lefel diffyg ymddiriedaeth oedolion - mae'n well gwirio a gweld ddwywaith.
Er enghraifft, aethon ni yn y bore ac edrych, iawn?
Nid yn y bore, rydym fel arfer yn dysgu am y ffeil awtomatig bron ar unwaith. Rydym yn derbyn hysbysiadau, rydym yn gweld bod ffeil awtomatig wedi digwydd. Rydym bron yn syth yn mynd i edrych. Ond dylid dod â'r holl wiriadau hyn i'r lefel fonitro. Os ydych chi'n cyrchu Patroni trwy'r API REST, mae yna hanes. Yn ôl hanes gallwch weld y stampiau amser pan ddigwyddodd y ffeiliwr. Yn seiliedig ar hyn, gellir monitro. Gallwch weld yr hanes, faint o ddigwyddiadau oedd yno. Os oes gennym fwy o ddigwyddiadau, yna mae ffeil awtomatig wedi digwydd. Gallwch chi fynd i weld. Neu fe wnaeth ein awtomeiddio monitro wirio bod gennym yr holl atgynyrchiadau yn eu lle, nad oes oedi ac mae popeth yn iawn.
Diolch yn fawr!
Diolch yn fawr am y stori wych! Pe baem yn symud y clwstwr DCS i rywle ymhell o glwstwr Postgres, yna mae angen gwasanaethu'r clwstwr hwn o bryd i'w gilydd hefyd? Beth yw'r arferion gorau y mae angen i rai darnau o'r clwstwr DCS eu diffodd, rhywbeth i'w wneud â nhw, ac ati? Sut mae'r strwythur cyfan hwn yn goroesi? A sut ydych chi'n gwneud y pethau hyn?
Ar gyfer un cwmni, roedd angen gwneud matrics o broblemau, beth sy'n digwydd os bydd un o'r cydrannau neu sawl cydran yn methu. Yn ôl y matrics hwn, rydym yn dilyn yr holl gydrannau ac yn adeiladu senarios rhag ofn y bydd y cydrannau hyn yn methu. Yn unol â hynny, ar gyfer pob senario methiant, gallwch gael cynllun gweithredu ar gyfer adferiad. Ac yn achos DCS, daw fel rhan o'r seilwaith safonol. Ac mae'r gweinyddwr yn ei weinyddu, ac rydym eisoes yn dibynnu ar y gweinyddwyr sy'n ei weinyddu a'u gallu i'w drwsio rhag ofn y bydd damweiniau. Os nad oes DCS o gwbl, yna rydym yn ei ddefnyddio, ond ar yr un pryd nid ydym yn ei fonitro'n arbennig, oherwydd nid ydym yn gyfrifol am y seilwaith, ond rydym yn rhoi argymhellion ar sut a beth i'w fonitro.
Hynny yw, a wnes i ddeall yn iawn bod angen i mi analluogi Patroni, analluogi'r ffeiliwr, analluogi popeth cyn gwneud unrhyw beth gyda'r gwesteiwyr?
Mae'n dibynnu ar faint o nodau sydd gennym yn y clwstwr DCS. Os oes llawer o nodau ac os ydym yn analluogi dim ond un o'r nodau (y replica), yna mae'r clwstwr yn cynnal cworwm. Ac mae Patroni yn parhau i fod yn weithredol. Ac nid oes dim yn cael ei sbarduno. Os oes gennym rai gweithrediadau cymhleth sy'n effeithio ar fwy o nodau, a gall eu diffyg ddifetha'r cworwm, yna - ie, efallai y byddai'n gwneud synnwyr i roi Patroni ar saib. Mae ganddo orchymyn cyfatebol - patronictl pause, patronictl resume. Rydyn ni'n oedi ac nid yw'r autofiler yn gweithio bryd hynny. Rydyn ni'n gwneud gwaith cynnal a chadw ar y clwstwr DCS, yna rydyn ni'n tynnu'r saib ac yn parhau i fyw.
Dim byd!
Diolch yn fawr iawn am eich adroddiad! Sut mae'r tîm cynnyrch yn teimlo am golli data?
Nid oes ots gan dimau cynnyrch, ac mae arweinwyr tîm yn poeni.
Pa warantau sydd?
Mae gwarantau yn anodd iawn. Mae gan Alexander Kukushkin adroddiad “Sut i gyfrifo RPO a RTO”, h.y. amser adfer a faint o ddata y gallwn ei golli. Rwy'n meddwl bod angen i ni ddod o hyd i'r sleidiau hyn a'u hastudio. Hyd y cofiaf, mae camau penodol ar sut i gyfrifo'r pethau hyn. Faint o drafodion y gallwn eu colli, faint o ddata y gallwn ei golli. Fel opsiwn, gallwn ddefnyddio atgynhyrchu cydamserol ar lefel Patroni, ond cleddyf dau ymyl yw hwn: naill ai mae gennym ddibynadwyedd data, neu rydym yn colli cyflymder. Mae yna ddyblygiad cydamserol, ond nid yw ychwaith yn gwarantu amddiffyniad 100% yn erbyn colli data.
Alexey, diolch am yr adroddiad gwych! Unrhyw brofiad o ddefnyddio Patroni ar gyfer amddiffyniad lefel sero? Hynny yw, ar y cyd â standby cydamserol? Dyma'r cwestiwn cyntaf. A'r ail gwestiwn. Rydych chi wedi defnyddio atebion gwahanol. Fe wnaethon ni ddefnyddio Repmgr, ond heb autofiler, a nawr rydyn ni'n bwriadu cynnwys autofiler. Ac rydym yn ystyried Patroni fel ateb amgen. Beth allwch chi ei ddweud fel manteision o gymharu â Repmgr?
Roedd y cwestiwn cyntaf yn ymwneud â chopïau cydamserol. Nid oes unrhyw un yn defnyddio dyblygu cydamserol yma, oherwydd mae ofn ar bawb (Mae sawl cleient eisoes yn ei ddefnyddio, mewn egwyddor, ni wnaethant sylwi ar broblemau perfformiad - Nodyn y siaradwr). Ond rydym wedi datblygu rheol i ni ein hunain y dylai fod o leiaf dri nod mewn clwstwr atgynhyrchu cydamserol, oherwydd os oes gennym ddau nod ac os bydd y meistr neu'r replica yn methu, yna mae Patroni yn newid y nod hwn i fodd Standalone fel bod y cais yn parhau i gwaith. Yn yr achos hwn, mae risg o golli data.
O ran yr ail gwestiwn, rydym wedi defnyddio Repmgr ac yn dal i wneud gyda rhai cleientiaid am resymau hanesyddol. Beth ellir ei ddweud? Daw Patroni ag autofiler allan o'r bocs, daw Repmgr ag autofiler fel nodwedd ychwanegol y mae angen ei galluogi. Mae angen i ni redeg y daemon Repmgr ar bob nod ac yna gallwn ffurfweddu'r autofiler.
Mae Repmgr yn gwirio a yw nodau Postgres yn fyw. Mae prosesau Repmgr yn gwirio bodolaeth ei gilydd, nid yw hwn yn ddull effeithlon iawn. gall fod achosion cymhleth o ynysu rhwydwaith lle gall clwstwr Repmgr mawr ddisgyn ar wahân i nifer o rai llai a pharhau i weithio. Nid wyf wedi bod yn dilyn Repmgr ers amser maith, efallai ei fod yn sefydlog ... neu efallai ddim. Ond dileu gwybodaeth am gyflwr y clwstwr yn DCS, fel y mae Stolon, Patroni yn ei wneud, yw'r opsiwn mwyaf hyfyw.
Alexey, mae gennyf gwestiwn, efallai un lamer. Yn un o'r enghreifftiau cyntaf, fe wnaethoch chi symud DCS o'r peiriant lleol i westeiwr anghysbell. Rydym yn deall bod y rhwydwaith yn beth sydd â'i nodweddion ei hun, mae'n byw ar ei ben ei hun. A beth fydd yn digwydd os na fydd y clwstwr DCS ar gael am ryw reswm? Ni ddywedaf y rhesymau, gall fod llawer ohonynt: o ddwylo cam rhwydweithwyr i broblemau gwirioneddol.
Wnes i ddim ei ddweud yn uchel, ond mae’n rhaid i’r clwstwr DCS fod yn fethiant hefyd, h.y. mae’n odrif o nodau, er mwyn cyrraedd cworwm. Beth fydd yn digwydd os na fydd y clwstwr DCS ar gael, neu os na ellir bodloni cworwm, h.y. rhyw fath o hollt rhwydwaith neu fethiant nodau? Yn yr achos hwn, mae clwstwr Patroni yn mynd i fodd darllen yn unig. Ni all clwstwr Patroni bennu cyflwr y clwstwr a beth i'w wneud. Ni all gysylltu â'r DCS a storio'r cyflwr clwstwr newydd yno, felly mae'r clwstwr cyfan yn mynd i ddarllen yn unig. Ac yn aros naill ai am ymyrraeth â llaw gan y gweithredwr neu i DCS adfer.
Yn fras, mae DCS yn dod yn wasanaeth yr un mor bwysig i ni â'r ganolfan ei hun?
Ydy Ydy. Mewn cymaint o gwmnïau modern, mae Darganfod Gwasanaeth yn rhan annatod o'r seilwaith. Mae'n cael ei weithredu hyd yn oed cyn bod cronfa ddata yn y seilwaith hyd yn oed. Yn gymharol siarad, lansiwyd y seilwaith, ei ddefnyddio yn y DC, ac mae gennym Ddarganfod Gwasanaeth ar unwaith. Os mai Conswl ydyw, yna gellir adeiladu DNS arno. Os yw hyn yn Etcd, yna efallai y bydd rhan o glwstwr Kubernetes, lle bydd popeth arall yn cael ei ddefnyddio. Mae’n ymddangos i mi fod Darganfod Gwasanaeth eisoes yn rhan annatod o seilweithiau modern. Ac maen nhw'n meddwl amdano'n llawer cynharach nag am gronfeydd data.
Diolch yn fawr!
Ffynhonnell: hab.com