Armanca sereke ya Patroni ev e ku ji bo PostgreSQL Hebûna Bilind peyda bike. Lê Patroni tenê şablonek e, ne amûrek amade ye (ku, bi gelemperî, di belgeyê de tê gotin). Di nihêrîna pêşîn de, ku Patroni di laboratûara ceribandinê de saz kir, hûn dikarin bibînin ka ew çi amûrek hêja ye û ew çiqas bi hêsanî hewildanên me yên ji bo şikandina komê digire dest. Lêbelê, di pratîkê de, di hawîrdorek hilberînê de, her tişt her gav bi qasî di laboratuarek ceribandinê de bi xweşikî û xweşik çênabe.
Ez ê hinekî behsa xwe bikim. Min wekî rêveberê pergalê dest pê kir. Di pêşkeftina malperê de xebitî. Ez ji sala 2014an vir ve li Data Egret dixebitim. Pargîdanî di warê Postgres de bi şêwirmendiyê re mijûl e. Û em tam Postgres re xizmetê dikin, û em her roj bi Postgres re dixebitin, ji ber vê yekê pisporên me yên cûda yên têkildarî operasyonê hene.
Û di dawiya 2018 de, me hêdî hêdî dest bi karanîna Patroni kir. Û hinek tecrûbe hatiye berhevkirin. Me bi rengekî ew teşhîs kir, guhezand, hatin pratîkên xwe yên çêtirîn. Û di vê raporê de ez ê behsa wan bikim.
Ji bilî Postgres, ez ji Linux hez dikim. Ez hez dikim li dora wê bigerim û bigerim, ez hez dikim kok berhev bikim. Ez ji virtualbûnê, konteyneran, docker, Kubernetes hez dikim. Hemî ev min eleqedar dike, ji ber ku adetên admîn ên kevn bandor dikin. Ez dixwazim bi çavdêriyê re mijûl bibim. Û ez ji tiştên postgres ên girêdayî rêveberiyê hez dikim, ango dubarekirin, paşvekişandin. Û di dema xwe ya vala de ez di Go de dinivîsim. Ez ne endezyarek nermalavê me, ez tenê ji bo xwe di Go de dinivîsim. Û kêfê dide min.
- Ez difikirim ku gelek ji we dizanin ku Postgres HA (Hebûna Bilind) ji qutîkê nîne. Ji bo bidestxistina HA, hûn hewce ne ku tiştek saz bikin, mîheng bikin, hewl bidin û wê bigirin.
- Gelek amûr hene û Patroni yek ji wan e ku HA pir xweş û pir baş çareser dike. Lê bi danîna wê hemî li laboratûvarek ceribandinê û xebitandina wê, em dikarin bibînin ku ew hemî kar dike, em dikarin hin pirsgirêkan dubare bikin, bibînin ka Patroni çawa ji wan re xizmet dike. Û em ê bibînin ku ew hemî baş dixebite.
- Lê di pratîkê de em bi pirsgirêkên cuda re rû bi rû man. Û ez ê behsa van pirsgirêkan bikim.
- Ez ê ji we re vebêjim ka me ew çawa teşhîs kir, me çi tweak kir - gelo ew alîkariya me kir an na.
- Ez ê ji we re nebêjim ka meriv çawa Patroni saz dike, ji ber ku hûn dikarin li ser Înternetê google bikin, hûn dikarin li pelên mîhengê binihêrin da ku fêm bikin ka ew hemî çawa dest pê dike, çawa tê mîheng kirin. Hûn dikarin nexşe, mîmarî, li ser Înternetê agahdariya li ser wê bibînin.
- Ez ê qala serpêhatiya kesekî din nekim. Ez ê tenê li ser pirsgirêkên ku em pê re rû bi rû mane biaxivim.
- Û ez ê li ser pirsgirêkên ku li derveyî Patroni û PostgreSQL ne biaxivim. Ger, bo nimûne, pirsgirêkên bi hevsengiyê re têkildar bin, dema ku koma me hilweşiya, ez ê qala wê nekim.
Û berî ku em dest bi raporta xwe bikin, nerazîbûnek piçûk.
Ev hemû pirsgirêkên ku em rastî wan hatin, di 6-7-8 mehên destpêkê yên operasyonê de jî hebûn. Bi demê re, em gihîştin pratîkên xwe yên çêtirîn ên navxweyî. Û pirsgirêkên me ji holê rabûn. Ji ber vê yekê, rapor nêzî şeş meh berê hate ragihandin, dema ku ew hemî di serê min de nû bû û min ew hemî bi tevahî hate bîra min.
Di dema amadekirina raporê de, min berê xwe da postmortemên kevn, li têketin nihêrî. Û dibe ku hin hûrgilî bêne ji bîr kirin, an hin hûrgulî di dema analîzkirina pirsgirêkan de bi tevahî neyên lêkolîn kirin, ji ber vê yekê di hin xalan de dibe ku xuya bibe ku pirsgirêk bi tevahî nehatine berçav kirin, an jî kêmbûna agahdarî heye. Û ji ber vê yekê ez ji we daxwaz dikim ku hûn ji bo vê gavê min biborînin.
Patroni çi ye?
- Ev şablonek ji bo avakirina HA ye. Ya ku di belgeyê de tê gotin ev e. Û bi dîtina min, ev zelalkirinek pir rast e. Patroni ne guleyek zîv e ku dê hemî pirsgirêkên we çareser bike, ango, hûn hewce ne ku hewl bidin ku wê bixebitin û sûd werbigirin.
- Ev karûbarek ajan e ku li ser her karûbarê databasê tê saz kirin û ji bo Postgres-a we celebek pergala destpêkê ye. Ew Postgres dest pê dike, disekine, ji nû ve dest pê dike, ji nû ve saz dike, û topolojiya koma we diguhezîne.
- Li gorî vê yekê, ji bo hilanîna rewşa komê, nûneriya wê ya heyî, wekî ku xuya dike, celebek hilanînê hewce ye. Û ji vî alî ve, Patroni riya hilanîna dewletê di sîstemeke derve de girt. Ew pergalek hilanîna mîhengê ya belavkirî ye. Ew dikare Etcd, Konsul, ZooKeeper, an kubernetes Etcd be, ango yek ji van vebijarkan.
- Û yek ji taybetmendiyên Patroni ev e ku hûn otofiler ji qutiyê derdixin, tenê bi sazkirina wê. Ger em Repmgr ji bo berhevdanê bistînin, wê hingê peler li wir tê de ye. Bi Repmgr re, em veguherînek werdigirin, lê heke em bixweberek dixwazin, wê hingê pêdivî ye ku em wê pêvekî mîheng bikin. Patroni jixwe otofilerek ji qutîkê heye.
- Û gelek tiştên din hene. Mînakî, domandina veavakirinan, rijandina kopiyên nû, paşvegirtin, hwd. Lê ev ji çarçoweya raporê wêdetir e, ez ê qala wê nekim.
Û encamek piçûk ev e ku peywira sereke ya Patroni ev e ku pelek otomatîkî baş û pêbawer bike da ku komika me bikêr bimîne û serîlêdan di topolojiya komê de guh nede guhertinan.
Lê gava ku em dest bi karanîna Patroni dikin, pergala me hinekî tevlihevtir dibe. Ger berê me Postgres hebû, wê hingê dema ku Patroni bikar tînin em Patroni bixwe distînin, em DCS-ya ku dewlet lê hatî hilanîn digirin. Û her tişt divê bi awayekî bixebite. Îcar çi dibe bila bibe?
Gulan bişkîne:
- Postgres dibe ku bişkînin. Ew dikare bibe master an replica, yek ji wan dibe ku têk bibe.
- Patroni bixwe dibe ku bişkîne.
- DCS ya ku dewlet lê tê hilanîn dibe ku bişkê.
- Û torê dikare bişkîne.
Van hemû xalan ez ê di raporê de binirxînim.
Ez ê dozan her ku tevlihevtir dibin binirxînim, ne ji wê nêrînê de ku doz gelek pêkhateyan vedihewîne. Û ji hêla hestên subjektîf ve, ku ev doz ji min re dijwar bû, jihevxistina wê dijwar bû ... û berevajî, hin doz sivik bû û jihevxistina wê hêsan bû.
Û doza yekem herî hêsan e. Ev rewş dema ku me komek databas girt û hilanîna DCS-ya xwe li ser heman komê bicîh kir. Ev xeletiya herî gelemperî ye. Ev di avakirina mîmariyan de xeletiyek e, ango berhevkirina pêkhateyên cûda li yek cîhek.
Ji ber vê yekê, dosyayek hebû, em herin bi çi qewimî re mijûl bibin.
Û li vir em eleqedar dibin ka kengê peler qewimî. Ango em bala xwe didin vê dema ku rewşa komê guherî.
Lê peler ne her gav zû ye, ango ew yekîneyek dem nagire, dikare dereng bibe. Ew dikare dirêj bimîne.
Ji ber vê yekê, dema destpêk û dema dawî heye, ango bûyerek berdewam e. Û em hemî bûyeran di sê navberan de dabeş dikin: dema me li ber peler, di dema peler û piştî pelê de heye. Yanî em hemû bûyeran di vê demê de dihesibînin.
Û ya yekem, dema ku pelerek çêbû, em li sedema tiştê ku çêbû, çi bû sedema ku pelê pelê bû.
Ger em li têketin binêrin, ew ê têketinên Patroni yên klasîk bin. Ew di wan de ji me re dibêje ku server bûye serdest, û rola serdest derbasî vê nodê bûye. Li vir tê ronî kirin.
Dûv re, pêdivî ye ku em fêm bikin ka çima peldank qewimî, ango çi bûyer qewimîn ku bûne sedem ku rola master ji yek girêkek din biçe. Û di vê rewşê de, her tişt hêsan e. Di pêwendiya bi pergala hilanînê re xeletiyek me heye. Mamoste fêm kir ku ew nikare bi DCS-ê re bixebite, ango, di têkiliyê de celebek pirsgirêkek heye. Û dibêje ku ew êdî nikare bibe serwer û îstîfa dike. Ev rêza “xwe daxistî” tam vê yekê dibêje.
Ger em li bûyerên ku berî pelê nihêrîn, em dikarin li wir sedemên ku bûne sedema berdewamkirina pirsgirêkê ya sêrbaz bibînin.
Ger em li têketinên Patroni binerin, em ê bibînin ku gelek xeletiyên me hene, demên me hene, ango nûnerê Patroni nikare bi DCS re bixebite. Di vê rewşê de, ev nûnerê Konsulê ye, ku li ser porta 8500 danûstendinê dike.
Û pirsgirêk li vir ev e ku Patroni û databas li ser heman mêvandar têne xebitandin. Û serverên Konsulê li ser heman nodê hatin destpêkirin. Bi afirandina barek li ser serverê, me pirsgirêk ji bo serverên Konsulê jî çêkir. Nikarîbûn bi rêkûpêk têkilî daynin.
Piştî demekê, dema ku bar kêm bû, Patronê me dîsa bi ajanan re têkilî danî. Karê normal ji nû ve dest pê kir. Û heman servera Pgdb-2 dîsa bû master. Ango, felqek piçûk hebû, ji ber vê yekê girêk ji hêzên axayê îstifa kir, û dûv re dîsa wan girt, ango her tişt wekî xwe vegeriya.
Û ev dikare wekî alarmek derewîn were hesibandin, an jî dikare were hesibandin ku Patroni her tişt rast kir. Ango pê hesiya ku nikare rewşa komê biparêze û desthilatdariya xwe ji holê rakir.
Û li vir pirsgirêk derket holê ji ber vê yekê ku serverên Konsulê li ser heman hardware wekî bingeh in. Li gorî vê yekê, her barkirin: gelo ew barkirina dîskan an pêvajokeran be, ew di heman demê de bandorê li pêwendiya bi koma Konsulê jî dike.
Û me biryar da ku ew bi hev re nejîn, me komek cuda ji bo Konsulê veqetand. Û Patroni jixwe bi Konsulek cuda re dixebitî, yanî komek Postgres ya cihê, komek Konsulek cûda hebû. Ev rêwerzek bingehîn e ku meriv van tiştan çawa hilgire û biparêze da ku ew bi hev re nejî.
Wekî vebijark, hûn dikarin parametreyên ttl, loop_wait, retry_timeout bizivirînin, ango bi zêdekirina van parameteran hewl bidin ku ji van lûtkeyên barkirina demkurt sax bimînin. Lê ev ne vebijarka herî maqûl e, ji ber ku ev bar dikare di wextê de dirêj be. Û em ê bi tenê ji van sînorên van pîvanan derkevin. Û dibe ku ew bi rastî ne alîkar be.
Pirsgirêka yekem, wekî ku hûn fêm dikin, hêsan e. Me DCS bi bingehê re girt û danî ser hev, me pirsgirêkek derket.
Pirsgirêka duyemîn mîna ya yekem e. Ew dişibihe ku em dîsa bi pergala DCS re pirsgirêkên hevberdanê hene.
Ger em li qeydan binêrin, em ê bibînin ku dîsa xeletiyek me ya pêwendiyê heye. Û Patroni dibêje ez nikarim bi DCS re têkilî daynim ji ber vê yekê masterê heyî diçe moda replica.
Mamosteyê kevn dibe kopiyek, li vir Patroni dixebite, wekî ku divê bibe. Ew pg_rewind dimeşîne da ku têketina danûstendinê paşde vegerîne û dûv re bi masterê nû ve girêbide da ku bi masterê nû re bigihîje. Li vir Patroni dixebite, wekî ku divê.
Li vir divê em cîhê ku berî pelêrê hatî peyda kirin, ango ew xeletiyên ku bûne sedem ku em bibin xwedî peler. Û di vî warî de, têketinên Patroni ji bo xebatê pir hêsan in. Ew heman peyaman di navberek diyarkirî de dinivîse. Û heke em zû dest bi gerandina van têketinan bikin, wê hingê em ê ji qeydan bibînin ku têketin hatine guhertin, ku tê vê wateyê ku hin pirsgirêk dest pê kirine. Em zû vegerin vê derê, bibînin ka çi dibe.
Û di rewşeke normal de, têketin tiştek bi vî rengî xuya dikin. Xwediyê qeflê tê kontrolkirin. Û heke xwedan, wek nimûne, guherî, wê hingê dibe ku hin bûyer çêbibin ku divê Patroni bersivê bide. Lê di vê rewşê de em baş in. Em li cihê ku xeletiyan lê dest pê kirine digerin.
Û gava ku li ser xala ku xeletî dest pê kir xuya kir, em dibînin ku me peldankek otomatîkî heye. Û ji ber ku xeletiyên me bi danûstendina bi DCS re têkildar bûn û di doza me de me Konsul bikar anî, em li têketinên Konsulê jî dinêrin, ka li wir çi qewimî.
Bi qasî hevberdana dema pelan û dema di têketinên konsulê de, em dibînin ku cîranên me yên di koma Konsul de dest bi gumanê li hebûna endamên din ên koma Konsul kirine.
Û heke hûn li têketinên ajanên Konsulê yên din jî binihêrin, hûn dikarin bibînin ku celebek hilweşîna torê li wir pêk tê. Û hemû endamên koma Konsulê ji hebûna hev guman dikin. Û ev ji bo pelan bû sedema.
Ger hûn li tiştên ku berî van xeletiyan qewimîn binihêrin, hûn dikarin bibînin ku her cûre xeletî hene, mînakî, muhlet, RPC ket, ango eşkere ye ku di danûstendina endamên koma konsulê de bi hev re cûreyek pirsgirêk heye. .
Bersiva herî hêsan tamîrkirina torê ye. Lê ji bo min, li ser podiumê radiwestim, hêsan e ku meriv vê yekê bibêje. Lê şert û merc wisa ne ku her gav xerîdar nekare torê tamîr bike. Dibe ku ew di DC-ê de bijî û dibe ku nikaribe torê tamîr bike, bandorê li amûran bike. Û ji ber vê yekê hin vebijarkên din hewce ne.
Vebijêrk hene:
- Vebijarka herî hêsan, ya ku, bi dîtina min, tewra di belgenameyê de jî hatî nivîsandin, neçalakkirina kontrolên Konsulê ye, ango, tenê rêzek vala derbas bike. Û em ji nûnerê Konsulê re dibêjin ku tu kontrolê bikar neynin. Bi van kontrolan, em dikarin van bahozên torê paşguh bikin û pelerek dest pê nekin.
- Vebijarkek din ev e ku meriv raft_multiplier ducar kontrol bike. Ev pîvanek servera Konsul bixwe ye. Ji hêla xwerû ve, ew li ser 5-ê tête danîn. Ev nirx ji hêla belgeyên ji bo hawîrdorên sehneyê ve tê pêşniyar kirin. Di rastiyê de, ev bandorê li ser frekansa mesajên di navbera endamên tora Konsulê de dike. Bi rastî, ev parametre bandorê li leza ragihandina karûbarê di navbera endamên koma Konsulê de dike. Û ji bo hilberînê, jixwe tê pêşniyar kirin ku wê kêm bikin da ku girêk pir caran peyaman biguhezînin.
- Vebijarkek din a ku me pê re peyda kiriye ev e ku em di nav pêvajoyên din de ji bo nexşerêya pêvajoya pergala xebitandinê pêşîniya pêvajoyên Konsulê zêde bikin. Parametreyek wusa "xweş" heye, ew tenê pêşîniya pêvajoyên ku ji hêla plansazkerê OS-ê ve di dema bernamekirinê de tê hesibandin destnîşan dike. Me nirxê xweş ji bo ajanên Konsulê jî kêm kiriye, yanî. pêşanî zêde kir da ku pergala xebitandinê bêtir wext bide pêvajoyên Konsulê ku bixebite û koda xwe bicîh bîne. Di rewşa me de, ev pirsgirêka me çareser kir.
- Vebijêrkek din ew e ku Konsul bikar neynin. Hevalek min heye ku piştgirek mezin a Etcd ye. Û em bi rêkûpêk bi wî re nîqaş dikin ku Etcd an Konsul çêtir e. Lê di warê ka kîjan çêtir e, em bi gelemperî bi wî re dipejirînin ku Konsul xwediyê karmendek e ku divê li ser her girêkek bi databasek were xebitandin. Ango pêwendiya Patronî bi koma Konsul re bi vî ajan derbas dibe. Û ev ajan dibe kelek. Ger tiştek bi ajan were, wê hingê Patroni nema dikare bi koma Konsul re bixebite. Û ev pirsgirêk e. Di plana Etcd de ajanek tune. Patroni dikare rasterast bi navnîşek serverên Etcd re bixebite û berê bi wan re têkilî daynin. Di vî warî de, heke hûn di pargîdaniya xwe de Etcd bikar bînin, wê hingê dibe ku Etcd ji Konsul bijarek çêtir be. Lê em li xerîdarên xwe her gav ji hêla tiştê ku xerîdar hilbijartiye û bikar tîne ve sînorkirî ne. Û em bi piranî ji bo hemî xerîdar Konsul hene.
- Û xala paşîn ev e ku meriv nirxên parametreyê ji nû ve binirxîne. Em dikarin van parameteran bilind bikin bi hêviya ku pirsgirêkên me yên torê yên demkurt kurt bin û nekevin derveyî rêza van pîvanan. Heke hin pirsgirêkên torê çêbibin, bi vî rengî em dikarin aggressiveness Patroni ji bo otofile kêm bikin.
Ez difikirim ku gelek kesên ku Patroni bikar tînin bi vê fermanê dizanin.
Ev ferman rewşa heyî ya komê nîşan dide. Û di nihêrîna pêşîn de, ev wêne dikare normal xuya bike. Mamosteyek me heye, replika me heye, derengiya dubarekirinê tune. Lê ev wêne tam normal e heya ku em zanibin ku ev kom divê sê girêk hebin, ne du.
Li gorî vê yekê, otofilek hebû. Û piştî vê otofilê, kopya me winda bû. Divê em bizanin ka çima ew winda bûye û wê vegerînin, wê vegerînin. Û em dîsa diçin ser têketin û dibînin ka çima me pelek otomatîk heye.
Di vê rewşê de, replica duyemîn bû master. Li vir her tişt rast e.
Û pêdivî ye ku em li kopyaya ku ket û ne di komê de ye binihêrin. Em têketinên Patroni vedikin û dibînin ku di qonaxa pg_rewind de di pêvajoya girêdana bi komê de pirsgirêkek me hebû. Ji bo girêdana bi komê re, hûn hewce ne ku têketina danûstendinê bi paş ve bizivirînin, têketina danûstendinê ya pêwîst ji masterê bixwazin, û wê bikar bînin da ku bi masterê re bigirin.
Di vê rewşê de, me têketinek danûstendinê tune û replica nikare dest pê bike. Li gorî vê yekê, em Postgres bi xeletiyek rawestînin. Û ji ber vê yekê ew ne di komê de ye.
Pêdivî ye ku em fêm bikin ka çima ew ne di komê de ye û çima têketin tune bûn. Em diçin cem axayê nû û li tiştên ku di qeydan de hene dinêrin. Derket holê ku dema pg_rewind hate kirin, xalek kontrolê derket. Û hin têketinên danûstendinê yên kevin bi tenê hatin guhertin. Gava ku axayê kevin hewl da ku bi axayê nû ve girêbide û li van qeydan bipirse, ew jixwe navên wan hatin guhertin, ew tenê tune bûn.
Dema ku ev bûyer qewimîn min mohra demjimêran dan ber hev. Û li wir ferq bi rastî 150 milî çirkeyan e, ango, xala kontrolê di 369 milîsaniyeyan de qediya, beşên WAL hatin guhertin. Û bi rastî di sala 517-an de, piştî 150 milîçirkeyan, paşvekêşana li ser kopiya kevn dest pê kir. Ango bi rastî 150 milîsaniye têra me dikir da ku kopya nikaribe bi hev ve girêbide û qezenc bike.
Vebijarkên çi ne?
Me di destpêkê de hêlînên dubarekirinê bikar anî. Em difikirin ku ew baş bû. Her çend di qonaxa yekem a operasyonê de me hêlîn vekir. Ji me re xuya bû ku ger hêlîn gelek beşên WAL berhev bikin, em dikarin masterê bavêjin. Ew ê bikeve. Em ji bo demekê bê slots cefayê. Û me fêhm kir ku pêdiviya me bi slotan heye, me hêlîn vegeriyan.
Lê di vir de pirsgirêkek heye, ku dema ku master diçe replikayê, hêlînê jê dike û beşên WAL-ê li gel hêlînan jê dike. Û ji bo rakirina vê pirsgirêkê, me biryar da ku em pîvana wal_keep_segments bilind bikin. Ew ji bo 8 beşan vedigire. Me ew derxist 1 û me nihêrî ka çiqas cîhê me yê belaş heye. Û me ji bo wal_keep_segments 000 gigabayt bexş kir. Ango, dema ku diguhezîne, em her gav rezervek ji 16 gigabayt têketinên danûstendinê li ser hemî girêkan hene.
Û plus - ew hîn jî ji bo karên lênêrîna dirêj-dirêj têkildar e. Ka em bibêjin ku em hewce ne ku yek ji kopiyan nûve bikin. Û em dixwazin wê vemirînin. Divê em nermalavê nûve bikin, dibe ku pergala xebitandinê, tiştek din. Û gava ku em kopiyek diqelişînin, hêlîna wê kopiyê jî tê rakirin. Û heke em wal_keep_segments piçûk bikar bînin, wê hingê bi nebûna dirêj a kopiyek, têketinên danûstendinê dê winda bibin. Em ê kopiyek rakin, ew ê wan têketinên danûstendinê li cihê ku ew rawestandiye bixwaze, lê dibe ku ew ne li ser masterê bin. Û replica jî dê nikaribe bi hev ve girêdayî be. Ji ber vê yekê, em stokek mezin a kovaran digirin.
Bingehek me ya hilberînê heye. Jixwe proje hene.
Dosyayek hebû. Em ketin hundur û me mêze kir - her tişt bi rêkûpêk e, kopî li cihê xwe ne, derengiya dubarekirinê tune. Di qeydan de jî xeletî tune, her tişt bi rêk û pêk e.
Tîma hilberê dibêje ku divê hin dane hebin, lê em wê ji yek çavkaniyekê dibînin, lê em wê di databasê de nabînin. Û divê em fêm bikin ka çi hat serê wan.
Eşkere ye ku pg_rewind wan ji bîr kiriye. Me di cih de ev fêm kir, lê em çûn ku bibînin ka çi diqewime.
Di qeydan de, em her gav dikarin bibînin ka peler kengê qewimiye, kî bûye serdest, û em dikarin diyar bikin ka kî serdestê kevn bû û kengê xwest ku bibe replica, ango ji me re pêdivî ye ku em bi van têketinên ku hejmara têketinên danûstendinê bibînin. winda bû.
Mîrê me yê kevn ji nû ve dest pê kir. Û Patroni di autorun de qeydkirî bû. Patroni dest pê kir. Wî paşê Postgres dest pê kir. Zêdetir, berî destpêkirina Postgres û berî çêkirina wê kopiyek, Patroni pêvajoya pg_rewind da destpêkirin. Li gorî vê yekê, wî beşek ji têketinên danûstendinê jê kir, yên nû dakêşand û ve girêdayî bû. Li vir Patroni bi aqilmendî xebitî, yanî wekî ku dihat hêvî kirin. Kluster hatiye restorekirin. Me 3 girêk hebûn, piştî pelê 3 nod - her tişt xweş e.
Me hin dane winda kirin. Û divê em fêm bikin ku me çiqas winda kiriye. Em tenê li wê kêliya ku paşveçûnek me hebû lê digerin. Em dikarin wê di navnîşên kovarên weha de bibînin. Rewind dest pê kir, tiştek li wir kir û bi dawî bû.
Pêdivî ye ku em di têketina danûstendinê de cîhê ku axayê kevn lê hiştiye bibînin. Di vê rewşê de, ev nîşan e. Û ji me re nîşanek duyemîn hewce ye, ango dûrahiya ku axayê kevn ji ya nû cuda dibe.
Em pg_wal_lsn_diff-a asayî digirin û van her du nîşanan didin ber hev. Û di vê rewşê de, em 17 megabytes bistînin. Pir an hindik, her kes bi xwe biryarê dide. Ji ber ku ji bo kesekî 17 megabayt ne zêde ye, ji bo kesekî pir e û nayê qebûlkirin. Li vir, her kes li gorî hewcedariyên karsaziyê ji bo xwe diyar dike.
Lê me ji xwe re çi dît?
Pêşîn, divê em bi xwe biryar bidin - gelo em her gav hewce ne ku Patroni piştî nûvekirina pergalê bixweber bide destpêkirin? Gelek caran diqewime ku divê em herin cem axayê kal, bibînin ka ew çiqas çûye. Dibe ku beşên danûstendina danûstendinê kontrol bikin, bibînin ka çi li wir heye. Û ji bo ku em fêm bikin ka em dikarin vê daneyê winda bikin an gelo em hewce ne ku masterê kevn di moda serbixwe de bimeşînin da ku vê daneyê derxînin.
Û tenê piştî wê divê em biryar bidin ka em dikarin van daneyan ji holê rakin an em dikarin wê vegerînin, vê girêkê wekî kopiyek bi koma xwe ve girêdin.
Wekî din, pîvanek "maximum_lag_on_failover" heye. Ji hêla xwerû, heke bîra min ji min re xizmetê dike, nirxa vê parameterê 1 megabyte ye.
Ew çawa dixebite? Ger kopya me bi 1 megabyte daneya paşveçûna dubarekirinê li paş bimîne, wê demê ev kopya beşdarî hilbijartinan nabe. Û heke ji nişka ve pelek çêbibe, Patroni dinêre ka kîjan kopî li paş in. Ger ew li pişt hejmareke mezin ji têketinên danûstendinê bin, ew nikanin bibin master. Ev taybetmendiyek ewlehiyê ya pir baş e ku pêşî li windakirina gelek daneyan digire.
Lê pirsgirêkek heye ku derengiya dubarekirinê di koma Patroni de û DCS di navberek diyarkirî de tê nûve kirin. Ez difikirim 30 çirke nirxa ttl ya xwerû ye.
Li gorî vê yekê, dibe ku rewşek hebe ku di DCS-ê de ji bo replikayan yek derengiya dubarekirinê hebe, lê di rastiyê de dibe ku derengiyek bi tevahî cûda hebe an jî bi tevahî dereng tune be, ango ev tişt ne rast e. Û ew her gav wêneya rastîn nîşan nade. Û ne hêja ye ku meriv li ser wê mantiqê xweşik bike.
Û rîska winda her tim dimîne. Û di rewşa herî xirab de, yek formula, û di rewşa navîn de, formula din. Ango, gava ku em pêkanîna Patroni plan dikin û dinirxînin ka çiqas daneya ku em dikarin winda bikin, divê em xwe bispêrin van formulan û bi qasî xeyal bikin ka em dikarin çiqas daneyan winda bikin.
Û nûçeyên baş hene. Gava ku axayê kevn pêş de çû, ew dikare ji ber hin pêvajoyên paşerojê pêşde here. Ango, cûreyek otovacuumê hebû, wî dane nivîsandin, ew di qeyda danûstendinê de tomar kir. Û em dikarin bi hêsanî vê daneyê paşguh bikin û winda bikin. Di vê de tu pirsgirêk nîne.
Û bi vî rengî têketin dişibin ger maximum_lag_on_failover were danîn û pelerek çêbibe, û hûn hewce ne ku masterek nû hilbijêrin. Replika xwe wekî ku nikare beşdarî hilbijartinan bibe dinirxîne. Û ew red dike ku beşdarî pêşbaziya ji bo rêberiyê bibe. Û ew li bendê ye ku masterek nû were hilbijartin, da ku ew paşê pê ve girêbide. Ev tedbîrek zêde ye li dijî windabûna daneyê.
Li vir tîmek hilberek me heye ku nivîsandiye ku hilberê wan bi Postgres re pirsgirêk hene. Di heman demê de, master bixwe nikare bigihîje, ji ber ku ew bi SSH re peyda nabe. Û otofil jî çênabe.
Ev mêvandar neçar bû ku ji nû ve dest pê bike. Ji ber rebootkirinê, pelek otomatîkî çêbû, her çend mimkun bû ku pelek otomatîkî bi destan were çêkirin, wekî ku ez nuha fam dikim. Û piştî rebootkirinê, em ê berê bibînin ka me bi masterê heyî re çi bû.
Di heman demê de, me di pêş de dizanibû ku pirsgirêkên me bi dîskê re hene, ango, me berê ji çavdêriyê dizanibû ku li ku derê bikolin û li çi bigerin.
Em ketin qeyda postgresê, dest pê kir ku em bibînin ka li wir çi diqewime. Me tedbîrên ku li wir yek, du, sê saniye dom dikin dîtin, ku ew qet ne normal e. Me dît ku otovacuuma me pir hêdî û ecêb dest pê dike. Û me pelên demkî li ser dîskê dît. Ango, ev hemî nîşaneyên pirsgirêkên bi dîskê ne.
Me li dmesg-ya pergalê (log kernel) nihêrî. Û me dît ku pirsgirêkên me bi yek ji dîskê re hene. Binepergala dîskê nermalava Raid bû. Me li /proc/mdstat mêze kir û dît ku me yek ajoker winda kir. Ango Raidek ji 8 dîskan heye, em yek winda dikin. Ger hûn bi baldarî li slaytê mêze bikin, wê hingê di encam de hûn dikarin bibînin ku me li wir sde tune. Li cem me, bi şert û mercî, dîsk derketiye. Vê yekê pirsgirêkên dîskê derxist, û serîlêdan jî dema ku bi koma Postgres re dixebitin pirsgirêk derketin.
Û di vê rewşê de, Patroni dê bi tu awayî alîkariya me neke, ji ber ku Patroni ne xwediyê peywira çavdêriya rewşa serverê, rewşa dîskê ye. Û divê em rewşên wiha bi çavdêriya derve bişopînin. Me zû çavdêriya dîskê li çavdêriya derveyî zêde kir.
Û ramanek wusa hebû - gelo nermalava felq an çavdêriyê dikare alîkariya me bike? Em difikirîn ku ew ê di vê rewşê de bi zor alîkariya me bike, ji ber ku di dema pirsgirêkan de Patroni berdewam kir ku bi koma DCS re têkilî daynin û ti pirsgirêk nedît. Ango, ji nihêrîna DCS û Patroni, her tişt bi komê re baş bû, her çend bi rastî di dîskê de pirsgirêk hebûn, di hebûna databasê de pirsgirêk hebûn.
Bi dîtina min, ev yek ji wan pirsgirêkên herî xerîb e ku min demek pir dirêj lê lêkolîn kiriye, min gelek têketin xwendiye, ji nû ve hilbijartiye û jê re gotiye simulatorek komê.
Pirsgirêk ev bû ku axayê kevn nikarîbû bibe replika normal, ango Patroni dest pê kir, Patroni nîşan da ku ev girêk wekî replica heye, lê di heman demê de ew ne kopiyek normal bû. Niha hûn ê bibînin ka çima. Ya ku min ji analîza wê pirsgirêkê girtiye ev e.
Û çawa hemû dest pê kir? Weke pirsgirêka berê, bi frenên dîskê dest pê kir. Em ji bo saniyeyekê, du commits bûn.
Di têkiliyan de qut bûn, ango xerîdar qut bûn.
Astengiyên bi giraniya cûda hebûn.
Û, li gorî vê, binepergala dîskê ne pir bersivdar e.
Û ji bo min tiştê herî nepenî daxwaza girtina tavilê ya ku hatî ye. Postgres sê awayên girtinê hene:
- Dema ku em li bendê ne ku hemî xerîdar bi tena serê xwe qut bibin, xweş e.
- Gava ku em zorê didin xerîdaran ku xwe qut bikin ji ber ku em ê qut bibin zû heye.
- Û yekser. Di vê rewşê de, tavilê jî ji xerîdaran re nabêje ku biqedin, ew tenê bêyî hişyariyê diqede. Û ji hemî xerîdaran re, pergala xebitandinê jixwe peyamek RST dişîne (peyamek TCP ku têkiliyek qut bûye û xerîdar tiştek din tune ku bigire).
Kê ev sînyala şandiye? Pêvajoyên paşîn ên Postgres ji hev re îşaretên weha naşînin, ango ev kuştin-9 e. Tiştên wiha ji hev re naşînin, tenê ji van tiştan re bertek nîşan didin, ango ev ji nû ve destpêkirina awarte ya Postgresê ye. Kê şandiye, ez nizanim.
Min li fermana "paşîn" nihêrî û min kesek dît ku ew jî bi me re têketî vê serverê, lê ez pir şerm bûm ku ez pirsek bikim. Dibe ku ew kuştin -9 bû. Ez ê bibînim kuştin -9 di têketinên, ji ber Postgres dibêje ku ew kuştin -9 girt, lê min ew di qeydan de nedît.
Dûv re nihêrî, min dît ku Patroni ji bo demek dirêj - 54 çirke - li têketinê nenivîsî. Û heke em du nîşanan bidin ber hev, bi qasî 54 çirkeyan tu peyam tunebûn.
Û di vê demê de otofilek hebû. Patroni dîsa li vir karekî mezin kir. Mîrê me yê kal tunebû, tiştek hat serê wî. Û hilbijartina axayekî nû dest pê kir. Li vir her tişt baş bû. Pgsql01 me bûye serokê nû.
Kopiyek me heye ku bûye master. Û bersiva duyemîn heye. Û bi replica duyemîn re pirsgirêk hebûn. Wê hewl da ku ji nû ve veava bike. Wekî ku ez jê fêm dikim, wê hewl da ku recovery.conf biguhezîne, Postgres ji nû ve bide destpêkirin û bi masterê nû ve girêbide. Her 10 saniyeyan carekê peyamên ku hewl dide dinivîse, lê bi ser nakeve.
Û di dema van hewldanan de, sînyalek girtina tavilê digihîje axayê kevn. Master ji nû ve tê destpêkirin. Û di heman demê de başbûn raweste ji ber ku masterê kevn diçe reboot. Ango, replica nikare pê ve girêbide, ji ber ku ew di moda girtinê de ye.
Di demekê de, ew xebitî, lê dubare dest pê nekir.
Texmîna min tenê ev e ku navnîşanek masterê kevn di hilanînê de hebû.conf. Û gava ku masterek nû xuya bû, kopiya duyemîn dîsa jî hewl da ku bi axayê kevn ve girêdayî bike.
Dema ku Patroni dest bi kopya duyemîn kir, girêk dest pê kir lê nikaribû dubare bibe. Û derengiya dubarekirinê çêbû, ku tiştek wusa xuya bû. Yanî her sê girêk li cihê xwe bûn, lê girêka duyemîn li paş ma.
Di heman demê de, heke hûn li têketinên ku hatine nivîsandin mêze bikin, hûn dikarin bibînin ku dubarekirin nikare dest pê bike ji ber ku têketinên danûstendinê cûda bûn. Û ew têketinên danûstendinê yên ku master pêşkêşî dike, yên ku di recovery.conf de hatine destnîşan kirin, bi tenê bi girêka meya heyî re nagirin.
Û li vir min xeletiyek kir. Diviya bû ku ez werim û bibînim ka di başbûnê de çi heye.conf da ku hîpoteza xwe biceribînim ku em bi axayê xelet ve girêdidin. Lê wê gavê ez tenê bi vê yekê re mijûl dibûm û ew ji min re nedihat, an jî min dît ku kopiyek li paş maye û pêdivî ye ku were tije kirin, ango ez bi rengekî bêhiş xebitîm. Ev hevpariya min bû.
Piştî 30 hûrdeman, admîn berê hat, ango min Patroni li ser replikayê ji nû ve da destpêkirin. Min berê dawî lê anî, min fikirîn ku ew ê ji nû ve were dagirtin. Û ez fikirîm - ez ê Patroni ji nû ve bidim destpêkirin, dibe ku tiştek baş derkeve. Vegere dest pê kir. Û bingeh jî vebû, ew amade bû ku pêwendiyan qebûl bike.
Repplication dest pê kir. Lê deqîqeyek şûnda ew bi xeletiyek ket ku têketinên danûstendinê ji bo wê ne guncan in.
Min fikir kir ku ez ê ji nû ve dest pê bikim. Min Patroni ji nû ve da destpêkirin, û min Postgres ji nû ve neda, lê Patroni ji nû ve dest pê kir bi hêviya ku ew ê bi efsûnî databasê dest pê bike.
Repplication dîsa dest pê kir, lê nîşaneyên di têketina danûstendinê de cûda bûn, ew ne wekî hewildana destpêkê ya berê bûn. Replication dîsa rawestiya. Û peyam jixwe hinekî cuda bû. Û ew ji bo min ne pir agahdar bû.
Û dûv re ew ji min re tê - ma heke ez Postgres ji nû ve dest pê bikim, di vê demê de ez nuqteyek kontrolê li ser masterê heyî çêdikim da ku xala di qeyda danûstendinê de hinekî pêşde bikişîne da ku başbûn ji demek din dest pê bike? Zêdeyî, me hîn jî stokên WAL hebûn.
Min Patroni ji nû ve da destpêkirin, çend xalên kontrolê li ser master, çend xalên ji nû ve destpêkirinê li ser replika gava ku ew vebû. Û ew alîkarî kir. Ez ji bo demek dirêj fikirîm ku çima ew alîkarî kir û ew çawa dixebite. Û replica dest pê kir. Û dubarekirin êdî nehat çikandin.
Pirsgirêkek wusa ji bo min yek ji wan ên razdartir e, ku ez hîn jî li ser tiştê ku bi rastî li wir qewimî şaş dikim.
Encamên li vir çi ne? Patroni dikare wekî ku tê xwestin û bêyî xeletî bixebite. Lê di heman demê de, ev ne garantiyek 100% e ku her tişt bi me re baş e. Dibe ku kopî dest pê bike, lê dibe ku ew di rewşek nîv-xebatê de be, û serîlêdan nikare bi kopiyek wusa re bixebite, ji ber ku dê daneyên kevn hebin.
Û piştî pelê, hûn her gav hewce ne ku hûn kontrol bikin ka her tişt bi komê re di rê de ye, ango, hejmara pêdivî ya kopiyan heye, derengiya dubarekirinê tune.
Û dema ku em di van mijaran re derbas dibin, ez ê pêşniyaran bikim. Min hewl da ku wan di du slaytan de berhev bikim. Dibe ku, hemî çîrok di du slaytan de werin berhev kirin û tenê bêne vegotin.
Dema ku hûn Patroni bikar tînin, divê hûn çavdêriyek hebe. Pêdivî ye ku hûn her gav zanibin ka kengê pelê otomatîk çê bûye, ji ber ku heke hûn nizanin ku we pelek otomatîkî heye, kontrola we li ser komê tune. Û ev xerab e.
Piştî her peldankê, divê em her gav bi destan komê kontrol bikin. Pêdivî ye ku em pê ewle bin ku em her gav jimareyek nûvekirî ya me heye, derengiya dubarekirinê tune, di têketinên ku bi veguheztina weşana ve girêdayî ne, bi Patroni re, bi pergala DCS re xeletî tune.
Otomasyon dikare bi serfirazî bixebite, Patroni amûrek pir baş e. Ew dikare bixebite, lê ev ê komê nekeve rewşa tê xwestin. Û heger em vê yekê nebînin, em ê di tengahiyê de bibin.
Û Patroni ne guleyek zîv e. Em hîn jî hewce ne ku fêm bikin ka Postgres çawa dixebite, dubarekirin çawa dixebite û Patroni çawa bi Postgres re dixebite, û ka têkiliya di navbera girêkan de çawa tê peyda kirin. Ji bo ku hûn bikaribin pirsgirêkan bi destên xwe çareser bikin ev pêdivî ye.
Ez çawa nêzî pirsgirêka teşhîs dibim? Wusa çêbû ku em bi xerîdarên cihêreng re dixebitin û tu kes ELK stek tune, û pêdivî ye ku em bi vekirina 6 konsol û 2 tabloyan têketin ji hev vekin. Di tabloyek de, ev têketinên Patroni ji bo her girêk in, di tabloya din de, ev têketinên Konsulê ne, an jî heke hewce be Postgres in. Teşhîsa vê yekê pir zehmet e.
Min çi nêzîkatî pêşxistiye? Pêşîn, ez her gav dinihêrim gava peler hat. Û ji bo min ev der av e. Ez li ber peler, di dema peler û piştî pelê de çi qewimî. Di pelê de du nîşan hene: ev dema destpêk û dawî ye.
Dûv re, ez di têketinê de li bûyerên berî pelê, yên ku berî pelêrê ne, digerim, ango ez li sedemên ku peler qewimî digerim.
Û ev wêneyek têgihîştina çi qewimî û di pêşerojê de çi dikare were kirin da ku rewşên weha çênebin (û di encamê de, peler tune) dide.
Û em bi gelemperî li ku derê digerin? Ez dinêrim:
- Pêşîn, ji têketinên Patroni re.
- Dûv re, ez li têketinên Postgres, an têketinên DCS-ê dinihêrim, li gorî tiştê ku di têketinên Patroni de hate dîtin.
- Û têketinên pergalê carinan jî têgihiştinê dide ka çi bûye sedema pelê.
Ez li ser Patroni çawa hest dikim? Têkiliyeke min a pir baş bi Patroni re heye. Bi dîtina min, îro ev çêtirîn e. Ez gelek berhemên din dizanim. Ev Stolon, Repmgr, Pg_auto_failover, PAF ne. 4 amûr. Min ew hemî ceribandin. Patroni bijareya min e.
Ger ew ji min bipirsin: "Ma ez Patroni pêşniyar dikim?". Ez ê bibêjim erê, ji ber ku ez ji Patroni hez dikim. Û ez difikirim ku ez fêr bûm ku meriv wê çawa çêdike.
Heke hûn dixwazin bibînin ka ji bilî pirsgirêkên ku min behs kiriye çi pirsgirêkên din bi Patroni re hene, hûn dikarin her gav rûpelê bişopînin. li ser GitHub. Çîrokên cuda hene û gelek mijarên balkêş li wir tên nîqaşkirin. Û di encamê de, hin xeletî hatin destnîşan kirin û çareser kirin, ango ev xwendinek balkêş e.
Çîrokên balkêş li ser kesên ku gule li lingê xwe dibarînin hene. Pir agahdar. Hûn dixwînin û fêm dikin ku ne hewce ye ku meriv wiya bike. Min xwe hejand.
Û ez dixwazim spasiyek mezin ji Zalando re ji bo pêşxistina vê projeyê, ango ji Alexander Kukushkin û Alexey Klyukin re bibêjim. Aleksey Klyukin yek ji nivîskarên hevpar e, ew êdî li Zalando naxebite, lê ev du kes in ku bi vê berhemê re dest bi xebatê kirine.
Û ez difikirim ku Patroni tiştek pir xweş e. Ez kêfxweş im ku ew heye, bi wê re balkêş e. Û spasek mezin ji hemî beşdarên ku ji Patroni re paçeyan dinivîsin. Ez hêvî dikim ku Patroni bi temen re mazintir, sartir û bikêrtir bibe. Ew jixwe fonksiyonel e, lê ez hêvî dikim ku ew ê hîn çêtir bibe. Ji ber vê yekê, heke hûn plan dikin ku Patroni bikar bînin, wê hingê netirsin. Ev çareseriyek baş e, dikare were pêkanîn û bikar anîn.
Navê pêger. Ger pirsên we hebin, bipirsin.
Pirsên
Spas ji bo raporê! Ger piştî peldankek hûn hîn jî hewce ne ku pir bi baldarî li wir mêze bikin, wê hingê çima ji me re peldankek otomatîkî hewce ye?
Ji ber ku ew tiştên nû ye. Em tenê salek bi wê re ne. Çêtir e ku ewle be. Em dixwazin werin hundur û bibînin ku her tişt bi rastî wekî ku divê xebitî. Ev asta bêbaweriya mezinan e - çêtir e ku meriv du caran kontrol bike û bibîne.
Mînakî, em sibê çûn û me mêze kir, rast?
Ne sibehê, em bi gelemperî hema hema yekser li ser otofîlê fêr dibin. Em agahdarî distînin, em dibînin ku pelek otomatîkî çêbûye. Em hema yekser diçin û digerin. Lê divê ev hemû kontrol bên asta çavdêriyê. Ger hûn bi riya API-ya REST-ê xwe bigihînin Patroni, dîrokek heye. Ji hêla dîrokê ve hûn dikarin demjimêrên dema ku peler çêbûye bibînin. Li ser vê yekê, çavdêrî dikare were kirin. Hûn dikarin dîrokê bibînin, çend bûyer li wir bûn. Ger zêdetir bûyerên me hebin, wê hingê pelek otomatîkî çêbûye. Hûn dikarin herin û bibînin. An jî otomasyona çavdêriya me kontrol kir ku me hemî kopiyên li cîhê me hene, dereng tune û her tişt baş e.
Spas!
Gelek spas ji bo çîroka mezin! Ger me koma DCS li cîhek dûr ji koma Postgres bar kir, wê hingê ev kom jî pêdivî ye ku bi periyodîk were servîs kirin? Pratîkên çêtirîn çi ne ku hin perçeyên koma DCS-ê hewce ne ku werin vemirandin, tiştek ku bi wan re were kirin, hwd.? Ev tevaya avahî çawa dijî? Û hûn van tiştan çawa dikin?
Ji bo pargîdaniyek, pêdivî bû ku matrixek pirsgirêkan çêbike, ka çi dibe bila bibe heke yek ji pêkhateyan an çend pêkhateyan têk biçin. Li gorî vê matrixê, em bi rêzê li hemû pêkhateyan derbas dibin û di dema têkçûna van pêkhateyan de senaryoyan ava dikin. Li gorî vê yekê, ji bo her senaryoyek têkçûnê, hûn dikarin ji bo başbûnê plansaziyek çalakiyê hebe. Û di doza DCS de, ew wekî beşek ji binesaziya standard tê. Û rêvebir wê bi rê ve dibe, û em berê xwe didin rêvebirên ku wê bi rê ve dibin û şiyana wan a rastkirina wê di bûyera qezayan de. Ger DCS bi tevahî tune be, wê hingê em wê bicîh dikin, lê di heman demê de em bi taybetî çavdêriya wê nakin, ji ber ku em ne berpirsiyarê binesaziyê ne, lê em pêşniyaran li ser çawa û çi çavdêriyê didin.
Ango, ma min rast fêm kir ku ez hewce dikim ku Patroni neçalak bikim, pelê neçalak bikim, her tiştî neçalak bikim berî ku ez tiştek bi mêvandaran re bikim?
Ew bi çend girêkên me yên di koma DCS de ve girêdayî ye. Ger gelek girêk hebin û heke em tenê yek ji girêkan (kopîka) neçalak bikin, wê gavê kom quorumê diparêze. Û Patroni di operasyonê de dimîne. Û tiştek nayê avêtin. Ger hin operasyonên me yên tevlihev hene ku bandorê li zêdetir girêkan dikin, nebûna wan dikare quorumê xera bike, wê hingê - erê, dibe ku maqûl be ku em Patroni bidin sekinandin. Ew fermanek têkildar heye - patronictl pause, patronictl resume. Em tenê disekinin û otofiler wê demê naxebite. Em li ser koma DCS-ê lênihêrînê dikin, dûv re em rawestanê radikin û jiyanê didomînin.
Şivan Perwer
Gelek spas ji bo rapora we! Tîma hilberê li ser windabûna daneyan çawa hîs dike?
Tîmên hilberan eleqedar nakin, û rêberên tîmê bi fikar in.
Çi garantî hene?
Garantî pir dijwar in. Alexander Kukushkin raporek "RPO û RTO çawa tê hesibandin" heye, ango dema başbûnê û çiqas daneya ku em dikarin winda bikin. Ez difikirim ku divê em van slaytan bibînin û wan lêkolîn bikin. Bi qasî ku tê bîra min, gavên taybetî hene ku meriv van tiştan çawa hesab dike. Em dikarin çend danûstendinan winda bikin, em dikarin çend daneyan winda bikin. Wekî vebijark, em dikarin di asta Patroni de dubarekirina hevdemî bikar bînin, lê ev şûrek du-devî ye: an pêbaweriya daneya me heye, an jî em lezê winda dikin. Veguheztina hevdem heye, lê ew jî 100% parastina li dijî windabûna daneyê garantî nake.
Alexey, spas ji bo rapora mezin! Ti ezmûnek bi karanîna Patroni ji bo parastina asta sifir heye? Yanî bi hevdemî standby? Ev pirsa yekem e. Û pirsa duyemîn. We çareseriyên cuda bikar anîne. Me Repmgr bikar anî, lê bêyî otofiler, û naha em plan dikin ku otofiler têxin nav xwe. Û em Patroni wekî çareseriyek alternatîf dibînin. Hûn dikarin li gorî Repmgr wekî avantajên çi bibêjin?
Pirsa yekem li ser kopiyên hevdem bû. Tu kes li vir dubarekirina hevdemî bikar nayîne, ji ber ku her kes ditirse (Gelek xerîdar berê wê bikar tînin, di prensîbê de, wan pirsgirêkên performansê nedîtin - Nîşe Speaker). Lê me ji xwe re qaîdeyek pêşxistiye ku divê herî kêm sê girêk di komikek dubarekirina hevdem de hebin, ji ber ku ger du girêkên me hebin û heke master an replica têk biçe, wê hingê Patroni vê girêkê vediguhezîne moda Standalone da ku serîlêdan berdewam bike. kar. Di vê rewşê de, rîska windabûna daneyê heye.
Di derbarê pirsa duyemîn de, me Repmgr bikar aniye û hîn jî ji ber sedemên dîrokî bi hin xerîdaran re dikin. Çi dikare bê gotin? Patroni bi otofilerek ji qutiyê tê, Repmgr bi otofiler re wekî taybetmendiyek pêvek a ku divê were çalak kirin tê. Pêdivî ye ku em li ser her girêk daemon Repmgr bimeşînin û dûv re em dikarin otofiler mîheng bikin.
Repmgr kontrol dike ka girêkên Postgres sax in. Pêvajoyên Repmgr hebûna hevûdu kontrol dikin, ev ne nêzîkatiyek pir bikêr e. dibe ku rewşên tevlihev ên îzolekirina torê hebin ku tê de komek mezin a Repmgr dikare li çend piçûktir perçe bibe û xebata xwe bidomîne. Demek dirêj e ez Repmgr naşopînim, dibe ku ew rast bû ... an dibe ku ne. Lê rakirina agahdariya li ser rewşa koma li DCS, wekî Stolon, Patroni dike, vebijarka herî maqûl e.
Alexey, pirsek min heye, dibe ku pirsek lamer. Di yek ji mînakên yekem de, we DCS ji makîneya herêmî veguhezand mêvanek dûr. Em têdigihin ku tore tiştek e ku taybetmendiyên xwe hene, ew bi xwe dijî. Û heke ji ber hin sedeman koma DCS neberdest bibe, çi dibe? Ez ê sedeman nebêjim, dibe ku gelek ji wan hebin: ji destên qeşeng ên toran heya pirsgirêkên rastîn.
Min ew bi dengekî bilind negot, lê divê komika DCS jî têkçûyî be, ango ew jimareyek bêkêmasî ya girêkan e, da ku quorumek pêk were. Ger komika DCS neberdest bibe, an quorumek pêk neyê, ango celebek perçebûna torê an têkçûna nodê çi dibe? Di vê rewşê de, koma Patroni diçe moda tenê xwendinê. Koma Patroni nikare rewşa komê û çi bike diyar bike. Ew nikare bi DCS-ê re têkilî dayne û rewşa koma nû li wir hilîne, ji ber vê yekê tevahiya komê tenê diçe xwendinê. Û li benda destwerdana bi destan a ji operatorê an jî ji bo vegerandina DCS ye.
Bi gelemperî, DCS ji me re dibe karûbarek bi qasî bingeh bi xwe?
Yes Yes. Di gelek pargîdaniyên nûjen de, Vedîtina Karûbar beşek yekbûyî ya binesaziyê ye. Beriya ku di binesaziyê de databasek hebe jî ew tê sepandin. Bi nisbetî re, binesaziyê hate destpêkirin, li DC-ê hate bicîh kirin, û me tavilê xwedan Vedîtina Karûbarê ye. Ger ew Konsul be, wê hingê DNS dikare li ser wê were çêkirin. Ger ev Etcd be, wê hingê dibe ku beşek ji koma Kubernetes hebe, ku tê de dê her tiştê din were bicîh kirin. Ji min re xuya dike ku Vedîtina Karûbarê jixwe beşek yekbûyî ya binesaziyên nûjen e. Û ew ji databasan pir zûtir li ser wê difikirin.
Spas!
Source: www.habr.com