Mga Istorya sa Pagkapakyas sa Patroni o Giunsa pag-crash ang imong PostgreSQL cluster. Alexey Lesovsky

Ang nag-unang tumong sa Patroni mao ang paghatag og High Availability alang sa PostgreSQL. Apan ang Patroni usa lamang ka template, dili usa ka andam nga himan (nga, sa kinatibuk-an, giingon sa dokumentasyon). Sa una nga pagtan-aw, nga na-set up ang Patroni sa test lab, makita nimo kung unsa kini ka maayo nga himan ug kung unsa kadali kini pagdumala sa among mga pagsulay sa pagguba sa cluster. Bisan pa, sa praktis, sa usa ka palibot sa produksiyon, ang tanan dili kanunay mahitabo ingon ka matahum ug kaanyag sama sa usa ka test lab.

Isulti ko kanimo ang gamay bahin sa akong kaugalingon. Nagsugod ko isip usa ka tigdumala sa sistema. Nagtrabaho sa web development. Nagtrabaho ko sa Data Egret sukad 2014. Ang kompanya nakigbahin sa pagkonsulta sa natad sa Postgres. Ug kami nag-alagad sa tukma nga mga Postgres, ug kami nagtrabaho uban sa mga Postgres matag adlaw, mao nga kami adunay lain-laing mga kahanas nga may kalabutan sa operasyon.

Ug sa katapusan sa 2018, nagsugod kami sa hinay nga paggamit sa Patroni. Ug ang pipila ka kasinatian natipon. Sa usa ka paagi nadayagnos namo kini, gipahiangay kini, miabut sa among labing maayo nga mga gawi. Ug niini nga taho ako maghisgot mahitungod kanila.

Gawas sa Postgres, ganahan ko sa Linux. Ganahan ko magsuroy-suroy niini ug mag-explore, ganahan ko mangolekta og mga cores. Ganahan ko sa virtualization, containers, docker, Kubernetes. Kining tanan nakapainteres kanako, tungod kay ang mga karaan nga batasan sa admin makaapekto. Ganahan kong makig-atubang sa pagmonitor. Ug ganahan ko sa mga postgres nga butang nga may kalabotan sa administrasyon, ie replication, backup. Ug sa akong bakante nga oras nagsulat ko sa Go. Dili ko software engineer, nagsulat lang ko para sa akong kaugalingon sa Go. Ug kini naghatag kanako og kalipay.

• Sa akong hunahuna daghan kaninyo ang nahibal-an nga ang mga Postgres walay HA (High Availability) gikan sa kahon. Aron makuha ang HA, kinahanglan nimo nga i-install ang usa ka butang, i-configure kini, paningkamot ug makuha kini.
• Adunay ubay-ubay nga mga himan ug ang Patroni usa niini nga nagsulbad sa HA nga cool ug maayo kaayo. Apan pinaagi sa pagbutang niini sa tanan sa usa ka test lab ug pagpadagan niini, atong makita nga ang tanan nga mga buhat, kita mahimo usab sa pipila ka mga problema, tan-awa kon sa unsang paagi Patroni nag-alagad kanila. Ug atong makita nga kining tanan maayo kaayo.
• Apan sa praktis, lainlain ang among giatubang nga mga problema. Ug ako maghisgot mahitungod niini nga mga problema.
• Isulti ko kanimo kung giunsa namon kini nadayagnos, kung unsa ang among gi-tweak - nakatabang ba kini kanamo o wala.

• Dili ko isulti kanimo kung giunsa ang pag-install sa Patroni, tungod kay mahimo nimo ang google sa Internet, mahimo nimong tan-awon ang mga file sa pag-configure aron masabtan kung giunsa kini tanan nagsugod, kung giunsa kini gi-configure. Mahimo nimong masabtan ang mga laraw, arkitektura, pagpangita og kasayuran bahin niini sa Internet.
• Dili ko maghisgot bahin sa kasinatian sa uban. Maghisgot lang ko sa mga problema nga among giatubang.
• Ug dili ko maghisgot bahin sa mga problema nga naa sa gawas sa Patroni ug PostgreSQL. Kung, pananglitan, adunay mga problema nga adunay kalabotan sa pagbalanse, kung nahugno ang among cluster, dili nako kini hisgutan.

Ug gamay nga disclaimer sa dili pa kita magsugod sa atong report.

Kining tanan nga mga problema nga among nasugatan, naa namo kini sa unang 6-7-8 ka bulan nga operasyon. Sa paglabay sa panahon, nakaabot kami sa among internal nga labing maayong gawi. Ug nawala ang among mga problema. Busa, ang taho gipahibalo mga unom ka bulan ang milabay, sa diha nga kini tanan presko sa akong ulo ug akong nahinumduman kini sa hingpit.

Sa dagan sa pag-andam sa taho, gipataas ko na ang daan nga mga postmortem, gitan-aw ang mga troso. Ug ang pipila sa mga detalye mahimong makalimtan, o ang pipila sa pipila ka mga detalye dili hingpit nga masusi sa panahon sa pagtuki sa mga problema, mao nga sa pipila ka mga punto ingon og ang mga problema dili hingpit nga gikonsiderar, o adunay pipila ka kakulang sa kasayuran. Ug busa gihangyo ko ikaw nga pasayloa ako alang niining higayona.

Unsa ang Patroni?

• Kini usa ka template alang sa pagtukod sa HA. Mao kana ang giingon sa dokumentasyon. Ug gikan sa akong panglantaw, kini usa ka husto nga pagpatin-aw. Ang Patroni dili usa ka pilak nga bala nga makasulbad sa tanan nimong mga problema, sa ato pa, kinahanglan nimo nga maningkamot aron kini molihok ug magdala mga benepisyo.
• Kini usa ka serbisyo sa ahente nga gi-install sa matag serbisyo sa database ug usa ka klase sa init nga sistema para sa imong mga Postgres. Nagsugod kini sa mga Postgres, mihunong, nag-restart, nag-reconfigure, ug nagbag-o sa topology sa imong cluster.
• Tungod niini, aron matipigan ang kahimtang sa cluster, ang kasamtangan nga representasyon niini, ingon sa hitsura niini, gikinahanglan ang usa ka matang sa pagtipig. Ug gikan niini nga punto sa panglantaw, si Patroni mikuha sa dalan sa pagtipig sa estado sa usa ka eksternal nga sistema. Kini usa ka distributed configuration storage system. Mahimo kini nga Etcd, Consul, ZooKeeper, o kubernetes Etcd, i.e. usa niini nga mga kapilian.
• Ug usa sa mga bahin sa Patroni mao nga makuha nimo ang autofiler gikan sa kahon, pinaagi lamang sa pag-set up niini. Kung gikuha namon ang Repmgr alang sa pagtandi, nan ang filer gilakip didto. Uban sa Repmgr, nakakuha kami usa ka switchover, apan kung gusto namon ang usa ka autofiler, nan kinahanglan namon nga i-configure kini dugang. Si Patroni aduna nay autofiler gikan sa kahon.
• Ug adunay daghang uban pang mga butang. Pananglitan, ang pagmentinar sa mga kumpigurasyon, pagbubo sa bag-ong mga replika, backup, ug uban pa. Apan kini labaw pa sa kasangkaran sa taho, dili ako maghisgot niini.

Ug ang gamay nga resulta mao nga ang nag-unang tahas sa Patroni mao ang paghimo sa usa ka autofile nga maayo ug kasaligan aron ang among cluster magpabilin nga operasyon ug ang aplikasyon dili makamatikod sa mga pagbag-o sa cluster topology.

