Patroni Fiaskaj Rakontoj aŭ Kiel kraŝi vian PostgreSQL-grupon. Aleksej Lesovskij

La ĉefa celo de Patroni estas provizi Alta Haveblecon por PostgreSQL. Sed Patroni estas nur ŝablono, ne preta ilo (kio, ĝenerale, estas dirita en la dokumentado). Unuavide, instalinte Patroni en la testlaboratorio, vi povas vidi kia bonega ilo ĝi estas kaj kiel facile ĝi pritraktas niajn provojn rompi la areton. Tamen, en la praktiko, en produkta medio, ĉio ne ĉiam okazas tiel bele kaj elegante kiel en testa laboratorio.

Mi rakontos al vi iom pri mi mem. Mi komencis kiel sistemadministranto. Laboris en retejo-disvolviĝo. Mi laboras ĉe Data Egret ekde 2014. La kompanio okupiĝas pri konsultado en la kampo de Postgres. Kaj ni servas ĝuste Postgres, kaj ni laboras kun Postgres ĉiutage, do ni havas malsaman kompetentecon rilate al la operacio.

Kaj fine de 2018, ni komencis malrapide uzi Patroni. Kaj iom da sperto amasiĝis. Ni iel diagnozis ĝin, agordis ĝin, venis al niaj plej bonaj praktikoj. Kaj en ĉi tiu raporto mi parolos pri ili.

Krom Postgres, mi amas Linukson. Mi ŝatas piki ĝin kaj esplori, mi ŝatas kolekti kernojn. Mi amas virtualigon, ujojn, docker, Kubernetes. Ĉio ĉi interesas min, ĉar la malnovaj administraj kutimoj influas. Mi ŝatas trakti monitoradon. Kaj mi amas postgresajn aferojn rilatajn al administrado, t.e. reproduktadon, sekurkopion. Kaj en mia libertempo mi skribas en Go. Mi ne estas programaro-inĝeniero, mi nur skribas por mi en Go. Kaj ĝi donas al mi plezuron.

• Mi pensas, ke multaj el vi scias, ke Postgres ne havas HA (Alta Havebleco) el la skatolo. Por akiri HA, vi devas instali ion, agordi ĝin, klopodi kaj akiri ĝin.
• Estas pluraj iloj kaj Patroni estas unu el ili, kiu solvas HA sufiĉe bonega kaj tre bone. Sed metante ĉion en provan laboratorion kaj funkciigante ĝin, ni povas vidi ke ĉio funkcias, ni povas reprodukti iujn problemojn, vidi kiel Patroni servas ilin. Kaj ni vidos, ke ĉio funkcias bonege.
• Sed en la praktiko, ni alfrontis malsamajn problemojn. Kaj mi parolos pri ĉi tiuj problemoj.
• Mi rakontos al vi kiel ni diagnozis ĝin, kion ni tajlis - ĉu ĝi helpis nin aŭ ne.

• Mi ne diros al vi kiel instali Patroni, ĉar vi povas guglo en la Interreto, vi povas rigardi la agordajn dosierojn por kompreni kiel ĉio komenciĝas, kiel ĝi estas agordita. Vi povas kompreni la skemojn, arkitekturojn, trovi informojn pri ĝi en la Interreto.
• Mi ne parolos pri la sperto de iu alia. Mi nur parolos pri la problemoj, kiujn ni renkontis.
• Kaj mi ne parolos pri problemoj kiuj estas ekster Patroni kaj PostgreSQL. Se, ekzemple, estas problemoj asociitaj kun ekvilibro, kiam nia areto kolapsis, mi ne parolos pri tio.

Kaj malgranda malgarantio antaŭ ol ni komencu nian raporton.

Ĉiuj ĉi tiuj problemoj, kiujn ni renkontis, ni havis ilin en la unuaj 6-7-8 monatoj de operacio. Kun la tempo, ni venis al niaj internaj plej bonaj praktikoj. Kaj niaj problemoj malaperis. Tial, la raporto estis anoncita antaŭ proksimume ses monatoj, kiam ĝi estis ĉio freŝa en mia kapo kaj mi ĉion memoris perfekte.

Dum la preparado de la raporto mi jam levis malnovajn postmortemojn, rigardis la ŝtipojn. Kaj kelkaj el la detaloj povus esti forgesitaj, aŭ kelkaj el kelkaj detaloj ne povus esti plene esploritaj dum la analizo de la problemoj, do en kelkaj punktoj povas ŝajni ke la problemoj ne estas plene pripensitaj, aŭ estas iom da manko de informoj. Kaj do mi petas vin pardoni min por ĉi tiu momento.

Kio estas Patroni?

• Ĉi tio estas ŝablono por konstrui HA. Tion ĝi diras en la dokumentado. Kaj el mia vidpunkto, ĉi tio estas tre ĝusta klarigo. Patroni ne estas arĝenta kuglo, kiu solvos ĉiujn viajn problemojn, tio estas, vi devas klopodi por funkcii kaj alporti profitojn.
• Ĉi tio estas agentservo kiu estas instalita sur ĉiu datumbaza servo kaj estas speco de initsistemo por via Postgres. Ĝi lanĉas Postgres, haltigas, rekomencas, reagordas kaj ŝanĝas la topologion de via areto.
• Sekve, por konservi la staton de la areto, ĝia nuna reprezento, kiel ĝi aspektas, necesas ia stokado. Kaj de ĉi tiu vidpunkto, Patroni prenis la vojon de stokado de stato en ekstera sistemo. Ĝi estas distribuita agorda stokadosistemo. Ĝi povas esti Etcd, Consul, ZooKeeper, aŭ kubernetes Etcd, t.e. unu el ĉi tiuj opcioj.
• Kaj unu el la trajtoj de Patroni estas, ke vi eliras la aŭtomatan dosieron el la skatolo, nur agordante ĝin. Se ni prenas Repmgr por komparo, tiam la dosiero estas inkluzivita tie. Kun Repmgr, ni ricevas ŝanĝon, sed se ni volas aŭtomatan dosieron, tiam ni devas agordi ĝin aldone. Patroni jam havas aŭtomatan dosieron el la skatolo.
• Kaj estas multaj aliaj aferoj. Ekzemple, prizorgado de agordoj, verŝado de novaj kopioj, sekurkopio, ktp. Sed ĉi tio estas preter la amplekso de la raporto, mi ne parolos pri ĝi.

Kaj malgranda rezulto estas, ke la ĉefa tasko de Patroni estas fari aŭtomatan dosieron bone kaj fidinde, por ke nia areto restu funkcianta kaj la aplikaĵo ne rimarku ŝanĝojn en la cluster-topologio.

Sed kiam ni komencas uzi Patroni, nia sistemo fariĝas iom pli komplika. Se pli frue ni havis Postgres, tiam uzante Patroni ni ricevas Patroni mem, ni ricevas DCS kie stato estas konservita. Kaj ĉio devas funkcii iel. Do kio povas misfunkcii?

