{"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":"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 fornire alta disponibilit\u00e0 per PostgreSQL. Ma Patroni \u00e8 solo un template, non uno strumento gi\u00e0 pronto (come si dice nella documentazione). A prima vista, configurando Patroni in un laboratorio di test, si pu\u00f2 vedere quanto sia uno strumento magnifico e come gestisca facilmente i nostri tentativi di compromettere il cluster. Tuttavia, nella pratica, nell'ambiente di produzione, tutto non sempre avviene cos\u00ec bene ed elegantemente come nel laboratorio di test.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/ff445e6d76a2ad46a232b705e104446f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Racconter\u00f2 un po' di me. Ho iniziato come amministratore di sistema. Ho lavorato nello sviluppo web. Dal 2014 lavoro in Data Egret. L'azienda si occupa di consulenze nel settore di Postgres. E ci occupiamo proprio di Postgres, lavorando con Postgres ogni giorno, quindi abbiamo una variet\u00e0 di esperienza legata all'operativit\u00e0. <\/p>\n<p><\/p>\n<p>E alla fine del 2018 abbiamo iniziato a utilizzare lentamente Patroni. Abbiamo accumulato una certa esperienza. In qualche modo l'abbiamo diagnosticato, ottimizzato, siamo arrivati alle nostre migliori pratiche. E in questa relazione ne parler\u00f2.<\/p>\n<p><\/p>\n<p>Oltre a Postgres, amo Linux. Mi piace esplorarlo e sperimentare, mi piace compilare i kernel. Amo la virtualizzazione, i container, Docker, Kubernetes. Tutto questo mi interessa, perch\u00e9 riflette le mie vecchie abitudini da amministratore. Mi piace occuparmi del monitoraggio. E mi piacciono le cose di Postgres legate all'amministrazione, cio\u00e8 replica, backup. E nel mio tempo libero scrivo in Go. Non sono un ingegnere del software, scrivo solo per me stesso in Go. E questo mi porta gioia. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/02cfd9293af5a8410c91e39afe2c75e6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Penso che molti di voi sappiano che in Postgres non c'\u00e8 HA (Alta Disponibilit\u00e0) di default. Per ottenere HA \u00e8 necessario installare qualcosa, configurarlo, impegnarsi e ottenerlo. <\/li>\n<li>Ci sono diversi strumenti e Patroni \u00e8 uno di essi, che risolve 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, vedere come Patroni li gestisce. E vedremo che tutto funziona magnificamente. <\/li>\n<li>Ma nella pratica ci siamo imbattuti in vari problemi. E parler\u00f2 di questi problemi.<\/li>\n<li>Racconter\u00f2 come li abbiamo diagnosticati, cosa abbiamo aggiustato \u2013 se questo ci ha aiutato o meno. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/7126b45b40dd08521e80a3c150382bec.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Non racconter\u00f2 come installare Patroni, perch\u00e9 \u00e8 possibile cercare su internet, e si possono guardare i file di configurazione per capire come tutto questo viene avviato e configurato. Si pu\u00f2 approfondire nelle architetture, trovando informazioni su questo in rete. <\/li>\n<li>Non parler\u00f2 delle esperienze altrui. Parler\u00f2 solo dei problemi che abbiamo incontrato noi. <\/li>\n<li>E non parler\u00f2 dei problemi al di fuori di Patroni e PostgreSQL. Se, ad esempio, ci sono problemi legati al bilanciamento, quando il nostro cluster si \u00e8 rotto, non ne parler\u00f2. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/3f8d179e7c78ce83e8842ef5c72fe30d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E una piccola premessa prima di cominciare la nostra presentazione. <\/p>\n<p><\/p>\n<p>Tutti questi problemi che abbiamo affrontato si sono presentati nei primi 6-7-8 mesi di utilizzo. Col tempo, siamo giunti ai nostri migliori criteri interni. E i problemi sono scomparsi. Pertanto, la presentazione \u00e8 stata annunciata circa sei mesi fa, quando tutto questo era fresco nella mia mente e lo ricordavo perfettamente. <\/p>\n<p><\/p>\n<p>Durante la preparazione della presentazione, ho gi\u00e0 rivenuto vecchi post mortem e guardato i log. E parte dei dettagli potrebbe essersi dimenticata, oppure alcuni dettagli potrebbero non essere stati esplorati a sufficienza durante l'analisi dei problemi, quindi in alcuni punti potrebbe sembrare che i problemi non siano stati trattati completamente, o che ci sia una mancanza di informazioni. Pertanto, vi chiedo di scusarmi per questo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 costruire HA. Cos\u00ec \u00e8 scritto nella documentazione. E dal mio punto di vista, \u00e8 un'ottima precisazione. Patroni non \u00e8 una panacea che risolver\u00e0 tutti i vostri problemi, ovvero \u00e8 necessario fare uno sforzo affinch\u00e9 inizi a funzionare e a portare benefici. <\/li>\n<li>\u00c8 un servizio agente che viene installato su ogni servizio con database, e che \u00e8 una sorta di sistema di init per il vostro Postgres. Avvia Postgres, lo ferma, lo riavvia, modifica la configurazione e cambia la topologia del vostro cluster. <\/li>\n<li>Pertanto, per memorizzare lo stato del cluster, la sua attuale rappresentazione, come appare, \u00e8 necessario un certo tipo di archiviazione. E da questo punto di vista, Patroni ha scelto di memorizzare lo stato in un sistema esterno. Si tratta di un sistema di archiviazione della configurazione distribuita. Possono essere Etcd, Consul, ZooKeeper, oppure Etcd di Kubernetes, quindi uno di questi opzioni. <\/li>\n<li>Una delle caratteristiche di Patroni \u00e8 che l'auto-failover \u00e8 incluso di default, basta configurarlo. Se confrontiamo con Repmgr, il failover viene fornito a parte. Con Repmgr otteniamo lo switchover, ma se vogliamo l'auto-failover, dobbiamo configurarlo separatamente. In Patroni l'auto-failover \u00e8 gi\u00e0 incluso di default.<\/li>\n<li>E ci sono molte altre cose. Ad esempio, la gestione delle configurazioni, il provisioning di nuove repliche, il backup, ecc. Ma questo \u00e8 al di fuori della presentazione, non ne parler\u00f2. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/fed0f1ce931df99ca76ae1116f8098cc.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E un piccolo riassunto \u00e8 che l'obiettivo principale di Patroni \u00e8 di gestire bene e in modo affidabile l'auto-failover, affinch\u00e9 il cluster rimanga operativo e l'applicazione non noti cambiamenti nella topologia del cluster. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 prima avevamo Postgres, ora con Patroni abbiamo Patroni stesso, un DCS in cui \u00e8 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 guastarsi:<\/p>\n<p><\/p>\n<ul>\n<li>Pu\u00f2 guastarsi Postgres. Pu\u00f2 essere il master o una replica, uno dei due pu\u00f2 smettere di funzionare. <\/li>\n<li>Pu\u00f2 guastarsi lo stesso Patroni. <\/li>\n<li>Pu\u00f2 guastarsi il DCS, dove \u00e8 memorizzato lo stato.<\/li>\n<li>E pu\u00f2 guastarsi la rete. <\/li>\n<\/ul>\n<p><\/p>\n<p>Tutti questi aspetti li tratter\u00f2 nella presentazione. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/1aeaf46d37bf1935b514b0581e0dbd0b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Esaminer\u00f2 i casi in ordine di complessit\u00e0, non dal punto di vista del numero di componenti coinvolti, ma da quello delle sensazioni soggettive, ovvero se un caso \u00e8 stato difficile o facile da analizzare. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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. \u00c8 il caso in cui abbiamo preso un cluster di database e abbiamo configurato il nostro archivio DCS su quel cluster. Questo \u00e8 l'errore pi\u00f9 comune. \u00c8 un errore di architettura, ossia combinare diversi componenti nello stesso posto. <\/p>\n<p><\/p>\n<p>Quindi, si \u00e8 verificato un failover, andiamo a vedere cosa \u00e8 successo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 in cui lo stato del cluster \u00e8 cambiato. <\/p>\n<p><\/p>\n<p>Ma il failover non avviene sempre in un solo momento, cio\u00e8 non occupa una singola unit\u00e0 di tempo, pu\u00f2 prolungarsi. Pu\u00f2 durare nel tempo.<\/p>\n<p><\/p>\n<p>Quindi ha un tempo di inizio e un tempo di fine, cio\u00e8 \u00e8 un evento prolungato. E dividiamo 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 in questa linea temporale. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/a0ed61afe55d1a157147e0d80b17e5d1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E per prima cosa, quando si \u00e8 verificato il failover, cerchiamo la causa di cosa \u00e8 successo, cosa ha causato il failover. <\/p>\n<p><\/p>\n<p>Se guardiamo ai log, avremo i classici log di Patroni. In essi ci dice che il server \u00e8 diventato master e il ruolo di master \u00e8 passato a questo nodo. Qui \u00e8 evidenziato. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/9998c69f7d0d4358b277f4e0e7b4350f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Poi dobbiamo capire perch\u00e9 si \u00e8 verificato il failover, cio\u00e8 quali eventi si sono verificati che hanno costretto il ruolo di master a trasferirsi da un nodo all'altro. E in questo caso \u00e8 tutto semplice. Abbiamo un errore di interazione con il sistema di archiviazione. Il master ha capito che non pu\u00f2 lavorare con DCS, cio\u00e8 si \u00e8 presentato un problema di interazione. E dice che non pu\u00f2 pi\u00f9 essere master e si dimette. Questa riga \"demoted self\" parla proprio di questo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/4a8eca27689546b4b0fc3c666a3c37c4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Se guardiamo agli eventi che hanno preceduto il failover, possiamo vedere le cause che hanno creato problemi per il proseguimento del lavoro del master. <\/p>\n<p><\/p>\n<p>Se guardiamo ai log di Patroni, vedremo che ci sono molti tipi di errori, timeout, cio\u00e8 l'agente Patroni non pu\u00f2 lavorare con DCS. In questo caso \u00e8 l'agente Consul, con cui si comunica tramite la porta 8500. <\/p>\n<p><\/p>\n<p>E il problema qui \u00e8 che Patroni e il database sono in esecuzione sulla stessa host. E su questo stesso nodo sono stati avviati i server Consul. Creando un carico sul server, abbiamo creato 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=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 \u00e8 diminuito, il nostro Patroni \u00e8 riuscito a comunicare di nuovo con gli agenti. Il lavoro normale \u00e8 ripreso. E lo stesso server Pgdb-2 \u00e8 tornato a essere master. Cio\u00e8 c'\u00e8 stata una piccola fluttuazione, per la quale il nodo ha rinunciato ai diritti di master e poi li ha ripresi, cio\u00e8 tutto \u00e8 tornato come era. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/131b93e0bd83099e1b99b53742419e13.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E questo pu\u00f2 essere considerato come un falso attivazione, oppure pu\u00f2 essere interpretato che Patroni ha fatto tutto correttamente. Cio\u00e8 ha capito che non poteva mantenere lo stato del cluster e ha rinunciato ai diritti.<\/p>\n<p><\/p>\n<p>E qui il problema \u00e8 sorto dal fatto che i server Consul si trovano sullo stesso hardware delle basi. Pertanto, qualsiasi carico: sia esso sul disco o sui processori, influisce anche sull'interazione con il cluster Consul.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 doveva convivere, abbiamo creato un cluster separato per Consul. E Patroni stava gi\u00e0 funzionando con un Consul separato, cio\u00e8 c'era un cluster Postgres separato, un cluster Consul separato. Questa \u00e8 una guida di base su come distribuire e mantenere tutte queste cose, affinch\u00e9 non coesistano. <\/p>\n<p><\/p>\n<p>Come opzione, si possono modificare i parametri ttl, loop_wait, retry_timeout, cio\u00e8 si pu\u00f2 cercare di superare questi picchi di carico a breve termine aumentando questi parametri. Ma questa non \u00e8 la soluzione pi\u00f9 adatta, perch\u00e9 questo carico potrebbe durare nel tempo. E semplicemente supereremmo i limiti di questi parametri. E questo potrebbe non aiutare molto. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/c51f35dcd88b1c792acec231c0c6c66c.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Il primo problema, come avete capito, \u00e8 semplice. Abbiamo messo DCS insieme con il database, e abbiamo ottenuto un problema. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/cc2a98d9790441577fb4080406cbc53f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Il secondo problema \u00e8 simile al primo. \u00c8 simile in quanto abbiamo di nuovo problemi di interazione con il sistema DCS.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/e5c01b105adca48cc620085db8dd2d2b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Se guardiamo i log, vedremo che abbiamo di nuovo un errore di comunicazione. E Patroni dice che non riesce a interagire con DCS, quindi il master attuale passa in modalit\u00e0 replica.<\/p>\n<p><\/p>\n<p>Il vecchio master diventa replica, qui Patroni agisce come dovrebbe. Avvia pg_rewind per tornare indietro nel log delle transazioni e poi connettersi al nuovo master, e quindi raggiungere il nuovo master. Qui Patroni agisce come deve. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 che ha preceduto il file system, cio\u00e8 quegli errori che hanno causato l'insorgere del file system. E in questo senso i log di Patroni sono piuttosto facili da lavorare. Scrive gli stessi messaggi a intervalli regolari. E se iniziamo a scorrere rapidamente questi log, vedremo che i log sono cambiati, il che significa che sono iniziati dei problemi. Torniamo rapidamente a quel punto e vediamo cosa sta succedendo. <\/p>\n<p><\/p>\n<p>E in una situazione normale, i log appaiono pi\u00f9 o meno cos\u00ec. Viene controllato il proprietario del blocco. E se il proprietario, ad esempio, \u00e8 cambiato, possono accadere eventi a cui Patroni deve reagire. Ma in questo caso va tutto bene. Stiamo cercando il punto in cui sono iniziati gli errori. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/f48ebd22a405f5b2900621451c68f543.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E facendo scorrere fino a quel punto in cui gli errori hanno iniziato a comparire, vediamo che abbiamo avuto un auto-failover. E 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 sia successo l\u00ec. <\/p>\n<p><\/p>\n<p>Circa allineando il momento del failover e il tempo nei log di Consul, vediamo che i nostri vicini nel cluster Consul hanno iniziato a dubitare dell'esistenza degli altri membri del cluster Consul.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/63b02ac5b4f5a34a2822f1eee2b1f2f8.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E se guardiamo anche i log di altri agenti Consul, possiamo vedere che l\u00ec sta accadendo qualche tipo di collasso di rete. E tutti i membri del cluster Consul dubitano dell'esistenza reciproca. E questo ha provocato il failover. <\/p>\n<p><\/p>\n<p>Se guardiamo a cosa \u00e8 successo prima di questi errori, possiamo vedere che ci sono vari errori, ad esempio, scadenza, errore RPC, cio\u00e8 chiaramente ci sono problemi nell'interazione tra i membri del cluster Consul. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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, in piedi al podio, \u00e8 facile dirlo. Tuttavia, le circostanze sono tali che non sempre il cliente pu\u00f2 permettersi di riparare la rete. Pu\u00f2 vivere in un Data Center e potrebbe non avere la possibilit\u00e0 di riparare la rete, influenzare l'hardware. E quindi sono necessarie altre opzioni. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/1dbdb66233acc3bc321a30a1c5fe14f9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Le opzioni ci sono:<\/p>\n<p><\/p>\n<ul>\n<li>L'opzione pi\u00f9 semplice, che \u00e8 scritta, penso, anche nella documentazione, \u00e8 disattivare i controlli di Consul, cio\u00e8 semplicemente passare un array vuoto. E diciamo all'agente Consul di non utilizzare alcun controllo. Grazie a questi controlli possiamo ignorare queste tempeste di rete e non avviare il failover. <\/li>\n<li>Un'altra opzione \u00e8 controllare il raft_multiplier. Questo \u00e8 un parametro del server Consul stesso. Di default \u00e8 impostato su 5. Questo valore \u00e8 consigliato dalla documentazione per gli ambienti di staging. Sostanzialmente influisce sulla frequenza dello scambio di messaggi tra i membri della rete Consul. Di fatto, questo parametro influisce sulla velocit\u00e0 della comunicazione tra i membri del cluster Consul. E per la produzione si consiglia di ridurlo affinch\u00e9 i nodi scambino messaggi pi\u00f9 frequentemente. <\/li>\n<li>Un'altra opzione che abbiamo iniziato a usare \u00e8 quella di aumentare la priorit\u00e0 dei processi di Consul rispetto ad altri processi per il pianificatore dei processi del sistema operativo. Esiste un parametro chiamato \"nice\", che determina esattamente la priorit\u00e0 dei processi che il pianificatore OS considera durante la pianificazione. Abbiamo deciso di ridurre il valore di nice per gli agenti di Consul, cio\u00e8 di aumentare la priorit\u00e0, in modo che il sistema operativo fornisca ai processi di Consul pi\u00f9 tempo per lavorare e per 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 noi discutiamo regolarmente su quale sia meglio, Etcd o Consul. Ma di solito concordiamo 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 di Consul avviene tramite questo agente. E questo agente diventa il collo di bottiglia. Se succede qualcosa all'agente, Patroni non pu\u00f2 pi\u00f9 lavorare con il cluster di Consul. E questo \u00e8 un problema. In Etcd non c'\u00e8 un agente. Patroni pu\u00f2 lavorare direttamente con l'elenco dei server Etcd e comunicare con essi. In questo senso, se nella vostra azienda utilizzate Etcd, allora probabilmente sar\u00e0 una scelta migliore rispetto a Consul. Ma per i nostri clienti siamo sempre limitati a ci\u00f2 che scelgono e utilizzano. E per la maggior parte dei casi, Consul \u00e8 utilizzato da tutti i clienti. <\/li>\n<li>E l'ultimo punto \u00e8 riesaminare i valori dei parametri. Possiamo aumentare questi parametri sperando che i nostri problemi di rete a breve termine siano brevi e non superino l'intervallo di questi parametri. In questo modo possiamo ridurre l'aggressivit\u00e0 di Patroni nell'eseguire il failover automatico se si verificano problemi di rete.<\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 situazione potrebbe sembrare normale. Abbiamo un master, abbiamo una replica, non ci sono ritardi nella replicazione. 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=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 capire perch\u00e9 \u00e8 scomparsa e riportarla indietro, ripristinarla. E torniamo di nuovo ai log per vedere perch\u00e9 si \u00e8 verificato l'auto-failover.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 master. Qui va tutto bene. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/b86ccea68b0c6013a23bbd2804e48320.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E dobbiamo gi\u00e0 guardare la replica che \u00e8 andata gi\u00f9 e che non \u00e8 nel cluster. Apriamo i log di Patroni e vediamo che durante il tentativo di connessione al cluster si \u00e8 verificato un problema durante la fase di pg_rewind. Per connettersi al cluster \u00e8 necessario ripristinare il log delle transazioni, richiedere il log delle transazioni necessario dal master e seguirlo per raggiungere il master. <\/p>\n<p><\/p>\n<p>In questo caso non abbiamo il log delle transazioni e la replica non pu\u00f2 avviarsi. Di conseguenza, fermiamo Postgres con un errore. E per questo non \u00e8 nel cluster. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 nel cluster e perch\u00e9 non ci sono log. Andiamo sul nuovo master e verifichiamo cosa ha nei log. Si scopre che durante il pg_rewind si \u00e8 verificato un checkpoint. E parte dei vecchi log delle transazioni \u00e8 stata semplicemente rinominata. Quando il vecchio master ha cercato di connettersi al nuovo master e richiedere questi log, erano gi\u00e0 stati rinominati, semplicemente non c'erano.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/f2d5c37324f9436b2bdad1290612d86f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ho confrontato i timestamp quando si sono verificati questi eventi. E l\u00ec la differenza \u00e8 di appena 150 millisecondi, ossia, in 369 millisecondi si \u00e8 concluso il checkpoint e i segmenti WAL sono stati rinominati. E letteralmente 517 millisecondi dopo, quindi dopo 150 millisecondi, \u00e8 iniziato il rewind sulla vecchia replica. Cio\u00e8, ci sono voluti solo 150 millisecondi perch\u00e9 la replica non riuscisse a connettersi e avviarsi. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/99dd80deb8466bfc3aff568456e07102.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Quali sono le opzioni?<\/p>\n<p><\/p>\n<p>Inizialmente abbiamo utilizzato gli slot di replica. Ci sembrava una buona idea. Anche se nella prima fase di utilizzo abbiamo disattivato gli slot. Ci sembrava che, se gli slot accumulassero molti segmenti WAL, potremmo far cadere il master. Sarebbe crollato. Dopo aver sopportato un po' di tempo senza slot, abbiamo capito che ne avevamo bisogno, quindi li abbiamo riattivati. <\/p>\n<p><\/p>\n<p>Ma qui c'\u00e8 un problema: quando il master passa alla replica, elimina gli slot e con gli slot vengono eliminati i segmenti WAL. Per escludere l'emergere di questo problema, abbiamo deciso di aumentare il parametro wal_keep_segments. Di default sono 8 segmenti. Lo abbiamo aumentato a 1.000 e abbiamo controllato quanto spazio libero avevamo. Abbiamo riservato 16 gigabyte per wal_keep_segments. Cio\u00e8, durante il passaggio abbiamo sempre a disposizione su tutti i nodi 16 gigabyte di registri di transazioni.<\/p>\n<p><\/p>\n<p>Inoltre, questo \u00e8 particolarmente rilevante per attivit\u00e0 di manutenzione prolungate. Supponiamo di dover aggiornare una delle repliche. Vogliamo spegnerla. Dobbiamo aggiornare il software, forse il sistema operativo, o qualcos'altro. E quando spegniamo la replica, per questa replica viene anche eliminato lo slot. Se utilizziamo un piccolo wal_keep_segments, durante l'assenza prolungata della replica, i registri di transazioni verranno riprodotti. Riattraeremo la replica, essa richieder\u00e0 i registri di transazioni in cui si era fermata, ma sul master potrebbero non essere disponibili. E la replica non potr\u00e0 collegarsi. Perci\u00f2 manteniamo una grande riserva di registri.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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. L\u00ec sono gi\u00e0 in corso progetti. <\/p>\n<p><\/p>\n<p>Si \u00e8 verificato un failover. Siamo entrati e abbiamo controllato: tutto a posto, le repliche sono al loro posto, non ci sono ritardi nella replica. Non ci sono errori nei registri, tutto va bene. <\/p>\n<p><\/p>\n<p>Il team di prodotto dice che dovrebbero esserci dei dati, ma noi li vediamo in una fonte e non nel database. Dobbiamo capire cosa \u00e8 successo con loro. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 capito subito, ma siamo andati a vedere cosa stava succedendo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 determinare la quantit\u00e0 di registri di transazioni che \u00e8 stata persa.<\/p>\n<p><\/p>\n<p>Il nostro vecchio master si \u00e8 riavviato. E nel caricamento automatico era registrato Patroni. Patroni si \u00e8 avviato. Subito dopo ha avviato Postgres. Pi\u00f9 precisamente, prima di avviare Postgres e prima di farlo diventare una replica, Patroni ha avviato il processo pg_rewind. Di conseguenza, ha cancellato parte dei log delle transazioni, ha scaricato nuovi log e si \u00e8 connesso. Qui Patroni ha funzionato in modo impeccabile, cio\u00e8 come doveva. Il nostro cluster \u00e8 stato ripristinato. Avevamo 3 nodi, dopo il failover 3 nodi - tutto fantastico. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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. Dobbiamo capire quanto abbiamo perso. Stiamo cercando il momento esatto in cui \u00e8 avvenuto il rewind. Possiamo trovarlo grazie a queste registrazioni nel registro. \u00c8 partito il rewind, ha fatto qualcosa e si \u00e8 concluso.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 registro delle transazioni in cui si \u00e8 fermato il vecchio master. In questo caso, \u00e8 questa marca. E abbiamo bisogno di un secondo marcatore, cio\u00e8 della distanza che separa il vecchio master dal nuovo. <\/p>\n<p><\/p>\n<p>Prendiamo il normale pg_wal_lsn_diff e confrontiamo queste due marche. In questo caso otteniamo 17 megabyte. Se siano tanti o pochi, ognuno lo decide per s\u00e9. Perch\u00e9 per qualcuno 17 megabyte sono pochi, mentre per altri sono tanti e inaccettabili. Ognuno, quindi, definisce individualmente in base alle esigenze del proprio business. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 stessi? <\/p>\n<p><\/p>\n<p>In primo luogo, dobbiamo decidere se abbiamo sempre bisogno dell'avvio automatico di Patroni dopo il riavvio del sistema. Spesso capita che dobbiamo accedere al vecchio master, vedere quanto si \u00e8 spostato. Potrebbe essere necessario ispezionare i segmenti del registro delle transazioni, vedere cosa c'\u00e8. E capire se possiamo perdere questi dati o se dobbiamo avviare il vecchio master in modalit\u00e0 standalone per recuperare questi dati. <\/p>\n<p><\/p>\n<p>E solo dopo questo dobbiamo prendere decisioni su se possiamo scartare questi dati o se possiamo recuperarli, collegando questo nodo come replica nel nostro cluster.<\/p>\n<p><\/p>\n<p>Inoltre, c'\u00e8 il parametro \u00abmaximum_lag_on_failover\u00bb. Di default, se non ricordo male, questo parametro ha un valore di 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, allora questa replica non partecipa alle elezioni. E se improvvisamente 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 utile, che impedisce di perdere molti dati. <\/p>\n<p><\/p>\n<p>Ma qui c'\u00e8 il problema: il lag di replicazione nel cluster Patroni e DCS viene aggiornato con un determinato intervallo. Credo che il valore di ttl di default sia di 30 secondi.<\/p>\n<p><\/p>\n<p>Di conseguenza, pu\u00f2 esistere una situazione in cui il lag di replica per le repliche in DCS \u00e8 uno, mentre in realt\u00e0 potrebbe esserci un lag completamente diverso o addirittura non esserci affatto lag, cio\u00e8 questa cosa non \u00e8 in tempo reale. E non riflette sempre la situazione reale. Non vale la pena costruire logiche complesse su di essa. <\/p>\n<p><\/p>\n<p>E il rischio di perdite di dati rimane sempre. E nel peggiore dei casi una formula, mentre nel caso medio un'altra formula. Cio\u00e8, quando pianifichiamo l'implementazione di Patroni e valutiamo quanti dati possiamo perdere, dobbiamo basarci su queste formule e avere un'idea di quanti dati possiamo perdere. <\/p>\n<p><\/p>\n<p>E c'\u00e8 una buona notizia. Quando il vecchio master si allontana, pu\u00f2 farlo a causa di alcuni processi in background. Cio\u00e8, c'\u00e8 stato qualche autovacuum, ha scritto dei dati, li ha salvati nel log delle transazioni. E quei dati possiamo tranquillamente ignorarli e perderli. Non c'\u00e8 alcun problema in questo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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, pertanto \u00e8 necessario scegliere un nuovo master. La replica si considera incapacit\u00e0 di partecipare alle votazioni. E si ritira dalla corsa per diventare leader. Aspetta che venga scelto un nuovo master per potersi connettere a lui. Questo \u00e8 un ulteriore passo per evitare la perdita di dati.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/c32f26e7526e1873f3bfd7d3693fcc72.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Qui il nostro team di prodotto ha scritto che il loro prodotto ha problemi quando lavora con Postgres. Nel frattempo, non \u00e8 possibile accedere al master stesso, poich\u00e9 non \u00e8 disponibile tramite SSH. E non si verifica neanche un 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 si poteva effettuare un auto-failover manuale, come ora capisco. E dopo il riavvio andremo a vedere cosa \u00e8 successo con l'attuale master. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/95efb82e0647a396a21683cd53a69547.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nel frattempo, sapevamo gi\u00e0 che avevamo problemi con i dischi, cio\u00e8 gi\u00e0 dal monitoraggio sapevamo dove scavare e cosa cercare. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/367aaab607d833d96a573ddbbbced502.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Siamo entrati nel log di postgres e abbiamo iniziato a vedere cosa stava succedendo. Abbiamo notato commit che durano da un secondo a tre secondi, il che non va affatto bene. Abbiamo visto che l'autovacuum si avvia molto lentamente e in modo strano. E abbiamo trovato file temporanei sul disco. Cio\u00e8, questi sono tutti indicatori di problemi con i dischi. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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) e abbiamo visto che ci sono problemi con uno dei dischi. Il sottosistema disk era un RAID software. Abbiamo guardato \/proc\/mdstat e abbiamo notato che manca un disco. Cio\u00e8, qui abbiamo un RAID di 8 dischi, e ci manca uno. Se si guarda attentamente la diapositiva, si pu\u00f2 vedere che manca sde. In termini pratici, abbiamo perso un disco. Questo ha innescato problemi con i dischi, e anche le applicazioni hanno avuto problemi nel funzionamento con il cluster Postgres.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/4b09b3aa761cb504fa79173ef280faac.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In questo caso, Patroni non ci avrebbe aiutato, perch\u00e9 Patroni non ha il compito di monitorare lo stato del server e dello stato del disco. Dobbiamo monitorare tali situazioni con un monitoraggio esterno. Abbiamo rapidamente aggiunto il monitoraggio dei dischi al monitoraggio esterno. <\/p>\n<p><\/p>\n<p>E ci siamo chiesti se il fencing o un watchdog software potessero aiutarci. Abbiamo pensato che probabilmente non ci sarebbero stati di aiuto in questo caso, perch\u00e9 durante i problemi Patroni continuava a interagire con il cluster DCS e non vedeva alcun problema. Cio\u00e8, dal punto di vista di DCS e Patroni, tutto andava bene con il cluster, anche se in realt\u00e0 c'erano problemi con il disco e problemi di disponibilit\u00e0 del database. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/15fdac78535355d4eb889efcc27efc46.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>A mio parere, questo \u00e8 uno dei problemi pi\u00f9 strani che ho esplorato; ho passato molto tempo a esaminarlo, ho riletto molti log e l'ho definito cluster-simulator. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/b5259774931c290eda6673deb14b6c48.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Il problema era che il vecchio master non poteva diventare una replica normale, cio\u00e8 Patroni lo avviava, Patroni mostrava che quel nodo era presente come replica, ma allo stesso tempo non era una replica normale. Ora vedrete perch\u00e9. Questo mi \u00e8 rimasto dall'analisi di quel problema. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/c35a5d102a46764bbf96e5a75ee88171.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E come \u00e8 iniziato tutto? \u00c8 iniziato, come nel problema precedente, con dei rallentamenti nei dischi. Avevamo commit di uno o due al secondo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/435c1b350a89f288e0e10ca9d5a2ec6e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ci sono stati interruzioni delle connessioni, cio\u00e8 i clienti venivano disconnessi. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/920cb1f3f3b40578e15e6ff711e85c50.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ci sono stati blocchi di varia gravit\u00e0. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/285d6292d89b928a85e95602ee57d38a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E, di conseguenza, il sottosistema disk non era molto reattivo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 misteriosa 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 graciale, in cui aspettiamo che tutti i clienti si disconnettano autonomamente. <\/li>\n<li>C'\u00e8 la modalit\u00e0 veloce, in cui costringiamo i clienti a disconnettersi perch\u00e9 stiamo per spegnere. <\/li>\n<li>E immediate. In questo caso, immediate non informa nemmeno i clienti che devono disconnettersi, si spegne semplicemente senza preavviso. E a tutti i clienti viene gi\u00e0 inviato dal sistema operativo un messaggio RST (messaggio TCP che indica 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 in background di Postgres non si inviano tali segnali tra loro, cio\u00e8 \u00e8 un kill-9. Non si inviano messaggi del genere tra di loro, ma reagiscono solo a ci\u00f2, cio\u00e8 si tratta di un riavvio di emergenza di Postgres. Chi lo ha inviato, non lo so. <\/p>\n<p><\/p>\n<p>Ho guardato con il comando \u00ablast\u00bb e ho visto una persona che ha effettuato l'accesso a questo server insieme a noi, ma ho esitato a porre la domanda. Forse \u00e8 stato un kill -9. Avrei visto il kill -9 nei log, poich\u00e9 Postgres scrive che ha ricevuto il kill -9, ma non l'ho visto nei log. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/fe8e844649cea3384ebfde86e36eba44.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Continuando a indagare, ho notato che Patroni non ha scritto nel log per un periodo piuttosto lungo \u2013 54 secondi. E se si confrontano i due timestamp, qui non ci sono stati messaggi per circa 54 secondi. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/ffb1c4db3d7de591d77d56ed2fcc4f2a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E in quel periodo si \u00e8 verificato un failover automatico. Patroni ha funzionato bene qui. Il nostro vecchio master era non disponibile, qualcosa stava accadendo con esso. E sono iniziate le elezioni per un nuovo master. Qui tutto ha funzionato bene. Il nostro pgsql01 \u00e8 diventato il nuovo leader. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 una seconda replica. E con la seconda replica c'erano proprio dei problemi. Stava cercando di riconfigurarsi. Come capisco, stava cercando di cambiare recovery.conf, riavviare Postgres e connettersi al nuovo master. Ogni 10 secondi invia messaggi che sta provando, ma non riesce. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/381818f189e19c3e1154074b4652f837.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E durante questi tentativi, al vecchio master arriva un segnale di immediate-shutdown. Il master si riavvia. E anche il recovery viene interrotto, perch\u00e9 il vecchio master va in riavvio. Cio\u00e8, la replica non pu\u00f2 connettersi a lui perch\u00e9 \u00e8 in modalit\u00e0 spegnimento. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 \u00e8 stata avviata. <\/p>\n<p><\/p>\n<p>Ho solo un'ipotesi, che in recovery.conf ci fosse l'indirizzo del vecchio master. E 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=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/425ea3af1f1e186f4760e1fb1f5419fa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Quando Patroni si \u00e8 avviato sulla seconda replica, il nodo si \u00e8 avviato, ma non \u00e8 riuscito a connettersi per la replica. E si \u00e8 creato un ritardo nella replica, che sembrava circa cos\u00ec. Cio\u00e8, tutti e tre i nodi erano al loro posto, ma il secondo nodo era in ritardo. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/f564eacd9944666c9a3f5bea634ede6b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Se si guarda ai log registrati, si pu\u00f2 notare che la replica non pu\u00f2 avviarsi perch\u00e9 i registri delle transazioni sono diversi. E quei registri delle transazioni suggeriti dal master, indicati in recovery.conf, non sono adatti al nostro nodo attuale. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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. Dovevo controllare cosa c'era in recovery.conf per verificare la mia ipotesi che ci stessimo collegando al master sbagliato. Ma all'epoca stavo solo iniziando a capire questo e non mi \u00e8 venuto in mente, oppure ho visto che la replica \u00e8 in ritardo e che dovevo ricaricarla, cio\u00e8 ho lavorato un po' superficialmente. \u00c8 stato un mio errore. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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. Avevo gi\u00e0 perso le speranze, pensavo che dovessimo ricaricarla. E ho pensato: riavvio Patroni, forse esce qualcosa di buono. Il ripristino \u00e8 partito. E il database si \u00e8 persino aperto, era pronto ad accettare connessioni. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/aeac98750386c8389d39e006a229cc85.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La replica \u00e8 ripartita. Ma dopo un minuto si \u00e8 fermata con un errore, che i registri delle transazioni non erano adatti. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/17eaba000a79c80c29d1bc3902de05e6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ho pensato di riavviarla ancora una volta. Ho riavviato di nuovo Patroni, e non ho riavviato Postgres, ma ho riavviato proprio Patroni nella speranza che in qualche modo riavviasse il database. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/a85b38e033c45ad73da317f41e0ef24a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La replica \u00e8 ripartita di nuovo, ma i segni nei registri delle transazioni erano diversi, non erano quelli della precedente tentativo di avvio. La replica si \u00e8 fermata di nuovo. E il messaggio era gi\u00e0 un po' diverso. E non era molto informativo per me. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/fd90d708230bd54af685786c7e361ee1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E qui mi \u00e8 venuta in mente un'idea: e se riavviassi Postgres, in quel momento sul master corrente facessi un checkpoint, per spostare il punto nei registri delle transazioni un po' pi\u00f9 avanti, per iniziare il ripristino da un altro momento? Inoltre, avevamo anche delle riserve di WAL. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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, un paio di punti di riavvio sulla replica, quando si \u00e8 aperta. E questo ha funzionato. Ho pensato a lungo perch\u00e9 ha funzionato e come \u00e8 successo. E la replica si \u00e8 avviata. E la replica non si \u00e8 pi\u00f9 interrotta. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/418ca59a681be84f51ed374a73a759c9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Questo problema per me \u00e8 uno dei pi\u00f9 misteriosi, su cui sto ancora riflettendo, su cosa fosse realmente successo. <\/p>\n<p><\/p>\n<p>Quali conclusioni possiamo trarre? Patroni pu\u00f2 funzionare come previsto e senza errori. Tuttavia, questo non garantisce al 100% che tutto vada bene. La replica pu\u00f2 avviarsi, ma potrebbe trovarsi in uno stato semi-funzionale, e l'applicazione non pu\u00f2 lavorare con una tale replica, perch\u00e9 ci saranno dati obsoleti. <\/p>\n<p><\/p>\n<p>Dopo ogni failover, \u00e8 sempre necessario verificare che il cluster sia in ordine, ovvero che ci siano il numero necessario di repliche e che non ci sia lag nella replica.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/aca7047ff33d3efe14071b798b554091.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Durante l'analisi di questi problemi, formuler\u00f2 delle raccomandazioni. Ho cercato di riunirle in due diapositive. Probabilmente, tutte le storie avrebbero potuto essere riunite in due diapositive e solo queste raccontate.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/d4ad31b26d83c8846fe4097a11d70849.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Quando usate Patroni, \u00e8 obbligatorio avere un monitoraggio. Dovete sempre sapere quando si \u00e8 verificato un failover automatico, perch\u00e9 se non siete a conoscenza del failover, non controllate il cluster. E questo \u00e8 un problema.<\/p>\n<p><\/p>\n<p>Dopo ogni failover, dobbiamo sempre verificare manualmente il cluster. Dobbiamo assicurarci che ci sia sempre il numero attuale di repliche, che non ci sia lag nella replica, e che nei log non ci siano errori relativi alla replica 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 valido. Pu\u00f2 funzionare, ma ci\u00f2 non porter\u00e0 il cluster allo stato desiderato. E se non ne veniamo a conoscenza, avremo problemi.<\/p>\n<p><\/p>\n<p>E Patroni non \u00e8 una soluzione miracolosa. Dobbiamo comunque avere una comprensione di come funziona Postgres, come funziona la replica e di come Patroni opera con Postgres, e di come avviene l'interazione tra i nodi. Questo \u00e8 necessario per poter risolvere manualmente i problemi che si presentano.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/ea4162df3561d2ea7001f2ef6788eaaa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Come mi avvicino alla diagnosi? \u00c8 successo che lavoriamo con diversi clienti e che nessuno di loro ha uno stack ELK, e 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 ci sono i log di Consul, oppure Postgres se necessario. Diagnosticare questo \u00e8 molto difficile. <\/p>\n<p><\/p>\n<p>Quali approcci ho sviluppato? Per prima cosa, guardo sempre quando si \u00e8 verificato il failover. Per me questo rappresenta una sorta di spartiacque. Osservo cosa \u00e8 successo prima del failover, durante e dopo il failover. Il failover ha due marcatori: l'orario di inizio e quello di fine. <\/p>\n<p><\/p>\n<p>Poi guardo nei log gli eventi precedenti al failover, cio\u00e8 cerco le cause per cui si \u00e8 verificato il failover. <\/p>\n<p><\/p>\n<p>E questo fornisce un quadro di comprensione di ci\u00f2 che \u00e8 accaduto e di cosa si pu\u00f2 fare in futuro per evitare che tali circostanze si ripetano (e di conseguenza per evitare un failover).<\/p>\n<p><\/p>\n<p>E dove guardiamo di solito? Io guardo:<\/p>\n<p><\/p>\n<ul>\n<li>Inizialmente nei log di Patroni. <\/li>\n<li>Poi guardo i log di Postgres o i log di DCS, a seconda di ci\u00f2 che trovo nei log di Patroni. <\/li>\n<li>E i log di sistema a volte forniscono anche comprensione delle cause del failover. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" src=\"\/wp-content\/uploads\/2020\/07\/a53618e366020e1a550d852fc308c188.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Come mi sento riguardo a Patroni? Mi sento molto bene riguardo a Patroni. A mio avviso, \u00e8 il migliore disponibile oggi. Conosco molti altri prodotti. Sono Stolon, Repmgr, Pg_auto_failover, PAF. Quattro strumenti. Li ho provati tutti. Patroni mi \u00e8 piaciuto di pi\u00f9. <\/p>\n<p><\/p>\n<p>Se mi chiedono: \u00abConsiglierei Patroni?\u00bb. Direi di s\u00ec, perch\u00e9 mi piace Patroni. E mi sembra di aver imparato a utilizzarlo. <\/p>\n<p><\/p>\n<p>Se sei interessato a vedere 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 vengono discusse molte problematiche interessanti. Alla fine, alcuni bug sono stati segnalati e risolti, quindi \u00e8 una lettura interessante. <\/p>\n<p><\/p>\n<p>Ci sono storie interessanti su come le persone si fanno del male da sole. Molto istruttivo. Leggi e capisci che non dovresti fare cos\u00ec. Ho messo una spunta. <\/p>\n<p><\/p>\n<p>E vorrei ringraziare molto l'azienda Zalando per aver sviluppato questo progetto, in particolare Alexander Kukushkin e Alexey Klyukin. Alexey 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>E credo che Patroni sia 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 sempre pi\u00f9 maturo, straordinario e funzionante con il tempo. \u00c8 gi\u00e0 funzionante, ma spero che diventi ancora migliore. Quindi, se stai pensando di utilizzare Patroni, non avere paura. \u00c8 una buona soluzione, pu\u00f2 essere implementata e utilizzata. <\/p>\n<p><\/p>\n<p>Questo \u00e8 tutto. Se hai domande, chiedi.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Patroni Failure Stories o Come far crollare il tuo cluster PostgreSQL. Aleksei Lesovski\" 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 la presentazione! Se dopo il failover \u00e8 comunque necessario guardare l\u00ec con molta attenzione, perch\u00e9 abbiamo bisogno di un failover automatico?<\/em> <\/p>\n<p><\/p>\n<p>Perch\u00e9 si tratta di una cosa nuova. Lavoriamo con essa da solo un anno. \u00c8 meglio essere prudenti. Vogliamo entrare e controllare che tutto funzioni davvero come dovrebbe. Questo \u00e8 un livello di sfiducia adulta: \u00e8 meglio ricontrollare e verificare. <\/p>\n<p><\/p>\n<p><em>Ad esempio, siamo entrati al mattino e abbiamo guardato, vero?<\/em><\/p>\n<p><\/p>\n<p>Non al mattino, di solito veniamo a sapere dell'auto-failover praticamente subito. Riceviamo notifiche e vediamo che si \u00e8 verificato un auto-failover. Entriamo e controlliamo quasi subito. Ma tutti questi controlli devono essere portati a un livello di monitoraggio. Se facciamo riferimento a Patroni tramite REST API, c'\u00e8 la cronologia. Nella cronologia possiamo vedere i timestamp quando si \u00e8 verificato il failover. Sulla base di questo si pu\u00f2 fare monitoraggio. Possiamo guardare la cronologia, quanti eventi ci sono stati. Se abbiamo avuto pi\u00f9 eventi, significa che c'\u00e8 stato un auto-failover. Possiamo andare a controllare. Oppure la nostra automazione nel monitoraggio ha verificato che tutte le nostre repliche sono a posto, non ci sono ritardi e va tutto bene. <\/p>\n<p><\/p>\n<p><em>Grazie!<\/em><\/p>\n<p><\/p>\n<p><em>Grazie mille per la splendida esposizione! Se abbiamo spostato il cluster DCS lontano dal cluster Postgres, dobbiamo servirlo periodicamente? Quali sono le best practices in merito a quando alcuni segmenti del cluster DCS devono essere spenti, cosa fare con essi, ecc.? Come vive l'intera struttura in questi casi? E come si fanno queste operazioni?<\/em><\/p>\n<p><\/p>\n<p>Per un'azienda era necessario creare una matrice di problemi, per cosa accade se uno o pi\u00f9 componenti si guastano. Su questa matrice esaminiamo sequenzialmente tutti i componenti e costruiamo scenari in caso di guasto di questi componenti. Pertanto, per ogni scenario di guasto, possiamo avere un piano d'azione per il ripristino. E nel caso del DCS, questo fa parte dell'infrastruttura standard. E l'amministratore si occupa di questo, e noi ci affidiamo gi\u00e0 agli amministratori per la loro capacit\u00e0 di ripararlo in caso di emergenze. Se il DCS non \u00e8 presente, lo implementiamo noi, ma senza seguirlo attentamente, poich\u00e9 non siamo responsabili per l'infrastruttura, ma forniamo raccomandazioni su cosa e come monitorare. <\/p>\n<p><\/p>\n<p><em>Cio\u00e8, ho capito bene che bisogna disattivare Patroni, disattivare il failover, disattivare tutto prima di fare qualcosa con gli host?<\/em><\/p>\n<p><\/p>\n<p>Dipende da quanti nodi abbiamo nel cluster DCS. Se ci sono molti nodi e se mettiamo fuori uso solo uno di essi (una replica), il cluster mantiene il quorum. E Patroni rimane funzionante. E non si attiva nulla. Se abbiamo operazioni complesse che coinvolgono pi\u00f9 nodi, la cui assenza potrebbe compromettere il quorum, allora s\u00ec, potrebbe avere senso mettere Patroni in pausa. Ha il comando corrispondente: patronictl pause, patronictl resume. Semplicemente mettiamo in pausa, e l'auto-failover non si attiva in quel momento. Facciamo manutenzione nel cluster DCS, poi togliamo la pausa e continuiamo a operare.<\/p>\n<p><\/p>\n<p><em>Grazie mille!<\/em><\/p>\n<p><\/p>\n<p><em>Grazie mille per la relazione! Come si sente il team di prodotto riguardo alla possibilit\u00e0 di perdita di dati?<\/em> <\/p>\n<p><\/p>\n<p>Ai team di prodotto non importa, mentre i team leader sono preoccupati. <\/p>\n<p><\/p>\n<p><em>Quali garanzie ci sono?<\/em><\/p>\n<p><\/p>\n<p>Le garanzie sono molto complicate. C'\u00e8 una presentazione di Aleksandr Kukushkin \"Come calcolare RPO e RTO\", ovvero il tempo di recupero e quanto dati possiamo perdere. Penso sia necessario trovare queste diapositive e studiarle. Quanto ricordo, ci sono passi specifici su come calcolare queste cose. Quante transazioni possiamo perdere, quanti dati possiamo perdere. Come alternativa possiamo usare la replica sincrona a livello di Patroni, ma \u00e8 un'arma a doppio taglio: abbiamo affidabilit\u00e0 dei dati oppure perdiamo in velocit\u00e0. C'\u00e8 la replica sincrona, ma non garantisce comunque una protezione al 100% contro la perdita di dati.<\/p>\n<p><\/p>\n<p><em>Aleksy, grazie per la meravigliosa relazione! Hai esperienza nell'uso di Patroni per la protezione di livello zero? Cio\u00e8, in combinazione con standby sincrono? Questa \u00e8 la prima domanda. E la seconda domanda. Hai utilizzato diverse soluzioni. Noi abbiamo usato Repmgr, ma senza auto-failover e ora stiamo pianificando di aggiungere auto-failover. E stiamo considerando Patroni come soluzione alternativa. Cosa puoi dire riguardo ai vantaggi rispetto a Repmgr?<\/em><\/p>\n<p><\/p>\n<p>La prima domanda riguardava le repliche sincrone. Nessuno di noi utilizza la replica sincrona, perch\u00e9 fa paura a tutti (Alcuni clienti gi\u00e0 la usano, problemi di performance sostanzialmente non riscontrati \u2014 <em>Nota del relatore<\/em>). Ma abbiamo elaborato una regola secondo cui nel cluster di replica sincrona devono esserci almeno tre nodi, poich\u00e9 se abbiamo due nodi e se il master o la replica smettono di funzionare, Patroni trasferisce quel nodo in modalit\u00e0 Standalone affinch\u00e9 l'applicazione continui 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 tuttora lo usiamo con alcuni clienti per motivi storici. Cosa si pu\u00f2 dire? In Patroni, l'auto-failover \u00e8 integrato, mentre in Repmgr l'auto-failover \u00e8 gi\u00e0 una funzionalit\u00e0 aggiuntiva che deve essere attivata. \u00c8 necessario avviare il demone Repmgr su ogni nodo e poi possiamo configurare l'auto-failover. <\/p>\n<p><\/p>\n<p>Repmgr verifica se i nodi Postgres sono vivi. I processi di Repmgr controllano l'esistenza reciproca, ma questo non \u00e8 un approccio molto efficace, poich\u00e9 potrebbero verificarsi casi complessi di isolamento di rete, in cui un grande cluster Repmgr pu\u00f2 rompersi in pi\u00f9 piccoli e continuare a funzionare. Non seguo pi\u00f9 Repmgr da un po', forse hanno risolto questo problema\u2026 o forse no. La trasmissione delle informazioni sullo stato del cluster in DCS, come fa Stolon o Patroni, \u00e8 l'opzione pi\u00f9 sostenibile. <\/p>\n<p><\/p>\n<p><em>Alexey, ho una domanda, forse da principiante. In uno dei primi esempi, hai spostato DCS da una macchina locale a un nodo remoto. Sappiamo che la rete ha le sue peculiarit\u00e0, vive di vita propria. E cosa succede se per qualche motivo il cluster DCS diventa non disponibile? Non parler\u00f2 dei motivi, potrebbero essere molteplici: da errori degli operatori di rete a problemi reali.<\/em> <\/p>\n<p><\/p>\n<p>Non l'ho detto ad alta voce, ma il cluster DCS deve essere anche resistente ai guasti, cio\u00e8 deve avere un numero dispari di nodi affinch\u00e9 possa essere raggiunto il quorum. Cosa succede se il cluster DCS diventa non disponibile o non riesce a raggiungere il quorum, ad esempio a causa di uno split di rete o di guasti dei nodi? In questo caso, il cluster Patroni passa in modalit\u00e0 di sola lettura. Il cluster Patroni non riesce a determinare lo stato del cluster e cosa fare. Non riesce a comunicare con DCS e a salvare il nuovo stato del cluster, quindi l'intero cluster passa in modalit\u00e0 di sola lettura. E attende o l'intervento manuale dell'operatore o il ripristino di DCS.<\/p>\n<p><\/p>\n<p><em>In parole povere, DCS diventa per noi un servizio altrettanto importante quanto il database stesso?<\/em><\/p>\n<p><\/p>\n<p>S\u00ec, s\u00ec. In molte moderne aziende, il Service Discovery \u00e8 una parte indispensabile dell'infrastruttura. Viene implementato anche prima che esista un database nell'infrastruttura. In altre parole, l'infrastruttura viene avviata, si fa il deployment in un centro dati, e abbiamo immediatamente il Service Discovery pronto. Se si tratta di Consul, pu\u00f2 essere costruito anche il DNS su di esso. Se si tratta di Etcd, potrebbe essere parte di un cluster Kubernetes, in cui si dispiegher\u00e0 tutto il resto. Mi sembra che il Service Discovery sia gi\u00e0 una parte imprescindibile delle infrastrutture moderne. E se ne comincia a pensare molto prima che ai database. <\/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 5.0.1.1 - 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\/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) 5.0.1.1\" \/>\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: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\udd47Storie di fallimenti di Patroni o come far crashare il tuo cluster PostgreSQL. Alexey Lesovski | ProHoster","description":"","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: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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}