Apan kung nagsugod kami sa paggamit sa Patroni, ang among sistema labi ka komplikado. Kung sa sayo pa kami adunay mga Postgres, unya kung gigamit ang Patroni makuha namon ang Patroni mismo, makuha namon ang DCS kung diin gitipig ang estado. Ug kini tanan kinahanglan nga molihok sa usa ka paagi. Busa unsa ang mahimong sayop?

Mahimong mabungkag:

• Mahimong mabungkag ang mga postgres. Kini mahimo nga usa ka agalon o usa ka kopya, ang usa niini mahimong mapakyas.
• Ang Patroni mismo mahimong mabuak.
• Ang DCS diin gitipigan ang estado mahimong maguba.
• Ug ang network mahimong maguba.

Kining tanan nga mga punto akong ikonsiderar sa report.

Akong ikonsiderar ang mga kaso samtang kini nahimong mas komplikado, dili gikan sa punto nga ang kaso naglakip sa daghang mga sangkap. Ug gikan sa punto sa panglantaw sa suhetibong mga pagbati, nga kini nga kaso mao ang lisud alang kanako, kini mao ang lisud nga sa pag-disassemble niini ... ug vice versa, sa pipila ka mga kaso mao ang gaan ug kini sayon ​​sa pag-disassemble niini.

Ug ang una nga kaso mao ang labing kadali. Mao kini ang kahimtang sa dihang mikuha kami ug database cluster ug gi-deploy ang among DCS storage sa samang cluster. Kini ang labing kasagarang sayop. Kini usa ka sayup sa pagtukod sa mga arkitektura, i.e., paghiusa sa lainlaing mga sangkap sa usa ka lugar.

So, naay nag filer, sugton ta sa nahitabo.

Ug dinhi kami interesado kung kanus-a nahitabo ang filer. Kana mao, interesado kami niining higayona sa panahon nga ang kahimtang sa cluster nausab.

Apan ang filer dili kanunay diha-diha dayon, i.e. wala kini magkinahanglan og bisan unsang yunit sa oras, mahimo kini nga malangan. Mahimo kini nga dugay.

Busa, kini adunay panahon sa pagsugod ug panahon sa pagtapos, sa ato pa, kini usa ka padayon nga panghitabo. Ug among gibahin ang tanan nga mga panghitabo sa tulo ka mga agwat: kami adunay oras sa wala pa ang filer, sa panahon sa filer ug pagkahuman sa filer. Sa ato pa, gikonsiderar namon ang tanan nga mga panghitabo sa kini nga timeline.

Ug ang unang butang, sa diha nga ang usa ka filer nahitabo, atong tan-awon ang hinungdan sa unsa ang nahitabo, unsa ang hinungdan sa unsa ang mitultol ngadto sa filer.

Kung atong tan-awon ang mga troso, kini mahimong klasiko nga mga troso sa Patroni. Gisultihan niya kami diha kanila nga ang server nahimong agalon, ug ang papel sa agalon miagi niini nga node. Dinhi kini gipasiugda.

Sunod, kinahanglan natong masabtan kung nganong nahitabo ang filer, i.e. unsa nga mga panghitabo ang nahitabo nga hinungdan nga ang master nga papel sa pagbalhin gikan sa usa ka node ngadto sa lain. Ug sa kini nga kaso, ang tanan yano ra. Kami adunay sayup sa pagpakig-uban sa sistema sa pagtipig. Ang agalon nakaamgo nga dili siya makatrabaho sa DCS, nga mao, adunay usa ka matang sa problema sa interaksyon. Ug ingon niya nga dili na siya mahimong agalon ug mo-resign. Kini nga linya nga "gipaubos sa kaugalingon" nagsulti nga eksakto.

Kung atong tan-awon ang mga panghitabo nga nag-una sa filer, atong makita didto ang mga hinungdan nga hinungdan sa problema sa pagpadayon sa wizard.

Kung atong tan-awon ang mga troso sa Patroni, atong makita nga kita adunay daghan nga mga sayop, mga timeout, i.e. ang ahente sa Patroni dili makatrabaho sa DCS. Sa kini nga kaso, kini ang ahente sa Consul, nga nakigsulti sa pantalan 8500.

Ug ang problema dinhi mao nga ang Patroni ug ang database nagdagan sa parehas nga host. Ug ang mga server sa Consul gilunsad sa parehas nga node. Pinaagi sa paghimo og load sa server, nakamugna mi og mga problema para sa mga Consul servers usab. Dili sila makakomunikar sa hustong paagi.

Human sa pipila ka mga panahon, sa dihang ang load mihubas, ang among Patroni nakahimo sa pagpakigsulti sa mga ahente pag-usab. Gipadayon ang normal nga trabaho. Ug ang parehas nga Pgdb-2 server nahimo na usab nga agalon. Kana mao, adunay usa ka gamay nga pag-flip, tungod niini ang node nag-resign sa mga gahum sa agalon, ug unya gikuha kini pag-usab, nga mao, ang tanan mibalik ingon nga kaniadto.

Ug kini mahimong isipon nga usa ka bakak nga alarma, o kini mahimong isipon nga gibuhat ni Patroni ang tanan nga husto. Sa ato pa, nakaamgo siya nga dili niya mapadayon ang kahimtang sa cluster ug gitangtang ang iyang awtoridad.

Ug dinhi mitungha ang problema tungod sa kamatuoran nga ang mga server sa Consul naa sa parehas nga hardware sama sa mga base. Busa, bisan unsa nga load: kini mao ang load sa mga disk o processor, kini usab makaapekto sa pakig-uban sa Consul cluster.

Ug nakahukom kami nga dili kini mag-uban, naggahin kami usa ka lahi nga cluster alang sa Consul. Ug si Patroni nagtrabaho na sa usa ka bulag nga Consul, nga mao, adunay usa ka lahi nga cluster sa Postgres, usa ka lahi nga cluster sa Consul. Kini usa ka sukaranan nga panudlo kung giunsa ang pagdala ug pagtipig sa tanan nga mga butang aron dili kini maghiusa.

Isip usa ka kapilian, mahimo nimong iliko ang mga parameter ttl, loop_wait, retry_timeout, i.e. sulayi nga mabuhi kini nga mga mubu nga panahon nga mga peak sa pagkarga pinaagi sa pagdugang niini nga mga parameter. Apan dili kini ang labing angay nga kapilian, tungod kay kini nga pagkarga mahimong dugay sa panahon. Ug molapas ra kami sa kini nga mga limitasyon sa kini nga mga parameter. Ug tingali dili kana makatabang.

Ang unang problema, sumala sa imong nasabtan, yano ra. Among gikuha ug gibutang ang DCS kauban ang base, naa mi problema.

Ang ikaduha nga problema susama sa una. Susama kini nga kita adunay mga problema sa interoperability sa DCS system.

Kung atong tan-awon ang mga troso, atong makita nga aduna na usab kitay sayop sa komunikasyon. Ug si Patroni nag-ingon nga dili ko makig-interact sa DCS mao nga ang kasamtangan nga agalon moadto sa replica mode.

Ang tigulang nga agalon nahimong usa ka replika, dinhi si Patroni nagtrabaho, ingon nga kini kinahanglan. Nagdagan kini pg_rewind aron i-rewind ang log sa transaksyon ug dayon magkonektar sa bag-ong agalon aron maabut ang bag-ong agalon. Dinhi nagtrabaho si Patroni, ingon nga kinahanglan niya.