Paŭzo de majo:

• Postgres povus rompi. Ĝi povas esti majstro aŭ kopio, unu el ili povas malsukcesi.
• La Patroni mem povas rompi.
• La DCS kie stato estas stokita povas rompi.
• Kaj la reto povas rompi.

Ĉiujn ĉi tiujn punktojn mi konsideros en la raporto.

Mi konsideros kazojn kiam ili iĝas pli kompleksaj, ne de la vidpunkto ke la kazo implikas multajn komponantojn. Kaj el la vidpunkto de subjektivaj sentoj, ke ĉi tiu kazo estis malfacila por mi, estis malfacile malmunti ĝin ... kaj inverse, iu kazo estis malpeza kaj estis facile malmunti ĝin.

Kaj la unua kazo estas la plej facila. Ĉi tiu estas la kazo kiam ni prenis datumbazan areton kaj deplojis nian DCS-stokadon sur la sama areto. Ĉi tio estas la plej ofta eraro. Ĉi tio estas eraro en konstruado de arkitekturoj, t.e., kombinado de malsamaj komponantoj en unu loko.

Do, estis dosiero, ni iru trakti kio okazis.

Kaj ĉi tie ni interesiĝas pri kiam la dosiero okazis. Tio estas, ni interesiĝas pri ĉi tiu momento en la tempo, kiam la stato de la areto ŝanĝiĝis.

Sed la fajlilo ne ĉiam estas tuja, t.e. ĝi ne prenas ajnan unuon de tempo, ĝi povas esti prokrastita. Ĝi povas esti longdaŭra.

Tial ĝi havas komencan tempon kaj fintempon, t.e. ĝi estas kontinua evento. Kaj ni dividas ĉiujn eventojn en tri intervalojn: ni havas tempon antaŭ la dosiero, dum la dosiero kaj post la dosiero. Tio estas, ni konsideras ĉiujn eventojn en ĉi tiu templinio.

Kaj la unua afero, kiam arkivo okazis, ni serĉas la kaŭzon de kio okazis, kio estis la kaŭzo de tio, kio kondukis al la arkivo.

Se ni rigardas la ŝtipojn, ili estos klasikaj Patroni-ŝtipoj. Li diras al ni en ili, ke la servilo fariĝis la mastro, kaj la rolo de la majstro pasis al ĉi tiu nodo. Ĉi tie ĝi estas reliefigita.

Poste, ni devas kompreni kial la fajlilo okazis, t.e. kiaj eventoj okazis, kiuj kaŭzis, ke la majstra rolo moviĝis de unu nodo al alia. Kaj en ĉi tiu kazo, ĉio estas simpla. Ni havas eraron en interagado kun la stokadsistemo. La majstro rimarkis, ke li ne povas labori kun DCS, tio estas, ke estis ia problemo kun la interago. Kaj li diras, ke li ne plu povas esti majstro kaj eksiĝas. Ĉi tiu linio "degradita memo" diras ĝuste tion.

Se ni rigardas la eventojn, kiuj antaŭis la dosieron, ni povas vidi tie la kialojn, kiuj estis la problemo por la daŭrigo de la sorĉisto.

Se ni rigardas la protokolojn de Patroni, ni vidos, ke ni havas multajn erarojn, tempomalpermesojn, t.e. la agento de Patroni ne povas labori kun DCS. En ĉi tiu kazo, ĉi tio estas konsula agento, kiu komunikas sur haveno 8500.

Kaj la problemo ĉi tie estas, ke Patroni kaj la datumbazo funkcias sur la sama gastiganto. Kaj la konsulaj serviloj estis lanĉitaj sur la sama nodo. Kreante ŝarĝon sur la servilo, ni kreis problemojn ankaŭ por la konsulaj serviloj. Ili ne povis konvene komuniki.

Post iom da tempo, kiam la ŝarĝo malpliiĝis, nia Patroni povis denove komuniki kun agentoj. Normala laboro rekomencis. Kaj la sama servilo Pgdb-2 denove fariĝis la mastro. Tio estas, estis malgranda flip, pro kiu la nodo rezignis la potencojn de la majstro, kaj poste transprenis ilin denove, tio estas, ĉio revenis kiel ĝi estis.

Kaj tio povas esti rigardata kiel falsa alarmo, aŭ oni povas rigardi, ke Patroni faris ĉion ĝuste. Tio estas, li ekkomprenis ke li ne povis konservi la staton de la areto kaj forigis sian aŭtoritaton.

Kaj ĉi tie la problemo ekestis pro la fakto, ke la konsulaj serviloj estas sur la sama aparataro kiel la bazoj. Sekve, ajna ŝarĝo: ĉu ĝi estas la ŝarĝo sur diskoj aŭ procesoroj, ĝi ankaŭ influas la interagadon kun la Konsulo-grupo.

Kaj ni decidis, ke ĝi ne kunvivu, ni asignis apartan areton por Konsulo. Kaj Patroni jam laboris kun aparta Konsulo, tio estas, estis aparta Postgres-grupo, aparta Konsulo-grupo. Ĉi tio estas baza instrukcio pri kiel porti kaj konservi ĉiujn ĉi tiujn aferojn por ke ĝi ne kunvivu.

Kiel opcio, vi povas tordi la parametrojn ttl, loop_wait, retry_timeout, t.e. provi postvivi ĉi tiujn mallongperspektivajn ŝarĝpintojn pliigante ĉi tiujn parametrojn. Sed ĉi tio ne estas la plej taŭga opcio, ĉar ĉi tiu ŝarĝo povas esti longa en tempo. Kaj ni simple iros preter ĉi tiuj limoj de ĉi tiuj parametroj. Kaj tio eble ne vere helpos.

La unua problemo, kiel vi komprenas, estas simpla. Ni prenis kaj kunmetis la DCS kun la bazo, ni ricevis problemon.

La dua problemo estas simila al la unua. Ĝi similas, ke ni denove havas kunfunkcieblecojn kun la DCS-sistemo.

Se ni rigardas la protokolojn, ni vidos, ke ni denove havas eraron pri komunikado. Kaj Patroni diras, ke mi ne povas interagi kun DCS, do la nuna majstro iras en kopireĝimon.

La maljuna majstro fariĝas kopio, ĉi tie Patroni funkcias, kiel ĝi devus esti. Ĝi rulas pg_winind por rebobeni la transakcian protokolon kaj poste konekti al la nova majstro por atingi la novan majstron. Ĉi tie Patroni funkcias, kiel li devus.

