{"id":90103,"date":"2020-07-29T13:42:32","date_gmt":"2020-07-29T11:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij"},"modified":"2020-07-29T13:42:32","modified_gmt":"2020-07-29T11:42:32","slug":"patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij","title":{"rendered":"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/6404cba13214f499d1f347cca0aacbe7.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Glavna cilj Patroni je osigurati visoku dostupnost za PostgreSQL. No, Patroni je samo \u0161ablon, a ne gotov alat (\u0161to je, u su\u0161tini, navedeno u dokumentaciji). Na prvi pogled, nakon \u0161to konfiguri\u0161emo Patroni u testnoj laboratoriji, mo\u017eemo videti koliko je to divan alat i kako lako obra\u0111uje na\u0161e poku\u0161aje da sru\u0161imo klaster. Me\u0111utim, u praksi, u proizvodnom okru\u017eenju, ne de\u0161ava se uvek tako lepo i elegantno kao u testnoj laboratoriji.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/ff445e6d76a2ad46a232b705e104446f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Pri\u010da\u0107u malo o sebi. Po\u010deo sam kao sistemski administrator. Radio sam u web razvoju. Od 2014. godine radim u Data Egret. Kompanija se bavi konsaltingom u oblasti Postgres. I mi se ponekad bavimo samo Postgres-om, i svakodnevno radimo sa Postgres-om, zato imamo raznu stru\u010dnost vezanu za eksploataciju. <\/p>\n<p><\/p>\n<p>I na kraju 2018. godine po\u010deli smo polako koristiti Patroni. Nac\u030cinili smo odre\u0111eno iskustvo. Na neki na\u010din smo ga dijagnostikovali, optimizovali, do\u0161li do svojih najboljih praksi. I o njima \u0107u pri\u010dati u ovom izlaganju.<\/p>\n<p><\/p>\n<p>Osim Postgres-a, volim Linux. Volim da eksperimenti\u0161em i istra\u017eujem, volim da sastavljam jezgre. Volim virtualizaciju, kontejnere, Docker, Kubernetes. Sve to me zanima jer se stare adminske navike odra\u017eavaju. Volim da se bavim monitoringom. I volim stvari vezane za postgres administraciju, tj. replikaciju, rezervno kopiranje. I u slobodno vreme pi\u0161em na Go. Nisam softverski in\u017eenjer, samo pi\u0161em za sebe na Go. I to mi donosi zadovoljstvo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/02cfd9293af5a8410c91e39afe2c75e6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Mislim da mnogi od vas znaju da u Postgres-u nema HA (visoke dostupnosti) iz kutije. Da biste dobili HA, morate ne\u0161to postaviti, konfigurirati, ulo\u017eiti trud i dobiti to. <\/li>\n<li>Postoji nekoliko alata i Patroni je jedan od njih, koji prili\u010dno dobro re\u0161ava HA. Ali nakon \u0161to sve to postavimo u testnoj laboratoriji i pokrenemo, mo\u017eemo videti da to sve funkcioni\u0161e, mo\u017eemo reprodukovati neke probleme, da vidimo kako ih Patroni obra\u0111uje. I vide\u0107emo da sve to savr\u0161eno radi. <\/li>\n<li>Ali u praksi smo se suo\u010dili s raznim problemima. I o tim problemima \u0107u pri\u010dati.<\/li>\n<li>Re\u0107i \u0107u kako smo to dijagnostikovali, \u0161ta smo pode\u0161avali \u2013 da li nam je to pomoglo ili nije. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/7126b45b40dd08521e80a3c150382bec.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Ne bom govoril o tem, kako namestiti Patroni, ker se to lahko enostavno najde na spletu, lahko si ogledate konfiguracijske datoteke, da razumete, kako se vse to za\u017eene in kako se nastavi. Lahko se poklicno ukvarite s shemami in arhitekturami, tako da boste na\u0161li informacije o tem na internetu. <\/li>\n<li>Ne bom govoril o izku\u0161njah drugih. Govoril bom le o te\u017eavah, s katerimi smo se sre\u010dali prav mi. <\/li>\n<li>In ne bom govoril o te\u017eavah, ki presegajo Patroni in PostgreSQL. Na primer, te\u017eave, povezane z uravnote\u017eenjem, ko se je na\u0161 klaster razpadel, o tem ne bom govoril. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/3f8d179e7c78ce83e8842ef5c72fe30d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In majhna izjema, preden za\u010dnem na\u0161o predstavitev. <\/p>\n<p><\/p>\n<p>Vse te te\u017eave, s katerimi smo se sre\u010dali, so bile prisotne v prvih 6-7-8 mesecih delovanja. S\u010dasoma smo pri\u0161li do svojih notranjih najbolj\u0161ih praks. In te\u017eave so izginile. Zato je bila ta predstavitev na\u010drtovana pred pribli\u017eno \u0161estimi meseci, ko je vse to \u0161e bilo sve\u017ee v spominu in sem se spomnil vsega. <\/p>\n<p><\/p>\n<p>Med pripravo na predstavitev sem ponovno prebral stare postmortem poro\u010dila, pregledal dnevnik. In del podrobnosti se je morda pozabil, ali pa del nekaterih podrobnosti morda ni bil dovolj raziskovan med razre\u0161evanjem te\u017eav, zato se morda zdi, da te\u017eave niso bile obravnavane v celoti, ali da je kak\u0161na pomanjkljivost informacij. In zato se za to opravi\u010dujem. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/30d414284a41fcbc3bf417c9da28ca52.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kaj je Patroni?<\/p>\n<p><\/p>\n<ul>\n<li>To je predloga za gradnjo HA. Tako pi\u0161e v dokumentaciji. In z moje to\u010dke pogleda je to zelo pravilna opredelitev. Patroni ni srebrna krogla, ki bi re\u0161ila vse va\u0161e te\u017eave; potrebna so prizadevanja, da za\u010dne delovati in prina\u0161ati koristi. <\/li>\n<li>To je agenta slu\u017eba, ki je name\u0161\u010dena na vsaki storitvi z bazo podatkov, in ki deluje kot svojevrstni init sistem za va\u0161 Postgres. Za\u017eene Postgres, ustavi ga, ponovno za\u017eene, spremeni konfiguracijo in spreminja topologijo va\u0161ega klasterja. <\/li>\n<li>Zato je potrebno, da se stanje klasterja shrani, njegova trenutna predstavitev, kako izgleda; potrebna je nekak\u0161na shramba. In iz te perspektive je Patroni izbral pot shranjevanja stanja v zunanji sistem. To je sistem porazdeljenega shranjevanja konfiguracije. To so lahko Etcd, Consul, ZooKeeper, ali Kubernetes'ki Etcd, torej ena od teh mo\u017enosti. <\/li>\n<li>Ena od zna\u010dilnosti Patroni je, da avtofajler dobite iz \u0161katle, takoj ko ga nastavite. V primerjavi z Repmgr, kjer je fajler prilo\u017een. S Repmgr dobimo switchover, toda \u010de \u017eelimo avtofajler, ga moramo dodatno nastaviti. Patroni pa \u017ee ima avtofajler iz \u0161katle.<\/li>\n<li>Obstaja \u0161e veliko drugih stvari. Na primer, upravljanje s konfiguracijami, dodajanje novih replik, varnostno kopiranje itd. Toda to presega obseg poro\u010dila, o tem ne bom govoril. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/fed0f1ce931df99ca76ae1116f8098cc.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Zato lahko sklenemo, da je glavna naloga Patroni to, da u\u010dinkovito in zanesljivo izvaja avtofajler, da na\u0161 klaster ostane delujo\u010d in aplikacija ne opazi sprememb v topologiji klasterja. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/fac52620957efa47ced330e7cc8084e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Toda ko za\u010dnemo uporabljati Patroni, se na\u0161 sistem nekoliko zaplete. \u010ce smo prej imeli Postgres, ob uporabi Patroni dobimo samega Patroni, dobimo DCS, kjer se shranjuje stanje. In vse to mora kako delovati. Zato, kaj se lahko pokvari?<\/p>\n<p><\/p>\n<p>Lahko se pokvari:<\/p>\n<p><\/p>\n<ul>\n<li>Postgres se lahko pokvari. To je lahko glavni ali replika, eden od njiju lahko odpove. <\/li>\n<li>Lahko se pokvari tudi sam Patroni. <\/li>\n<li>Lahko se pokvari DCS, kjer se shranjuje stanje.<\/li>\n<li>In lahko se pokvari omre\u017eje. <\/li>\n<\/ul>\n<p><\/p>\n<p>Vse te vidike bom obravnaval v poro\u010dilu. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/1aeaf46d37bf1935b514b0581e0dbd0b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Obravnaval bom primere, kako se zapletajo, ne z vidika, da primer pokriva veliko komponent. Temve\u010d z vidika subjektivnih ob\u010dutij, da je bil ta primer zame zapleten, te\u017eko ga je bilo analizirati\u2026 in obratno, nek primer je bil enostaven in ga je bilo lahko analizirati. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/65b0c98bf2284610e955ced5eb998f39.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Prvi primer je najpreprostej\u0161i. To je primer, ko smo vzeli klaster podatkovnih baz in na tem istem klasterju postavili na\u0161 DCS. To je najpogostej\u0161a napaka. To je napaka pri zasnovi arhitektur, tj. zdru\u017eevanje razli\u010dnih komponent na enem mestu. <\/p>\n<p><\/p>\n<p>Torej, ko se zgodi fajler, gremo raziskati, kaj se je zgodilo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/244b69d623fe2205c2d9ed2aa4620067.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In tukaj nas zanima, kdaj se je zgodil fajler. Tj. zanima nas ta \u010dasovni trenutek, ko je pri\u0161lo do spremembe stanja klasterja. <\/p>\n<p><\/p>\n<p>Toda fajler ni vedno trenutni, tj. ne traja vedno to\u010dno dolo\u010den \u010das, lahko se zavle\u010de. Lahko traja dalj \u010dasa.<\/p>\n<p><\/p>\n<p>Zato ima za\u010detni in kon\u010dni \u010das, torej gre za dolg dogodek. Vse dogodke delimo na tri intervale: imamo \u010das pred failoverjem, med failoverjem in po failoverju. To pomeni, da obravnavamo vse dogodke na tej \u010dasovni osi. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/a0ed61afe55d1a157147e0d80b17e5d1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In prva re\u010d, ko se zgodi failover, i\u0161\u010demo vzrok, kaj se je zgodilo, kaj je privedlo do failoverja. <\/p>\n<p><\/p>\n<p>\u010ce pogledamo dnevnike, bodo to klasi\u010dni dnevniki Patroni. V njih nam sporo\u010da, da je stre\u017enik postal glavni in da je vloga glavnega pre\u0161la na to vozli\u0161\u010de. To je ozna\u010deno. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/9998c69f7d0d4358b277f4e0e7b4350f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nato moramo razumeti, zakaj je pri\u0161lo do failoverja, torej kak\u0161ni dogodki so povzro\u010dili, da se je vloga glavnega preselila z enega vozli\u0161\u010da na drugo. In v tem primeru je vse preprosto. Imamo napako pri interakciji s shranjevanjem. Glavni je ugotovil, da ne more delovati z DCS, torej se je pojavila neka te\u017eava pri interakciji. In pravi, da ne more biti ve\u010d glavni in se odpove pooblastilom. Ta vrstica 'demoted self' to natan\u010dno opisuje. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/4a8eca27689546b4b0fc3c666a3c37c4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u010ce pogledamo dogodke, ki so predhodili failoverju, lahko vidimo tiste vzroke, ki so povzro\u010dili te\u017eave pri nadaljnjem delu glavnega. <\/p>\n<p><\/p>\n<p>\u010ce pogledamo dnevnike Patroni, bomo videli, da nastane mno\u017eica razli\u010dnih napak, \u010dasovnih zamud, torej agent Patroni ne more delovati z DCS. V tem primeru je to Consul agent, s katerim komuniciramo prek vrata 8500. <\/p>\n<p><\/p>\n<p>In te\u017eava je v tem, da sta Patroni in baza podatkov zagnana na istem stre\u017eniku. Na tem istem vozli\u0161\u010du so bile zagnane tudi Consul stre\u017eniki. Z ustvarjanjem obremenitve na stre\u017eniku smo povzro\u010dili te\u017eave tudi za <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/sl\/server\/\"   title=\"stre\u017enikov\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1515\">stre\u017enikov<\/a> Consul. Niso mogli normalno komunicirati. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/0d8dba6641809560e6b32825d481e30b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u010cez nekaj \u010dasa, ko je obremenitev popustila, je na\u0161 Patroni znova uspel komunicirati z agenti. Normalno delovanje se je ponovno vzpostavilo. In tisti isti stre\u017enik Pgdb-2 je znova postal glavni. To pomeni, da je pri\u0161lo do majhnega preklopa, zaradi katerega je vozli\u0161\u010de odneslo svoje glavne pooblastila, nato pa jih ponovno prevzelo, torej se je vse vrnilo, kot je bilo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/131b93e0bd83099e1b99b53742419e13.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In to lahko obravnavamo kot la\u017eno spro\u017eitev, ali pa lahko obravnavamo, da je Patroni vse naredil pravilno. To pomeni, da je razumel, da ne more vzdr\u017eevati stanja grozda in je odnesel svoja pooblastila.<\/p>\n<p><\/p>\n<p>In this case, the problem arose because the Consul servers are on the same hardware as the databases. Accordingly, any load\u2014whether on disks or processors\u2014also affects interaction with the Consul cluster.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/142c7cf839c8da078451f7ba9d5499e5.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In prepri\u010dali smo se, da to ne sme \u017eiveti skupaj, zato smo za Consul ustvarili lo\u010den klaster. Patroni je \u017ee deloval s lo\u010denim Consul-om, torej je bil lo\u010den klaster Postgres in lo\u010den klaster Consul. To je osnovno navodilo, kako razporediti te stvari in jih obdr\u017eati lo\u010dene, da ne \u017eivijo skupaj. <\/p>\n<p><\/p>\n<p>One option is to adjust the parameters ttl, loop_wait, and retry_timeout, for instance, attempting to withstand these short peaks in load by increasing these parameters. However, this isn't the most suitable approach because these loads might persist. We would eventually exceed the limits of these parameters, which may not help at all. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/c51f35dcd88b1c792acec231c0c6c66c.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>The first problem, as you might have guessed, is straightforward. We combined DCS with the database and encountered an issue. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/cc2a98d9790441577fb4080406cbc53f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>The second problem is similar to the first. It resembles it in that we again have communication issues with the DCS system.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/e5c01b105adca48cc620085db8dd2d2b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>If we look at the logs, we will see that there is once again a communication error. Patroni indicates that it cannot communicate with the DCS, which causes the current master to switch to replica mode.<\/p>\n<p><\/p>\n<p>The old master becomes a replica; here, Patroni functions as intended. It runs pg_rewind to rewind the transaction log and then connects to the new master to catch up with it. Patroni operates as it should. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/29255f4790abb15b64dbf9ee0b41c7fc.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Here, we need to identify the point that preceded the file error, meaning the errors that caused the file error. In this regard, working with Patroni logs is quite convenient. It writes the same messages at specific intervals. If we quickly scroll through the logs, we'll notice changes, indicating that some issues have arisen. We can swiftly return to that point and see what's happening. <\/p>\n<p><\/p>\n<p>In a normal situation, the logs look something like this. The lock owner is checked. If the owner has, say, changed, certain events may occur that Patroni needs to react to. However, in this case, everything is in order. We're looking for the point when the errors began. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/f48ebd22a405f5b2900621451c68f543.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In scrolling to the point when errors began appearing, we see that we had an autofailer. And since our errors were related to the interaction with DCS and in our case we used Consul, we also look at the Consul logs to see what was happening there. <\/p>\n<p><\/p>\n<p>By approximately correlating the failover time with the time in the Consul logs, we see that our neighbors in the Consul cluster started to doubt the existence of other participants in the Consul cluster.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/63b02ac5b4f5a34a2822f1eee2b1f2f8.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>And if we look at the logs of other Consul agents, it is also clear that there is some sort of network collapse occurring. All participants in the Consul cluster doubt each other's existence. This served as a trigger for the failover. <\/p>\n<p><\/p>\n<p>If we look at what was happening before these errors, we can see that there are various errors, for example, deadline, RPC failed, which clearly indicates a problem in the interaction between participants in the Consul cluster. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/b15c912f2afb49d9d85e7bb9361ce449.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>The simplest answer is to fix the network. But from the podium, it's easy for me to state that. However, circumstances arise that sometimes the client cannot afford to fix the network. They might live in a data center and lack the ability to repair the network or affect the equipment. Therefore, we need some other options. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/1dbdb66233acc3bc321a30a1c5fe14f9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>There are options:<\/p>\n<p><\/p>\n<ul>\n<li>The simplest option, which I think is even mentioned in the documentation, is to disable the Consul checks, that is, simply pass an empty array. We tell the Consul agent not to use any checks. By ignoring these checks, we can avoid these network storms and not initiate a failover. <\/li>\n<li>Another option is to recheck the raft_multiplier. This is a parameter of the Consul server itself. By default, it is set to a value of 5. This value is recommended in the documentation for staging environments. Essentially, this affects the frequency of message exchange between participants in the Consul network. In essence, this parameter impacts the speed of service communication between participants in the Consul cluster. For production, it is already recommended to reduce it so that nodes exchange messages more frequently. <\/li>\n<li>Druga mo\u017enost, ki smo jo za\u010deli uporabljati, je pove\u010danje prioritet Consul procesov med drugimi procesi za na\u010drtovalnika procesov operacijskega sistema. Obstaja parameter \u201enice\u201c, ki dolo\u010da prioritet procesa, kar upo\u0161teva na\u010drtovalnik OS pri na\u010drtovanju. Zni\u017eali smo vrednost nice za Consul agente, tj. pove\u010dali prednost, da je operacijski sistem dal Consul procesom ve\u010d \u010dasa za delo in izvr\u0161evanje njihovega kode. V na\u0161em primeru je to re\u0161ilo na\u0161o te\u017eavo. <\/li>\n<li>Druga mo\u017enost je, da ne uporabljate Consul. Imam prijatelja, ki je velik zagovornik Etcd. In z njim redno razpravljava, kaj je bolje Etcd ali Consul. Vendar se obi\u010dajno strinjamo, da ima Consul agenta, ki mora biti zagnan na vsakem vozli\u0161\u010du s podatkovno bazo. Tj. interakcija Patroni s Consul klastra poteka preko tega agenta. In ta agent postane ozko grlo. \u010ce se z agentom kaj zgodi, Patroni ne more ve\u010d delovati z Consul klastri. To predstavlja problem. Pri Etcd pa agenta ni. Patroni lahko neposredno sodeluje s seznamom Etcd stre\u017enikov in se z njimi pogovarja. V tem smislu, \u010de v va\u0161i dru\u017ebi uporabljate Etcd, bo verjetno Etcd bolj\u0161a izbira kot Consul. Vendar smo pri na\u0161ih strankah vedno omejeni s tem, kar je stranka izbrala in uporablja. In pri ve\u010dini na\u0161ih strank je Consul glavni. <\/li>\n<li>In zadnja to\u010dka je pregledati vrednosti parametrov. Te parametre lahko pove\u010damo v upanju, da bodo na\u0161i kratkotrajni omre\u017eni problemi kratki in ne bodo presegli intervala teh parametrov. Tako lahko zmanj\u0161amo agresivnost Patroni pri izvajanju samodejnega preklopa, \u010de pride do kak\u0161nih omre\u017enih te\u017eav.<\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/f0043050da20f6368dabf66ec9a4eade.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Mislim, da so mnogi, ki uporabljajo Patroni, seznanjeni s to ukazno vrstico. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/9f78f59dab166e47ac78436802156d04.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ta ukaz prikazuje trenutno stanje klasterja. Na prvi pogled se ta slika lahko zdi normalna. Imamo glavnega, imamo replikacijo, med replikacijo ni zakasnitve. Vendar je ta slika normalna le, dokler ne vemo, da bi morali v tem klasterju biti trije vozli\u0161\u010da in ne dve. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/a39c891f8620ba210b6bce0727e0fa8b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Zato je pri\u0161lo do samodejnega preklopa. In po tem samodejnem preklopu nam je izginila replika. Moramo ugotoviti, zakaj je izginila in jo vrniti, obnoviti. Ponovno gremo v dnevnike in pregledujemo, zakaj je pri\u0161lo do samodejnega preklopa.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/e6e67d46cb20c8d7e58c7505157f68e1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>V tem primeru je druga replika postala glavni. Tukaj je vse v redu. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/b86ccea68b0c6013a23bbd2804e48320.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In moramo pogledati na repliko, ki je izpadla in ki ni v klasterju. Odprimo dnevnike Patroni in pogledamo, da smo imeli te\u017eave pri povezovanju s klasterjem na stopnji pg_rewind. Da se pove\u017eemo s klasterjem, moramo zavrteti dnevnik transakcij nazaj, zahtevati ustrezen dnevnik transakcij od glavnega in se po njem uskladiti z glavnim. <\/p>\n<p><\/p>\n<p>V tem primeru nimamo dnevnika transakcij in replika se ne more zagnati. Zato Postgres ustavimo z napako. In zato je ni v klasterju. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/dadbd44b766674b719d85781ef7f0caa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Treba je razumeti, zakaj je ni v klasterju in zakaj ni bilo dnevnikov. Gremo na nov glavni server in pogledamo, kaj ima v dnevnikih. Izkazalo se je, da je pri\u0161lo do checkpointa, ko je bil izveden pg_rewind. In del starej\u0161ih dnevnikov transakcij je bil preimenovan. Ko se je stari glavni posku\u0161al povezati z novim glavnim in zahtevati te dnevnike, so bili \u017ee preimenovani in jih preprosto ni bilo.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/f2d5c37324f9436b2bdad1290612d86f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Primerjal sem \u010dasovne oznake, ko so se ta dogajanja zgodila. Razlika je bila komaj 150 milisekund, torej je bil checkpoint zaklju\u010den v 369 milisekundah, WAL-segmenti so bili preimenovani. In komaj 517 milisekund kasneje, po 150 milisekundah, se je zagnal rewind na stari repliki. To pomeni, da je bilo dobesedno 150 milisekund dovolj, da se replika ni mogla povezati in zagnati. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/99dd80deb8466bfc3aff568456e07102.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kak\u0161ne so mo\u017enosti?<\/p>\n<p><\/p>\n<p>Sprva smo uporabljali replikacijske bloke. Mislili smo, da je to dobro. Toda na za\u010detku eksploatacije smo bloke izklopili. Mislili smo, da lahko, \u010de bloki naberejo veliko WAL-segmentov, obrnemo glavnega. On bo padel. Naredili smo si nekaj te\u017eav brez blokov. In razumeli smo, da jih potrebujemo, zato smo jih vrnili. <\/p>\n<p><\/p>\n<p>Vendar tu je te\u017eava, da ko mojster preide na kopijo, izbri\u0161e re\u017ene lokacije in skupaj z re\u017eami izbri\u0161e tudi WAL-segmente. Da bi odpravili to te\u017eavo, smo se odlo\u010dili pove\u010dati parameter wal_keep_segments. Privzeto je 8 segmentov. Mi smo ga pove\u010dali na 1.000 in preverili, koliko prosto prostora imamo. Tako smo 16 gigabajtov namenili za wal_keep_segments. To pomeni, da imamo pri preklopu vedno na vseh vozli\u0161\u010dih rezervo 16 gigabajtov transakcijskih dnevnikov.<\/p>\n<p><\/p>\n<p>In poleg tega \u2013 to je \u0161e posebej pomembno za dolgotrajne vzdr\u017eevalne naloge. Recimo, treba je posodobiti eno od kopij. In jo \u017eelimo izklju\u010diti. Moramo posodobiti programsko opremo, morda operacijski sistem, \u0161e kaj. Ko izklopimo kopijo, se za to kopijo tudi izbri\u0161e re\u017enja. In \u010de uporabljamo majhne wal_keep_segments, se med dolgotrajno odsotnostjo kopije transakcijski dnevniki predvajajo. Povi\u0161ali bomo kopijo, ta bo zahtevala tiste transakcijske dnevnike, kjer je ostala, a na glavnem morda ne bo ve\u010d tam. In kopija se ne bo mogla povezati. Zato ohranjamo veliko zalogo dnevnikov.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/dad55c828128ce92f649a99cc53ce54b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/63e70f0b098567f3a6d4fd66a0c293bb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Imamo produkcijsko bazo. Tam \u017ee delujejo projekti. <\/p>\n<p><\/p>\n<p>Pri\u0161lo je do napake datoteke. Vstopili smo in preverili \u2013 vse je v redu, kopije so na mestu, zakasnitev replikacije ni. Napak v dnevnikih tudi ni, vse je v redu. <\/p>\n<p><\/p>\n<p>Produktna ekipa pravi, da bi morale biti neke podatke, a jih vidimo v enem viru, v bazi pa jih ne. Treba je razumeti, kaj se je z njimi zgodilo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/568ca9aa31680d5e0c9d4ed9693b14e6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Jasno je, da je pg_rewind te podatke izgubil. To smo takoj razumeli, a smo \u0161li preveriti, kaj se je dogajalo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/a8fee389201d96e81761cd276c5265c3.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>V dnevnikih vedno lahko najdemo, kdaj se je zgodila napaka datoteke, kdo je postal mojster in lahko dolo\u010dimo, kdo je bil stari mojster in kdaj je \u017eelel postati kopija, tj. potrebujemo te dnevnike, da ugotovimo obseg izgubljenih transakcijskih dnevnikov.<\/p>\n<p><\/p>\n<p>Na\u0161 stari master se je ponovno zagnal. In v samodejnem zagonu je bil vpisan Patroni. Patroni se je zagnal in za njim je zagnal Postgres. Natan\u010dneje, pred zagonem Postgres-a in pred tem, ko ga je naredil za replikacijo, je Patroni zagnal proces pg_rewind. Tako je izbrisal del transakcijskih dnevnikov, prenesel nove in se povezal. Tukaj je Patroni deloval odli\u010dno, kot je treba. Na\u0161 klaster se je obnovil. Imeli smo 3 vozli\u0161\u010da, po failoverju 3 vozli\u0161\u010da \u2013 vse je super. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/b747a24f53e20ed098c2dc0afc79bead.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Izgubili smo deo podataka. Moramo da shvatimo koliko smo izgubili. Tra\u017eimo trenutak kada se pojavio rewind. To mo\u017eemo da prona\u0111emo u zapisima u dnevniku. Pokrenut je rewind, ne\u0161to se dogodilo i zavr\u0161eno je.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/5b7bacffb52e3ccd529a3a734c441295.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Moramo prona\u0107i tu poziciju u dnevniku transakcija na kojoj se zaustavio stari master. U ovom slu\u010daju \u2013 to je ova oznaka. I potrebna nam je druga oznaka, odnosno udaljenost po kojoj se stari master razlikuje od novog. <\/p>\n<p><\/p>\n<p>Uzimamo obi\u010dan pg_wal_lsn_diff i upore\u0111ujemo te dve oznake. U ovom slu\u010daju dobijamo 17 megabajta. Da li je to mnogo ili malo, svako za sebe odlu\u010duje. Jer za nekoga je 17 megabajta malo, a za nekoga mnogo i nedopustivo. Tu svako za sebe individualno odre\u0111uje u skladu sa potrebama poslovanja. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/55335fce85961e159459c38300a0ad12.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ali \u0161ta smo saznali za sebe? <\/p>\n<p><\/p>\n<p>Pre svega, moramo da odlu\u010dimo \u2013 da li nam je uvek potreban automatski start Patroni nakon restartovanja sistema? \u010cesto se de\u0161ava da moramo da u\u0111emo na stari master, pogledamo koliko je daleko oti\u0161ao. Mogu\u0107e je da inspektujemo segmente dnevnika transakcija, da vidimo \u0161ta tu ima. I da shvatimo \u2013 da li mo\u017eemo da izgubimo te podatke ili nam je potrebno da pokrenemo stari master u standalone re\u017eimu kako bismo ih izvadili. <\/p>\n<p><\/p>\n<p>I tek nakon toga trebamo da donesemo odluku, da li mo\u017eemo da odbacimo te podatke ili mo\u017eemo da ih obnovimo, povezujemo ovu \u010dvor kao repliku u na\u0161 klaster.<\/p>\n<p><\/p>\n<p>Pored toga, postoji parametar \u201emaximum_lag_on_failover\u201c. Ako se dobro se\u0107am, podrazumevana vrednost ovog parametra iznosi 1 megabajt. <\/p>\n<p><\/p>\n<p>Kako to funkcioni\u0161e? Ako na\u0161oj replici nedostaje 1 megabajt podataka zbog zaostatka replikacije, ta replika ne\u0107e u\u010destvovati u izborima. I ako se dogodi failover, Patroni gleda koje replike zaostaju. Ako zaostaju za velikim brojem dnevnika transakcija, ne mogu postati master. To je veoma dobra za\u0161titna funkcija koja omogu\u0107ava da ne izgubimo mnogo podataka. <\/p>\n<p><\/p>\n<p>Ali postoji problem u tome \u0161to se zaostatak replikacije u klasteru Patroni i DCS a\u017eurira u odre\u0111enim intervalima. \u010cini mi se da je podrazumevani ttl 30 sekundi.<\/p>\n<p><\/p>\n<p>Zato lahko pride do situacije, ko je zamik replikacije za replicirane podatke v DCS eden, v resnici pa je lahko povsem druga\u010den zamik ali pa zamika sploh ni, torej ta stvar ni v realnem \u010dasu. In ne odra\u017ea vedno dejanske slike. In ne bi smeli zgraditi kompleksne logike na njej. <\/p>\n<p><\/p>\n<p>In tveganje za izgube vedno ostaja. In v najslab\u0161em primeru ena formula, v povpre\u010dju pa druga formula. To pomeni, da ko na\u010drtujemo uvedbo Patroni in ocenjujemo, koliko podatkov lahko izgubimo, moramo upo\u0161tevati te formule in pribli\u017eno imeti predstavo o tem, koliko podatkov lahko izgubimo. <\/p>\n<p><\/p>\n<p>In dobra novica je. Ko je stari glavni stre\u017enik \u0161el naprej, je lahko \u0161el naprej zaradi nekaterih ozadnih procesov. To pomeni, da je bil avto-vakuum, napisani podatki so bili shranjeni v transakcijski dnevnik. Te podatke lahko brez te\u017eav prezremo in izgubimo. V tem ni nobenih te\u017eav. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/a86e8971ab4ef41b89af9cf0bdf519ba.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In tako izgledajo dnevniki, \u010de je nastavljena maximum_lag_on_failover in se je zgodil failover, ter je treba izbrati novega glavnega stre\u017enika. Replika se ocenjuje kot nezmo\u017ena sodelovati v volitvah. In odklanja sodelovanje v dirki za vodjo. \u010caka, da bo izbran nov glavni stre\u017enik, da se nato pove\u017ee z njim. To je dodatna za\u0161\u010dita pred izgubo podatkov.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/f760788e5951facdd08b2069037830fa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/c32f26e7526e1873f3bfd7d3693fcc72.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tukaj imamo produktno ekipo, ki je napisala, da njihov izdelek do\u017eivlja te\u017eave pri delu s Postgresom. Ob tem pa ni mogo\u010de dostopati do glavnega stre\u017enika, ker ni dostopen preko SSH. In avtomatski failover se prav tako ne zgodi. <\/p>\n<p><\/p>\n<p>Ta stre\u017enik je bil prisilno ponovno zagnan. Zaradi ponovnega zagona se je zgodil avtomatski failover, \u010deprav bi lahko izvedli tudi ro\u010dni failover, kot sedaj razumem. In po ponovnem zagonu gremo \u017ee pogledati, kaj se je zgodilo z trenutnim glavnim stre\u017enikom. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/95efb82e0647a396a21683cd53a69547.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ob tem smo vnaprej vedeli, da imamo te\u017eave z diski, torej smo \u017ee po monitoringu vedeli, kje iskati in kaj iskanje. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/367aaab607d833d96a573ddbbbced502.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Sko\u010dili smo v postgresov dnevnik, za\u010deli gledati, kaj se dogaja. Videli smo commit-e, ki trajajo eno, dve, tri sekunde, kar ni normalno. Videli smo, da se avto-vakuum zelo dolgo in nenavadno za\u017eene. In opazili smo za\u010dasne datoteke na disku. To so vse kazalniki te\u017eav z diski. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/7e0cfce7a81901ef9ef736c3fefc8dce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Pogledali smo sistemski dmesg (dnevnik kernalnih poruka). Uo\u010dili smo da imamo problema sa jednim od diskova. Diskovni sistem je predstavljao softverski Raid. Pogledali smo \/proc\/mdstat i uo\u010dili da nam nedostaje jedan disk. To jest, ovde je Raid od 8 diskova, a jednom nedostaje. Ako pa\u017eljivo pogledate slajd, mo\u017eete primetiti da nam nedostaje sde. Drugim re\u010dima, jedan disk je ispao. To je izazvalo diskovne probleme, a aplikacije su tako\u0111e imale problema pri radu sa Postgres klasterom.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/4b09b3aa761cb504fa79173ef280faac.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>U ovom slu\u010daju, Patroni nam nikako ne bi pomogao, jer Patroni nema zadatak da prati stanje servera ili diskova. Ove situacije moramo pratiti putem spoljnog monitoring sistema. Uveli smo monitoring diskova kroz eksterni monitoring. <\/p>\n<p><\/p>\n<p>Imali smo ideju \u2013 da li bi nam mogao pomo\u0107i fencing ili softverski watchdog? Pomislili smo da nam verovatno ne bi pomogao u ovom slu\u010daju, jer tokom problema, Patroni je nastavio da komunicira sa DCS klasterom i nije video nikakve probleme. Drugim re\u010dima, sa stanovi\u0161ta DCS i Patroni, sa klasterom je sve bilo u redu, iako su u stvari postojali problemi sa diskovima i dostupno\u0161\u0107u baze podataka. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/15fdac78535355d4eb889efcc27efc46.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Po mom mi\u0161ljenju, ovo je jedan od naj\u010dudnijih problema koje sam dugo istra\u017eivao, pregledao mnogo dnevnika i nazvao ga klaster-simulantom. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/b5259774931c290eda6673deb14b6c48.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Problem je bio u tome \u0161to stari master nije mogao postati normalna replika, tj. Patroni ga je pokretao, a Patroni je pokazivao da je ovaj \u010dvor prisutan kao replika, ali istovremeno nije bio normalna replika. Sada \u0107ete videti za\u0161to. Ovo je sa\u010duvano iz analize tog problema. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/c35a5d102a46764bbf96e5a75ee88171.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I kako je sve po\u010delo? Po\u010delo je, kao i u prethodnom problemu, sa usporenjem diskova. Imali smo po jedan do dva commit-a u sekundi. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/435c1b350a89f288e0e10ca9d5a2ec6e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Bilo je prekida konekcija, tj. klijenti su se gubili. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/920cb1f3f3b40578e15e6ff711e85c50.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Bile su blokade razli\u010ditih te\u017eina. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/285d6292d89b928a85e95602ee57d38a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>U skladu sa tim, diskovni sistem nije bio previ\u0161e responzivan. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/ebe71d49360e7f604ecd6a3c8276cb73.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I ono \u0161to mi je najsumnjivije \u2013 to je bila hitna shutdown zahtev. Postgres ima tri re\u017eima ga\u0161enja:<\/p>\n<p><\/p>\n<ul>\n<li>To je graceful, kada \u010dekamo da se svi klijenti isklju\u010de sami. <\/li>\n<li>Postoji fast, kada primoravamo klijente da se isklju\u010de jer idemo na ga\u0161enje. <\/li>\n<li>Immediate. In this case, immediate doesn't even inform clients that it needs to shut down; it simply turns off without warning. The operating system sends a RST message (TCP message indicating that the connection has been interrupted and there is nothing left for the client to catch) to all clients. <\/li>\n<\/ul>\n<p><\/p>\n<p>Who sent this signal? Background Postgres processes do not send such signals to each other, i.e., this is a kill-9. They don't send such things to one another; they only react to it, meaning this is an emergency restart of Postgres. I do not know who sent it. <\/p>\n<p><\/p>\n<p>I checked with the 'last' command and saw one person who also logged into this server with us, but I hesitated to ask. Perhaps it was a kill -9. I would have seen kill -9 in the logs since Postgres writes that it has received kill -9, but I did not find this in the logs. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/fe8e844649cea3384ebfde86e36eba44.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Looking further, I noticed that Patroni hadn't written to the log for quite a while \u2013 54 seconds. And comparing the two timestamps, there were no messages for about 54 seconds. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/ffb1c4db3d7de591d77d56ed2fcc4f2a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>During this time, an auto-failover occurred. Patroni worked perfectly again here. Our old master was unavailable; something was happening with it. Elections for a new master began. Everything worked well here. Our pgsql01 became the new leader. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/6b2457653e9f77af44cd64b4aff021a0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>We have a replica that became the master. And there is a second replica. There were problems with the second replica. It was trying to reconfigure. As I understand, it was attempting to change recovery.conf, restart Postgres, and connect to the new master. Every 10 seconds, it wrote messages stating that it was trying, but it couldn't. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/381818f189e19c3e1154074b4652f837.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>And during these attempts, the old master received an immediate-shutdown signal. The master restarts. And recovery also stops because the old master is rebooting. That is, the replica cannot connect to it because it is in shutdown mode. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/d8a8cde925fa8fe601d44ab908ae69dc.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>At some point, it started working, but replication did not start. <\/p>\n<p><\/p>\n<p>I have a sole hypothesis that the old master's address was in recovery.conf. And when the new master appeared, the second replica was still trying to connect to the old master. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/425ea3af1f1e186f4760e1fb1f5419fa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>When Patroni started on the second replica, the node started up but could not connect for replication. A replication lag formed, which looked something like this. That is, all three nodes were in place, but the second node was behind. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/f564eacd9944666c9a3f5bea634ede6b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Pri tem, \u010de pogledamo dnevnike, ki so bili pisani, lahko opazimo, da se replikacija ne more zagnati, ker se transakcijski dnevniki razlikujejo. In tisti transakcijski dnevniki, ki jih ponuja master, navedeni v recovery.conf, preprosto ne ustrezajo na\u0161emu trenutnemu vozli\u0161\u010du. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/6b09947d157c9ef0a190da2df2cb5892.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In tukaj sem storil napako. Moral sem priti in preveriti, kaj je v recovery.conf, da bi preveril svojo hipotezo, da se ne povezujemo s pravim masterjem. Toda takrat sem se \u0161ele za\u010del spoznavati s tem in mi to ni pri\u0161lo na pomik, ali pa sem videl, da replikacija zamuja in da jo bo treba znova naliti, t.j. nekako sem to odsvetoval. To je bila moja napaka. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/159f2256fd81428fd0d82a255528887d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Po 30 minutah je administr\u00e1tor \u017ee pri\u0161el, t.j. zopet sem zagnal Patroni na replikaciji. \u017de sem jo imel za izgubljeno, mislil sem, da jo bo treba ponovno naliti. In sem pomislil \u2013 ponovno bom zagnal Patroni, mogo\u010de bo vseeno uspelo. Re\u0161itev se je za\u010dela. In baza je bila celo odprta, bila je pripravljena sprejemati povezave. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/aeac98750386c8389d39e006a229cc85.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Replikacija se je zagnala. A \u010dez minuto se je ponovno ustavila s sporo\u010dilom, da transakcijski dnevniki ne ustrezajo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/17eaba000a79c80c29d1bc3902de05e6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Pomislil sem, da bom \u0161e enkrat zagnal. Ponovno sem zagnal Patroni, in sicer nisem ponastavil Postgresa, ampak sem ponovno zagnal prav Patroni v upanju, da bo na \u010daroben na\u010din zagnal bazo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/a85b38e033c45ad73da317f41e0ef24a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Replikacija se je ponovno zagnala, a oznake v transakcijskem dnevniku so se razlikovale; niso bile tiste, ki so bile ob prej\u0161njem poskusu zagona. Replikacija se je ponovno ustavila. In sporo\u010dilo je bilo nekoliko druga\u010dno. Ni bilo preve\u010d informativno zame. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/fd90d708230bd54af685786c7e361ee1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In takrat mi je pri\u0161lo na misel \u2013 kaj \u010de ponovno za\u017eenem Postgres, medtem pa na trenutnem masterju naredim checkpoint, da nekoliko premaknem to\u010dko v transakcijskem dnevniku naprej, tako da se replikacija za\u010dne iz drugega trenutka? Poleg tega so bili pri nas \u0161e dodatki WAL. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/19e67f95d1a74141a013947c9aa39e38.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ponovno sem zagnal Patroni, naredil nekaj checkpointov na masterju in nekaj restart-to\u010dk na replikaciji, ko se je odprla. In to je pomagalo. Dolgo sem razmi\u0161ljal, zakaj je to pomagalo in kako je to delovalo. In replikacija se je zagnala. In replikacija se ve\u010d ni ustavila. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/418ca59a681be84f51ed374a73a759c9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tak\u0161na te\u017eava je zame ena od bolj skrivnostnih, nad katerimi \u0161e vedno razmi\u0161ljam, kaj se je dejansko dogajalo. <\/p>\n<p><\/p>\n<p>Kak\u0161ni so zaklju\u010dki tukaj? Patroni lahko deluje, kot je predvideno, brez napak. Vendar to ni 100 % garancija, da je vse v redu. Replika se lahko za\u017eene, vendar je lahko v pol-aktivnem stanju, in aplikacija ne more delovati z tak\u0161no replikacijo, ker bodo tam stari podatki. <\/p>\n<p><\/p>\n<p>In po failoverju je vedno treba preveriti, ali je z na\u0161im grozdom vse v redu, t.j. ali je potrebno \u0161tevilo replik, ni zamude replikacije.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/aca7047ff33d3efe14071b798b554091.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Med obravnavo teh te\u017eav bom oblikoval priporo\u010dila. Posku\u0161al sem jih zdru\u017eiti v dva diapozitiva. Verjetno bi bilo mogo\u010de vse zgodbe zdru\u017eiti v dva diapozitiva in le to predstaviti.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/d4ad31b26d83c8846fe4097a11d70849.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ko uporabljate Patroni, morate imeti nujno monitoring. Vedno morate vedeti, kdaj je pri\u0161lo do avto-failoverja, ker, \u010de ne veste, da je pri\u0161el avto-failover, ne nadzorujete grozda. In to je slabo.<\/p>\n<p><\/p>\n<p>Po vsakem failoverju moramo vedno ro\u010dno preveriti grozd. Moramo se prepri\u010dati, da imamo vedno ustrezno \u0161tevilo replik, ni zamude replikacije, v dnevnikih ni napak, povezanih s pretokovno replikacijo, s Patronijem, s sistemom DCS.<\/p>\n<p><\/p>\n<p>Avtomatika lahko uspe\u0161no deluje, Patroni je zelo dobro orodje. Lahko deluje, vendar to ne pripelje grozda v \u017eeleno stanje. In \u010de tega ne ugotovimo, bomo imeli te\u017eave.<\/p>\n<p><\/p>\n<p>In Patroni ni srebrna krogla. Kljub temu se moramo zavedati, kako deluje Postgres, kako deluje replikacija in kako Patroni deluje s Postgresom, ter kako je zagotovljena interakcija med vozli\u0161\u010di. To je potrebno, da bomo znali ro\u010dno odpraviti nastale te\u017eave.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/ea4162df3561d2ea7001f2ef6788eaaa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kako se lotevam diagnoze? Tako se je zgodilo, da delamo z razli\u010dnimi strankami in nih\u010de nima ELK sklada, zato se moramo ukvarjati z dnevniki, odpirati 6 konzol in 2 zavihka. V enem zavihku so dnevniki Patroni za vsak vozli\u0161\u010de, v drugem zavihku so dnevniki Consul-a ali Postgres, \u010de je potrebno. Diagnoza je zelo te\u017eka. <\/p>\n<p><\/p>\n<p>Kak\u0161ne pristope sem razvil? Prvi\u010d, vedno gledam, kdaj je pri\u0161el failover. In zame je to nekak\u0161na prelomnica. Gledam, kaj se je zgodilo pred failoverjem, med failoverjem in po failoverju. Failover ima dve oznaki: to sta \u010das za\u010detka in konca. <\/p>\n<p><\/p>\n<p>Zdaj preverjam dogodke v dnevnikih pred preklopom, kar je predhodilo preklopu, tj. i\u0161\u010dem razloge, zakaj se je zgodil preklop. <\/p>\n<p><\/p>\n<p>In to daje sliko razumevanja, kaj se je dogajalo in kaj lahko storimo v prihodnje, da do tak\u0161nih okoli\u0161\u010din ne bi pri\u0161lo (in posledi\u010dno ne do preklopa).<\/p>\n<p><\/p>\n<p>In kam obi\u010dajno gledamo? Jaz gledam:<\/p>\n<p><\/p>\n<ul>\n<li>Najprej v dnevnikih Patroni. <\/li>\n<li>Nato preverim dnevnike Postgres ali dnevnike DCS, odvisno od tega, kar najdem v dnevnikih Patroni. <\/li>\n<li>In dnevniki sistema tudi v\u010dasih ponujajo razumevanje, kaj je povzro\u010dilo preklop. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/a53618e366020e1a550d852fc308c188.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kako gledam na Patroni? Na Patroni gledam zelo dobro. Po mojem mnenju je to najbolj\u0161e, kar imamo danes. Poznam veliko drugih proizvodov. To so Stolon, Repmgr, Pg_auto_failover, PAF. 4 orodja. Poskusil sem vsa. <\/p>\n<p><\/p>\n<p>\u010ce me vpra\u0161ajo: 'Ali priporo\u010dam Patroni?'. Bom rekel, da da, ker mi je Patroni v\u0161e\u010d. In mislim, da sem se ga nau\u010dil pripravljati. <\/p>\n<p><\/p>\n<p>\u010ce vas zanima, katere \u0161e druge te\u017eave obstajajo s Patroni, poleg tistih, ki sem jih omenil, lahko vedno greste na stran <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/zalando\/patroni\/issues\/\">issues<\/a><\/noindex> na GitHub. Tam je veliko razli\u010dnih zgodb in razpravlja se o mnogih zanimivih te\u017eavah. In na koncu so bile nekatere napake zabele\u017eene in re\u0161ene, tj. to je zanimivo branje. <\/p>\n<p><\/p>\n<p>Tam so zanimive zgodbe o tem, kako si ljudje streljajo v nogo. Zelo pou\u010dno. Berete in razumete, da tega ne bi smeli po\u010deti. Postavil si bom kodo. <\/p>\n<p><\/p>\n<p>In rad bi se zahvalil podjetju Zalando za to, da razvijajo ta projekt, zlasti Alekseju Kuku\u0161kinu in Alekseju Kljukinu. Aleksej Kljukin je eden od soustanoviteljev, \u017ee ne dela ve\u010d v Zalandu, ampak sta to dva \u010dloveka, ki sta za\u010dela delati s tem izdelkom. <\/p>\n<p><\/p>\n<p>In mislim, da je Patroni zelo kul stvar. Zadovoljen sem, da obstaja, zanimivo je delati z njim. In hvala vsem, ki prispevajo, ki pi\u0161ejo popravke za Patroni. Upam, da bo Patroni s staranjem postal bolj zrel, bolj kul in delujo\u010d. \u017de zdaj deluje, a upam, da bo \u0161e bolj\u0161i. Zato, \u010de nameravate uporabljati Patroni, se ne bojte. To je dobra re\u0161itev, lahko jo uvedete in uporabljate. <\/p>\n<p><\/p>\n<p>To je vse. \u010ce imate vpra\u0161anja, vpra\u0161ajte.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439\" src=\"\/wp-content\/uploads\/2020\/07\/85c2fef2455999b48413c9fc3b235ed6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vpra\u0161anja<\/p>\n<p><\/p>\n<p><em>Hvala za predstavitev! \u010ce je po preklopu vseeno treba zelo pozorno gledati, zakaj potrebujemo avtomatski preklop?<\/em> <\/p>\n<p><\/p>\n<p>Ker v\u00ec to je nova stvar. Radimo s njom samo godinu dana. Bolje je previ\u0161e se osigurati. \u017delimo u\u0107i i pogledati jesu li sve stvarno funkcionirale kako treba. Ovo je nivo odrasle nepovjerenja \u2013 bolje provjeriti i pogledati. <\/p>\n<p><\/p>\n<p><em>Na primjer, ujutro smo u\u0161li i pogledali, zar ne?<\/em><\/p>\n<p><\/p>\n<p>Ne ujutro, obi\u010dno saznamo za auto-failover gotovo odmah. Dolaze nam obavijesti, vidimo da se dogodio auto-failover. Uzimamo i provjeravamo gotovo odmah. No, sve te provjere trebaju biti iznesene na nivo monitorniga. Ako se obratimo Patroniju preko REST API-ja, postoji povijest. Kroz povijest mo\u017eemo gledati vremenske oznake kada se dogodio failover. Na temelju toga mo\u017eemo napraviti monitoring. Mo\u017eemo gledati povijest, koliko je tamo doga\u0111aja bilo. Ako nam se pove\u0107ao broj doga\u0111aja, tada se dogodio auto-failover. Mo\u017eemo oti\u0107i i provjeriti. Ili je na\u0161a automatizacija u monitoringu provjerila da su sve replike na mjestu, da nema ka\u0161njenja i da je sve u redu. <\/p>\n<p><\/p>\n<p><em>Hvala!<\/em><\/p>\n<p><\/p>\n<p><em>Puno hvala za sjajnu pri\u010du! Ako smo premjestili DCS klaster negdje daleko od Postgres klastera, ho\u0107e li taj klaster isto tako trebati povremeno odr\u017eavanje? Koje su najbolje prakse u vezi s tim da se neki dijelovi DCS klastera isklju\u010de, ne\u0161to s njima napravi itd.? Kako pri tome \u017eivi cijela ova konstrukcija? I kako te stvari raditi?<\/em><\/p>\n<p><\/p>\n<p>Za jednu tvrtku trebalo je napraviti matricu problema, \u0161to se doga\u0111a ako neki od komponenti ili vi\u0161e njih zaka\u017eu. Kroz tu matricu mo\u017eemo postupno obraditi sve komponente i izgraditi scenarije u slu\u010daju kvara tih komponenti. Tako da za svaki scenarij kvara mo\u017eemo imati plan akcije za oporavak. I u slu\u010daju DCS-a to ide kao dio standardne infrastrukture. I admin to administrira, a mi se oslanjamo na admina koji to upravlja i na njegove sposobnosti da to popravi u slu\u010daju nesre\u0107e. Ako DCS-a uop\u0107e nema, tada ga mi postavljamo, ali pri tome ne pratimo previ\u0161e, jer nismo odgovorni za infrastrukturu, ali dajemo preporuke kako i \u0161to pratiti. <\/p>\n<p><\/p>\n<p><em>Dakle, je li to\u010dno da sam shvatio da trebamo isklju\u010diti Patroni, isklju\u010diti failover, isklju\u010diti sve prije nego \u0161to ne\u0161to radimo s hostovima?<\/em><\/p>\n<p><\/p>\n<p>To je odvisno od tega, koliko vozli\u0161\u010d imamo v DCS-klastru. \u010ce je vozli\u0161\u010d veliko in \u010de odpovemo samo enemu vozli\u0161\u010du (replikaciji), potem v klastru ostane kvorum. In Patroni ostaja funkcionalen. In ni\u010d se ne spro\u017ei. \u010ce imamo kak\u0161ne kompleksne operacije, ki vklju\u010dujejo ve\u010d vozli\u0161\u010d, katerih odsotnost lahko povzro\u010di razpad kvoruma, potem \u2013 ja, morda ima smisel postaviti Patroni na pavzo. Ima ustrezen ukaz \u2013 patronictl pause, patronictl resume. Preprosto postavimo na pavzo in avtofajler v tem \u010dasu ne deluje. Opravljamo vzdr\u017eevanje na DCS-klastru, nato odstranimo pavzo in nadaljujemo s delom.<\/p>\n<p><\/p>\n<p><em>Hvala lepa!<\/em><\/p>\n<p><\/p>\n<p><em>Najlep\u0161a hvala za predstavitev! Kako se produktna ekipa odnasa do mo\u017enosti izgube podatkov?<\/em> <\/p>\n<p><\/p>\n<p>Produktne ekipe je vseeno, tim liderji pa so zaskrbljeni. <\/p>\n<p><\/p>\n<p><em>Kak\u0161ne so tam garancije?<\/em><\/p>\n<p><\/p>\n<p>Z garancijami je zelo te\u017eko. Imajo poro\u010dilo Aleksandra Kuku\u0161kina \"Kako izra\u010dunati RPO in RTO\", torej \u010das obnove in koliko podatkov lahko izgubimo. Mislim, da bi morali najti te diapozitive in jih preu\u010diti. Kolikor se spomnim, so tam konkretni koraki, kako izra\u010dunati te stvari. Koliko transakcij lahko izgubimo, koliko podatkov lahko izgubimo. Kot mo\u017enost lahko uporabimo sinhrono replikacijo na ravni Patroni, vendar je to dvorezen me\u010d: ali imamo zanesljivost podatkov, ali izgubljamo hitrost. Obstaja sinhrona replikacija, vendar tudi ta ne zagotavlja 100%-ne za\u0161\u010dite pred izgubo podatkov.<\/p>\n<p><\/p>\n<p><em>Aleksej, hvala za odli\u010dno predstavitev! Ali imate izku\u0161nje z uporabo Patroni za za\u0161\u010dito na ni\u010dli? T.j. v kombinaciji s sinhronim standby-jem? To je prvo vpra\u0161anje. In drugo vpra\u0161anje. Uporabljali ste razli\u010dne re\u0161itve. Mi smo uporabljali Repmgr, vendar brez avtofajlerja in zdaj na\u010drtujemo povezati avtofajler. Razmi\u0161ljamo o Patroni kot alternativni re\u0161itvi. Kaj lahko poveste kot prednosti v primerjavi z Repmgr?<\/em><\/p>\n<p><\/p>\n<p>Prvo vpra\u0161anje je bilo o sinhronih replikah. Nih\u010de ne uporablja sinhrone replikacije, ker se vsi bojijo (\u017de uporablja nekaj strank, te\u017eav s zmogljivostjo na\u010deloma niso opazili \u2013 <em>Opomba predavatelja<\/em>). V na\u0161em p\u0159\u00edpad\u011b jsme si vypracovali pravidlo, \u017ee v clusteru synchronn\u00ed replikace mus\u00ed b\u00fdt alespo\u0148 t\u0159i uzly, proto\u017ee pokud m\u00e1me dva uzly a dojde k selh\u00e1n\u00ed masteru nebo repliky, Patroni p\u0159evede tento uzel do re\u017eimu Standalone, aby aplikace mohla pokra\u010dovat v chodu. V takov\u00e9m p\u0159\u00edpad\u011b existuj\u00ed rizika ztr\u00e1ty dat.<\/p>\n<p><\/p>\n<p>Co se t\u00fd\u010de druh\u00e9 ot\u00e1zky, pou\u017e\u00edvali jsme Repmgr a st\u00e1le jej pou\u017e\u00edv\u00e1me u n\u011bkter\u00fdch klient\u016f z historick\u00fdch d\u016fvod\u016f. Co m\u016f\u017eeme \u0159\u00edci? V Patroni je auto failover k dispozici hned, v Repmgr je auto failover ji\u017e jako dodate\u010dn\u00e1 funkce, kterou je t\u0159eba aktivovat. Je t\u0159eba spustit Repmgr daemon na ka\u017ed\u00e9m uzlu, a pak m\u016f\u017eeme nastavit auto failover. <\/p>\n<p><\/p>\n<p>Repmgr kontroluje, zda jsou uzly Postgres \u017eiv\u00e9. Procesy Repmgr kontroluj\u00ed existenci jeden druh\u00e9ho, co\u017e nen\u00ed p\u0159\u00edli\u0161 efektivn\u00ed p\u0159\u00edstup, proto\u017ee mohou nastat slo\u017eit\u00e9 p\u0159\u00edpady s\u00ed\u0165ov\u00e9 izolace, kdy se velk\u00fd cluster Repmgr m\u016f\u017ee rozpadnout na n\u011bkolik men\u0161\u00edch a pokra\u010dovat v chodu. Posledn\u00ed dobou jsem Repmgr nesledoval, mo\u017en\u00e1 to opravili... mo\u017en\u00e1 ne. Av\u0161ak vy\u010dlen\u011bn\u00ed informac\u00ed o stavu clusteru do DCS, tak jak to d\u011blaj\u00ed Stolon a Patroni, je nej\u017eivotaschopn\u011bj\u0161\u00ed mo\u017enost. <\/p>\n<p><\/p>\n<p><em>Alexei, m\u00e1m ot\u00e1zku, mo\u017en\u00e1 tro\u0161ku naivn\u00ed. V jednom z prvn\u00edch p\u0159\u00edklad\u016f DCS jste p\u0159esunuli z m\u00edstn\u00edho po\u010d\u00edta\u010de na vzd\u00e1len\u00fd uzel. Ch\u00e1peme, \u017ee s\u00ed\u0165 m\u00e1 sv\u00e9 vlastnosti, \u017eije sv\u00fdm vlastn\u00edm \u017eivotem. A co se stane, pokud se z n\u011bjak\u00e9ho d\u016fvodu cluster DCS stane nedostupn\u00fdm? O p\u0159\u00ed\u010din\u00e1ch te\u010f mluvit nebudu, m\u016f\u017ee jich b\u00fdt spousta: od neobratn\u00fdch rukou s\u00ed\u0165a\u0159\u016f po skute\u010dn\u00e9 probl\u00e9my.<\/em> <\/p>\n<p><\/p>\n<p>Nehovo\u0159il jsem o tom nahlas, ale cluster DCS by m\u011bl b\u00fdt tak\u00e9 vysoce dostupn\u00fd, tj. m\u00e1 b\u00fdt neparn\u00ed po\u010det uzl\u016f, aby mohlo b\u00fdt dosa\u017eeno kv\u00f3ra. Co se stane, pokud se cluster DCS stane nedostupn\u00fdm, nebo nebude schopen dos\u00e1hnout kv\u00f3ra, tj. n\u011bjak\u00fd s\u00ed\u0165ov\u00fd split nebo selh\u00e1n\u00ed uzl\u016f? V tomto p\u0159\u00edpad\u011b p\u0159ech\u00e1z\u00ed cluster Patroni do re\u017eimu pouze pro \u010dten\u00ed. Cluster Patroni nem\u016f\u017ee ur\u010dit stav clusteru a co m\u00e1 d\u011blat. Nem\u016f\u017ee se spojit s DCS a ulo\u017eit tam nov\u00fd stav clusteru, proto cel\u00fd cluster p\u0159ech\u00e1z\u00ed do re\u017eimu pouze pro \u010dten\u00ed. A \u010dek\u00e1 bu\u010f na manu\u00e1ln\u00ed z\u00e1sah oper\u00e1tora, nebo na obnoven\u00ed DCS.<\/p>\n<p><\/p>\n<p><em>Jednodu\u0161e \u0159e\u010deno, DCS se pro n\u00e1s st\u00e1v\u00e1 slu\u017ebou stejn\u011b d\u016fle\u017eitou, jako je samotn\u00e1 datab\u00e1ze?<\/em><\/p>\n<p><\/p>\n<p>Da, da. V mnogih sodobnih podjetjih je Service Discovery nepogre\u0161ljiv del infrastrukture. Uvajajo ga celo prej, kot so se pojavile baze podatkov v infrastrukturi. Pogojo je mogo\u010de opisati tako, da smo zagnali infrastrukturo, postavili v DC, in \u017ee imamo Service Discovery. \u010ce je to Consul, lahko na njem temelji tudi DNS. \u010ce je to Etcd, je lahko del Kubernetes klasterja, kjer se bo razporedilo vse drugo. Zdi se mi, da je Service Discovery \u017ee nepogre\u0161ljiv del sodobnih infrastrukturnih sistemov in o njem razmi\u0161ljajo veliko prej, kot o bazah podatkov. <\/p>\n<p><\/p>\n<p><em>Hvala!<\/em><\/p>\n<p>Izvor: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/512768\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041e\u0441\u043d\u043e\u0432\u043d\u0430\u044f \u0446\u0435\u043b\u044c Patroni \u2014 \u044d\u0442\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u0435 High Availability \u0434\u043b\u044f PostgreSQL. \u041d\u043e Patroni \u2014 \u044d\u0442\u043e \u043b\u0438\u0448\u044c template, \u0430 \u043d\u0435 \u0433\u043e\u0442\u043e\u0432\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 (\u0447\u0442\u043e, \u0432 \u043e\u0431\u0449\u0435\u043c, \u0438 \u0441\u043a\u0430\u0437\u0430\u043d\u043e \u0432 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438). \u041d\u0430 \u043f\u0435\u0440\u0432\u044b\u0439 \u0432\u0437\u0433\u043b\u044f\u0434, \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0432 Patroni \u0432 \u0442\u0435\u0441\u0442\u043e\u0432\u043e\u0439 \u043b\u0430\u0431\u0435, \u043c\u043e\u0436\u043d\u043e \u0443\u0432\u0438\u0434\u0435\u0442\u044c, \u043a\u0430\u043a\u043e\u0439 \u044d\u0442\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0438 \u043a\u0430\u043a \u043e\u043d \u043b\u0435\u0433\u043a\u043e \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043d\u0430\u0448\u0438 \u043f\u043e\u043f\u044b\u0442\u043a\u0438 \u0440\u0430\u0437\u0432\u0430\u043b\u0438\u0442\u044c \u043a\u043b\u0430\u0441\u0442\u0435\u0440. \u041e\u0434\u043d\u0430\u043a\u043e \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0432 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":90104,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-90103","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.4 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sl_SI\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-07-29T11:42:32+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-07-29T11:42:32+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Patroni zgodbe o neuspehu ali kako zru\u0161iti svoj PostgreSQL klaster. Aleksej Lesovski | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Patroni Failure Stories or How to crash your PostgreSQL cluster. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439 | ProHoster","og:url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-07-29T11:42:32+00:00","article:modified_time":"2020-07-29T11:42:32+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"90103","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:58:48","updated":"2026-02-09 16:50:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/90103","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=90103"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/90103\/revisions"}],"predecessor-version":[{"id":158759,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/90103\/revisions\/158759"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/90104"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=90103"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=90103"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=90103"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}