Dinhi kinahanglan naton pangitaon ang lugar nga nag-una sa filer, i.e. kadtong mga sayup nga hinungdan nga adunay usa ka filer. Ug niining bahina, ang mga troso sa Patroni sayon ​​​​nga gamiton. Gisulat niya ang parehas nga mga mensahe sa usa ka gilay-on. Ug kung magsugod kita sa pag-scroll sa kini nga mga troso sa madali, nan atong makita gikan sa mga troso nga ang mga troso nausab, nga nagpasabot nga ang pipila ka mga problema nagsugod na. Kami dali nga mibalik niining dapita, tan-awa kung unsa ang mahitabo.

Ug sa usa ka normal nga sitwasyon, ang mga troso ingon niini. Gisusi ang tag-iya sa kandado. Ug kung ang tag-iya, pananglitan, nagbag-o, nan ang pipila ka mga panghitabo mahimong mahitabo nga kinahanglan tubagon ni Patroni. Apan sa kini nga kaso, maayo kami. Gipangita namo ang dapit diin nagsugod ang mga sayop.

Ug sa pag-scroll sa punto diin ang mga sayup nagsugod sa pagpakita, among nakita nga kami adunay usa ka auto-fileover. Ug tungod kay ang among mga kasaypanan adunay kalabotan sa pakig-uban sa DCS ug sa among kaso gigamit namon ang Consul, gitan-aw usab namon ang mga log sa Consul, kung unsa ang nahitabo didto.

Sa halos pagtandi sa oras sa filer ug sa oras sa Consul logs, atong makita nga ang atong mga silingan sa Consul cluster nagsugod sa pagduhaduha sa pagkaanaa sa ubang mga sakop sa Consul cluster.

Ug kung imong tan-awon ang mga troso sa ubang mga ahente sa Consul, makita usab nimo nga adunay usa ka matang sa pagkahugno sa network nga nahitabo didto. Ug ang tanang miyembro sa Consul cluster nagduhaduha sa paglungtad sa usag usa. Ug kini mao ang impetus alang sa filer.

Kung imong tan-awon kung unsa ang nahitabo sa wala pa kini nga mga kasaypanan, imong makita nga adunay tanan nga mga matang sa mga sayup, pananglitan, ang deadline, nahulog ang RPC, nga mao, adunay klaro nga usa ka matang sa problema sa interaksyon sa mga miyembro sa cluster sa Consul sa usag usa .

Ang pinakasimple nga tubag mao ang pag-ayo sa network. Apan alang kanako, nga nagbarug sa podium, dali ra kini isulti. Apan ang mga sirkumstansya ingon nga dili kanunay ang kustomer makaarang sa pag-ayo sa network. Mahimo siyang magpuyo sa usa ka DC ug mahimong dili makaayo sa network, makaapekto sa kagamitan. Ug busa gikinahanglan ang ubang mga kapilian.

Adunay mga kapilian:

• Ang pinakasimple nga kapilian, nga gisulat, sa akong opinyon, bisan sa dokumentasyon, mao ang pag-disable sa mga tseke sa Consul, nga mao, pagpasa lang sa usa ka walay sulod nga laray. Ug among gisultihan ang ahente sa Consul nga dili mogamit ug bisan unsang mga tseke. Uban niini nga mga pagsusi, mahimo natong ibaliwala kini nga mga bagyo sa network ug dili magsugod sa usa ka filer.
• Ang laing kapilian mao ang pag-double check sa raft_multiplier. Kini usa ka parameter sa Consul server mismo. Pinaagi sa default, kini gibutang sa 5. Kini nga kantidad girekomenda sa dokumentasyon alang sa mga palibot sa dula. Sa tinuud, nakaapekto kini sa kasubsob sa pagmemensahe tali sa mga miyembro sa network sa Consul. Sa tinuud, kini nga parameter nakaapekto sa katulin sa komunikasyon sa serbisyo tali sa mga miyembro sa cluster sa Consul. Ug alang sa produksiyon, girekomenda na nga pakunhuran kini aron ang mga node magbinayloay og mga mensahe nga mas kanunay.
• Ang laing kapilian nga among nahimo mao ang pagdugang sa prayoridad sa mga proseso sa Consul taliwala sa ubang mga proseso alang sa scheduler sa proseso sa operating system. Adunay ingon nga "maayo" nga parameter, kini nagtino lamang sa prayoridad sa mga proseso nga gikonsiderar sa OS scheduler sa pag-iskedyul. Gipaubos usab namo ang nindot nga kantidad sa mga ahente sa Consul, i.e. gidugangan ang prayoridad aron ang operating system naghatag sa mga proseso sa Consul og dugang nga panahon sa pagtrabaho ug pagpatuman sa ilang code. Sa among kaso, nakasulbad kini sa among problema.
• Ang laing kapilian mao ang dili paggamit sa Consul. Naa koy amigo nga dako kaayog supporter sa Etcd. Ug kanunay kaming makiglalis kaniya kung unsa ang mas maayo nga Etcd o Konsul. Apan kung unsa ang mas maayo, kasagaran kami mouyon kaniya nga ang Consul adunay ahente nga kinahanglan nga modagan sa matag node nga adunay database. Sa ato pa, ang interaksyon ni Patroni sa cluster sa Consul moagi niini nga ahente. Ug kini nga ahente nahimong bottleneck. Kung adunay mahitabo sa ahente, dili na makatrabaho si Patroni sa cluster sa Consul. Ug mao kini ang problema. Walay ahente sa Etcd nga plano. Mahimong direkta nga magtrabaho si Patroni sa usa ka lista sa mga server sa Etcd ug nakigsulti na kanila. Niining bahina, kung mogamit ka og Etcd sa imong kompanya, nan ang Etcd mahimo’g mas maayo nga kapilian kaysa sa Consul. Apan kami sa among mga kustomer kanunay nga limitado sa kung unsa ang gipili ug gigamit sa kliyente. Ug kami adunay Consul sa kadaghanan alang sa tanan nga mga kliyente.
• Ug ang katapusan nga punto mao ang pag-usab sa mga kantidad sa parameter. Mahimo natong ipataas kini nga mga parameter sa paglaum nga ang atong mga short-term nga problema sa network mahimong mubo ug dili mahulog sa gawas sa han-ay niini nga mga parameter. Niining paagiha mapakunhod nato ang pagkaagresibo sa Patroni sa pag-autofile kung adunay mga problema sa network nga mahitabo.

Sa akong hunahuna daghan nga naggamit sa Patroni ang pamilyar sa kini nga mando.

Kini nga sugo nagpakita sa kasamtangan nga kahimtang sa cluster. Ug sa unang pagtan-aw, kini nga hulagway morag normal. Naa mi master, naa mi replica, walay replication lag. Apan kini nga litrato normal ra hangtod nahibal-an naton nga kini nga cluster kinahanglan adunay tulo ka mga node, dili duha.

Tungod niini, adunay usa ka autofile. Ug pagkahuman niini nga autofile, nawala ang among replika. Kinahanglan naton mahibal-an kung ngano nga nawala siya ug ibalik siya, ibalik siya. Ug moadto kami pag-usab sa mga troso ug tan-awon kung ngano nga kami adunay usa ka auto-fileover.

Sa kini nga kaso, ang ikaduha nga kopya nahimong agalon. Maayo ra dinhi.

Ug kinahanglan natong tan-awon ang replika nga nahulog ug wala sa cluster. Among giablihan ang mga troso sa Patroni ug nakita nga kami adunay problema sa panahon sa proseso sa pagkonektar sa cluster sa pg_rewind stage. Aron makonektar sa cluster, kinahanglan nimo nga i-rewind ang log sa transaksyon, hangyoa ang gikinahanglan nga log sa transaksyon gikan sa agalon, ug gamita kini aron makaapas sa agalon.