Ĉi tie ni devas trovi la lokon, kiu antaŭis la dosieron, t.e. tiujn erarojn, kiuj igis nin havi dosieron. Kaj ĉi-rilate, Patroni-registroj estas sufiĉe oportunaj por labori. Li skribas la samajn mesaĝojn je certa intervalo. Kaj se ni komencos rulumi ĉi tiujn protokolojn rapide, tiam ni vidos el la protokoloj, ke la protokoloj ŝanĝiĝis, kio signifas, ke iuj problemoj komenciĝis. Ni rapide revenas al ĉi tiu loko, vidu kio okazas.

Kaj en normala situacio, la ŝtipoj aspektas kiel ĉi tio. La posedanto de la seruro estas kontrolita. Kaj se la posedanto, ekzemple, ŝanĝiĝis, tiam povas okazi iuj eventoj, al kiuj Patroni devas respondi. Sed en ĉi tiu kazo, ni fartas bone. Ni serĉas la lokon kie la eraroj komenciĝis.

Kaj ruluminte ĝis la punkto, kie la eraroj komencis aperi, ni vidas, ke ni havis aŭtomatan dosieron. Kaj ĉar niaj eraroj estis rilataj al interago kun DCS kaj en nia kazo ni uzis Konsulo, ni ankaŭ rigardas la Konsulo-protokolojn, kio okazis tie.

Malglate komparante la tempon de la arkivisto kaj la tempon en la Konsulo-protokoloj, ni vidas ke niaj najbaroj en la Konsula areto komencis dubi pri la ekzisto de aliaj membroj de la Konsula areto.

Kaj se vi ankaŭ rigardas la protokolojn de aliaj konsulaj agentoj, vi ankaŭ povas vidi, ke tie okazas ia reto-kolapso. Kaj ĉiuj membroj de la Konsula grupo dubas pri la ekzisto de unu la alian. Kaj ĉi tio estis la impulso por la arkivisto.

Se vi rigardas tion, kio okazis antaŭ ĉi tiuj eraroj, vi povas vidi, ke estas ĉiaj eraroj, ekzemple, limdato, RPC falis, tio estas, estas klare ia problemo en la interago de la Konsulo-grupo-membroj unu kun la alia. .

La plej simpla respondo estas ripari la reton. Sed por mi, starante sur la podio, estas facile diri ĉi tion. Sed la cirkonstancoj estas tiaj, ke ne ĉiam la kliento povas pagi ripari la reton. Li povas vivi en DC kaj eble ne povas ripari la reton, influi la ekipaĵon. Kaj do necesas iuj aliaj ebloj.

Estas opcioj:

• La plej simpla opcio, kiu estas skribita, laŭ mi, eĉ en la dokumentado, estas malŝalti Konsulajn kontrolojn, tio estas, simple pasi malplenan tabelon. Kaj ni diras al la Konsula agento, ke li ne uzu ajnajn ĉekojn. Kun ĉi tiuj kontroloj, ni povas ignori ĉi tiujn retajn ŝtormojn kaj ne iniciati dosieron.
• Alia opcio estas duobligi raft_multiplier. Ĉi tio estas parametro de la Konsula servilo mem. Defaŭlte, ĝi estas agordita al 5. Ĉi tiu valoro estas rekomendita de la dokumentaro por enscenigantaj medioj. Fakte, ĉi tio influas la frekvencon de mesaĝado inter membroj de la Konsula reto. Fakte, ĉi tiu parametro influas la rapidecon de serva komunikado inter membroj de la Konsula grupo. Kaj por produktado, oni jam rekomendas redukti ĝin, por ke la nodoj interŝanĝu mesaĝojn pli ofte.
• Alia opcio, kiun ni elpensis, estas pliigi la prioritaton de konsulaj procezoj inter aliaj procezoj por la procezplanisto de la operaciumo. Estas tia "bela" parametro, ĝi nur determinas la prioritaton de procezoj, kiujn la OS-planilo konsideras dum la programado. Ni ankaŭ reduktis la belan valoron por konsulaj agentoj, t.e. pliigis la prioritaton tiel ke la operaciumo donas al Consul-procezoj pli da tempo por labori kaj ekzekuti ilian kodon. En nia kazo, ĉi tio solvis nian problemon.
• Alia eblo estas ne uzi Konsulo. Mi havas amikon, kiu estas granda subtenanto de Ktp. Kaj ni regule kverelas kun li, kio estas pli bona Ktp aŭ Konsulo. Sed laŭ kio estas pli bona, ni kutime konsentas kun li, ke Konsulo havas agenton, kiu devus funkcii sur ĉiu nodo kun datumbazo. Tio estas, la interago de Patroni kun la Konsula aro trairas ĉi tiun agenton. Kaj ĉi tiu agento fariĝas botelkolo. Se io okazas al la agento, tiam Patroni ne plu povas labori kun la Konsula grupo. Kaj ĉi tiu estas la problemo. Ne estas agento en la plano Etcd. Patroni povas labori rekte kun listo de Etcd-serviloj kaj jam komuniki kun ili. Ĉi-rilate, se vi uzas Etcd en via kompanio, tiam Etcd verŝajne estos pli bona elekto ol Konsulo. Sed ni ĉe niaj klientoj ĉiam estas limigitaj de tio, kion la kliento elektis kaj uzas. Kaj ni havas Konsulon plejparte por ĉiuj klientoj.
• Kaj la lasta punkto estas revizii la parametrajn valorojn. Ni povas levi ĉi tiujn parametrojn kun la espero, ke niaj mallongperspektivaj retaj problemoj estos mallongaj kaj ne falos ekster la gamo de ĉi tiuj parametroj. Tiel ni povas redukti la agresemon de Patroni al aŭtomata dosiero se iuj retaj problemoj okazas.

Mi pensas, ke multaj kiuj uzas Patroni konas ĉi tiun komandon.

Ĉi tiu komando montras la nunan staton de la areto. Kaj unuavide, ĉi tiu bildo povas ŝajni normala. Ni havas majstron, ni havas kopion, ne estas reprodukta malfruo. Sed ĉi tiu bildo estas normala ĝuste ĝis ni scias, ke ĉi tiu areto devus havi tri nodojn, ne du.

Sekve, estis aŭtomata dosiero. Kaj post ĉi tiu aŭtomata dosiero, nia kopio malaperis. Ni devas eltrovi kial ŝi malaperis kaj revenigi ŝin, restarigi ŝin. Kaj ni denove iras al la protokoloj kaj vidas kial ni havis aŭtomatan dosieron.

En ĉi tiu kazo, la dua kopio iĝis la majstro. Ĉi tie ĉio estas en ordo.

Kaj ni devas rigardi la kopion, kiu defalis kaj kiu ne estas en la areto. Ni malfermas la protokolojn de Patroni kaj vidas, ke ni havis problemon dum la procezo de konekto al la areto ĉe la stadio pg_winind. Por konektiĝi al la areto, vi devas rebobeni la transakcian protokolon, peti la postulatan transakcian protokolon de la majstro kaj uzi ĝin por atingi la majstron.

