{"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\/it\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij","title":{"rendered":"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/6404cba13214f499d1f347cca0aacbe7.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>L'obiettivo principale di Patroni \u00e8 garantire l'alta disponibilit\u00e0 per PostgreSQL. Tuttavia, Patroni \u00e8 solo un template, non uno strumento pronto all'uso (come indicato nella documentazione). A prima vista, configurando Patroni in un laboratorio di test, si pu\u00f2 vedere quanto sia uno strumento fantastico e come gestisca facilmente i nostri tentativi di far crollare il cluster. Tuttavia, nella pratica, in un ambiente di produzione, non sempre tutto avviene con la stessa bellezza ed eleganza che si osserva in un laboratorio di test.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/ff445e6d76a2ad46a232b705e104446f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Parler\u00f2 un po' di me. Ho iniziato come sistemista. Ho lavorato nello sviluppo web. Dal 2014 lavoro in Data Egret. L'azienda si occupa di consulenza nel settore di Postgres. E ci occupiamo specificamente di Postgres, lavorando con esso ogni giorno, quindi abbiamo una variet\u00e0 di competenze legate alla sua gestione. <\/p>\n<p><\/p>\n<p>Verso la fine del 2018 abbiamo iniziato a utilizzare gradualmente Patroni. E abbiamo accumulato una certa esperienza. Abbiamo diagnosticato, ottimizzato e raggiunto le nostre best practices. In questa presentazione parler\u00f2 di esse.<\/p>\n<p><\/p>\n<p>Oltre a Postgres, adoro Linux. Mi piace esplorarlo e approfondirne le funzionalit\u00e0, adoro compilare kernel. Amo la virtualizzazione, i container, Docker, Kubernetes. Tutto ci\u00f2 mi interessa perch\u00e9 derivano dalle mie vecchie abitudini da amministratore. Mi piace occuparmi dei sistemi di monitoraggio. E mi piacciono le cose di Postgres legate all'amministrazione, come la replica e il backup. Nel tempo libero scrivo in Go. Non sono un ingegnere del software; scrivo in Go solo per me stesso. E questo mi d\u00e0 soddisfazione. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/02cfd9293af5a8410c91e39afe2c75e6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Credo che molti di voi sappiano che in Postgres non c'\u00e8 HA (Alta Disponibilit\u00e0) out-of-the-box. Per ottenere l'HA, \u00e8 necessario installare qualcosa, configurarlo, impegnarsi e raggiungere l'obiettivo. <\/li>\n<li>Ci sono diversi strumenti e Patroni \u00e8 uno di essi, che gestisce l'HA in modo piuttosto efficace e molto bene. Ma installando tutto questo in un laboratorio di test e avviandolo, possiamo vedere che funziona, possiamo riprodurre alcuni problemi e osservare come Patroni li gestisce. E scopriremo che tutto funziona perfettamente. <\/li>\n<li>Tuttavia, nella pratica abbiamo affrontato vari problemi. E parler\u00f2 di questi problemi.<\/li>\n<li>Vi racconter\u00f2 come li abbiamo diagnosticati, cosa abbiamo modificato e se questo ci ha aiutato o meno. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/7126b45b40dd08521e80a3c150382bec.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Non parler\u00f2 di come installare Patroni, perch\u00e9 puoi trovare facilmente informazioni online, puoi anche esaminare i file di configurazione per capire come avviare e configurare tutto. Puoi approfondire gli schemi e le architetture, cercando le informazioni appropriate sul web. <\/li>\n<li>Non condivider\u00f2 esperienze altrui. Parler\u00f2 solo dei problemi che abbiamo affrontato noi stessi. <\/li>\n<li>E non discuter\u00f2 di problemi che esulano da Patroni e PostgreSQL. Ad esempio, per quanto riguarda i problemi legati al bilanciamento, quando il nostro cluster \u00e8 andato in crash, non ne parler\u00f2. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/3f8d179e7c78ce83e8842ef5c72fe30d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ecco un piccolo disclaimer prima di iniziare la nostra presentazione. <\/p>\n<p><\/p>\n<p>Tutti questi problemi che abbiamo riscontrato si sono manifestati nei primi 6-7-8 mesi di utilizzo. Con il tempo, abbiamo sviluppato le nostre best practices interne e i problemi sono scomparsi. Pertanto, la presentazione \u00e8 stata programmata circa sei mesi fa, quando tutto era ancora fresco nella mia mente e lo ricordavo bene. <\/p>\n<p><\/p>\n<p>Durante la preparazione del rapporto, ho gi\u00e0 esaminato i vecchi post-mortem e controllato i log. Alcuni dettagli potrebbero essere dimenticati oppure alcune informazioni potrebbero non essere state approfondite durante l'analisi dei problemi, pertanto potrebbe sembrare che alcune problematiche non siano state completamente trattate o che ci sia una mancanza di informazioni. Pertanto, vi chiedo scusa per questo aspetto. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/30d414284a41fcbc3bf417c9da28ca52.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Che cos'\u00e8 Patroni?<\/p>\n<p><\/p>\n<ul>\n<li>\u00c8 un modello per la creazione di alta disponibilit\u00e0 (HA). Questo \u00e8 ci\u00f2 che si afferma nella documentazione. E dal mio punto di vista, \u00e8 un chiarimento molto importante. Patroni non \u00e8 una soluzione universale che risolver\u00e0 tutti i vostri problemi; \u00e8 necessario infatti fare uno sforzo affinch\u00e9 funzioni e porti benefici. <\/li>\n<li>\u00c8 un servizio di agenzia che viene installato su ogni servizio con un database, e che funge da sistema init per il vostro Postgres. Avvia, arresta, riavvia, modifica la configurazione e cambia la topologia del vostro cluster. <\/li>\n<li>Pertanto, per memorizzare lo stato del cluster e la sua rappresentazione attuale, \u00e8 necessaria una certa forma di archiviazione. Da questo punto di vista, Patroni ha scelto di conservare lo stato in un sistema esterno. Questo \u00e8 un sistema di memorizzazione distribuita delle configurazioni. Possono essere Etcd, Consul, ZooKeeper, o l\u2019Etcd di Kubernetes, cio\u00e8 una di queste opzioni. <\/li>\n<li>Una delle caratteristiche di Patroni \u00e8 che l\u2019autofailover \u00e8 disponibile direttamente 'fuori dalla scatola', una volta configurato. Se facciamo un confronto con Repmgr, l\u00ec il failover \u00e8 incluso. Con Repmgr otteniamo lo switchover, ma se desideriamo l\u2019autofailover, dobbiamo configurarlo ulteriormente. In Patroni, l\u2019autofailover \u00e8 gi\u00e0 incluso.<\/li>\n<li>E ci sono molte altre cose. Ad esempio, la gestione delle configurazioni, l\u2019aggiunta di nuove repliche, backup, ecc. Ma questo \u00e8 al di fuori di questa relazione, quindi non ne parler\u00f2. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/fed0f1ce931df99ca76ae1116f8098cc.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In sintesi, l'obiettivo principale di Patroni \u00e8 garantire un autofailover efficace e affidabile, in modo che il cluster rimanga operativo e l'applicazione non percepisca i cambiamenti nella topologia del cluster. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/fac52620957efa47ced330e7cc8084e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ma quando iniziamo a utilizzare Patroni, il nostro sistema diventa un po' pi\u00f9 complesso. Se in precedenza avevamo Postgres, utilizzando Patroni otteniamo Patrone stesso, otteniamo un DCS dove viene memorizzato lo stato. E tutto questo deve funzionare in qualche modo. Quindi, cosa pu\u00f2 andare storto?<\/p>\n<p><\/p>\n<p>Pu\u00f2 andare storto:<\/p>\n<p><\/p>\n<ul>\n<li>Pu\u00f2 andare storto Postgres. Pu\u00f2 essere il master o una replica, uno dei due potrebbe guastarsi. <\/li>\n<li>Pu\u00f2 andare storto lo stesso Patroni. <\/li>\n<li>Pu\u00f2 andare storto il DCS, dove viene memorizzato lo stato.<\/li>\n<li>E pu\u00f2 andare storto la rete. <\/li>\n<\/ul>\n<p><\/p>\n<p>Tutti questi aspetti li tratter\u00f2 nella mia presentazione. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/1aeaf46d37bf1935b514b0581e0dbd0b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Esaminer\u00f2 i casi man mano che si complicano, non dal punto di vista che il caso coinvolge molti componenti. Ma dal punto di vista delle sensazioni soggettive, che questo caso \u00e8 stato difficile per me, \u00e8 stato complicato da analizzare\u2026 e viceversa, un caso \u00e8 stato facile e l'ho trovato semplice da trattare. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/65b0c98bf2284610e955ced5eb998f39.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E il primo caso \u00e8 il pi\u00f9 semplice. Questo \u00e8 il caso in cui abbiamo preso un cluster di database e abbiamo distribuito il nostro DCS su quello stesso cluster. Questo \u00e8 l'errore pi\u00f9 comune. \u00c8 un errore di architettura, cio\u00e8 la fusione di diversi componenti nello stesso luogo. <\/p>\n<p><\/p>\n<p>Quindi, si \u00e8 verificato un file error, andiamo a scoprire cosa \u00e8 successo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/244b69d623fe2205c2d9ed2aa4620067.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E qui ci interessa sapere quando \u00e8 avvenuto il failover. Cio\u00e8, ci interessa questo momento preciso in cui \u00e8 avvenuto il cambiamento dello stato del cluster. <\/p>\n<p><\/p>\n<p>Tuttavia, il failover non \u00e8 sempre istantaneo, cio\u00e8 non avviene in un momento definito, ma pu\u00f2 richiedere tempo. Pu\u00f2 essere un processo prolungato.<\/p>\n<p><\/p>\n<p>Per questo motivo ha un tempo di inizio e un tempo di fine, cio\u00e8 \u00e8 un evento di lunga durata. Suddividiamo tutti gli eventi in tre intervalli: abbiamo il tempo prima del failover, durante il failover, e dopo il failover. Cio\u00e8, consideriamo tutti gli eventi su questa timeline. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/a0ed61afe55d1a157147e0d80b17e5d1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La prima cosa che facciamo quando si verifica il failover \u00e8 cercare la causa, cio\u00e8 cosa \u00e8 successo per provocare il failover. <\/p>\n<p><\/p>\n<p>Se guardiamo i log, troveremo i log classici di Patroni. Qui ci informa che il server \u00e8 diventato master, e il ruolo di master \u00e8 stato trasferito a questo nodo. Questo \u00e8 evidenziato qui. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/9998c69f7d0d4358b277f4e0e7b4350f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Iniziamo a capire perch\u00e9 si \u00e8 verificato il failover, ovvero quali eventi hanno causato il passaggio del master da un nodo all'altro. In questo caso, la situazione \u00e8 chiara. Abbiamo un errore di interazione con il sistema di storage. Il master ha compreso che non pu\u00f2 lavorare con il DCS, quindi si \u00e8 verificato un problema di interazione. E comunica che non pu\u00f2 pi\u00f9 funzionare come master e si dimette. La riga \"demoted self\" si riferisce proprio a questo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/4a8eca27689546b4b0fc3c666a3c37c4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Esaminando gli eventi che hanno preceduto il failover, possiamo individuare le cause che hanno ostacolato il funzionamento del master. <\/p>\n<p><\/p>\n<p>Dai log di Patroni, vediamo che ci sono numerosi errori e timeout, cio\u00e8 l'agente Patroni non riesce a comunicare con il DCS. In questo caso specifico, si tratta dell'agente Consul, con il quale si comunica sulla porta 8500. <\/p>\n<p><\/p>\n<p>Il problema risiede nel fatto che Patroni e il database sono in esecuzione sulla stessa macchina. Inoltre, su questo nodo erano attivi i server Consul. Creando un carico sul server, abbiamo generato problemi anche per <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/it\/server\/\"   title=\"server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1515\">server<\/a> Consul. Non sono riusciti a comunicare correttamente. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/0d8dba6641809560e6b32825d481e30b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dopo un po', quando il carico si \u00e8 attenuato, il nostro Patroni \u00e8 riuscito a comunicare di nuovo con gli agenti. Il funzionamento normale \u00e8 ripreso. E lo stesso server Pgdb-2 \u00e8 tornato a essere master. C'\u00e8 stato quindi un piccolo switch, che ha portato il nodo a rinunciare ai poteri di master, per poi riprenderli, quindi tutto \u00e8 tornato come prima. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/131b93e0bd83099e1b99b53742419e13.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Questo pu\u00f2 essere interpretato come un falso allarme, oppure si pu\u00f2 considerare che Patroni abbia fatto tutto correttamente. Cio\u00e8, ha capito di non poter mantenere lo stato del cluster e ha rinunciato ai poteri.<\/p>\n<p><\/p>\n<p>Il problema \u00e8 sorto a causa del fatto che i server Consul si trovano sullo stesso hardware delle basi. Di conseguenza, qualsiasi carico, sia su dischi che su processori, influisce anche sull'interazione con il cluster Consul.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/142c7cf839c8da078451f7ba9d5499e5.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E abbiamo deciso che non dovevano coesistere, quindi abbiamo creato un cluster separato per Consul. Patroni ha gi\u00e0 funzionato con un Consul separato, cio\u00e8 c'era un cluster Postgres separato e un cluster Consul. Questa \u00e8 una guida di base su come separare e mantenere queste cose, affinch\u00e9 non vivano insieme. <\/p>\n<p><\/p>\n<p>Una possibile soluzione \u00e8 regolare i parametri ttl, loop_wait, retry_timeout, cio\u00e8 cercare di gestire questi picchi di carico aumentando tali parametri. Tuttavia, non \u00e8 la soluzione ideale, poich\u00e9 questa sovraccarico potrebbe durare nel tempo. Finiremo per superare questi limiti e potrebbe non essere di grande aiuto. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/c51f35dcd88b1c792acec231c0c6c66c.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La prima problematica \u00e8 piuttosto semplice. Abbiamo posizionato il DCS insieme al database, creando un problema. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/cc2a98d9790441577fb4080406cbc53f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La seconda problematica \u00e8 simile alla prima. Ha in comune il fatto che ci sono nuovamente problemi di integrazione con il sistema DCS.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/e5c01b105adca48cc620085db8dd2d2b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Se diamo un'occhiata ai log, possiamo notare che c'\u00e8 di nuovo un errore di comunicazione. Patroni segnala che non riesce a interagire con il DCS, quindi il master attuale passa in modalit\u00e0 replica.<\/p>\n<p><\/p>\n<p>Il vecchio master diventa una replica; qui Patroni funziona come previsto. Avvia pg_rewind per ripristinare il registro delle transazioni e poi si collega al nuovo master per raggiungerlo. Patroni gestisce questa operazione come dovrebbe. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/29255f4790abb15b64dbf9ee0b41c7fc.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Qui dobbiamo trovare il punto precedente al failover, ovvero quegli errori che hanno causato il nostro failover. In questo senso, i log di Patroni sono piuttosto facili da gestire. Scrive gli stessi messaggi a intervalli regolari. E se cominciamo a scorrere rapidamente questi log, notiamo che i messaggi cambiano, il che indica che sono iniziati dei problemi. Torniamo rapidamente a quel punto e vediamo cosa sta succedendo. <\/p>\n<p><\/p>\n<p>In una situazione normale, i log appaiono pi\u00f9 o meno in questo modo. Viene controllato il proprietario del blocco. Se il proprietario, ad esempio, \u00e8 cambiato, possono verificarsi eventi a cui Patroni deve reagire. Ma in questo caso, tutto va bene. Stiamo cercando il punto in cui sono iniziati gli errori. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/f48ebd22a405f5b2900621451c68f543.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Scorrendo fino al punto in cui sono iniziati gli errori, vediamo che si \u00e8 verificato un auto-failover. Poich\u00e9 gli errori erano legati all'interazione con DCS e nel nostro caso abbiamo utilizzato Consul, guardiamo anche nei log di Consul per vedere cosa \u00e8 successo l\u00ec. <\/p>\n<p><\/p>\n<p>Confrontando approssimativamente l'orario del file server con l'orario nei log di Consul, notiamo che i nostri vicini nel cluster Consul iniziano a dubitare dell'esistenza di altri membri del cluster Consul.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/63b02ac5b4f5a34a2822f1eee2b1f2f8.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E se diamo un'occhiata ai log di altri agenti di Consul, si nota anche che c'\u00e8 qualche collasso di rete in corso. E tutti i membri del cluster Consul dubitano della presenza reciproca. Questo ha innescato una problematica per il file server. <\/p>\n<p><\/p>\n<p>Se analizziamo cosa \u00e8 successo prima di questi errori, possiamo vedere che ci sono vari errori, come deadline e RPC failed, cio\u00e8 \u00e8 chiaramente emersa qualche problematica nella comunicazione tra i membri del cluster Consul. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/b15c912f2afb49d9d85e7bb9361ce449.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La risposta pi\u00f9 semplice \u00e8 riparare la rete. Ma per me, qui sulla piattaforma, \u00e8 facile dirlo. Tuttavia, le circostanze sono tali che non sempre il cliente pu\u00f2 permettersi di riparare la rete. Potrebbe trovarsi in un data center e non avere possibilit\u00e0 di intervenire sulla rete o di influenzare l'hardware. Pertanto, sono necessarie altre opzioni. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/1dbdb66233acc3bc321a30a1c5fe14f9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Le opzioni sono:<\/p>\n<p><\/p>\n<ul>\n<li>L'opzione pi\u00f9 semplice, che credo sia persino documentata, \u00e8 disabilitare i controlli di Consul, ossia semplicemente passare un array vuoto. In questo modo diciamo all'agente di Consul di non utilizzare alcun controllo. Grazie a questi controlli, possiamo ignorare queste tempeste di rete e non avviare il file di recovery. <\/li>\n<li>Un'altra opzione \u00e8 quella di ricontrollare il raft_multiplier. Questo \u00e8 un parametro del server Consul. Di default, \u00e8 impostato su 5. Questo valore \u00e8 raccomandato dalla documentazione per gli ambienti di staging. Fondamentalmente, influisce sulla frequenza di scambio di messaggi tra i membri della rete Consul. In sostanza, questo parametro incide sulla velocit\u00e0 della comunicazione fra i nodi del cluster Consul. Per l'ambiente di produzione, \u00e8 consigliato diminuirlo affinch\u00e9 i nodi comunichino pi\u00f9 frequentemente. <\/li>\n<li>Un'altra opzione che abbiamo iniziato a utilizzare \u00e8 l'aumento della priorit\u00e0 dei processi di Consul rispetto agli altri processi per il pianificatore di processi del sistema operativo. Esiste un parametro chiamato \u00abnice\u00bb, che determina appunto la priorit\u00e0 dei processi considerata dal pianificatore OS durante la pianificazione. Abbiamo quindi ridotto il valore di nice per gli agenti di Consul, ossia abbiamo aumentato la priorit\u00e0, affinch\u00e9 il sistema operativo concedesse ai processi di Consul pi\u00f9 tempo per svolgere il proprio lavoro ed eseguire il proprio codice. Nel nostro caso, questo ha risolto il nostro problema. <\/li>\n<li>Un'altra opzione \u00e8 non utilizzare Consul. Ho un amico che \u00e8 un grande sostenitore di Etcd. E discutiamo regolarmente su quale sia migliore, Etcd o Consul. Ma per quanto riguarda qual \u00e8 il migliore, di solito ci accordiamo sul fatto che Consul ha un agente che deve essere eseguito su ogni nodo con il database. Cio\u00e8, l'interazione di Patroni con il cluster Consul avviene tramite questo agente. E questo agente diventa un collo di bottiglia. Se succede qualcosa all'agente, Patroni non pu\u00f2 pi\u00f9 lavorare con il cluster Consul. Questo \u00e8 un problema. Per quanto riguarda Etcd, non c'\u00e8 alcun agente. Patroni pu\u00f2 lavorare direttamente con l'elenco dei server Etcd e comunicare con loro. In questo senso, se utilizzi Etcd nella tua azienda, Etcd sar\u00e0 probabilmente una scelta migliore rispetto a Consul. Ma siamo sempre limitati da ci\u00f2 che il cliente ha scelto e sta utilizzando. E per la maggior parte dei nostri clienti utilizziamo Consul. <\/li>\n<li>L'ultimo punto \u00e8 rivedere i valori dei parametri. Possiamo aumentare questi parametri nella speranza che i nostri problemi di rete temporanei siano brevi e non superino l'intervallo di questi parametri. In questo modo possiamo ridurre l'aggressivit\u00e0 di Patroni nell'esecuzione dell'auto-failover, se si verificano problemi di rete.<\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/f0043050da20f6368dabf66ec9a4eade.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Penso che molti di coloro che utilizzano Patroni siano familiari con questo comando. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/9f78f59dab166e47ac78436802156d04.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Questo comando mostra lo stato attuale del cluster. E a prima vista, questa immagine pu\u00f2 sembrare normale. Abbiamo un master, abbiamo una replica, non ci sono lag nella replica. Ma questa situazione \u00e8 normale solo finch\u00e9 non sappiamo che in questo cluster dovrebbero esserci tre nodi, non due. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/a39c891f8620ba210b6bce0727e0fa8b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Di conseguenza, si \u00e8 verificato un auto-failover. E dopo questo auto-failover, la nostra replica \u00e8 scomparsa. Dobbiamo scoprire perch\u00e9 \u00e8 scomparsa e riportarla indietro, ripristinarla. E torniamo ai log per vedere perch\u00e9 si \u00e8 verificato il failover automatico.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/e6e67d46cb20c8d7e58c7505157f68e1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In questo caso, la seconda replica \u00e8 diventata il master. Qui va tutto bene. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/b86ccea68b0c6013a23bbd2804e48320.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dobbiamo esaminare la replica che si \u00e8 disconnessa e che non \u00e8 nel cluster. Apriamo i log di Patroni e vediamo che abbiamo avuto un problema durante la connessione al cluster nella fase di pg_rewind. Per connettersi al cluster \u00e8 necessario ripristinare il registro delle transazioni, richiedere il registro delle transazioni corretto dal master e sincronizzarsi con il master. <\/p>\n<p><\/p>\n<p>In questo caso non abbiamo il registro delle transazioni, e la replica non pu\u00f2 avviarsi. Di conseguenza, fermiamo Postgres con un errore. Pertanto, non \u00e8 presente nel cluster. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/dadbd44b766674b719d85781ef7f0caa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dobbiamo capire perch\u00e9 non \u00e8 presente nel cluster e perch\u00e9 non ci sono log. Andiamo sul nuovo master e controlliamo cosa c'\u00e8 nei suoi log. Si scopre che durante l'operazione di pg_rewind si \u00e8 verificato un checkpoint. Parte dei vecchi registri delle transazioni \u00e8 stata semplicemente rinominata. Quando il vecchio master ha tentato di connettersi al nuovo master e richiedere questi log, erano gi\u00e0 stati rinominati e quindi non esistevano pi\u00f9.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/f2d5c37324f9436b2bdad1290612d86f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ho confrontato i timestamp in cui si sono verificati questi eventi. La differenza \u00e8 di appena 150 millisecondi, ovvero il checkpoint \u00e8 stato completato in 369 millisecondi e i segmenti WAL sono stati rinominati. E letteralmente, dopo 150 millisecondi, nel momento 517, \u00e8 stata avviata la rewind sul vecchio replica. Cio\u00e8, ci sono bastati 150 millisecondi affinch\u00e9 il replica non riuscisse a connettersi e avviarsi. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/99dd80deb8466bfc3aff568456e07102.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Quali sono le opzioni disponibili?<\/p>\n<p><\/p>\n<p>All'inizio abbiamo utilizzato le slot di replicazione. Pensavamo fosse una buona idea. Anche se nella fase iniziale dell'utilizzo, abbiamo disattivato le slot. Credevamo che, se le slot accumulassero troppi segmenti WAL, avremmo potuto compromettere il master. Sarebbe crollato. Abbiamo lottato per un po' senza slot. E abbiamo capito che ci servivano le slot, quindi le abbiamo riattivate. <\/p>\n<p><\/p>\n<p>Ma qui c'\u00e8 un problema: quando il master passa al replica, elimina le slot e, insieme alle slot, elimina i segmenti WAL. Per evitare questa problematica, abbiamo deciso di aumentare il parametro wal_keep_segments. Il valore predefinito \u00e8 di 8 segmenti. Lo abbiamo aumentato a 1.000 e controllato quanto spazio libero avevamo. E abbiamo riservato 16 gigabyte per wal_keep_segments. Cio\u00e8, durante il commutazione, abbiamo sempre a disposizione 16 gigabyte di registri delle transazioni su tutti i nodi.<\/p>\n<p><\/p>\n<p>Inoltre, questo \u00e8 ancora valido per compiti di manutenzione prolungati. Supponiamo di dover aggiornare una delle repliche. Vogliamo spegnerla. Dobbiamo aggiornare il software, magari il sistema operativo o qualcos'altro. Quando spegniamo la replica, anche lo slot per quella replica viene rimosso. E se utilizziamo un basso numero di wal_keep_segments, in caso di assenza prolungata della replica, i registri delle transazioni verranno riprodotti. Riavvieremo la replica, richieder\u00e0 quei registri delle transazioni in cui si era fermata, ma potrebbero non essere disponibili sul master. E anche la replica non riuscir\u00e0 a connettersi. Pertanto, manteniamo una scorta abbondante di registri.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/dad55c828128ce92f649a99cc53ce54b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/63e70f0b098567f3a6d4fd66a0c293bb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Abbiamo un database di produzione. I progetti sono gi\u00e0 operativi l\u00ec. <\/p>\n<p><\/p>\n<p>Si \u00e8 verificato un file error. Siamo entrati e abbiamo controllato: tutto in ordine, le repliche sono al loro posto, non ci sono ritardi nella replicazione. Non ci sono errori nei registri, tutto \u00e8 a posto. <\/p>\n<p><\/p>\n<p>Il team del prodotto dice che dovrebbero esserci dei dati, ma li vediamo solo in una fonte, mentre nel database non li troviamo. Dobbiamo capire cosa sia successo con quei dati. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/568ca9aa31680d5e0c9d4ed9693b14e6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u00c8 chiaro che pg_rewind li ha sovrascritti. Lo abbiamo subito capito, ma siamo andati a vedere cosa era successo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/a8fee389201d96e81761cd276c5265c3.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nei log possiamo sempre trovare quando \u00e8 avvenuto il failover, chi \u00e8 diventato il master e possiamo determinare chi era il vecchio master e quando ha voluto diventare replica, cio\u00e8 abbiamo bisogno di questi log per scoprire il volume dei log delle transazioni che \u00e8 stato perso.<\/p>\n<p><\/p>\n<p>Il nostro vecchio master si \u00e8 riavviato. E nel programma di avvio automatico era stato registrato Patroni. Patroni \u00e8 stato avviato e ha avviato Postgres. Pi\u00f9 precisamente, prima di avviare Postgres e prima di renderlo una replica, Patroni ha avviato il processo pg_rewind. Di conseguenza, ha cancellato una parte dei log delle transazioni, ha scaricato nuovi log e si \u00e8 connesso. Qui Patroni ha funzionato alla grande, cio\u00e8 come doveva. Il nostro cluster \u00e8 stato ripristinato. Avevamo 3 nodi, dopo il failover ci sono stati 3 nodi: tutto fantastico. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/b747a24f53e20ed098c2dc0afc79bead.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Abbiamo perso parte dei dati. E dobbiamo capire quanto ne abbiamo perso. Stiamo cercando proprio quel momento in cui \u00e8 avvenuto il rewind. Possiamo trovarlo tramite queste registrazioni nel log. \u00c8 partito il rewind, ha fatto qualcosa e si \u00e8 concluso.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/5b7bacffb52e3ccd529a3a734c441295.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dobbiamo trovare la posizione nel log delle transazioni in cui si \u00e8 fermato il vecchio master. In questo caso, \u00e8 questo contrassegno. E abbiamo bisogno di un secondo contrassegno, cio\u00e8 della distanza in cui il vecchio master si differenzia dal nuovo. <\/p>\n<p><\/p>\n<p>Confrontiamo le due posizioni usando un normale pg_wal_lsn_diff. In questo caso, otteniamo 17 megabyte. Se siano tanti o pochi, ognuno lo stabilisce secondo la propria valutazione. Per alcuni 17 megabyte possono sembrare pochi, per altri sono un valore significativo e inaccettabile. Qui ognuno deve decidere in base alle esigenze del proprio business. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/55335fce85961e159459c38300a0ad12.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ma cosa abbiamo scoperto per noi? <\/p>\n<p><\/p>\n<p>Innanzitutto, dobbiamo decidere se abbiamo sempre bisogno dell'avvio automatico di Patroni dopo il riavvio del sistema. Spesso \u00e8 necessario accedere al vecchio master e vedere fin dove \u00e8 arrivato. Potrebbe essere utile ispezionare i segmenti del log delle transazioni e capire cosa ci sia. E comprendere se possiamo perdere questi dati o se dobbiamo avviare il vecchio master in modalit\u00e0 standalone per recuperare queste informazioni. <\/p>\n<p><\/p>\n<p>Solo dopo aver fatto questo possiamo prendere decisioni su ci\u00f2 che possiamo scartare o su ci\u00f2 che possiamo recuperare, connettere questo nodo come replica al nostro cluster.<\/p>\n<p><\/p>\n<p>In aggiunta, c'\u00e8 il parametro 'maximum_lag_on_failover'. Se non ricordo male, di default questo parametro \u00e8 impostato a 1 megabyte. <\/p>\n<p><\/p>\n<p>Come funziona? Se la nostra replica \u00e8 in ritardo di 1 megabyte di dati a causa del lag di replicazione, questa replica non partecipa alle elezioni. E se si verifica un failover, Patroni verifica quali repliche sono in ritardo. Se sono in ritardo di un gran numero di registri delle transazioni, non possono diventare master. Questa \u00e8 una funzione di protezione molto valida, che consente di non perdere molti dati. <\/p>\n<p><\/p>\n<p>Ma c'\u00e8 un problema: il lag di replicazione nel cluster Patroni e DCS viene aggiornato a intervalli specifici. Credo che il valore ttl predefinito sia di 30 secondi.<\/p>\n<p><\/p>\n<p>Di conseguenza, pu\u00f2 verificarsi una situazione in cui il lag di replicazione per le repliche in DCS \u00e8 uno, ma in realt\u00e0 potrebbe esserci un lag completamente diverso o addirittura non ci potrebbe essere affatto, cio\u00e8 questa cosa non \u00e8 in tempo reale. E non riflette sempre la situazione reale. Quindi non ha senso basare logiche complesse su di essa. <\/p>\n<p><\/p>\n<p>E il rischio di perdite rimane sempre. Nel peggior caso una formula, mentre nel caso medio un'altra formula. Cio\u00e8, quando pianifichiamo l'implementazione di Patroni e valutiamo quanti dati possiamo perdere, dobbiamo considerare queste formule e avere un'idea di quanti dati possiamo effettivamente perdere. <\/p>\n<p><\/p>\n<p>E c'\u00e8 una buona notizia. Quando il vecchio master \u00e8 andato avanti, pu\u00f2 farlo grazie a qualche processo in background. C'era un certo auto-vacuum, ha registrato i dati e li ha salvati nel log delle transazioni. Possiamo tranquillamente ignorare questi dati e perderli. Non ci sono problemi in questo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/a86e8971ab4ef41b89af9cf0bdf519ba.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ecco come appaiono i log nel caso in cui sia impostato maximum_lag_on_failover e si sia verificato un failover dei file, e sia necessario scegliere un nuovo master. La replica si valuta come incapace di partecipare alle elezioni. Si ritira dalla corsa per diventare leader. Aspetta che venga scelto un nuovo master per poi connettersi a lui. Questa \u00e8 una misura aggiuntiva contro la perdita di dati.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/f760788e5951facdd08b2069037830fa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/c32f26e7526e1873f3bfd7d3693fcc72.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Qui il nostro team prodotto ha scritto che il loro prodotto ha problemi con Postgres. Nel frattempo, non possiamo accedere al master stesso, perch\u00e9 non \u00e8 disponibile tramite SSH. E non si verifica neppure l'auto-failover. <\/p>\n<p><\/p>\n<p>Questo host \u00e8 stato forzato a riavviarsi. A causa del riavvio si \u00e8 verificato un auto-failover, anche se potevo fare un failover manuale, come capisco ora. E dopo il riavvio andiamo a controllare cosa \u00e8 successo con il master attuale. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/95efb82e0647a396a21683cd53a69547.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Sapevamo in anticipo che avevamo problemi con i dischi, quindi avevamo gi\u00e0 delle indicazioni da monitoraggio su dove intervenire e cosa cercare. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/367aaab607d833d96a573ddbbbced502.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Abbiamo esaminato il log di PostgreSQL e iniziato a controllare cosa stesse accadendo. Abbiamo notato commit che duravano da una a tre secondi, il che non \u00e8 affatto normale. Abbiamo visto che l'autovacuum impiegava molto tempo e in modo anomalo. Inoltre, abbiamo riscontrato file temporanei sul disco. Questi sono tutti segnali di problemi con i dischi. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/7e0cfce7a81901ef9ef736c3fefc8dce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Abbiamo controllato il dmesg di sistema (il log dei messaggi del kernel). Abbiamo constatato che c'era un problema con uno dei dischi. Il sistema di dischi era un software RAID. Abbiamo esaminato \/proc\/mdstat e abbiamo visto che ci mancava un disco. Quindi, avevamo un RAID composto da 8 dischi, ma uno era assente. Se si guarda attentamente la slide, si pu\u00f2 vedere che sde \u00e8 mancante. In sostanza, un disco \u00e8 andato perso. Questo ha innescato problemi ai dischi e le applicazioni hanno riscontrato difficolt\u00e0 nella gestione del cluster PostgreSQL.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/4b09b3aa761cb504fa79173ef280faac.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In this case, Patroni wouldn't help us because it doesn't track the server status or disk condition. We must monitor such situations externally. We promptly added disk monitoring to our external monitoring. <\/p>\n<p><\/p>\n<p>We had the thought\u2014could fencing or a watchdog software assist us? We concluded it probably wouldn't be helpful because, during the issues, Patroni continued to interact with the DCS cluster and didn't see any problems. From the DCS and Patroni perspective, everything was fine with the cluster, even though there were actual disk issues and database availability problems. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/15fdac78535355d4eb889efcc27efc46.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In my opinion, this is one of the most peculiar issues I have researched for a long time; I read through many logs, sifted through them extensively, and I called it the cluster-simulant. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/b5259774931c290eda6673deb14b6c48.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>The issue was that the old master couldn't become a proper replica. Patroni would start it and indicate that this node was present as a replica, but at the same time, it wasn't a valid replica. You'll see why shortly. I kept this from the analysis of that problem. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/c35a5d102a46764bbf96e5a75ee88171.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E da dove \u00e8 iniziato tutto? \u00c8 iniziato, come nel problema precedente, con i freni a disco. Avevamo commit al secondo, due. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/435c1b350a89f288e0e10ca9d5a2ec6e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ci sono stati disservizi di connessione, cio\u00e8 i clienti si disconnettevano. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/920cb1f3f3b40578e15e6ff711e85c50.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ci sono state interruzioni di varia gravit\u00e0. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/285d6292d89b928a85e95602ee57d38a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E, di conseguenza, il sistema dei dischi non era molto reattivo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/ebe71d49360e7f604ecd6a3c8276cb73.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E la cosa pi\u00f9 enigmatica per me \u00e8 stata la richiesta di spegnimento immediato. Postgres ha tre modalit\u00e0 di spegnimento:<\/p>\n<p><\/p>\n<ul>\n<li>C'\u00e8 la modalit\u00e0 elegante, quando aspettiamo che tutti i clienti si disconnettano da soli. <\/li>\n<li>C'\u00e8 la modalit\u00e0 veloce, quando costringiamo i clienti a disconnettersi perch\u00e9 stiamo per spegnere. <\/li>\n<li>E c'\u00e8 la modalit\u00e0 immediata. In questo caso, immediata non informa nemmeno i clienti che devono disconnettersi, si spegne semplicemente senza preavviso. A tutti i clienti, il sistema operativo invia un messaggio RST (un messaggio TCP che comunica che la connessione \u00e8 stata interrotta e il cliente non ha pi\u00f9 nulla da fare). <\/li>\n<\/ul>\n<p><\/p>\n<p>Chi ha inviato questo segnale? I processi di background di Postgres non si inviano segnali reciproci, cio\u00e8 \u00e8 un kill-9. Non si inviano segnali di questo tipo, ma reagiscono solamente a essi, quindi \u00e8 un riavvio emergenziale di Postgres. Chi l'ha inviato, non lo so. <\/p>\n<p><\/p>\n<p>Ho controllato con il comando \u00ablast\u00bb e ho visto una persona che ha effettuato il login su questo server insieme a noi, ma ho esitato a fare una domanda. Potrebbe essere stato un kill -9. Avrei visto un kill -9 nei log, poich\u00e9 Postgres riporta di aver ricevuto un kill -9, ma non l'ho visto nei log. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/fe8e844649cea3384ebfde86e36eba44.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Proseguendo, ho notato che Patroni non ha scritto nei log per un periodo piuttosto lungo \u2013 54 secondi. Se confronto i due timestamp, ci sono circa 54 secondi senza messaggi. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/ffb1c4db3d7de591d77d56ed2fcc4f2a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E in quel tempo c'\u00e8 stata un'auto-failover. Patroni ha funzionato di nuovo perfettamente. Il nostro vecchio master non era disponibile, qualcosa stava succedendo. E sono iniziate le elezioni per il nuovo master. Qui tutto ha funzionato bene. pgsql01 \u00e8 diventato il nuovo leader. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/6b2457653e9f77af44cd64b4aff021a0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Abbiamo una replica che \u00e8 diventata master. E c'\u00e8 un secondo replica. Ci sono stati problemi con il secondo replica. Stava tentando di riconfigurarsi. Come capisco, stava cercando di cambiare recovery.conf, riavviare Postgres e connettersi al nuovo master. Ogni 10 secondi scrive messaggi che sta provando, ma non ci riesce. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/381818f189e19c3e1154074b4652f837.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Durante questi tentativi, il vecchio master riceve un segnale di spegnimento immediato. Il master si riavvia. Inoltre, il recovery si interrompe perch\u00e9 il vecchio master sta per riavviarsi. Ci\u00f2 significa che la replica non pu\u00f2 connettersi a lui, poich\u00e9 \u00e8 in modalit\u00e0 di spegnimento. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/d8a8cde925fa8fe601d44ab908ae69dc.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>A un certo punto ha funzionato, ma la replica non si \u00e8 avviata. <\/p>\n<p><\/p>\n<p>Ho una sola ipotesi: che in recovery.conf ci fosse l'indirizzo del vecchio master. Quando \u00e8 apparso il nuovo master, la seconda replica continuava a cercare di connettersi al vecchio master. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/425ea3af1f1e186f4760e1fb1f5419fa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Quando Patroni \u00e8 stato avviato sulla seconda replica, il nodo si \u00e8 avviato, ma non \u00e8 riuscito a connettersi in replica. Questo ha creato un ritardo di replica, che appariva in questo modo. Cio\u00e8, tutti e tre i nodi erano presenti, ma il secondo nodo ritardava. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/f564eacd9944666c9a3f5bea634ede6b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tuttavia, guardando i log che venivano generati, si poteva vedere che la replica non riusciva ad avviarsi perch\u00e9 i log delle transazioni erano diversi. E i log delle transazioni forniti dal master, indicati in recovery.conf, semplicemente non corrispondevano al nostro nodo attuale. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/6b09947d157c9ef0a190da2df2cb5892.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E qui ho commesso un errore. Avrei dovuto controllare cosa c'era in recovery.conf per verificare la mia ipotesi che ci stavamo connettendo al master sbagliato. Ma all'epoca ero ancora alle prime armi e non mi \u00e8 venuto in mente, oppure ho notato che la replica era in ritardo e che sarebbe stato necessario ripristinarla, cio\u00e8 l'ho gestita in modo un po' superficiale. \u00c8 stata una mia svista. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/159f2256fd81428fd0d82a255528887d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dopo 30 minuti \u00e8 arrivato l'amministratore, cio\u00e8 ho riavviato Patroni sulla replica. La consideravo gi\u00e0 compromessa, pensavo che sarebbe stata necessaria una ripristino. Ho pensato \u2013 riavvier\u00f2 Patroni, forse verr\u00e0 fuori qualcosa di buono. Il recovery \u00e8 partito. E il database si \u00e8 anche aperto, era pronto a ricevere connessioni. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/aeac98750386c8389d39e006a229cc85.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La replica si \u00e8 avviata. Ma dopo un minuto si \u00e8 disconnessa con un errore, indicando che i registri delle transazioni non erano compatibili. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/17eaba000a79c80c29d1bc3902de05e6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ho pensato di riavviare di nuovo. Ho riavviato nuovamente Patroni, e non ho riavviato Postgres, ma ho riavviato proprio Patroni sperando che potesse avviare il database in modo magico. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/a85b38e033c45ad73da317f41e0ef24a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La replica \u00e8 ripartita, ma i registri delle transazioni erano differenti, non corrispondevano a quelli del tentativo precedente. La replica si \u00e8 fermata di nuovo. E il messaggio era leggermente diverso, non era molto informativo per me. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/fd90d708230bd54af685786c7e361ee1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E mi \u00e8 venuta in mente un'idea: e se riavviassi Postgres, mentre faccio un checkpoint corrente sul master, per spostare leggermente il punto nei registri delle transazioni in modo che il recovery inizi da un altro momento? Inoltre, avevamo anche delle riserve di WAL. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/19e67f95d1a74141a013947c9aa39e38.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ho riavviato Patroni, ho fatto un paio di checkpoint sul master e un paio di punti di riavvio sulla replica, quando \u00e8 stata attivata. E questo ha funzionato. Ho pensato a lungo a perch\u00e9 ha funzionato e come sia successo. E la replica si \u00e8 avviata. La replicazione non si \u00e8 pi\u00f9 interrotta. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/418ca59a681be84f51ed374a73a759c9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Questo problema \u00e8 per me uno dei pi\u00f9 misteriosi, su cui sto ancora riflettendo, su cosa stesse realmente accadendo. <\/p>\n<p><\/p>\n<p>Quali sono le conclusioni qui? Patroni pu\u00f2 funzionare come previsto e senza errori. Tuttavia, ci\u00f2 non garantisce al 100% che tutto vada bene. La replica pu\u00f2 avviarsi, ma pu\u00f2 anche trovarsi in uno stato semi-funzionale, e l'applicazione non pu\u00f2 lavorare con tale replica, perch\u00e9 conterr\u00e0 dati obsoleti. <\/p>\n<p><\/p>\n<p>E dopo ogni failover \u00e8 sempre necessario controllare che tutto sia a posto con il cluster, ossia che ci sia il numero corretto di repliche e che non ci sia un ritardo nella replicazione.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/aca7047ff33d3efe14071b798b554091.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E durante l'esame di questi problemi, formuler\u00f2 delle raccomandazioni. Ho cercato di riunirle in due slide. Probabilmente, tutte le storie avrebbero potuto essere riassunte in due slide e semplicemente raccontate.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/d4ad31b26d83c8846fe4097a11d70849.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Quando usate Patroni, \u00e8 fondamentale avere un monitoraggio. \u00c8 necessario sapere sempre quando si \u00e8 verificato un failover automatico, perch\u00e9 se non sapete che si \u00e8 verificato un failover automatico, non controllate il cluster. E questo \u00e8 problematico.<\/p>\n<p><\/p>\n<p>Dopo ogni failover, dobbiamo sempre verificare manualmente il cluster. Dobbiamo assicurarci che ci sia sempre il numero corretto di repliche, che non ci siano ritardi nella replicazione e che nei log non ci siano errori relativi alla replicazione in streaming, a Patroni o al sistema DCS.<\/p>\n<p><\/p>\n<p>L'automazione pu\u00f2 funzionare con successo, Patroni \u00e8 uno strumento molto utile. Pu\u00f2 operare, ma ci\u00f2 non porter\u00e0 il cluster allo stato desiderato. E se non ce ne rendiamo conto, avremo dei problemi.<\/p>\n<p><\/p>\n<p>E Patroni non \u00e8 una soluzione miracolosa. Dobbiamo comunque avere una comprensione di come funziona Postgres, come avviene la replica e come Patroni interagisce con Postgres, oltre a come viene garantita l'interazione tra i nodi. Questo \u00e8 necessario per poter risolvere manualmente i problemi che sorgono.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/ea4162df3561d2ea7001f2ef6788eaaa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Come mi approccio alla diagnosi? \u00c8 cos\u00ec che lavoriamo con diversi clienti e nessuno ha un stack ELK, quindi dobbiamo analizzare i log aprendo 6 console e 2 schede. In una scheda ci sono i log di Patroni per ogni nodo, nell'altra scheda i log di Consul o di Postgres se necessario. Diagnosticarlo \u00e8 molto difficile. <\/p>\n<p><\/p>\n<p>Quali approcci ho sviluppato? In primo luogo, guardo sempre quando \u00e8 arrivato il failover. E per me questo \u00e8 un punto di svolta. Osservo cosa \u00e8 successo prima del failover, durante il failover e dopo il failover. Il failover ha due marcatori: l'orario di inizio e quello di fine. <\/p>\n<p><\/p>\n<p>Successivamente, controllo nei log gli eventi precedenti al failover, cercando di capire le cause del failover. <\/p>\n<p><\/p>\n<p>Questo mi offre una visione di ci\u00f2 che \u00e8 accaduto e cosa si pu\u00f2 fare in futuro per evitare che si verifichino circostanze simili (e quindi impedire future interruzioni).<\/p>\n<p><\/p>\n<p>E dove di solito guardiamo? Io guardo:<\/p>\n<p><\/p>\n<ul>\n<li>Innanzitutto nei log di Patroni. <\/li>\n<li>Successivamente, controllo i log di Postgres o i log del DCS, a seconda di ci\u00f2 che \u00e8 emerso nei log di Patroni. <\/li>\n<li>A volte anche i log di sistema offrono indicazioni su cosa abbia causato il failover. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/a53618e366020e1a550d852fc308c188.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Qual \u00e8 la mia opinione su Patroni? Ho una grande considerazione per Patroni. A mio avviso, \u00e8 la soluzione migliore disponibile attualmente. Conosco molti altri strumenti, come Stolon, Repmgr, Pg_auto_failover, PAF. Ho provato tutti e quattro. Patroni mi \u00e8 piaciuto di pi\u00f9. <\/p>\n<p><\/p>\n<p>Se qualcuno mi chiedesse: 'Consiglieresti Patroni?'. Risponderei di s\u00ec, perch\u00e9 mi piace Patroni. E credo di aver imparato a configurarlo. <\/p>\n<p><\/p>\n<p>Se sei interessato a scoprire quali altri problemi possono sorgere con Patroni, oltre a quelli che ho menzionato, puoi sempre visitare la pagina <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/zalando\/patroni\/issues\/\">issues<\/a><\/noindex> su GitHub. Ci sono molte storie diverse e si discutono molti problemi interessanti. Alla fine, alcuni bug sono stati individuati e risolti, quindi \u00e8 una lettura affascinante. <\/p>\n<p><\/p>\n<p>Ci sono storie intriganti su come le persone si sparano sui piedi. \u00c8 molto istruttivo. Leggi e capisci che non dovresti farlo. Ti segni la cosa. <\/p>\n<p><\/p>\n<p>Vorrei esprimere un grande grazie a Zalando per lo sviluppo di questo progetto, in particolare ad Aleksandr Kukushkin e Aleksei Klyukin. Aleksei Klyukin \u00e8 uno dei coautori, non lavora pi\u00f9 in Zalando, ma sono due persone che hanno iniziato a lavorare su questo prodotto. <\/p>\n<p><\/p>\n<p>Ritengo che Patroni sia davvero una cosa fantastica. Sono contento che esista, \u00e8 interessante. E un grande grazie a tutti i contributori che scrivono patch per Patroni. Spero che Patroni diventi pi\u00f9 maturo, fantastico e funzionale con il tempo. \u00c8 gi\u00e0 funzionale, ma spero che diventi ancora migliore. Quindi, se pianificate di utilizzare Patroni, non abbiate paura. \u00c8 una buona soluzione, pu\u00f2 essere implementata e utilizzata. <\/p>\n<p><\/p>\n<p>Questo \u00e8 tutto. Se avete domande, chiedete.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Storie di fallimento di Patroni o come far crollare il tuo cluster PostgreSQL. Aleksej Lesovskij\" src=\"\/wp-content\/uploads\/2020\/07\/85c2fef2455999b48413c9fc3b235ed6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Domande<\/p>\n<p><\/p>\n<p><em>Grazie per il report! Se dopo il file manager dobbiamo comunque controllare attentamente, perch\u00e9 abbiamo bisogno di un file manager automatico?<\/em> <\/p>\n<p><\/p>\n<p>Perch\u00e9 \u00e8 una cosa nuova. Lavoriamo con esso da solo un anno. \u00c8 meglio essere cauti. Vogliamo entrarci e assicurarci che tutto funzioni come deve. \u00c8 un livello di sfiducia adulta \u2014 \u00e8 meglio ricontrollare e verificare. <\/p>\n<p><\/p>\n<p><em>Per esempio, ci siamo entrati e abbiamo controllato, giusto?<\/em><\/p>\n<p><\/p>\n<p>Non al mattino, di solito veniamo a sapere dell'auto-file manager praticamente subito. Riceviamo notifiche, vediamo che c'\u00e8 stato un auto-file manager. Entro quasi subito e controllo. Ma tutti questi controlli devono essere portati a un livello di monitoraggio. Se ci si rivolge a Patroni tramite REST API, c'\u00e8 la cronologia. Dalla cronologia si possono vedere i timestamp di quando \u00e8 avvenuto il file manager. Sulla base di questo si pu\u00f2 fare monitoraggio. Possiamo visualizzare la cronologia e vedere quanti eventi ci sono stati. Se abbiamo avuto pi\u00f9 eventi, significa che c'\u00e8 stato un auto-file manager. Possiamo andare e controllare. Oppure la nostra automazione nel monitoraggio ha verificato che tutte le repliche sono al loro posto, non ci sono ritardi e tutto va bene. <\/p>\n<p><\/p>\n<p><em>Grazie!<\/em><\/p>\n<p><\/p>\n<p><em>Grazie mille per il fantastico racconto! Se abbiamo spostato il cluster DCS lontano dal cluster Postgres, deve essere comunque manutenuto periodicamente? Quali sono le best practices per gestire parti del cluster DCS, spegnere alcune sezioni e cos\u00ec via? Come funziona l'intero sistema in questo caso? E in che modo si pu\u00f2 procedere con queste operazioni?<\/em><\/p>\n<p><\/p>\n<p>Per una azienda, era necessario sviluppare una matrice di problemi, per comprendere cosa succede se uno o pi\u00f9 componenti smettono di funzionare. Con questa matrice, esaminiamo sistematicamente tutti i componenti e creiamo scenari in caso di guasto. Pertanto, per ogni scenario di guasto \u00e8 possibile avere un piano d'azione per il ripristino. Nel caso del DCS, questo rientra come parte dell'infrastruttura standard. L'amministratore si occupa della gestione e ci affidiamo gi\u00e0 agli amministratori che lo gestiscono e alle loro capacit\u00e0 di ripararlo in caso di emergenza. Se il DCS non esiste affatto, lo implementiamo noi, ma non ne monitoriamo particolarmente il funzionamento, poich\u00e9 non siamo responsabili dell'infrastruttura, ma forniamo raccomandazioni su come e cosa monitorare. <\/p>\n<p><\/p>\n<p><em>Cio\u00e8, ho capito bene che devo disattivare Patroni, disattivare il file manager e disattivare tutto prima di fare qualcosa con gli host?<\/em><\/p>\n<p><\/p>\n<p>Questo dipende da quanti nodi abbiamo nel cluster DCS. Se ci sono molti nodi e se disattiviamo solo uno dei nodi (replica), il quorum rimane attivo nel cluster. E Patroni rimane funzionante. E non si attiva nulla. Se abbiamo operazioni complesse che coinvolgono pi\u00f9 nodi, la cui assenza potrebbe far crollare il quorum, allora s\u00ec, potrebbe avere senso mettere in pausa Patroni. Ha un comando corrispondente \u2013 patronictl pause, patronictl resume. Semplicemente lo mettiamo in pausa, e il file manager automatico non si attiva in quel momento. Facciamo la manutenzione sul cluster DCS, poi ripristiniamo la pausa e continuiamo a vivere.<\/p>\n<p><\/p>\n<p><em>Grazie mille!<\/em><\/p>\n<p><\/p>\n<p><em>Grazie mille per la presentazione! Come si sente il team di prodotto riguardo al fatto che i dati possano andare persi?<\/em> <\/p>\n<p><\/p>\n<p>Ai team di prodotto non importa, mentre ai team leader preoccupa. <\/p>\n<p><\/p>\n<p><em>Quali garanzie ci sono?<\/em><\/p>\n<p><\/p>\n<p>Le garanzie sono molto difficili. C'\u00e8 un rapporto di Aleksandr Kukushkin su \"Come calcolare RPO e RTO\", cio\u00e8 il tempo di ripristino e la quantit\u00e0 di dati che possiamo perdere. Penso che sia necessario trovare queste diapositive e studiarle. Da quanto ricordo, ci sono passi specifici su come calcolare queste cose. Quante transazioni possiamo perdere, quanti dati possiamo perdere. Come opzione, possiamo utilizzare la replica sincrona a livello di Patroni, ma \u00e8 un'arma a doppio taglio: abbiamo affidabilit\u00e0 dei dati oppure perdiamo in velocit\u00e0. Esiste la replica sincrona, ma questa non garantisce nemmeno una protezione al 100% contro la perdita di dati.<\/p>\n<p><\/p>\n<p><em>Alexey, grazie per la tua presentazione fantastica! Hai esperienza nell'uso di Patroni per la protezione a zero livelli? Cio\u00e8, in abbinamento con un standby sincrono? Questa \u00e8 la prima domanda. E la seconda domanda. Hai utilizzato diverse soluzioni. Noi abbiamo usato Repmgr, ma senza failover automatico e ora stiamo pianificando di collegare il failover automatico. Consideriamo Patroni come un'alternativa. Cosa puoi dire riguardo ai vantaggi rispetto a Repmgr?<\/em><\/p>\n<p><\/p>\n<p>Il primo quesito riguardava le repliche sincrone. Qui da noi nessuno utilizza la replicazione sincrona, perch\u00e9 \u00e8 motivo di paura (alcuni clienti la usano gi\u00e0 e non hanno riscontrato problemi di prestazioni \u2014 <em>Nota del relatore<\/em>). Tuttavia, abbiamo stabilito una regola: nel cluster di replicazione sincrona devono esserci almeno tre nodi, perch\u00e9 se abbiamo solo due nodi e uno dei due, master o replica, si guasta, Patroni porta quel nodo in modalit\u00e0 Standalone, cos\u00ec l'applicazione continua a funzionare. In questo caso, ci sono rischi di perdita di dati.<\/p>\n<p><\/p>\n<p>Per quanto riguarda la seconda domanda, abbiamo utilizzato Repmgr e continuiamo ad usarlo per alcuni clienti per motivi storici. Cosa si pu\u00f2 dire? In Patroni l'auto failover \u00e8 incluso di default, mentre in Repmgr l'auto failover \u00e8 una funzionalit\u00e0 aggiuntiva che deve essere attivata. \u00c8 necessario avviare il demone Repmgr su ogni nodo e allora possiamo configurare l'auto failover. <\/p>\n<p><\/p>\n<p>Repmgr controlla se i nodi Postgres sono attivi. I processi di Repmgr verificano l'esistenza reciproca, il che non \u00e8 un approccio molto efficace, poich\u00e9 possono verificarsi casi complessi di isolamento di rete in cui un grande cluster di Repmgr pu\u00f2 dividersi in pi\u00f9 piccoli e continuare a funzionare. Non seguo pi\u00f9 Repmgr da un po', forse hanno risolto questo problema... o forse no. Tuttavia, esternalizzare le informazioni sullo stato del cluster in DCS, come fa Stolon o Patroni, \u00e8 l'alternativa pi\u00f9 valida. <\/p>\n<p><\/p>\n<p><em>Alexey, ho una domanda, potrebbe essere un po' basilare. In uno dei primi esempi DCS, hai spostato da una macchina locale a un nodo remoto. Comprendiamo che la rete ha le sue peculiarit\u00e0 e vive di vita propria. Cosa succede se per qualche motivo il cluster DCS diventa inaccessibile? Non dir\u00f2 le cause, possono essere molte: da problemi legati ai tecnici di rete a vere e proprie difficolt\u00e0.<\/em> <\/p>\n<p><\/p>\n<p>Non l'ho detto ad alta voce, ma il cluster DCS deve essere anch'esso resistente ai guasti, cio\u00e8 deve avere un numero dispari di nodi per permettere la formazione del quorum. Cosa succede se il cluster DCS diventa non disponibile o non riesce a formare il quorum, ad esempio in caso di una divisione di rete o guasto di nodi? In tal caso, il cluster Patroni passa alla modalit\u00e0 di sola lettura. Il cluster Patroni non pu\u00f2 determinare lo stato del cluster e cosa deve fare. Non riesce a contattare il DCS per salvare il nuovo stato del cluster, quindi l'intero cluster passa alla modalit\u00e0 di sola lettura. E aspetta un intervento manuale da parte dell'operatore o il ripristino del DCS.<\/p>\n<p><\/p>\n<p><em>In sostanza, il DCS diventa per noi un servizio altrettanto importante quanto il database stesso?<\/em><\/p>\n<p><\/p>\n<p>S\u00ec, in molte aziende moderne il Service Discovery \u00e8 una parte essenziale dell'infrastruttura. Viene implementato anche prima che venga creata la base dati nell'infrastruttura. In parole semplici, si avvia l'infrastruttura, si realizza nel data center e subito c'\u00e8 il Service Discovery. Se si tratta di Consul, pu\u00f2 essere costruito anche su di esso il DNS. Se si tratta di Etcd, potrebbe far parte di un cluster Kubernetes, dove verr\u00e0 distribuito tutto il resto. Penso che il Service Discovery sia gi\u00e0 una parte integrante delle infrastrutture moderne, e ci si pensa molto prima rispetto alle basi dati. <\/p>\n<p><\/p>\n<p><em>Grazie!<\/em><\/p>\n<p>Fonte: <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 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\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\" \/>\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\/it\/blog\/administrirovanie\/patroni-failure-stories-or-how-to-crash-your-postgresql-cluster-aleksej-lesovskij\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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:description\" content=\"\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\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/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 Failure Stories o Come far crashare il tuo cluster PostgreSQL. Aleksey Lesovskiy | ProHoster","description":"L'obiettivo principale di Patroni \u00e8 garantire l'alta disponibilit\u00e0 per PostgreSQL. Ma Patroni \u00e8 solo un template, non uno strumento pronto all'uso (come specificato nella documentazione). A prima vista, configurando Patroni in un laboratorio di test, si pu\u00f2 notare quanto sia uno strumento eccellente e come gestisca facilmente i nostri tentativi di far crashare il cluster. Tuttavia, nella pratica in produzione","canonical_url":"https:\/\/prohoster.info\/it\/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":"it_IT","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:description":"\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","og:url":"https:\/\/prohoster.info\/it\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/90103","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=90103"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/90103\/revisions"}],"predecessor-version":[{"id":158759,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/90103\/revisions\/158759"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/90104"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=90103"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=90103"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=90103"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}