Sa kini nga kaso, wala kami usa ka log sa transaksyon ug ang replika dili magsugod. Tungod niini, gipahunong namo ang Postgres nga adunay sayup. Ug busa wala kini sa pungpong.

Kinahanglan natong masabtan kung nganong wala kini sa cluster ug nganong walay mga troso. Moadto kami sa bag-ong agalon ug tan-awon kung unsa ang naa niya sa mga troso. Kini nahimo nga sa dihang gihimo ang pg_rewind, usa ka checkpoint ang nahitabo. Ug ang pipila sa mga karaan nga mga log sa transaksyon gibag-o lang ang ngalan. Sa diha nga ang tigulang nga agalon misulay sa pagkonektar sa bag-ong agalon ug nangutana niini nga mga troso, sila giusab na sa ngalan, sila lang wala anaa.

Gikumpara nako ang mga timestamp sa dihang nahitabo kini nga mga panghitabo. Ug didto ang kalainan literal nga 150 millisecond, nga mao, ang checkpoint nahuman sa 369 milliseconds, ang mga bahin sa WAL giilisan. Ug sa literal sa 517, pagkahuman sa 150 millisecond, nagsugod ang pag-rewind sa daan nga replika. Sa ato pa, ang literal nga 150 milliseconds igo na alang kanamo aron ang replica dili makakonekta ug makakuha.

Unsa ang mga kapilian?

Sa sinugdan migamit kami ug mga slot sa pagkopya. Naghunahuna kami nga kini maayo. Bisan kung sa una nga yugto sa operasyon gipalong namon ang mga slot. Ingon namo nga kung ang mga slots makaipon ug daghang bahin sa WAL, mahimo namong ihulog ang master. Mahulog siya. Nag-antos kami sulod sa pipila ka panahon nga walay mga slots. Ug nahibal-an namon nga kinahanglan namon ang mga slot, gibalik namon ang mga slot.

Apan adunay usa ka problema dinhi, nga kung ang agalon moadto sa replika, gitangtang niini ang mga slot ug gitangtang ang mga bahin sa WAL kauban ang mga slot. Ug aron mawagtang kini nga problema, nakahukom kami nga ipataas ang parameter sa wal_keep_segments. Nag-default kini sa 8 ka bahin. Gipataas namo kini ngadto sa 1 ug gitan-aw kung unsa kadaghan ang among libre nga luna. Ug midonar kami ug 000 ka gigabytes para sa wal_keep_segments. Kana mao, kung magbalhinbalhin, kanunay kami adunay reserba nga 16 gigabytes nga mga log sa transaksyon sa tanan nga mga node.

Ug dugang pa - kini may kalabutan gihapon alang sa dugay nga mga buluhaton sa pagpadayon. Ingnon ta nga kinahanglan natong i-update ang usa sa mga replika. Ug gusto namong i-off kini. Kinahanglan namon nga i-update ang software, tingali ang operating system, uban pa. Ug kung atong i-off ang usa ka replica, ang slot alang sa maong replika gikuha usab. Ug kung mogamit kita og gamay nga wal_keep_segments, unya sa dugay nga pagkawala sa usa ka replika, ang mga log sa transaksyon mawala. Magpataas kami og replika, mangayo kini sa mga log sa transaksyon kung diin kini mihunong, apan mahimo nga wala kini sa agalon. Ug ang replika dili usab makakonektar. Busa, kami nagtipig ug daghang mga magasin.

Kami adunay base sa produksiyon. Duna nay mga proyekto nga nagpadayon.

Adunay usa ka filer. Misulod kami ug gitan-aw - naa na ang tanan, naa sa lugar ang mga replika, wala’y lag sa pagkopya. Wala usab mga sayup sa mga troso, ang tanan naa sa kahusay.

Ang grupo sa produkto nag-ingon nga kinahanglan adunay pipila ka mga datos, apan atong makita kini gikan sa usa ka tinubdan, apan dili nato kini makita sa database. Ug kinahanglan natong masabtan kung unsa ang nahitabo kanila.

Klaro nga gimingaw sila ni pg_rewind. Nasabtan dayon namo kini, apan miadto aron tan-awon kung unsa ang nahitabo.

Sa mga troso, kanunay natong makit-an kung kanus-a nahitabo ang filer, kinsa ang nahimong master, ug atong mahibal-an kung kinsa ang tigulang nga agalon ug kung kanus-a siya gusto nga mahimong usa ka replika, i.e. kinahanglan naton kini nga mga troso aron mahibal-an ang kantidad sa mga log sa transaksyon nga nawala.

Ang among tigulang nga agalon nag-reboot. Ug si Patroni narehistro sa autorun. Gilusad ang Patroni. Nagsugod siya sa Postgres. Mas tukma, sa wala pa magsugod ang Postgres ug sa wala pa kini mahimo nga usa ka replika, gilusad ni Patroni ang proseso sa pg_rewind. Tungod niini, iyang gipapas ang bahin sa mga log sa transaksyon, gi-download ang mga bag-o ug konektado. Dinhi si Patroni nagtrabaho nga maalamon, nga mao, sama sa gipaabut. Ang cluster gipahiuli. Kami adunay 3 nga mga node, pagkahuman sa filer 3 nga mga node - ang tanan cool.

Nawad-an mig data. Ug kinahanglan natong masabtan kung unsa ka dako ang nawala kanato. Gipangita namo ang higayon nga kami adunay rewind. Makita nato kini sa maong mga journal entries. Nagsugod ang pag-rewind, adunay gibuhat didto ug natapos.

Kinahanglan naton pangitaon ang posisyon sa log sa transaksyon kung diin gibiyaan ang tigulang nga agalon. Sa kini nga kaso, kini ang marka. Ug kinahanglan namon ang ikaduha nga marka, nga mao, ang gilay-on diin ang daan nga agalon lahi sa bag-o.

Atong kuhaon ang naandan nga pg_wal_lsn_diff ug itandi kining duha ka marka. Ug sa kini nga kaso, nakakuha kami 17 megabytes. Daghan o gamay, ang matag usa nagdesisyon alang sa iyang kaugalingon. Tungod kay alang sa usa ka tawo ang 17 megabytes dili kaayo, alang sa usa ka tawo kini daghan ug dili madawat. Dinhi, ang matag indibidwal nagtino alang sa iyang kaugalingon pinauyon sa mga panginahanglanon sa negosyo.

Apan unsay atong nakaplagan sa atong kaugalingon?

Una, kinahanglan naton nga magdesisyon para sa atong kaugalingon - kinahanglan ba naton kanunay nga mag-autostart si Patroni pagkahuman sa pag-reboot sa sistema? Kanunay nga mahitabo nga kinahanglan namon nga moadto sa tigulang nga agalon, tan-awa kung unsa siya ka layo. Tingali susihon ang mga bahin sa log sa transaksyon, tan-awa kung unsa ang naa. Ug aron masabtan kung mawad-an ba kami niini nga datos o kung kinahanglan namon nga padaganon ang daan nga agalon sa standalone mode aron makuha kini nga datos.

Ug pagkahuman ra kinahanglan naton nga magdesisyon kung mahimo ba naton isalikway kini nga datos o mahimo naton kini ibalik, ikonektar kini nga node ingon usa ka kopya sa among cluster.

Dugang pa, adunay usa ka parameter nga "maximum_lag_on_failover". Sa kasagaran, kung ang akong panumduman nagsilbi kanako, kini nga parameter adunay kantidad nga 1 megabyte.