En ĉi tiu kazo, ni ne havas transakcian protokolon kaj la kopio ne povas komenci. Sekve, ni haltigas Postgres kun eraro. Kaj tial ĝi ne estas en la areto.

Ni devas kompreni kial ĝi ne estas en la areto kaj kial ne estis protokoloj. Ni iras al la nova majstro kaj rigardas kion li havas en la ŝtipoj. Rezultas, ke kiam pg_winind estis farita, kontrolpunkto okazis. Kaj iuj el la malnovaj transakciaj protokoloj estis simple renomitaj. Kiam la malnova majstro provis konektiĝi al la nova majstro kaj pridemandi ĉi tiujn protokolojn, ili jam estis renomitaj, ili simple ne ekzistis.

Mi komparis tempomarkojn kiam ĉi tiuj eventoj okazis. Kaj tie la diferenco estas laŭvorte 150 milisekundoj, tio estas, la kontrolpunkto kompletigita en 369 milisekundoj, la WAL-segmentoj estis renomitaj. Kaj laŭvorte en 517, post 150 milisekundoj, rebobeno komenciĝis sur la malnova kopio. Tio estas, laŭvorte 150 milisekundoj sufiĉis por ni por ke la kopio ne povis konekti kaj gajni.

Kio estas la elektoj?

Ni komence uzis reproduktajn fendojn. Ni pensis, ke ĝi estas bona. Kvankam en la unua etapo de operacio ni malŝaltis la fendojn. Ŝajnis al ni, ke se la fendoj amasigas multajn WAL-segmentojn, ni povas faligi la majstron. Li falos. Ni suferis dum kelka tempo sen slotoj. Kaj ni rimarkis, ke ni bezonas slotojn, ni redonis la fendojn.

Sed estas problemo ĉi tie, ke kiam la majstro iras al la kopio, ĝi forigas la fendojn kaj forigas la WAL-segmentojn kune kun la fendoj. Kaj por forigi ĉi tiun problemon, ni decidis levi la parametron wal_keep_segments. Ĝi defaŭlte al 8 segmentoj. Ni levis ĝin al 1 kaj rigardis kiom da libera spaco ni havis. Kaj ni donacis 000 gigabajtojn por wal_keep_segments. Tio estas, kiam ni ŝanĝas, ni ĉiam havas rezervon de 16 gigabajtoj da transakciaj protokoloj sur ĉiuj nodoj.

Kaj plus - ĝi ankoraŭ estas grava por longdaŭraj prizorgaj taskoj. Ni diru, ke ni devas ĝisdatigi unu el la kopioj. Kaj ni volas malŝalti ĝin. Ni devas ĝisdatigi la programaron, eble la operaciumon, ion alian. Kaj kiam ni malŝaltas kopion, la fendo por tiu kopio ankaŭ estas forigita. Kaj se ni uzas malgrandan wal_keep_segments, tiam kun longa foresto de kopio, la transakciaj protokoloj estos perditaj. Ni levos kopion, ĝi petos tiujn transakciajn protokolojn kie ĝi ĉesis, sed ili eble ne estas sur la majstro. Kaj la kopio ankaŭ ne povos konektiĝi. Tial ni konservas grandan stokon de revuoj.

Ni havas produktan bazon. Jam estas projektoj en progreso.

Estis dosiero. Ni eniris kaj rigardis - ĉio estas en ordo, la kopioj estas en loko, ne estas reproduktado malfruo. Ankaŭ ne estas eraroj en la protokoloj, ĉio estas en ordo.

La produktteamo diras, ke devus esti iuj datumoj, sed ni vidas ĝin de unu fonto, sed ni ne vidas ĝin en la datumbazo. Kaj ni devas kompreni kio okazis al ili.

Estas klare, ke pg_winind maltrafis ilin. Ni tuj komprenis tion, sed iris por vidi kio okazas.

En la protokoloj, ni ĉiam povas trovi kiam la arkivisto okazis, kiu fariĝis la majstro, kaj ni povas determini kiu estis la malnova majstro kaj kiam li volis fariĝi kopio, t.e. ni bezonas ĉi tiujn protokolojn por ekscii la kvanton da transakciaj protokoloj kiuj estis perdita.

Nia malnova majstro rekomencis. Kaj Patroni estis registrita en la aŭtorun. Lanĉis Patroni. Li tiam komencis Postgres. Pli precize, antaŭ ol komenci Postgres kaj antaŭ fari ĝin kopio, Patroni lanĉis la pg_winind-procezon. Sekve, li forviŝis parton de la transakciaj protokoloj, elŝutis novajn kaj konektis. Ĉi tie Patroni lerte laboris, tio estas, kiel atendite. La areto estis restarigita. Ni havis 3 nodojn, post la dosiero 3 nodoj - ĉio estas bonega.

Ni perdis iujn datumojn. Kaj ni devas kompreni kiom ni perdis. Ni serĉas ĝuste la momenton, kiam ni havis rebobenadon. Ni povas trovi ĝin en tiaj ĵurnaloj. Rewind komenciĝis, faris ion tie kaj finiĝis.

Ni devas trovi la pozicion en la transakcia protokolo, kie la malnova majstro ĉesis. En ĉi tiu kazo, ĉi tiu estas la marko. Kaj ni bezonas duan markon, tio estas, la distancon, per kiu la malnova majstro diferencas de la nova.

Ni prenas la kutiman pg_wal_lsn_diff kaj komparas ĉi tiujn du markojn. Kaj en ĉi tiu kazo, ni ricevas 17 megabajtojn. Multe aŭ malmulte, ĉiu decidas por si mem. Ĉar por iu 17 megabajtoj ne estas multe, por iu estas multe kaj neakceptebla. Ĉi tie, ĉiu individuo determinas por si konforme al la bezonoj de la komerco.

Sed kion ni mem eksciis?

Unue, ni devas decidi mem - ĉu ni ĉiam bezonas Patroni aŭtomaten post rekomenco de la sistemo? Ofte okazas, ke ni devas iri al la maljuna mastro, vidi kiom malproksimen li iris. Eble inspektu segmentojn de la transakcia protokolo, vidu kio estas tie. Kaj kompreni ĉu ni povas perdi ĉi tiujn datumojn aŭ ĉu ni devas ruli la malnovan majstron en memstara reĝimo por eltiri ĉi tiujn datumojn.

Kaj nur post tio ni devas decidi ĉu ni povas forĵeti ĉi tiujn datumojn aŭ ni povas restarigi ĝin, konekti ĉi tiun nodon kiel kopion al nia areto.

Krome, ekzistas parametro "maximum_lag_on_failover". Defaŭlte, se mia memoro servas al mi, ĉi tiu parametro havas valoron de 1 megabajto.

Kiel li laboras? Se nia kopio malfruiĝas je 1 megabajto da datumoj en la replika malfruo, tiam ĉi tiu kopio ne partoprenas en la elektoj. Kaj se subite okazas dosiero, Patroni rigardas, kiuj kopioj postrestas. Se ili estas malantaŭ granda nombro da transakciaj protokoloj, ili ne povas fariĝi majstro. Ĉi tio estas tre bona sekureca trajto, kiu malhelpas vin perdi multajn datumojn.

Sed estas problemo en tio, ke la replika malfruo en la Patroni-grupo kaj DCS estas ĝisdatigita je certa intervalo. Mi pensas, ke 30 sekundoj estas la defaŭlta ttl-valoro.

Sekve, povas ekzisti situacio kie ekzistas unu reproduktadmalfruo por kopioj en DCS, sed fakte povas esti tute malsama malfruo aŭ povas esti neniu malfruo, t.e. ĉi tiu afero ne estas realtempa. Kaj ĝi ne ĉiam reflektas la realan bildon. Kaj ne indas fari fantazian logikon pri ĝi.

Kaj la risko de perdo ĉiam restas. Kaj en la plej malbona kazo, unu formulo, kaj en la averaĝa kazo, alia formulo. Tio estas, kiam ni planas la efektivigon de Patroni kaj taksas kiom da datumoj ni povas perdi, ni devas fidi ĉi tiujn formulojn kaj proksimume imagi kiom da datumoj ni povas perdi.

Kaj estas bona novaĵo. Kiam la maljuna majstro iris antaŭen, li povas daŭrigi pro iuj fonprocezoj. Tio estas, estis ia aŭtomalvakuo, li skribis la datumojn, konservis ilin al la transakcia protokolo. Kaj ni povas facile ignori kaj perdi ĉi tiujn datumojn. Ne estas problemo en ĉi tio.

Kaj jen kiel aspektas la protokoloj, se maximum_lag_on_failover estas agordita kaj dosiero okazis, kaj vi devas elekti novan majstron. La kopio taksas sin kiel nekapabla partopreni en la elektoj. Kaj ŝi rifuzas partopreni en la vetkuro por la gvidanto. Kaj ŝi atendas ke nova majstro estos elektita, por ke ŝi tiam povu konekti al ĝi. Ĉi tio estas plia mezuro kontraŭ datuma perdo.

Ĉi tie ni havas produktan teamon, kiu skribis, ke ilia produkto havas problemojn kun Postgres. Samtempe, la majstro mem ne estas alirebla, ĉar ĝi ne haveblas per SSH. Kaj la aŭtomata dosiero ankaŭ ne okazas.

Ĉi tiu gastiganto estis devigita rekomenci. Pro la rekomenco okazis aŭtomata dosiero, kvankam eblis fari manan aŭtomatan dosieron, kiel mi nun komprenas. Kaj post la rekomenco, ni jam vidos, kion ni havis kun la nuna majstro.

Samtempe, ni anticipe sciis, ke ni havas problemojn kun diskoj, tio estas, ni jam sciis de monitorado kie fosi kaj kion serĉi.

Ni eniris la postgresan protokolon, komencis vidi kio okazas tie. Ni vidis komitojn, kiuj daŭras tie unu, du, tri sekundoj, kio tute ne estas normala. Ni vidis, ke nia aŭtomata vakuo ekas tre malrapide kaj strange. Kaj ni vidis provizorajn dosierojn sur la disko. Tio estas, ĉi tiuj estas ĉiuj indikiloj de problemoj kun diskoj.

Ni rigardis en la sistemon dmesg (kerna protokolo). Kaj ni vidis, ke ni havas problemojn kun unu el la diskoj. La disksubsistemo estis programaro Raid. Ni rigardis /proc/mdstat kaj vidis, ke mankas al ni unu disko. Tio estas, estas Raid de 8 diskoj, al ni mankas unu. Se vi zorge rigardas la gliton, tiam en la eligo vi povas vidi, ke ni ne havas sde tie. Ĉe ni, kondiĉe parolante, la disko elfalis. Ĉi tio ekigis diskoproblemojn, kaj aplikaĵoj ankaŭ spertis problemojn dum laborado kun la Postgres-areto.

Kaj ĉi-kaze Patroni neniel helpus nin, ĉar Patroni ne havas la taskon kontroli la staton de la servilo, la staton de la disko. Kaj ni devas kontroli tiajn situaciojn per ekstera monitorado. Ni rapide aldonis diskan monitoradon al ekstera monitorado.

Kaj estis tia penso - ĉu skermado aŭ gardohunda programaro povus helpi nin? Ni pensis, ke li apenaŭ helpus nin en ĉi tiu kazo, ĉar dum la problemoj Patroni daŭre interagis kun la DCS-areto kaj ne vidis neniun problemon. Tio estas, el la vidpunkto de DCS kaj Patroni, ĉio estis bone kun la cluster, kvankam fakte estis problemoj kun la disko, estis problemoj kun la havebleco de la datumbazo.

Miaopinie, ĉi tiu estas unu el la plej strangaj problemoj, kiujn mi esploris dum tre longa tempo, mi legis multajn protokolojn, reelektis kaj nomis ĝin grapolsimulilo.

La problemo estis, ke la malnova majstro ne povis fariĝi normala kopio, t.e. Patroni komencis ĝin, Patroni montris, ke ĉi tiu nodo ĉeestis kiel kopio, sed samtempe ĝi ne estis normala kopio. Nun vi vidos kial. Jen kion mi konservis el la analizo de tiu problemo.

Kaj kiel ĉio komenciĝis? Ĝi komenciĝis, kiel en la antaŭa problemo, per diskobremsoj. Ni havis komitojn por sekundo, du.

Ekzistis paŭzoj en ligoj, t.e., klientoj estis ŝiritaj.

Estis blokadoj de ŝanĝiĝanta severeco.

Kaj, sekve, la disksubsistemo ne estas tre respondema.

Kaj la plej mistera afero por mi estas la tuja haltpeto kiu alvenis. Postgres havas tri fermreĝimojn:

• Estas gracia kiam ni atendas, ke ĉiuj klientoj malkonektus memstare.
• Estas rapide kiam ni devigas klientojn malkonekti ĉar ni haltos.
• Kaj tuja. En ĉi tiu kazo, tuja eĉ ne diras al klientoj fermi, ĝi simple fermiĝas sen averto. Kaj al ĉiuj klientoj, la operaciumo jam sendas RST-mesaĝon (TCP-mesaĝo, ke la konekto estas interrompita kaj la kliento havas nenion pli por kapti).

Kiu sendis ĉi tiun signalon? Postgres-fonprocezoj ne sendas tiajn signalojn unu al la alia, t.e. ĉi tio estas kill-9. Ili ne sendas tiajn aferojn unu al la alia, ili nur reagas al tiaj aferoj, t.e. ĉi tio estas urĝa rekomenco de Postgres. Kiu sendis ĝin, mi ne scias.