Giunsa niya pagtrabaho? Kung ang atong replica naa sa likod sa 1 megabyte nga datos sa replication lag, nan kini nga replika dili moapil sa eleksyon. Ug kung kalit nga adunay usa ka fileover, si Patroni nagtan-aw kung unsang mga replika ang naulahi. Kung naa sila sa luyo sa daghang mga log sa transaksyon, dili sila mahimong master. Kini usa ka maayo kaayo nga bahin sa seguridad nga nagpugong kanimo nga mawala ang daghang data.

Apan adunay usa ka problema sa nga ang replication lag sa Patroni cluster ug DCS updated sa usa ka piho nga agwat. Sa akong hunahuna ang 30 segundos ang default nga ttl nga kantidad.

Tungod niini, mahimong adunay usa ka sitwasyon diin adunay usa ka replication lag alang sa mga replika sa DCS, apan sa pagkatinuod adunay usa ka hingpit nga lain-laing mga lag o mahimo nga walay lag sa tanan, i.e. kini nga butang dili realtime. Ug kini dili kanunay nagpakita sa tinuod nga hulagway. Ug dili kini angayan nga buhaton ang nindot nga lohika niini.

Ug ang risgo sa pagkawala kanunay nagpabilin. Ug sa pinakagrabe nga kaso, usa ka pormula, ug sa kasagaran nga kaso, laing pormula. Sa ato pa, kung magplano kita sa pagpatuman sa Patroni ug magtimbang-timbang kung unsa kadaghan nga datos ang mawala kanato, kinahanglan nga magsalig kita sa kini nga mga pormula ug halos mahanduraw kung unsa kadaghan nga datos ang mahimo naton mawala.

Ug adunay maayong balita. Kung ang tigulang nga agalon nagpadayon, mahimo siyang magpadayon tungod sa pipila nga mga proseso sa background. Sa ato pa, adunay usa ka matang sa autovacuum, gisulat niya ang datos, gitipigan kini sa log sa transaksyon. Ug dali ra natong ibaliwala ug mawala kini nga datos. Walay problema niini.

Ug ingon niini ang hitsura sa mga troso kung ang maximum_lag_on_failover gitakda ug usa ka filer ang nahitabo, ug kinahanglan nimo nga magpili usa ka bag-ong agalon. Gi-assess sa replika ang kaugalingon nga dili makaapil sa eleksyon. Ug nagdumili siya sa pag-apil sa lumba alang sa lider. Ug naghulat siya alang sa usa ka bag-ong agalon nga mapili, aron siya makakonektar niini. Kini usa ka dugang nga sukod batok sa pagkawala sa datos.

Dinhi kami adunay usa ka team sa produkto nga nagsulat nga ang ilang produkto adunay mga problema sa Postgres. Sa samang higayon, ang agalon mismo dili ma-access, tungod kay dili kini magamit pinaagi sa SSH. Ug ang autofile dili usab mahitabo.

Kini nga host napugos sa pag-reboot. Tungod sa pag-reboot, usa ka auto-file ang nahitabo, bisan kung posible nga maghimo usa ka manual nga auto-file, ingon sa akong nasabtan karon. Ug pagkahuman sa pag-reboot, makita na naton kung unsa ang naa kanato sa kasamtangan nga agalon.

Sa samang higayon, nahibal-an na namo daan nga kami adunay mga problema sa mga disk, nga mao, nahibal-an na namo gikan sa pag-monitor kung asa magkalot ug unsa ang pangitaon.

Nakasulod kami sa postgres log, nagsugod sa pagtan-aw kung unsa ang nahitabo didto. Nakita namon ang mga pasalig nga molungtad didto sa usa, duha, tulo ka segundo, nga dili gyud normal. Nakita namon nga ang among autovacuum nagsugod nga hinay kaayo ug katingad-an. Ug nakita namon ang temporaryo nga mga file sa disk. Kana mao, kini ang tanan nga mga timailhan sa mga problema sa mga disk.

Gitan-aw namo ang system dmesg (kernel log). Ug among nakita nga kami adunay mga problema sa usa sa mga disk. Ang disk subsystem kay software Raid. Gitan-aw namo ang /proc/mdstat ug nakita namo nga kulang kami og usa ka drive. Kana mao, adunay usa ka Raid sa 8 ka mga disk, kami kulang sa usa. Kung imong tan-awon pag-ayo ang slide, unya sa output makita nimo nga wala kami sde didto. Sa amon, sa kondisyon nga pagsulti, ang disk nahulog. Kini ang hinungdan sa mga problema sa disk, ug ang mga aplikasyon nakasinati usab og mga problema sa dihang nagtrabaho uban sa Postgres cluster.

Ug sa kini nga kaso, si Patroni dili makatabang kanamo sa bisan unsang paagi, tungod kay ang Patroni wala’y tahas sa pag-monitor sa kahimtang sa server, ang estado sa disk. Ug kinahanglan natong bantayan ang maong mga sitwasyon pinaagi sa pagmonitor sa gawas. Gidugang dayon namo ang disk monitoring sa external monitoring.

Ug adunay ingon nga hunahuna - makatabang ba kanato ang fencing o watchdog software? Naghunahuna kami nga halos dili siya makatabang kanamo niini nga kaso, tungod kay sa panahon sa mga problema si Patroni nagpadayon sa pagpakig-uban sa DCS cluster ug wala'y nakita nga problema. Kana mao, gikan sa punto sa panglantaw sa DCS ug Patroni, ang tanan maayo sa cluster, bisan tuod sa pagkatinuod adunay mga problema sa disk, adunay mga problema sa pagkabaton sa database.

Sa akong opinyon, kini usa sa labing katingad-an nga mga problema nga akong gisiksik sa dugay nga panahon, nakabasa ako og daghang mga troso, gipili pag-usab ug gitawag kini nga cluster simulator.

Ang problema mao nga ang tigulang nga agalon dili mahimo nga usa ka normal nga replika, i.e. gisugdan kini ni Patroni, gipakita ni Patroni nga kini nga node naa ingon usa ka replika, apan sa samang higayon dili kini usa ka normal nga kopya. Karon makita nimo kung ngano. Mao kini ang akong gitago gikan sa pagtuki sa maong problema.

Ug sa unsang paagi nagsugod ang tanan? Nagsugod kini, sama sa miaging problema, sa mga disc brake. Kami adunay mga pasalig sa usa ka segundo, duha.

Adunay mga break sa mga koneksyon, i.e., ang mga kliyente gisi.

Adunay mga pagbabag sa lainlaing kagrabe.

Ug, sumala niana, ang disk subsystem dili kaayo mosanong.

Ug ang labing misteryoso nga butang alang kanako mao ang diha-diha nga hangyo sa pagsira nga miabot. Ang mga postgres adunay tulo ka shutdown mode:

• Nindot kini kung maghulat kami nga ang tanan nga mga kliyente maputol sa ilang kaugalingon.
• Adunay paspas kung atong pugson ang mga kliyente sa pag-disconnect tungod kay kita mag-shutdown.
• Ug diha-diha dayon. Sa niini nga kaso, diha-diha dayon dili bisan sa pagsulti sa mga kliyente sa pag-shut down, kini lang shut down nga walay pasidaan. Ug sa tanan nga mga kliyente, ang operating system nagpadala na ug RST nga mensahe (usa ka TCP nga mensahe nga ang koneksyon nabalda ug ang kliyente wala nay makuha).

Kinsa ang nagpadala niini nga signal? Ang mga proseso sa background sa postgres wala magpadala sa ingon nga mga signal sa usag usa, i.e. kini mao ang pagpatay-9. Wala sila magpadala sa ingon nga mga butang sa usag usa, nag-react lang sila sa ingon nga mga butang, i.e. kini usa ka emergency nga pagsugod pag-usab sa Postgres. Kinsa ang nagpadala niini, wala ko kabalo.

Gitan-aw nako ang "katapusan" nga sugo ug nakita nako ang usa ka tawo nga mi-log in usab niini nga server uban kanamo, apan maulaw kaayo ko nga mangutana. Tingali kini pagpatay -9. Makita nako ang pagpatay -9 sa mga troso, tungod kay Ang mga postgres nag-ingon nga gikinahanglan ang pagpatay -9, apan wala nako kini makita sa mga troso.

Sa pagtan-aw sa dugang, akong nakita nga si Patroni wala magsulat sa log sa dugay nga panahon - 54 segundos. Ug kung atong itandi ang duha ka mga timestamp, walay mga mensahe sulod sa mga 54 segundos.

Ug niining panahona adunay usa ka autofile. Nindot kaayo ang gibuhat ni Patroni dinhi. Ang among tigulang nga agalon wala magamit, adunay nahitabo kaniya. Ug ang pagpili sa usa ka bag-ong agalon nagsugod. Maayo ang tanan dinhi. Ang among pgsql01 nahimong bag-ong lider.

Naa mi replica nga nahimong master. Ug adunay ikaduha nga tubag. Ug adunay mga problema sa ikaduha nga kopya. Gisulayan niya nga i-configure pag-usab. Sa akong nasabtan, gisulayan niya nga usbon ang recovery.conf, i-restart ang Postgres ug ikonektar ang bag-ong agalon. Nagsulat siya og mga mensahe matag 10 segundos nga iyang gisulayan, apan wala siya molampos.

Ug sa panahon sa kini nga mga pagsulay, usa ka signal sa gilayon nga pagsira moabut sa daan nga agalon. Ang agalon gi-restart. Ug usab ang pag-ayo mihunong tungod kay ang tigulang nga agalon moadto sa reboot. Sa ato pa, ang replica dili makakonektar niini, tungod kay anaa kini sa shutdown mode.

Sa usa ka punto, kini nagtrabaho, apan ang pagkopya wala magsugod.

Ang akong tagna ra kay naay karaang master address sa recovery.conf. Ug sa diha nga ang usa ka bag-ong agalon nagpakita, ang ikaduha nga kopya misulay gihapon sa pagkonektar sa daan nga agalon.

Sa dihang gisugdan ni Patroni ang ikaduhang replika, ang node misugod apan dili na makopya. Ug naporma ang usa ka replication lag, nga ingon niini ang hitsura. Sa ato pa, ang tanan nga tulo ka mga node naa sa lugar, apan ang ikaduha nga node naulahi.

Sa samang higayon, kung imong tan-awon ang mga troso nga gisulat, imong makita nga ang pagkopya dili magsugod tungod kay ang mga log sa transaksyon lahi. Ug kadtong mga log sa transaksyon nga gitanyag sa agalon, nga gipiho sa recovery.conf, dili gyud angay sa among node karon.

Ug dinhi nasayop ko. Kinahanglan ko nga moadto ug tan-awon kung unsa ang naa sa recovery.conf aron masulayan ang akong hypothesis nga nagkonektar kami sa sayup nga agalon. Apan pagkahuman nag-atubang ra ako niini ug wala kini mahitabo kanako, o nakita nako nga ang replica naatraso ug kinahanglan nga pun-on, nga mao, sa bisan unsang paagi nagtrabaho ako nga wala’y pagtagad. Kini ang akong kauban.

After 30 minutes, niabot na ang admin, ie gi restart nako si Patroni sa replica. Gitapos na nako kini, naghunahuna ko nga kinahanglan na kini i-refill. Ug naghunahuna ko - I-restart nako ang Patroni, tingali adunay maayo nga mahitabo. Nagsugod ang pagkaayo. Ug gibuksan pa ang base, andam na kini nga modawat sa mga koneksyon.

Nagsugod na ang pagkopya. Apan usa ka minuto ang milabay nahulog siya sa usa ka sayup nga ang mga log sa transaksyon dili angay alang kaniya.

Naghunahuna ko nga i-restart ko pag-usab. Gi-restart nako ang Patroni pag-usab, ug wala nako gi-restart ang Postgres, apan gi-restart ang Patroni sa paglaum nga kini mahika nga magsugod sa database.

Nagsugod pag-usab ang replikasyon, apan ang mga marka sa log sa transaksyon lahi, dili sila parehas sa miaging pagsulay sa pagsugod. Mihunong na usab ang pagkopya. Ug ang mensahe medyo lahi na. Ug kini dili kaayo informative alang kanako.

Ug unya kini mahitabo kanako - unsa man kung akong i-restart ang Postgres, niining panahona naghimo ako og checkpoint sa kasamtangan nga agalon aron ibalhin ang punto sa log sa transaksyon sa usa ka gamay nga unahan aron ang pagkaayo magsugod gikan sa laing higayon? Dugang pa, naa pa mi mga stock sa WAL.

Gisugdan nako pag-usab ang Patroni, naghimo usa ka pares nga mga checkpoint sa agalon, usa ka pares nga mga punto sa pagsugod sa replika sa pagbukas niini. Ug nakatabang kini. Naghunahuna ko sa dugay nga panahon ngano nga kini nakatabang ug kung giunsa kini nagtrabaho. Ug nagsugod ang replika. Ug ang pagkopya wala na gisi.

Ang ingon nga problema alang kanako mao ang usa sa labi ka misteryoso, diin naglibog pa ako kung unsa gyud ang nahitabo didto.

Unsa ang mga implikasyon dinhi? Mahimong magtrabaho ang Patroni sumala sa katuyoan ug wala’y mga sayup. Apan sa samang higayon, kini dili usa ka 100% nga garantiya nga ang tanan maayo kanato. Ang replica mahimong magsugod, apan kini mahimong anaa sa usa ka semi-working nga estado, ug ang aplikasyon dili molihok sa ingon nga usa ka replika, tungod kay adunay daan nga datos.

Ug pagkahuman sa filer, kinahanglan nimo kanunay nga susihon kung ang tanan naa sa cluster, nga mao, adunay gikinahanglan nga gidaghanon sa mga replika, wala’y replication lag.

Ug sa atong pag-agi niini nga mga isyu, maghimo ako og mga rekomendasyon. Gisulayan nako nga i-combine sila sa duha ka slide. Tingali, ang tanan nga mga istorya mahimong ikombinar sa duha ka mga slide ug isulti lamang.

Kung mogamit ka sa Patroni, kinahanglan nimo nga adunay pagmonitor. Kinahanglan nga mahibal-an nimo kung kanus-a nahitabo ang usa ka autofileover, tungod kay kung wala ka nahibal-an nga adunay usa ka autofileover, wala ka'y ​​kontrol sa cluster. Ug kana daotan.

Pagkahuman sa matag filer, kinahanglan namon nga mano-mano nga susihon ang cluster. Kinahanglan natong sigurohon nga kanunay kita adunay pinakabag-o nga gidaghanon sa mga replika, walay replication lag, walay mga sayup sa mga log nga may kalabutan sa streaming replication, uban sa Patroni, uban sa DCS system.

Ang automation mahimong malampuson nga molihok, ang Patroni usa ka maayo kaayo nga himan. Mahimo kini, apan dili kini magdala sa cluster sa gusto nga estado. Ug kung dili nato kini mahibal-an, maproblema kita.