Mi rigardis la "lastan" komandon kaj mi vidis unu personon, kiu ankaŭ ensalutis ĉi tiun servilon ĉe ni, sed mi estis tro timema por fari demandon. Eble estis mortigo -9. Mi vidus mortigi -9 en la ŝtipoj, ĉar Postgres diras, ke ĝi bezonis kill -9, sed mi ne vidis ĝin en la protokoloj.

Rigardante plu, mi vidis, ke Patroni ne skribis al la protokolo dum sufiĉe longa tempo - 54 sekundoj. Kaj se ni komparas du tempomarkojn, ne estis mesaĝoj dum ĉirkaŭ 54 sekundoj.

Kaj dum ĉi tiu tempo estis aŭtomata dosiero. Patroni faris bonegan laboron ĉi tie denove. Nia maljuna mastro estis neatingebla, io okazis al li. Kaj la elekto de nova majstro komenciĝis. Ĉio bone funkciis ĉi tie. Nia pgsql01 fariĝis la nova gvidanto.

Ni havas kopion, kiu fariĝis majstro. Kaj estas dua respondo. Kaj estis problemoj kun la dua kopio. Ŝi provis reagordi. Kiel mi komprenas ĝin, ŝi provis ŝanĝi recovery.conf, rekomenci Postgres kaj konekti al la nova majstro. Ŝi skribas mesaĝojn ĉiujn 10 sekundojn, kiujn ŝi provas, sed ŝi ne sukcesas.

Kaj dum ĉi tiuj provoj, tuja ĉesiga signalo alvenas al la maljuna majstro. La majstro estas rekomencita. Kaj ankaŭ reakiro ĉesas ĉar la malnova majstro iras en rekomencon. Tio estas, la kopio ne povas konekti al ĝi, ĉar ĝi estas en malŝalta reĝimo.

Iam ĝi funkciis, sed reproduktado ne komenciĝis.

Mia nura supozo estas, ke estis malnova majstra adreso en recovery.conf. Kaj kiam aperis nova majstro, la dua kopio ankoraŭ provis konektiĝi al la malnova majstro.

Kiam Patroni ekfunkciis sur la dua kopio, la nodo ekfunkciis sed ne povis reprodukti. Kaj reprodukta malfruo formiĝis, kiu aspektis io kiel ĉi tio. Tio estas, ĉiuj tri nodoj estis en loko, sed la dua nodo postrestis.

Samtempe, se vi rigardas la protokolojn, kiuj estis skribitaj, vi povus vidi, ke reproduktado ne povus komenciĝi ĉar la transakciaj protokoloj estis malsamaj. Kaj tiuj transakciaj protokoloj, kiujn la mastro proponas, kiuj estas specifitaj en recovery.conf, simple ne konvenas al nia nuna nodo.

Kaj jen mi eraris. Mi devis veni kaj vidi kio estis en recovery.conf por testi mian hipotezon, ke ni konektiĝas al la malĝusta majstro. Sed tiam mi nur traktis ĉi tion kaj ne venis al mi en la kapon, aŭ mi vidis, ke la kopio postrestis kaj devus esti replenigita, tio estas, mi iel laboris senzorge. Ĉi tio estis mia artiko.

Post 30 minutoj, la administranto jam venis, t.e. mi rekomencis Patroni sur la kopio. Mi jam ĉesigis ĝin, mi pensis, ke oni devos replenigi ĝin. Kaj mi pensis — mi rekomencos Patroni, eble io bona rezultos. Reakiro komenciĝis. Kaj la bazo eĉ malfermiĝis, ĝi estis preta akcepti ligojn.

Reproduktado komenciĝis. Sed minuton poste, ŝi falis kun eraro, ke transakciaj protokoloj ne taŭgas por ŝi.

Mi pensis, ke mi rekomencos. Mi rekomencis Patroni, kaj mi ne rekomencis Postgres, sed rekomencis Patroni kun la espero, ke ĝi magie lanĉus la datumbazon.

La reproduktado komenciĝis denove, sed la markoj en la transakcia protokolo estis malsamaj, ili ne estis la samaj kiel la antaŭa komenca provo. Reproduktado ĉesis denove. Kaj la mesaĝo jam estis iomete alia. Kaj ĝi ne estis tre informa por mi.

Kaj tiam okazas al mi - kio se mi rekomencas Postgres, ĉi-momente mi faras kontrolpunkton sur la nuna majstro por movi la punkton en la transakcia protokolo iom antaŭen, por ke reakiro komenciĝu de alia momento? Krome, ni ankoraŭ havis akciojn de WAL.

Mi rekomencis Patroni, faris kelkajn kontrolpunktojn sur la majstro, kelkajn rekomencpunktojn sur la kopio kiam ĝi malfermiĝis. Kaj ĝi helpis. Mi longe pensis kial ĝi helpis kaj kiel ĝi funkciis. Kaj la kopio komenciĝis. Kaj reproduktado ne plu estis ŝirita.

Tia problemo por mi estas unu el la pli misteraj, pri kiuj mi ankoraŭ konfuziĝas pri tio, kio vere okazis tie.

Kio estas la implicoj ĉi tie? Patroni povas funkcii kiel celite kaj sen eraroj. Sed samtempe, ĉi tio ne estas 100% garantio, ke ĉio estas en ordo ĉe ni. La kopio povas komenciĝi, sed ĝi povas esti en duonfunkcia stato, kaj la aplikaĵo ne povas funkcii kun tia kopio, ĉar estos malnovaj datumoj.

Kaj post la fajlilo, vi ĉiam devas kontroli, ke ĉio estas en ordo kun la areto, tio estas, ke ekzistas la bezonata nombro da kopioj, ne ekzistas reproduktado malfruo.

Kaj dum ni ekzamenos ĉi tiujn aferojn, mi faros rekomendojn. Mi provis kombini ilin en du diapozitivojn. Verŝajne, ĉiuj rakontoj povus esti kombinitaj en du lumbildojn kaj nur rakontitaj.

Kiam vi uzas Patroni, vi devas havi monitoradon. Vi ĉiam devas scii, kiam okazis aŭtomata transdono de dosiero, ĉar se vi ne scias, ke vi havis aŭtomatan transdonon, vi ne havas kontrolon pri la areto. Kaj tio estas malbona.

Post ĉiu dosiero, ni ĉiam devas permane kontroli la areton. Ni devas certigi, ke ni ĉiam havas ĝisdatigitan nombron da kopioj, ne estas replika malfruo, ne estas eraroj en la protokoloj rilate al streaming-reproduktado, kun Patroni, kun la DCS-sistemo.

Aŭtomatigo povas funkcii sukcese, Patroni estas tre bona ilo. Ĝi povas funkcii, sed ĉi tio ne alportos la areton al la dezirata stato. Kaj se ni ne ekscios pri tio, ni havos problemojn.

Kaj Patroni ne estas arĝenta kuglo. Ni ankoraŭ bezonas kompreni kiel Postgres funkcias, kiel reproduktado funkcias kaj kiel Patroni funkcias kun Postgres, kaj kiel komunikado inter nodoj estas provizita. Ĉi tio estas necesa por povi ripari problemojn per viaj manoj.

Kiel mi traktas la temon de diagnozo? Okazis, ke ni laboras kun malsamaj klientoj kaj neniu havas ELK-stakon, kaj ni devas ordigi la protokolojn malfermante 6 konzolojn kaj 2 langetojn. En unu langeto, ĉi tiuj estas la Patroni-protokoloj por ĉiu nodo, en la alia langeto, ĉi tiuj estas la Konsulo-protokoloj, aŭ Postgres se necese. Estas tre malfacile diagnozi ĉi tion.

Kiajn alirojn mi prenis? Unue, mi ĉiam rigardas kiam la dosiero alvenis. Kaj por mi ĉi tio estas akvodislimo. Mi rigardas tion, kio okazis antaŭ la arkivo, dum la arkivo kaj post la arkivo. La dosiertransporto havas du markojn: ĉi tiu estas la komenco kaj fintempo.

Poste, mi serĉas en la protokoloj eventojn antaŭ la arkivo, kiu antaŭis la arkivilon, t.e. mi serĉas la kialojn kial la arkivilo okazis.

Kaj ĉi tio donas bildon pri kompreno, kio okazis kaj kio povas esti farita en la estonteco, por ke tiaj cirkonstancoj ne okazu (kaj kiel rezulto, ne ekzistas dosiero).

Kaj kien ni kutime rigardas? Mi rigardas:

• Unue, al la registroj de Patroni.
• Poste, mi rigardas la protokolojn de Postgres, aŭ la protokolojn de DCS, depende de tio, kio estis trovita en la protokoloj de Patroni.
• Kaj la sistemaj protokoloj ankaŭ foje donas komprenon pri tio, kio kaŭzis la dosieron.

Kiel mi sentas min pri Patroni? Mi havas tre bonan rilaton kun Patroni. Laŭ mi, ĉi tio estas la plej bona kiu ekzistas hodiaŭ. Mi konas multajn aliajn produktojn. Ĉi tiuj estas Stolon, Repmgr, Pg_auto_failover, PAF. 4 iloj. Mi provis ilin ĉiujn. Patroni estas mia plej ŝatata.

Se ili demandas min: "Ĉu mi rekomendas Patroni?". Mi diros jes, ĉar mi ŝatas Patroni. Kaj mi pensas, ke mi lernis kiel kuiri ĝin.

Se vi interesiĝas pri vidi kiajn aliajn problemojn ekzistas ĉe Patroni krom la problemoj kiujn mi menciis, vi ĉiam povas kontroli la paĝon. temoj sur GitHub. Estas multaj diversaj rakontoj kaj multaj interesaj aferoj estas diskutataj tie. Kaj kiel rezulto, kelkaj eraroj estis enkondukitaj kaj solvitaj, tio estas, ĉi tio estas interesa legado.

Estas kelkaj interesaj rakontoj pri homoj, kiuj pafas sin en la piedon. Tre informa. Vi legas kaj komprenas, ke ne necesas fari tion. Mi tiktakis min.

Kaj mi ŝatus diri grandan dankon al Zalando por disvolvi ĉi tiun projekton, nome al Aleksandro Kukuŝkin kaj Aleksej Klyukin. Aleksey Klyukin estas unu el la kunaŭtoroj, li ne plu laboras ĉe Zalando, sed ĉi tiuj estas du homoj, kiuj komencis labori kun ĉi tiu produkto.

Kaj mi pensas, ke Patroni estas tre bonega afero. Mi ĝojas, ke ŝi ekzistas, estas interese ĉe ŝi. Kaj grandan dankon al ĉiuj kontribuantoj, kiuj skribas flikaĵojn al Patroni. Mi esperas, ke Patroni fariĝos pli matura, malvarmeta kaj efika kun aĝo. Ĝi jam funkcias, sed mi esperas, ke ĝi eĉ pliboniĝos. Tial, se vi planas uzi Patroni, tiam ne timu. Ĉi tio estas bona solvo, ĝi povas esti efektivigita kaj uzata.

Tio estas ĉio. Se vi havas demandojn, demandu.

Viaj demandoj

Dankon pro la raporto! Se post dosiero vi ankoraŭ devas rigardi tie tre zorge, kial do ni bezonas aŭtomatan dosieron?

Ĉar ĝi estas novaĵo. Ni estas kun ŝi nur de unu jaro. Pli bone esti sekura. Ni volas enveni kaj vidi ke ĉio vere funkciis kiel ĝi devus. Ĉi tiu estas la nivelo de plenkreska malfido - estas pli bone kontroli kaj vidi.

Ekzemple, ni iris matene kaj rigardis, ĉu ne?

Ne matene, ni kutime lernas pri la aŭtomata dosiero preskaŭ tuj. Ni ricevas sciigojn, ni vidas, ke aŭtomata dosiero okazis. Ni preskaŭ tuj iras kaj rigardas. Sed ĉiuj ĉi tiuj kontroloj devus esti alportitaj al la monitora nivelo. Se vi aliras Patroni per la REST API, ekzistas historio. Laŭ historio vi povas vidi la tempomarkojn kiam la arkivo okazis. Surbaze de tio, monitorado povas esti farita. Vi povas vidi la historion, kiom da eventoj estis tie. Se ni havas pli da eventoj, tiam aŭtomata dosiero okazis. Vi povas iri kaj vidi. Aŭ nia monitora aŭtomatigo kontrolis, ke ni havas ĉiujn kopiojn en la loko, ne estas malfruo kaj ĉio estas en ordo.

Dankon!

Koran dankon pro la bonega rakonto! Se ni movis la DCS-areton ien malproksimen de la Postgres-areto, tiam ĉi tiu areto ankaŭ devas esti periode prizorgata? Kio estas la plej bonaj praktikoj, ke iuj pecoj de la DCS-areto devas esti malŝaltitaj, io por fari kun ili, ktp.? Kiel ĉi tiu tuta strukturo pluvivas? Kaj kiel vi faras ĉi tiujn aferojn?

Por unu kompanio, estis necese fari matricon de problemoj, kio okazas se unu el la komponantoj aŭ pluraj komponantoj malsukcesas. Laŭ ĉi tiu matrico, ni sinsekve trapasas ĉiujn komponantojn kaj konstruas scenarojn en kazo de fiasko de ĉi tiuj komponantoj. Sekve, por ĉiu malsukcesa scenaro, vi povas havi agadplanon por reakiro. Kaj en la kazo de DCS, ĝi venas kiel parto de la norma infrastrukturo. Kaj la administranto administras ĝin, kaj ni jam fidas je la administrantoj, kiuj administras ĝin kaj ilian kapablon ripari ĝin en kazo de akcidentoj. Se tute ne ekzistas DCS, tiam ni deplojas ĝin, sed samtempe ni ne precipe kontrolas ĝin, ĉar ni ne respondecas pri la infrastrukturo, sed ni donas rekomendojn pri kiel kaj kion monitori.