Ug si Patroni dili usa ka pilak nga bala. Kinahanglan pa naton masabtan kung giunsa ang mga Postgres nagtrabaho, kung giunsa ang pagkopya ug kung giunsa ang pagtrabaho ni Patroni sa mga Postgres, ug kung giunsa gihatag ang komunikasyon tali sa mga node. Gikinahanglan kini aron masulbad ang mga problema sa imong mga kamot.

Unsaon nako pagduol ang isyu sa diagnosis? Nahitabo nga nagtrabaho kami sa lainlaing mga kliyente ug wala’y usa nga adunay usa ka stack sa ELK, ug kinahanglan namon nga ihan-ay ang mga troso pinaagi sa pag-abli sa 6 nga mga console ug 2 nga mga tab. Sa usa ka tab, kini ang mga Patroni logs alang sa matag node, sa pikas tab, kini ang Consul logs, o Postgres kung gikinahanglan. Lisud kaayo ang pagdayagnos niini.

Unsa nga mga pamaagi ang akong naugmad? Una, kanunay nakong tan-awon kung naabot na ang filer. Ug para nako usa kini ka watershed. Gitan-aw nako kung unsa ang nahitabo sa wala pa ang filer, sa panahon sa filer ug pagkahuman sa filer. Ang fileover adunay duha ka marka: kini ang oras sa pagsugod ug pagtapos.

Sunod, akong gitan-aw ang mga log alang sa mga panghitabo sa wala pa ang filer, nga nag-una sa filer, i.e. Pangitaon nako ang mga hinungdan ngano nga nahitabo ang filer.

Ug kini naghatag ug hulagway sa pagsabot sa nahitabo ug unsay mahimo sa umaabot aron dili mahitabo ang maong mga kahimtang (ug isip resulta, walay filer).

Ug asa ta kasagarang pangitaon? akong tan-awon:

• Una, sa mga troso sa Patroni.
• Sunod, akong gitan-aw ang mga Postgres log, o ang DCS log, depende sa kung unsa ang nakit-an sa mga troso sa Patroni.
• Ug ang mga log sa sistema usab usahay naghatag usa ka pagsabut kung unsa ang hinungdan sa filer.

Unsa man ang akong gibati kang Patroni? Maayo kaayo ang akong relasyon ni Patroni. Sa akong hunahuna, kini ang labing kaayo karon. Daghan pa akong nahibal-an nga mga produkto. Kini mao ang Stolon, Repmgr, Pg_auto_failover, PAF. 4 mga gamit. Gisulayan nako silang tanan. Patroni ang akong paborito.

Kung mangutana sila kanako: "Girekomenda ba nako si Patroni?". Moingon ko og oo, kay ganahan ko kang Patroni. Ug nagtuo ko nga nakakat-on ko unsaon pagluto niini.

Kung interesado ka nga makita kung unsa ang ubang mga problema sa Patroni gawas sa mga problema nga akong nahisgutan, mahimo nimo kanunay nga susihon ang panid mga isyu sa GitHub. Adunay daghang lainlaing mga istorya ug daghang makapaikag nga mga isyu ang gihisgutan didto. Ug isip resulta, ang pipila ka mga bug gipaila ug nasulbad, nga mao, kini usa ka makapaikag nga pagbasa.

Adunay pipila ka makapaikag nga mga istorya bahin sa mga tawo nga nagpusil sa ilang kaugalingon sa tiil. Very informative. Imong gibasa ug nasabtan nga dili kinahanglan nga buhaton kini. Gitiktikan ko ang akong kaugalingon.

Ug gusto nakong isulti ang usa ka dako nga salamat sa Zalando alang sa pagpalambo niini nga proyekto, nga mao sila Alexander Kukushkin ug Alexey Klyukin. Si Aleksey Klyukin usa sa mga co-authors, wala na siya nagtrabaho sa Zalando, apan kini ang duha ka tawo nga nagsugod sa pagtrabaho sa kini nga produkto.

Ug sa akong hunahuna nga ang Patroni usa ka cool nga butang. Happy ko nga naa sya, interesting sa iyaha. Ug usa ka dako nga salamat sa tanan nga mga nag-ambag nga nagsulat og mga patch sa Patroni. Nanghinaut ko nga si Patroni mahimong mas hamtong, cool ug episyente sa edad. Functional na kini, pero nanghinaut ko nga mas maayo pa kini. Busa, kung nagplano ka nga gamiton ang Patroni, nan ayaw kahadlok. Kini usa ka maayong solusyon, mahimo kini ipatuman ug magamit.

Mao ra. Kung naa kay pangutana, pangutana.

Ang imong mga pangutana

Salamat sa report! Kung pagkahuman sa usa ka filer kinahanglan nimo nga tan-awon pag-ayo didto, nan nganong kinahanglan naton ang usa ka awtomatikong filer?

Tungod kay bag-o kini nga butang. Usa ra ka tuig ang among pag-uban niya. Mas maayo nga luwas. Gusto namon nga mosulod ug tan-awon nga ang tanan nagtrabaho sa paagi nga kini kinahanglan. Kini ang lebel sa kawalay pagsalig sa mga hamtong - mas maayo nga doblehon ang pagsusi ug tan-awon.

Pananglitan, miadto kami sa buntag ug nangita, di ba?

Dili sa buntag, kasagaran kita makakat-on mahitungod sa autofile hapit diha-diha dayon. Nakadawat kami mga pahibalo, nakita namon nga adunay nahitabo nga autofile. Hapit dayon mi ug tan-aw. Apan kining tanan nga mga pagsusi kinahanglan nga dad-on sa lebel sa pagmonitor. Kung ma-access nimo ang Patroni pinaagi sa REST API, adunay kasaysayan. Pinaagi sa kasaysayan imong makita ang mga timestamp kung kanus-a nahitabo ang filer. Base niini, mahimo ang pagmonitor. Makita nimo ang kasaysayan, pila ka mga panghitabo didto. Kung aduna kitay daghang mga panghitabo, unya usa ka autofile ang nahitabo. Mahimo kang moadto ug tan-awa. O gisusi sa among monitoring automation nga naa na namo ang tanan nga mga replika, wala'y lag ug maayo ang tanan.

Спасибо!

Daghang salamat sa nindot nga istorya! Kung gibalhin namon ang cluster sa DCS sa usa ka lugar nga layo sa cluster sa Postgres, nan kini nga cluster kinahanglan usab nga serbisyohan matag karon ug unya? Unsa ang labing maayo nga mga gawi nga ang pipila ka mga piraso sa DCS cluster kinahanglan nga i-off, usa ka butang nga buhaton uban kanila, ug uban pa? Sa unsang paagi mabuhi kining tibuok nga estraktura? Ug giunsa nimo pagbuhat kining mga butanga?

Alang sa usa ka kompanya, kinahanglan nga maghimo usa ka matrix sa mga problema, kung unsa ang mahitabo kung mapakyas ang usa sa mga sangkap o daghang mga sangkap. Sumala sa kini nga matrix, sunud-sunod namon ang tanan nga mga sangkap ug magtukod mga senaryo kung adunay kapakyasan sa kini nga mga sangkap. Busa, alang sa matag senaryo sa kapakyasan, mahimo kang adunay plano sa aksyon alang sa pagkaayo. Ug sa kaso sa DCS, kini moabut isip bahin sa standard nga imprastraktura. Ug ang admin ang nagdumala niini, ug nagsalig na kami sa mga admin nga nagdumala niini ug sa ilang abilidad sa pag-ayo niini kung adunay mga aksidente. Kung wala'y DCS, nan among i-deploy kini, apan sa samang higayon dili namo kini mabantayan, tungod kay dili kami responsable sa imprastraktura, apan naghatag kami og mga rekomendasyon kung unsaon ug unsa ang pag-monitor.