Tio estas, ĉu mi ĝuste komprenis, ke mi bezonas malŝalti Patroni, malŝalti la arkivilon, malebligi ĉion antaŭ ol fari ion ajn kun la gastigantoj?

Ĝi dependas de kiom da nodoj ni havas en la DCS-areto. Se estas multaj nodoj kaj se ni malŝaltas nur unu el la nodoj (la kopio), tiam la areto konservas kvorumon. Kaj Patroni restas funkcianta. Kaj nenio estas ekigita. Se ni havas iujn kompleksajn operaciojn, kiuj influas pli da nodoj, kies foresto povas ruinigi la kvorumon, tiam - jes, povus havi sencon paŭzi Patroni. Ĝi havas respondan ordon - patronictl paŭzo, patronictl resumo. Ni nur paŭzas kaj la aŭtomata dosiero ne funkcias tiutempe. Ni faras prizorgadon sur la DCS-areto, tiam ni forigas la paŭzon kaj daŭre vivas.

Multan dankon!

Koran dankon pro via raporto! Kiel sentas la produktteamo pri la perdo de datumoj?

Produktteamoj ne zorgas, kaj teamgvidantoj estas maltrankvilaj.

Kiaj garantioj estas?

Garantioj estas tre malfacilaj. Aleksandro Kukushkin havas raporton "Kiel kalkuli RPO kaj RTO", t.e. reakiro kaj kiom da datumoj ni povas perdi. Mi pensas, ke ni devas trovi ĉi tiujn lumbildojn kaj studi ilin. Kiom mi memoras, ekzistas specifaj paŝoj pri kiel kalkuli ĉi tiujn aferojn. Kiom da transakcioj ni povas perdi, kiom da datumoj ni povas perdi. Kiel opcio, ni povas uzi sinkronan reproduktadon ĉe la Patroni-nivelo, sed ĉi tio estas dutranĉa glavo: ni aŭ havas fidindecon de datumoj, aŭ ni perdas rapidecon. Estas sinkrona reproduktado, sed ĝi ankaŭ ne garantias 100% protekton kontraŭ datumperdo.

Alexey, dankon pro la bonega raporto! Ĉu ajna sperto pri uzado de Patroni por nulnivela protekto? Tio estas, lige kun sinkrona standby? Jen la unua demando. Kaj la dua demando. Vi uzis malsamajn solvojn. Ni uzis Repmgr, sed sen aŭtomata dosiero, kaj nun ni planas inkluzivi aŭtomatan dosieron. Kaj ni konsideras Patroni kiel alternativan solvon. Kion vi povas diri kiel avantaĝojn kompare kun Repmgr?

La unua demando temis pri sinkronaj kopioj. Neniu uzas sinkronan reproduktadon ĉi tie, ĉar ĉiuj timas (Pluraj klientoj jam uzas ĝin, principe ili ne rimarkis rendimentajn problemojn - Noto de parolanto). Sed ni mem ellaboris regulon, ke devus ekzisti almenaŭ tri nodoj en sinkrona reprodukta aro, ĉar se ni havas du nodojn kaj se la majstro aŭ kopio malsukcesas, tiam Patroni ŝanĝas ĉi tiun nodon al Sendependa reĝimo, por ke la aplikaĵo daŭrigu. laboro. En ĉi tiu kazo, estas risko de perdo de datumoj.

Koncerne la duan demandon, ni uzis Repmgr kaj ankoraŭ faras kun iuj klientoj pro historiaj kialoj. Kion oni povas diri? Patroni venas kun aŭtomata dosiero el la skatolo, Repmgr venas kun aŭtomata dosiero kiel kroma funkcio, kiu devas esti ebligita. Ni devas ruli la Repmgr-demonon sur ĉiu nodo kaj tiam ni povas agordi la aŭtomatan dosieron.

Repmgr kontrolas ĉu Postgres-nodoj estas vivantaj. Repmgr-procezoj kontrolas la ekziston de unu la alian, ĉi tio ne estas tre efika aliro. povas ekzisti kompleksaj kazoj de retizolado en kiuj granda Repmgr-areto povas disfali en plurajn pli malgrandajn kaj daŭre funkcii. Mi delonge ne sekvas Repmgr, eble ĝi estis riparita... aŭ eble ne. Sed la forigo de informoj pri la stato de la areto en DCS, kiel Stolon, Patroni faras, estas la plej realigebla opcio.

Aleksej, mi havas demandon, eble pli laman. En unu el la unuaj ekzemploj, vi movis DCS de la loka maŝino al fora gastiganto. Ni komprenas, ke la reto estas afero, kiu havas siajn proprajn trajtojn, ĝi vivas memstare. Kaj kio okazas se ial la DCS-areto fariĝas neatingebla? Mi ne diros la kialojn, povas esti multaj: de la kurbaj manoj de retuloj ĝis realaj problemoj.

Mi ne diris ĝin laŭte, sed la DCS-areto ankaŭ devas esti malsukcesa, t.e. ĝi estas nepara nombro da nodoj, por ke kvorumo estu renkontita. Kio okazas se la DCS-areto fariĝas neatingebla, aŭ kvorumo ne povas esti renkontita, t.e. ia reto-disigo aŭ noda fiasko? En ĉi tiu kazo, la Patroni-grupo iras en nurlegeblan reĝimon. La Patroni-grupo ne povas determini la staton de la areto kaj kion fari. Ĝi ne povas kontakti la DCS kaj stoki la novan aretoŝtaton tie, tiel ke la tuta areto eniras nur legadon. Kaj atendas aŭ manan intervenon de la funkciigisto aŭ ke DCS resaniĝos.

Malglate parolante, DCS fariĝas servo por ni tiel grava kiel la bazo mem?

Jes Jes. En tiom da modernaj kompanioj, Service Discovery estas integra parto de la infrastrukturo. Ĝi estas efektivigita eĉ antaŭ ol ekzistis eĉ datumbazo en la infrastrukturo. Relative parolante, la infrastrukturo estis lanĉita, deplojita en la DC, kaj ni tuj havas Service Discovery. Se ĝi estas Konsulo, tiam DNS povas esti konstruita sur ĝi. Se ĉi tio estas Etcd, tiam povas esti parto de la Kubernetes-areo, en kiu ĉio alia estos deplojita. Ŝajnas al mi, ke Service Discovery jam estas integra parto de modernaj infrastrukturoj. Kaj ili pensas pri tio multe pli frue ol pri datumbazoj.

Dankon!

fonto: www.habr.com