Sa ato pa, nasabtan ba nako sa husto nga kinahanglan nako nga i-disable ang Patroni, i-disable ang filer, i-disable ang tanan sa dili pa buhaton ang bisan unsa sa mga host?

Nagdepende kini kung pila ang among mga node sa cluster sa DCS. Kung adunay daghang mga node ug kung among gi-disable ang usa lamang sa mga node (ang replika), nan ang cluster nagmintinar sa usa ka korum. Ug ang Patroni nagpabilin nga naglihok. Ug walay na-trigger. Kung kita adunay pipila ka komplikado nga mga operasyon nga makaapekto sa daghang mga node, ang pagkawala niini makaguba sa korum, nan - oo, mahimo’g makatarunganon nga ibutang si Patroni sa paghunong. Kini adunay katugbang nga sugo - patronictl pause, patronictl resume. Nag-pause lang kami ug ang autofiler dili molihok nianang panahona. Naghimo kami og pagmentinar sa cluster sa DCS, dayon among gikuha ang paghunong ug padayon nga mabuhi.

Salamat kaayo!

Salamat kaayo sa imong report! Unsa ang gibati sa team sa produkto bahin sa pagkawala sa datos?

Ang mga team sa produkto wala magtagad, ug ang mga nanguna sa team nabalaka.

Unsa ang mga garantiya?

Ang mga garantiya lisud kaayo. Si Alexander Kukushkin adunay usa ka taho nga "Unsaon pagkalkulo sa RPO ug RTO", i.e. oras sa pagbawi ug kung unsa kadaghan nga datos ang mawala kanato. Sa akong hunahuna kinahanglan naton pangitaon kini nga mga slide ug tun-an kini. Sa akong nahinumduman, adunay mga piho nga mga lakang kung giunsa ang pagkalkulo niini nga mga butang. Pila ka mga transaksyon ang mahimo natong mawala, unsa kadaghan nga datos ang mawala kanato. Isip usa ka kapilian, mahimo natong gamiton ang dungan nga pagkopya sa lebel sa Patroni, apan kini usa ka dobleng sulab nga espada: kita adunay kasaligan sa datos, o kita mawad-an sa katulin. Adunay dungan nga pagkopya, apan dili usab kini garantiya sa 100% nga proteksyon batok sa pagkawala sa datos.

Alexey, salamat sa maayong taho! Bisan unsa nga kasinatian sa paggamit sa Patroni alang sa zero level nga proteksyon? Sa ato pa, inubanan sa synchronous standby? Kini ang unang pangutana. Ug ang ikaduhang pangutana. Gigamit nimo ang lainlaing mga solusyon. Gigamit namo ang Repmgr, apan walay autofiler, ug karon nagplano kami nga ilakip ang autofiler. Ug among gikonsiderar ang Patroni isip alternatibong solusyon. Unsa ang imong masulti nga mga bentaha kumpara sa Repmgr?

Ang unang pangutana mao ang mahitungod sa synchronous replicas. Wala’y usa nga naggamit ug dungan nga pagkopya dinhi, tungod kay ang tanan nahadlok (Daghang mga kliyente ang naggamit na niini, sa prinsipyo, wala nila namatikdan ang mga problema sa pasundayag - Mubo nga sulat sa mamumulong). Apan nakahimo kami og usa ka lagda alang sa among kaugalingon nga kinahanglan adunay labing menos tulo ka mga node sa usa ka synchronous replication cluster, tungod kay kung kami adunay duha ka mga node ug kung ang master o replica mapakyas, nan ang Patroni nagbalhin niini nga node sa Standalone mode aron ang aplikasyon magpadayon sa trabaho. Sa kini nga kaso, adunay peligro sa pagkawala sa datos.

Mahitungod sa ikaduha nga pangutana, gigamit namon ang Repmgr ug gibuhat gihapon ang pipila nga mga kliyente alang sa mga hinungdan sa kasaysayan. Unsa may ikasulti? Ang Patroni adunay usa ka autofiler gikan sa kahon, ang Repmgr adunay autofiler ingon usa ka dugang nga bahin nga kinahanglan nga mahimo. Kinahanglan natong padaganon ang Repmgr daemon sa matag node ug unya mahimo natong i-configure ang autofiler.

Gisusi sa Repmgr kung buhi ba ang mga node sa Postgres. Ang mga proseso sa Repmgr nagsusi sa pagkaanaa sa usag usa, dili kini usa ka episyente nga pamaagi. mahimo nga adunay mga komplikado nga mga kaso sa pagkahimulag sa network diin ang usa ka dako nga cluster sa Repmgr mahimong mabahin ngadto sa pipila nga mas gagmay ug magpadayon sa pagtrabaho. Dugay na kong wala magsunod sa Repmgr, basin naayo na ... o dili. Apan ang pagtangtang sa impormasyon bahin sa kahimtang sa cluster sa DCS, sama sa gihimo ni Stolon, Patroni, mao ang labing praktikal nga kapilian.

Alexey, naa koy pangutana, basin lamer. Sa usa sa unang mga pananglitan, imong gibalhin ang DCS gikan sa lokal nga makina ngadto sa layo nga host. Nakasabut kami nga ang network usa ka butang nga adunay kaugalingon nga mga kinaiya, kini nagpuyo sa iyang kaugalingon. Ug unsa ang mahitabo kung sa usa ka hinungdan ang DCS cluster mahimong dili magamit? Dili nako isulti ang mga hinungdan, mahimo’g daghan niini: gikan sa hiwi nga mga kamot sa mga networker hangtod sa tinuod nga mga problema.

Wala nako isulti kini sa kusog, apan ang cluster sa DCS kinahanglan usab nga failover, i.e. kini usa ka katingad-an nga gidaghanon sa mga node, aron maabut ang usa ka korum. Unsa ang mahitabo kung ang DCS cluster mahimong dili magamit, o ang usa ka korum dili maabot, i.e. usa ka matang sa network split o node failure? Sa niini nga kaso, ang Patroni cluster moadto sa read only mode. Ang Patroni cluster dili makatino sa kahimtang sa cluster ug unsay buhaton. Dili kini makontak sa DCS ug tipigan ang bag-ong cluster state didto, mao nga ang tibuok cluster kay read only. Ug maghulat alang sa manwal nga interbensyon gikan sa operator o alang sa DCS nga mabawi.

Sa kinatibuk-an, ang DCS nahimong usa ka serbisyo alang kanato sama ka importante sa base mismo?

Oo Oo. Sa daghang mga modernong kompanya, ang Service Discovery usa ka hinungdanon nga bahin sa imprastraktura. Gipatuman kini bisan sa wala pa ang database sa imprastraktura. Sa relatibong pagkasulti, ang imprastraktura gilunsad, gipakatap sa DC, ug diha-diha dayon kami adunay Service Discovery. Kon kini mao ang Consul, nan ang DNS mahimong matukod niini. Kung kini ang Etcd, nan mahimo nga adunay usa ka bahin gikan sa cluster sa Kubernetes, diin ang tanan igabutang. Para nako, ang Service Discovery usa na ka bahin sa modernong mga imprastraktura. Ug gihunahuna nila kini labi ka sayo kaysa sa mga database.

Спасибо!

Source: www.habr.com