Patroni Failure Stories o Come arrestare in modo anomalo il tuo cluster PostgreSQL. Alexey Lesovsky

L'obiettivo principale di Patroni è fornire alta disponibilità per PostgreSQL. Ma Patroni è solo un modello, non uno strumento già pronto (cosa che, in generale, si dice nella documentazione). A prima vista, dopo aver impostato Patroni nel laboratorio di test, puoi vedere che ottimo strumento è e con quanta facilità gestisce i nostri tentativi di rompere il cluster. Tuttavia, in pratica, in un ambiente di produzione, non sempre tutto avviene in modo bello ed elegante come in un laboratorio di prova.

Ti racconto un po' di me. Ho iniziato come amministratore di sistema. Ha lavorato nello sviluppo web. Lavoro in Data Egret dal 2014. La società è impegnata nella consulenza nel campo di Postgres. E serviamo esattamente Postgres e lavoriamo con Postgres ogni giorno, quindi abbiamo competenze diverse relative all'operazione.

E alla fine del 2018, abbiamo iniziato a utilizzare lentamente Patroni. E una certa esperienza è stata accumulata. In qualche modo l'abbiamo diagnosticato, messo a punto, siamo arrivati ​​alle nostre migliori pratiche. E in questo rapporto parlerò di loro.

A parte Postgres, adoro Linux. Mi piace curiosarci dentro ed esplorare, mi piace collezionare anime. Adoro la virtualizzazione, i container, la finestra mobile, Kubernetes. Tutto questo mi interessa, perché le vecchie abitudini dell'amministratore stanno influenzando. Mi piace occuparmi del monitoraggio. E adoro le cose postgres relative all'amministrazione, ad esempio replica, backup. E nel tempo libero scrivo su Go. Non sono un ingegnere del software, scrivo solo per me stesso in Go. E mi fa piacere.

• Penso che molti di voi sappiano che Postgres non ha HA (High Availability) pronto all'uso. Per ottenere HA, devi installare qualcosa, configurarlo, fare uno sforzo e ottenerlo.
• Esistono diversi strumenti e Patroni è uno di quelli che risolve l'HA in modo piuttosto interessante e molto bene. Ma mettendo tutto in un laboratorio di prova ed eseguendolo, possiamo vedere che tutto funziona, possiamo riprodurre alcuni problemi, vedere come li serve Patroni. E vedremo che tutto funziona alla grande.
• Ma in pratica, abbiamo affrontato problemi diversi. E parlerò di questi problemi.
• Ti dirò come l'abbiamo diagnosticato, cosa abbiamo modificato, se ci ha aiutato o meno.

• Non ti dirò come installare Patroni, perché puoi google su Internet, puoi guardare i file di configurazione per capire come inizia tutto, come è configurato. Puoi capire gli schemi, le architetture, trovando informazioni a riguardo su Internet.
• Non parlerò dell'esperienza di qualcun altro. Parlerò solo dei problemi che abbiamo dovuto affrontare.
• E non parlerò di problemi che sono al di fuori di Patroni e PostgreSQL. Se, ad esempio, ci sono problemi legati al bilanciamento, quando il nostro cluster è crollato, non ne parlerò.

E un piccolo disclaimer prima di iniziare il nostro rapporto.

Tutti questi problemi che abbiamo riscontrato, li abbiamo avuti nei primi 6-7-8 mesi di attività. Nel tempo, siamo arrivati ​​alle nostre best practice interne. E i nostri problemi sono scomparsi. Pertanto, il rapporto è stato annunciato circa sei mesi fa, quando era tutto fresco nella mia testa e lo ricordavo perfettamente.

Nel corso della preparazione del rapporto, ho già raccolto vecchie autopsie, esaminato i registri. E alcuni dei dettagli potrebbero essere dimenticati, o alcuni di alcuni dettagli potrebbero non essere completamente esaminati durante l'analisi dei problemi, quindi in alcuni punti può sembrare che i problemi non siano completamente considerati, o ci sia una mancanza di informazioni. E quindi ti chiedo di scusarmi per questo momento.

Cos'è Patrono?

• Questo è un modello per la creazione di HA. Questo è quello che dice nella documentazione. E dal mio punto di vista, questo è un chiarimento molto corretto. Patroni non è una pallottola d'argento che risolverà tutti i tuoi problemi, cioè devi fare uno sforzo per farlo funzionare e portare benefici.
• Questo è un servizio agente che viene installato su ogni servizio di database ed è una sorta di sistema init per il tuo Postgres. Avvia Postgres, arresta, riavvia, riconfigura e modifica la topologia del tuo cluster.
• Di conseguenza, per memorizzare lo stato del cluster, la sua rappresentazione attuale, come sembra, è necessaria una sorta di archiviazione. E da questo punto di vista, Patroni ha intrapreso la strada dell'archiviazione dello stato in un sistema esterno. È un sistema di archiviazione della configurazione distribuito. Può essere Etcd, Consul, ZooKeeper o kubernetes Etcd, ovvero una di queste opzioni.
• E una delle caratteristiche di Patroni è che ottieni l'autofiler fuori dalla scatola, solo configurandolo. Se prendiamo Repmgr per il confronto, il filer è incluso lì. Con Repmgr, otteniamo un passaggio, ma se vogliamo un filtro automatico, dobbiamo configurarlo ulteriormente. Patroni ha già un autofiler pronto all'uso.
• E ci sono molte altre cose. Ad esempio, manutenzione delle configurazioni, versamento di nuove repliche, backup, ecc. Ma questo va oltre lo scopo del rapporto, non ne parlerò.

E un piccolo risultato è che il compito principale di Patroni è eseguire un file automatico in modo corretto e affidabile in modo che il nostro cluster rimanga operativo e l'applicazione non noti cambiamenti nella topologia del cluster.

Ma quando iniziamo a usare Patroni, il nostro sistema diventa un po' più complicato. Se prima avevamo Postgres, quando usiamo Patroni otteniamo Patroni stesso, otteniamo DCS dove è memorizzato lo stato. E tutto deve funzionare in qualche modo. Quindi cosa può andare storto?

Potrebbero rompersi:

• Postgres potrebbe rompersi. Può essere un master o una replica, uno di questi potrebbe fallire.
• Il Patroni stesso potrebbe rompersi.
• Il DCS in cui è memorizzato lo stato potrebbe rompersi.
• E la rete può rompersi.

Tutti questi punti che prenderò in considerazione nella relazione.

Prenderò in considerazione i casi man mano che diventano più complessi, non dal punto di vista che il caso coinvolge molti componenti. E dal punto di vista dei sentimenti soggettivi, che questa custodia fosse difficile per me, era difficile smontarla ... e viceversa, qualche custodia era leggera ed era facile smontarla.

E il primo caso è il più semplice. Questo è il caso quando abbiamo preso un cluster di database e distribuito il nostro storage DCS sullo stesso cluster. Questo è l'errore più comune. Questo è un errore nella costruzione di architetture, cioè nel combinare diversi componenti in un unico luogo.

Quindi, c'era un filer, andiamo ad affrontare quello che è successo.

E qui siamo interessati a quando è successo il filer. Cioè, siamo interessati a questo momento in cui lo stato del cluster è cambiato.

Ma il filer non è sempre istantaneo, ad es. non richiede alcuna unità di tempo, può essere ritardato. Può durare a lungo.

Pertanto, ha un'ora di inizio e un'ora di fine, cioè è un evento continuo. E dividiamo tutti gli eventi in tre intervalli: abbiamo tempo prima del filer, durante il filer e dopo il filer. Cioè, consideriamo tutti gli eventi in questa sequenza temporale.

E per prima cosa, quando è successo un filer, cerchiamo la causa di quello che è successo, qual è stata la causa di ciò che ha portato al filer.

Se guardiamo ai registri, saranno i classici registri Patroni. Ci dice in loro che il server è diventato il master e il ruolo del master è passato a questo nodo. Qui è evidenziato.

Successivamente, dobbiamo capire perché si è verificato il filer, ovvero quali eventi si sono verificati che hanno causato lo spostamento del ruolo master da un nodo all'altro. E in questo caso, tutto è semplice. Abbiamo un errore nell'interazione con il sistema di archiviazione. Il maestro si è reso conto che non poteva lavorare con DCS, cioè c'era qualche tipo di problema con l'interazione. E dice che non può più essere un maestro e si dimette. Questa riga "sé retrocesso" dice esattamente questo.

Se guardiamo agli eventi che hanno preceduto il filer, possiamo vedere lì le ragioni stesse che erano il problema per la continuazione della procedura guidata.

Se esaminiamo i registri Patroni, vedremo che abbiamo molti errori, timeout, ad es. l'agente Patroni non può funzionare con DCS. In questo caso, si tratta dell'agente Consul, che sta comunicando sulla porta 8500.

E il problema qui è che Patroni e il database sono in esecuzione sullo stesso host. E i server Consul sono stati lanciati sullo stesso nodo. Creando un carico sul server, abbiamo creato problemi anche ai server Consul. Non potevano comunicare correttamente.

Dopo qualche tempo, quando il carico si è abbassato, il nostro Patroni è stato in grado di comunicare nuovamente con gli agenti. Il normale lavoro è ripreso. E lo stesso server Pgdb-2 è diventato di nuovo il master. Cioè, c'è stato un piccolo capovolgimento, a causa del quale il nodo ha rinunciato ai poteri del maestro, e poi li ha ripresi, cioè tutto è tornato com'era.

E questo può essere considerato un falso allarme, oppure si può ritenere che Patroni abbia fatto tutto bene. Cioè, si è reso conto che non poteva mantenere lo stato dell'ammasso e ha rimosso la sua autorità.

E qui è sorto il problema dovuto al fatto che i server Consul si trovano sullo stesso hardware delle basi. Di conseguenza, qualsiasi carico: che si tratti di carico su dischi o processori, influisce anche sull'interazione con il cluster Consul.

E abbiamo deciso che non dovrebbe vivere insieme, abbiamo assegnato un cluster separato per Consul. E Patroni stava già lavorando con un Console separato, ovvero c'era un cluster Postgres separato, un cluster Consul separato. Questa è un'istruzione di base su come trasportare e conservare tutte queste cose in modo che non vivano insieme.

Come opzione, puoi modificare i parametri ttl, loop_wait, retry_timeout, ad es. provare a sopravvivere a questi picchi di carico a breve termine aumentando questi parametri. Ma questa non è l'opzione più adatta, perché questo carico può durare a lungo. E andremo semplicemente oltre questi limiti di questi parametri. E questo potrebbe non aiutare davvero.

Il primo problema, come capisci, è semplice. Abbiamo preso e messo insieme il DCS con la base, abbiamo un problema.

Il secondo problema è simile al primo. È simile in quanto abbiamo nuovamente problemi di interoperabilità con il sistema DCS.

Se esaminiamo i registri, vedremo che abbiamo nuovamente un errore di comunicazione. E Patroni dice che non posso interagire con DCS, quindi l'attuale master entra in modalità replica.

Il vecchio maestro diventa una replica, qui Patroni funziona, come dovrebbe essere. Esegue pg_rewind per riavvolgere il registro delle transazioni e quindi connettersi al nuovo master per recuperare il ritardo con il nuovo master. Qui Patroni si allena, come dovrebbe.

Qui dobbiamo trovare il posto che ha preceduto il filer, cioè quegli errori che ci hanno fatto avere un filer. E a questo proposito, i registri Patroni sono abbastanza convenienti con cui lavorare. Scrive gli stessi messaggi a un certo intervallo. E se iniziamo a scorrere rapidamente questi registri, vedremo dai registri che i registri sono cambiati, il che significa che sono iniziati alcuni problemi. Torniamo rapidamente in questo posto, vediamo cosa succede.

E in una situazione normale, i registri hanno un aspetto simile a questo. Il proprietario della serratura viene controllato. E se il proprietario, ad esempio, è cambiato, potrebbero verificarsi alcuni eventi a cui Patroni deve rispondere. Ma in questo caso, stiamo bene. Stiamo cercando il luogo in cui sono iniziati gli errori.

E dopo aver fatto scorrere fino al punto in cui gli errori hanno iniziato a comparire, vediamo che abbiamo avuto un fileover automatico. E poiché i nostri errori erano correlati all'interazione con DCS e nel nostro caso abbiamo utilizzato Consul, esaminiamo anche i registri di Consul, cosa è successo lì.

Confrontando approssimativamente l'ora del filer e l'ora nei registri del Console, vediamo che i nostri vicini nell'ammasso del Console hanno iniziato a dubitare dell'esistenza di altri membri dell'ammasso del Console.

E se guardi i registri di altri agenti del Console, puoi anche vedere che c'è una sorta di collasso della rete in corso lì. E tutti i membri del gruppo del Console dubitano l'uno dell'esistenza dell'altro. E questo è stato l'impulso per il filer.

Se guardi cosa è successo prima di questi errori, puoi vedere che ci sono tutti i tipi di errori, ad esempio scadenza, RPC caduto, cioè c'è chiaramente qualche tipo di problema nell'interazione tra i membri del cluster Consul .

La risposta più semplice è riparare la rete. Ma per me, in piedi sul podio, è facile dirlo. Ma le circostanze sono tali che non sempre il cliente può permettersi di riparare la rete. Potrebbe vivere in un DC e potrebbe non essere in grado di riparare la rete, influire sull'apparecchiatura. E quindi sono necessarie alcune altre opzioni.

Ci sono opzioni:

• L'opzione più semplice, che è scritta, secondo me, anche nella documentazione, è disabilitare i controlli Consul, ovvero passare semplicemente un array vuoto. E diciamo all'agente del Console di non usare assegni. Con questi controlli, possiamo ignorare queste tempeste di rete e non avviare un filer.
• Un'altra opzione è ricontrollare raft_multiplier. Questo è un parametro del server Consul stesso. Per impostazione predefinita, è impostato su 5. Questo valore è consigliato dalla documentazione per gli ambienti di gestione temporanea. In effetti, ciò influisce sulla frequenza della messaggistica tra i membri della rete Consul. Questo parametro, infatti, influisce sulla velocità di comunicazione del servizio tra i membri del cluster Consul. E per la produzione, si consiglia già di ridurlo in modo che i nodi si scambino messaggi più spesso.
• Un'altra opzione che abbiamo trovato è quella di aumentare la priorità dei processi Consul tra gli altri processi per lo scheduler dei processi del sistema operativo. Esiste un parametro così "bello", determina solo la priorità dei processi che viene presa in considerazione dallo scheduler del sistema operativo durante la pianificazione. Abbiamo anche ridotto il valore simpatico per gli agenti Consul, ad es. aumentato la priorità in modo che il sistema operativo dia ai processi Consul più tempo per lavorare ed eseguire il proprio codice. Nel nostro caso, questo ha risolto il nostro problema.
• Un'altra opzione è non usare Consul. Ho un amico che è un grande sostenitore di Etcd. E discutiamo regolarmente con lui su quale sia meglio Etcd o Consul. Ma in termini di cosa è meglio, di solito siamo d'accordo con lui sul fatto che Consul abbia un agente che dovrebbe essere in esecuzione su ogni nodo con un database. Cioè, l'interazione di Patroni con il cluster Consul passa attraverso questo agente. E questo agente diventa un collo di bottiglia. Se succede qualcosa all'agente, Patroni non può più lavorare con il cluster Consul. E questo è il problema. Non ci sono agenti nel piano Etcd. Patroni può lavorare direttamente con un elenco di server Etcd e comunicare già con loro. A questo proposito, se utilizzi Etcd nella tua azienda, allora Etcd sarà probabilmente una scelta migliore di Consul. Ma noi dei nostri clienti siamo sempre limitati da ciò che il cliente ha scelto e utilizza. E abbiamo Consul per la maggior parte per tutti i clienti.
• E l'ultimo punto è rivedere i valori dei parametri. Possiamo aumentare questi parametri nella speranza che i nostri problemi di rete a breve termine siano brevi e non cadano al di fuori della gamma di questi parametri. In questo modo possiamo ridurre l'aggressività di Patroni all'autofile se si verificano problemi di rete.

Penso che molti di coloro che usano Patroni abbiano familiarità con questo comando.

Questo comando mostra lo stato corrente del cluster. E a prima vista, questa immagine può sembrare normale. Abbiamo un master, abbiamo una replica, non c'è ritardo di replica. Ma questa immagine è esattamente normale fino a quando non sappiamo che questo cluster dovrebbe avere tre nodi, non due.

Di conseguenza, c'era un file automatico. E dopo questo file automatico, la nostra replica è scomparsa. Dobbiamo scoprire perché è scomparsa e riportarla indietro, ripristinarla. E andiamo di nuovo ai log e vediamo perché abbiamo avuto un fileover automatico.

In questo caso, la seconda replica è diventata il master. Va tutto bene qui.

E dobbiamo esaminare la replica che è caduta e che non è nel cluster. Apriamo i log Patroni e vediamo che abbiamo avuto un problema durante il processo di connessione al cluster nella fase pg_rewind. Per connettersi al cluster, è necessario riavvolgere il registro delle transazioni, richiedere il registro delle transazioni richiesto al master e utilizzarlo per mettersi al passo con il master.

In questo caso, non disponiamo di un registro delle transazioni e la replica non può essere avviata. Di conseguenza, fermiamo Postgres con un errore. E quindi non è nel cluster.

Dobbiamo capire perché non è nel cluster e perché non c'erano log. Andiamo dal nuovo maestro e guardiamo cosa ha nei registri. Si scopre che quando pg_rewind è stato eseguito, si è verificato un checkpoint. E alcuni dei vecchi registri delle transazioni sono stati semplicemente rinominati. Quando il vecchio master ha tentato di connettersi al nuovo master e di interrogare questi log, erano già stati rinominati, semplicemente non esistevano.

Ho confrontato i timestamp quando questi eventi sono accaduti. E lì la differenza è letteralmente di 150 millisecondi, ovvero il checkpoint completato in 369 millisecondi, i segmenti WAL sono stati rinominati. E letteralmente nel 517, dopo 150 millisecondi, è iniziato il riavvolgimento sulla vecchia replica. Cioè, ci sono bastati letteralmente 150 millisecondi in modo che la replica non potesse connettersi e guadagnare.

Quali sono le opzioni?

Inizialmente abbiamo utilizzato gli slot di replica. Abbiamo pensato che fosse buono. Sebbene nella prima fase dell'operazione abbiamo disattivato gli slot. Ci è sembrato che se gli slot accumulano molti segmenti WAL, possiamo eliminare il master. Cadrà. Abbiamo sofferto per qualche tempo senza slot. E ci siamo resi conto che abbiamo bisogno di slot, abbiamo restituito gli slot.

Ma c'è un problema qui, che quando il master va alla replica, cancella gli slot ed elimina i segmenti WAL insieme agli slot. E per eliminare questo problema, abbiamo deciso di aumentare il parametro wal_keep_segments. L'impostazione predefinita è 8 segmenti. L'abbiamo portato a 1 e abbiamo esaminato quanto spazio libero avevamo. E abbiamo donato 000 gigabyte per wal_keep_segments. Cioè, quando si passa, abbiamo sempre una riserva di 16 gigabyte di registri delle transazioni su tutti i nodi.

Inoltre, è ancora rilevante per le attività di manutenzione a lungo termine. Supponiamo di dover aggiornare una delle repliche. E vogliamo spegnerlo. Dobbiamo aggiornare il software, forse il sistema operativo, qualcos'altro. E quando disattiviamo una replica, viene rimosso anche lo slot per quella replica. E se utilizziamo un piccolo wal_keep_segments, con una lunga assenza di una replica, i registri delle transazioni andranno persi. Aumenteremo una replica, richiederà quei registri delle transazioni in cui si è fermato, ma potrebbero non essere sul master. E nemmeno la replica sarà in grado di connettersi. Pertanto, teniamo un grande stock di riviste.

Abbiamo una base di produzione. Ci sono già progetti in corso.

C'era un filer. Siamo entrati e abbiamo guardato: tutto è in ordine, le repliche sono a posto, non c'è ritardo di replica. Non ci sono errori nemmeno nei log, tutto è in ordine.

Il team del prodotto afferma che dovrebbero esserci dei dati, ma li vediamo da una fonte, ma non li vediamo nel database. E dobbiamo capire cosa è successo loro.

È chiaro che pg_rewind li ha persi. Lo abbiamo capito subito, ma siamo andati a vedere cosa stava succedendo.

Nei registri, possiamo sempre trovare quando si è verificato il filer, chi è diventato il master e possiamo determinare chi era il vecchio master e quando voleva diventare una replica, ovvero abbiamo bisogno di questi log per scoprire la quantità di log delle transazioni che era perso.

Il nostro vecchio master si è riavviato. E Patroni era registrato nell'autorun. Patroni lanciato. Ha quindi avviato Postgres. Più precisamente, prima di avviare Postgres e prima di farne una replica, Patroni ha lanciato il processo pg_rewind. Di conseguenza, ha cancellato parte dei registri delle transazioni, ne ha scaricati di nuovi e si è connesso. Qui Patroni ha lavorato in modo intelligente, cioè come previsto. Il cluster è stato ripristinato. Avevamo 3 nodi, dopo il filer 3 nodi: va tutto bene.

Abbiamo perso alcuni dati. E dobbiamo capire quanto abbiamo perso. Stiamo cercando solo il momento in cui abbiamo avuto un riavvolgimento. Possiamo trovarlo in tali voci di diario. Il riavvolgimento è iniziato, ha fatto qualcosa lì ed è finito.

Dobbiamo trovare la posizione nel registro delle transazioni da dove si era interrotto il vecchio master. In questo caso, questo è il marchio. E abbiamo bisogno di un secondo segno, cioè la distanza per cui il vecchio maestro differisce dal nuovo.

Prendiamo il solito pg_wal_lsn_diff e confrontiamo questi due segni. E in questo caso, otteniamo 17 megabyte. Molto o poco, ognuno decide per se stesso. Perché per qualcuno 17 megabyte non sono molti, per qualcuno è tanto e inaccettabile. Qui, ogni individuo determina da solo in base alle esigenze dell'azienda.

Ma cosa abbiamo scoperto per noi stessi?

Innanzitutto, dobbiamo decidere da soli: abbiamo sempre bisogno che Patroni si avvii automaticamente dopo un riavvio del sistema? Accade spesso che dobbiamo andare dal vecchio maestro, vedere fino a che punto è andato. Forse ispeziona segmenti del registro delle transazioni, vedi cosa c'è. E per capire se possiamo perdere questi dati o se dobbiamo eseguire il vecchio master in modalità autonoma per estrarre questi dati.

E solo dopo dobbiamo decidere se possiamo scartare questi dati o possiamo ripristinarli, connettere questo nodo come replica al nostro cluster.

Inoltre, esiste un parametro "maximum_lag_on_failover". Per impostazione predefinita, se la mia memoria mi serve, questo parametro ha un valore di 1 megabyte.

Come lavora? Se la nostra replica è in ritardo di 1 megabyte di dati nel ritardo di replica, questa replica non prende parte alle elezioni. E se all'improvviso c'è un fileover, Patroni guarda quali repliche sono in ritardo. Se sono indietro di un numero elevato di registri delle transazioni, non possono diventare master. Questa è un'ottima funzionalità di sicurezza che ti impedisce di perdere molti dati.

Ma c'è un problema in quanto il ritardo di replica nel cluster Patroni e DCS viene aggiornato a un certo intervallo. Penso che 30 secondi sia il valore ttl predefinito.

Di conseguenza, potrebbe esserci una situazione in cui è presente un ritardo di replica per le repliche in DCS, ma in realtà potrebbe esserci un ritardo completamente diverso o potrebbe non esserci alcun ritardo, ovvero questa cosa non è in tempo reale. E non sempre riflette l'immagine reale. E non vale la pena fare una logica fantasiosa su di esso.

E il rischio di perdita rimane sempre. E nel peggiore dei casi, una formula e, nel caso medio, un'altra formula. Cioè, quando pianifichiamo l'implementazione di Patroni e valutiamo quanti dati possiamo perdere, dobbiamo fare affidamento su queste formule e immaginare approssimativamente quanti dati possiamo perdere.

E ci sono buone notizie. Quando il vecchio maestro è andato avanti, può andare avanti a causa di alcuni processi in background. Cioè, c'era una specie di autovacuum, ha scritto i dati, li ha salvati nel registro delle transazioni. E possiamo facilmente ignorare e perdere questi dati. Non c'è problema in questo.

Ed ecco come appaiono i log se è impostato maximum_lag_on_failover e si è verificato un filer, ed è necessario selezionare un nuovo master. La replica si autovaluta come incapace di partecipare alle elezioni. E si rifiuta di partecipare alla corsa per il leader. E attende che venga selezionato un nuovo master, in modo da potersi poi connettere ad esso. Questa è una misura aggiuntiva contro la perdita di dati.

Qui abbiamo un team di prodotto che ha scritto che il suo prodotto ha problemi con Postgres. Allo stesso tempo, non è possibile accedere al master stesso, poiché non è disponibile tramite SSH. E neanche l'autofile si verifica.

Questo host è stato costretto a riavviarsi. A causa del riavvio, si è verificato un file automatico, sebbene fosse possibile eseguire un file automatico manuale, come ho capito ora. E dopo il riavvio, vedremo già cosa abbiamo avuto con l'attuale master.

Allo stesso tempo, sapevamo in anticipo di avere problemi con i dischi, cioè sapevamo già dal monitoraggio dove scavare e cosa cercare.

Siamo entrati nel log di Postgres, abbiamo iniziato a vedere cosa stava succedendo lì. Abbiamo visto commit che durano lì per uno, due, tre secondi, il che non è affatto normale. Abbiamo visto che il nostro autoaspirapolvere si avvia molto lentamente e in modo strano. E abbiamo visto file temporanei sul disco. Cioè, questi sono tutti indicatori di problemi con i dischi.

Abbiamo esaminato il sistema dmesg (registro del kernel). E abbiamo visto che abbiamo problemi con uno dei dischi. Il sottosistema del disco era il software Raid. Abbiamo esaminato /proc/mdstat e abbiamo visto che mancava un'unità. Cioè, c'è un Raid di 8 dischi, ne manca uno. Se guardi attentamente la diapositiva, nell'output puoi vedere che non abbiamo sde lì. A noi, condizionatamente parlando, il disco è caduto. Ciò ha innescato problemi del disco e anche le applicazioni hanno riscontrato problemi durante l'utilizzo del cluster Postgres.

E in questo caso Patroni non ci aiuterebbe in alcun modo, perché Patroni non ha il compito di monitorare lo stato del server, lo stato del disco. E dobbiamo monitorare tali situazioni tramite un monitoraggio esterno. Abbiamo rapidamente aggiunto il monitoraggio del disco al monitoraggio esterno.

E c'era un pensiero del genere: la scherma o il software watchdog potrebbero aiutarci? Abbiamo pensato che difficilmente ci avrebbe aiutato in questo caso, perché durante i problemi Patroni ha continuato a interagire con il cluster DCS e non ha riscontrato alcun problema. Cioè, dal punto di vista di DCS e Patroni, con il cluster andava tutto bene, anche se in realtà c'erano problemi con il disco, c'erano problemi con la disponibilità del database.

Secondo me, questo è uno dei problemi più strani su cui ho studiato per molto tempo, ho letto molti registri, l'ho riselezionato e l'ho chiamato simulatore di cluster.

Il problema era che il vecchio master non poteva diventare una replica normale, cioè Patroni lo avviava, Patroni mostrava che questo nodo era presente come replica, ma allo stesso tempo non era una replica normale. Ora vedrai perché. Questo è ciò che ho mantenuto dall'analisi di quel problema.

E come è iniziato tutto? È iniziato, come nel problema precedente, con i freni a disco. Abbiamo avuto commit per un secondo, due.

Ci sono state interruzioni nelle connessioni, ad es. i clienti sono stati strappati.

C'erano blocchi di varia gravità.

E, di conseguenza, il sottosistema del disco non è molto reattivo.

E la cosa per me più misteriosa è la richiesta di spegnimento immediato che è arrivata. Postgres ha tre modalità di spegnimento:

• È elegante quando aspettiamo che tutti i client si disconnettano da soli.
• C'è velocità quando costringiamo i clienti a disconnettersi perché stiamo per arrestare.
• E immediato. In questo caso, l'immediato non dice nemmeno ai client di spegnersi, si spegne senza preavviso. E a tutti i client, il sistema operativo invia già un messaggio RST (un messaggio TCP che la connessione è interrotta e il client non ha più nulla da catturare).

Chi ha inviato questo segnale? I processi in background di Postgres non si inviano tali segnali l'un l'altro, ad es. questo è kill-9. Non si scambiano cose del genere, reagiscono solo a tali cose, ad es. questo è un riavvio di emergenza di Postgres. Chi l'ha inviato, non lo so.

Ho guardato l'"ultimo" comando e ho visto una persona che ha anche effettuato l'accesso a questo server con noi, ma ero troppo timido per fare una domanda. Forse era kill -9. Vedrei kill -9 nei log, perché Postgres dice che ci sono voluti kill -9, ma non l'ho visto nei log.

Guardando oltre, ho visto che Patroni non ha scritto sul registro per molto tempo - 54 secondi. E se confrontiamo due timestamp, non ci sono stati messaggi per circa 54 secondi.

E durante questo periodo c'era un file automatico. Patroni ha fatto di nuovo un ottimo lavoro qui. Il nostro vecchio padrone non era disponibile, gli è successo qualcosa. E iniziò l'elezione di un nuovo maestro. Tutto ha funzionato bene qui. Il nostro pgsql01 è diventato il nuovo leader.

Abbiamo una replica che è diventata un maestro. E c'è una seconda risposta. E ci sono stati problemi con la seconda replica. Ha cercato di riconfigurare. A quanto ho capito, ha provato a modificare recovery.conf, riavviare Postgres e connettersi al nuovo master. Scrive messaggi ogni 10 secondi che sta provando, ma non ci riesce.

E durante questi tentativi, al vecchio padrone arriva un segnale di arresto immediato. Il master viene riavviato. E anche il ripristino si interrompe perché il vecchio master va in riavvio. Cioè, la replica non può connettersi ad essa, perché è in modalità di spegnimento.

Ad un certo punto ha funzionato, ma la replica non è stata avviata.

La mia unica ipotesi è che ci fosse un vecchio indirizzo principale in recovery.conf. E quando è apparso un nuovo master, la seconda replica ha comunque tentato di connettersi al vecchio master.

Quando Patroni è stato avviato sulla seconda replica, il nodo è stato avviato ma non è stato possibile replicare. E si è formato un ritardo di replicazione, che assomigliava a questo. Cioè, tutti e tre i nodi erano a posto, ma il secondo nodo è rimasto indietro.

Allo stesso tempo, se si esaminano i registri che sono stati scritti, è possibile vedere che la replica non può essere avviata perché i registri delle transazioni erano diversi. E quei registri delle transazioni offerti dal master, che sono specificati in recovery.conf, semplicemente non si adattano al nostro nodo attuale.

E qui ho commesso un errore. Sono dovuto venire a vedere cosa c'era in recovery.conf per verificare la mia ipotesi che ci stessimo connettendo al master sbagliato. Ma poi stavo solo affrontando questo e non mi è venuto in mente, oppure ho visto che la replica era in ritardo e avrebbe dovuto essere ricaricata, cioè in qualche modo ho lavorato con noncuranza. Questa era la mia canna.

Dopo 30 minuti è già arrivato l'amministratore, ad es. ho riavviato Patroni sulla replica. L'ho già messo fine, ho pensato che avrebbe dovuto essere riempito. E ho pensato: riavvierò Patroni, forse verrà fuori qualcosa di buono. Il recupero è iniziato. E la base si è persino aperta, era pronta ad accettare connessioni.

La replica è iniziata. Ma un minuto dopo è caduta con un errore secondo cui i registri delle transazioni non sono adatti a lei.

Ho pensato di ricominciare. Ho riavviato di nuovo Patroni e non ho riavviato Postgres, ma ho riavviato Patroni nella speranza che avviasse magicamente il database.

La replica è stata riavviata, ma i contrassegni nel registro delle transazioni erano diversi, non erano gli stessi del precedente tentativo di avvio. La replica si fermò di nuovo. E il messaggio era già leggermente diverso. E non è stato molto istruttivo per me.

E poi mi viene in mente: cosa succede se riavvio Postgres, in questo momento eseguo un checkpoint sul master corrente per spostare leggermente in avanti il ​​​​punto nel registro delle transazioni in modo che il ripristino inizi da un altro momento? Inoltre, avevamo ancora scorte di WAL.

Ho riavviato Patroni, fatto un paio di checkpoint sul master, un paio di punti di riavvio sulla replica quando si è aperta. E ha aiutato. Ho pensato a lungo perché ha aiutato e come ha funzionato. E la replica è iniziata. E la replica non era più strappata.

Un problema del genere per me è uno dei più misteriosi, sul quale mi scervella ancora su cosa sia realmente accaduto lì.

Quali sono le implicazioni qui? Patroni può funzionare come previsto e senza errori. Ma allo stesso tempo, questa non è una garanzia al 100% che per noi vada tutto bene. La replica potrebbe avviarsi, ma potrebbe trovarsi in uno stato semi-funzionante e l'applicazione non può funzionare con tale replica, poiché saranno presenti dati obsoleti.

E dopo il filer, devi sempre verificare che tutto sia in ordine con il cluster, ovvero che ci sia il numero richiesto di repliche, non ci sia ritardo di replica.

E mentre affrontiamo questi problemi, fornirò raccomandazioni. Ho provato a combinarli in due diapositive. Probabilmente, tutte le storie potrebbero essere combinate in due diapositive e solo raccontate.

Quando usi Patroni, devi avere il monitoraggio. Dovresti sempre sapere quando si è verificato un autofileover, perché se non sai di avere un autofileover, non hai alcun controllo sul cluster. E questo è male.

Dopo ogni filer, dobbiamo sempre controllare manualmente il cluster. Dobbiamo assicurarci di avere sempre un numero di repliche aggiornato, non ci sono repliche lag, non ci sono errori nei log relativi alla replica in streaming, con Patroni, con il sistema DCS.

L'automazione può funzionare con successo, Patroni è un ottimo strumento. Può funzionare, ma ciò non porterà il cluster allo stato desiderato. E se non lo scopriamo, saremo nei guai.

E Patroni non è un proiettile d'argento. Dobbiamo ancora capire come funziona Postgres, come funziona la replica e come funziona Patroni con Postgres e come viene fornita la comunicazione tra i nodi. Questo è necessario per poter risolvere i problemi con le tue mani.

Come affronto il problema della diagnosi? È successo così che lavoriamo con client diversi e nessuno ha uno stack ELK, e dobbiamo sistemare i registri aprendo 6 console e 2 schede. In una scheda, questi sono i log Patroni per ogni nodo, nell'altra scheda, questi sono i log Consul, o Postgres se necessario. È molto difficile diagnosticare questo.

Quali approcci ho adottato? Per prima cosa, guardo sempre quando è arrivato il filer. E per me questo è uno spartiacque. Guardo cosa è successo prima del filer, durante il filer e dopo il filer. Il fileover ha due segni: questa è l'ora di inizio e di fine.

Successivamente, cerco nei log gli eventi prima del filer, che hanno preceduto il filer, cioè cerco i motivi per cui si è verificato il filer.

E questo dà un'immagine della comprensione di cosa è successo e cosa si può fare in futuro in modo che tali circostanze non si verifichino (e, di conseguenza, non ci sia filer).

E dove guardiamo di solito? Io guardo:

• Innanzitutto, ai registri Patroni.
• Successivamente, guardo i log di Postgres o DCS, a seconda di cosa è stato trovato nei log di Patroni.
• E anche i registri di sistema a volte danno una comprensione di ciò che ha causato il filer.

Come mi sento per Patroni? Ho un ottimo rapporto con Patroni. Secondo me, questo è il meglio che c'è oggi. Conosco molti altri prodotti. Questi sono Stolon, Repmgr, Pg_auto_failover, PAF. 4 strumenti. Li ho provati tutti. Patroni è il mio preferito.

Se mi chiedono: "Consiglio Patroni?". Dirò di sì, perché mi piace Patroni. E penso di aver imparato a cucinarlo.

Se sei interessato a vedere quali altri problemi ci sono con Patroni oltre ai problemi che ho citato, puoi sempre controllare la pagina sicurezza su GitHub. Ci sono molte storie diverse e molte questioni interessanti vengono discusse lì. Di conseguenza, sono stati introdotti e risolti alcuni bug, ovvero questa è una lettura interessante.

Ci sono alcune storie interessanti su persone che si sparano ai piedi. Molto informativo. Leggi e capisci che non è necessario farlo. Ho spuntato me stesso.

E vorrei ringraziare di cuore Zalando per aver sviluppato questo progetto, in particolare Alexander Kukushkin e Alexey Klyukin. Aleksey Klyukin è uno dei coautori, non lavora più per Zalando, ma queste sono due persone che hanno iniziato a lavorare con questo prodotto.

E penso che Patroni sia una cosa molto interessante. Sono felice che esista, è interessante con lei. E un grande grazie a tutti i contributori che scrivono patch a Patroni. Spero che Patroni diventi più maturo, freddo ed efficiente con l'età. È già funzionante, ma spero che migliorerà ancora. Pertanto, se prevedi di utilizzare Patroni, non aver paura. Questa è una buona soluzione, può essere implementata e utilizzata.

È tutto. Se hai domande, chiedi.

domande

Grazie per la segnalazione! Se dopo un filer devi ancora guardare molto attentamente, allora perché abbiamo bisogno di un filer automatico?

Perché è roba nuova. Stiamo con lei solo da un anno. Meglio essere al sicuro. Vogliamo entrare e vedere che tutto ha funzionato davvero come dovrebbe. Questo è il livello di sfiducia degli adulti: è meglio ricontrollare e vedere.

Ad esempio, siamo andati la mattina e abbiamo guardato, giusto?

Non al mattino, di solito veniamo a conoscenza dell'autofile quasi immediatamente. Riceviamo notifiche, vediamo che si è verificato un file automatico. Andiamo quasi subito a guardare. Ma tutti questi controlli dovrebbero essere portati a livello di monitoraggio. Se accedi a Patroni tramite l'API REST, c'è una cronologia. Per cronologia puoi vedere i timestamp quando si è verificato il filer. Sulla base di ciò, è possibile eseguire il monitoraggio. Puoi vedere la cronologia, quanti eventi c'erano. Se abbiamo più eventi, si è verificato un file automatico. Puoi andare a vedere. Oppure la nostra automazione nel monitoraggio ha verificato che abbiamo tutte le repliche in atto, non ci sono ritardi e tutto va bene.

Grazie!

Grazie mille per la bella storia! Se abbiamo spostato il cluster DCS da qualche parte lontano dal cluster Postgres, anche questo cluster deve essere sottoposto a manutenzione periodica? Quali sono le migliori pratiche per cui alcuni pezzi del cluster DCS devono essere disattivati, qualcosa a che fare con loro, ecc.? Come sopravvive l'intera struttura? E come fai queste cose?

Per un'azienda era necessario creare una matrice di problemi, cosa succede se uno o più componenti si guastano. Secondo questa matrice, esaminiamo in sequenza tutti i componenti e costruiamo scenari in caso di guasto di questi componenti. Di conseguenza, per ogni scenario di errore, è possibile disporre di un piano d'azione per il ripristino. E nel caso di DCS, fa parte dell'infrastruttura standard. E l'amministratore lo amministra, e già ci affidiamo agli amministratori che lo amministrano e alla loro capacità di ripararlo in caso di incidenti. Se non esiste alcun DCS, lo distribuiamo, ma allo stesso tempo non lo monitoriamo particolarmente, perché non siamo responsabili dell'infrastruttura, ma diamo consigli su come e cosa monitorare.

Cioè, ho capito bene che devo disabilitare Patroni, disabilitare il filer, disabilitare tutto prima di fare qualsiasi cosa con gli host?

Dipende da quanti nodi abbiamo nel cluster DCS. Se ci sono molti nodi e se disabilitiamo solo uno dei nodi (la replica), allora il cluster mantiene un quorum. E Patroni resta operativo. E non scatta niente. Se abbiamo alcune operazioni complesse che interessano più nodi, la cui assenza può rovinare il quorum, allora sì, potrebbe avere senso mettere in pausa Patroni. Ha un comando corrispondente: patronictl pause, patronictl resume. Ci fermiamo e l'autofiler non funziona in quel momento. Facciamo manutenzione sul cluster DCS, poi togliamo la pausa e continuiamo a vivere.

La ringrazio molto!

Grazie mille per la tua segnalazione! Come si sente il team del prodotto riguardo alla perdita di dati?

Ai team di prodotto non interessa e i responsabili dei team sono preoccupati.

Quali garanzie ci sono?

Le garanzie sono molto difficili. Alexander Kukushkin ha un rapporto "Come calcolare RPO e RTO", ovvero il tempo di recupero e quanti dati possiamo perdere. Penso che dobbiamo trovare queste diapositive e studiarle. Per quanto ricordo, ci sono passaggi 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 questa è un'arma a doppio taglio: o abbiamo l'affidabilità dei dati o perdiamo velocità. Esiste una replica sincrona, ma non garantisce nemmeno una protezione al 100% contro la perdita di dati.

Alexey, grazie per l'ottimo rapporto! Qualche esperienza con l'utilizzo di Patroni per la protezione a livello zero? Cioè, insieme allo standby sincrono? Questa è la prima domanda. E la seconda domanda. Hai usato diverse soluzioni. Abbiamo utilizzato Repmgr, ma senza autofiler, e ora stiamo pianificando di includere l'autofiler. E consideriamo Patroni una soluzione alternativa. Cosa puoi dire come vantaggi rispetto a Repmgr?

La prima domanda riguardava le repliche sincrone. Nessuno usa la replica sincrona qui, perché tutti hanno paura (diversi client la stanno già utilizzando, in linea di principio, non hanno notato problemi di prestazioni - Nota del relatore). Ma abbiamo sviluppato una regola per noi stessi secondo cui dovrebbero esserci almeno tre nodi in un cluster di replica sincrona, perché se abbiamo due nodi e se il master o la replica falliscono, Patroni passa questo nodo alla modalità Standalone in modo che l'applicazione continui a lavoro. In questo caso, c'è il rischio di perdita di dati.

Per quanto riguarda la seconda domanda, abbiamo usato Repmgr e lo facciamo ancora con alcuni clienti per ragioni storiche. Cosa si può dire? Patroni viene fornito con un autofiler pronto all'uso, Repmgr viene fornito con l'autofiler come funzionalità aggiuntiva che deve essere abilitata. Dobbiamo eseguire il demone Repmgr su ciascun nodo e quindi possiamo configurare l'autofiler.

Repmgr controlla se i nodi Postgres sono attivi. I processi Repmgr controllano l'esistenza l'uno dell'altro, questo non è un approccio molto efficiente. possono verificarsi casi complessi di isolamento della rete in cui un cluster Repmgr di grandi dimensioni può scomporsi in diversi cluster più piccoli e continuare a funzionare. Non seguo Repmgr da molto tempo, forse è stato risolto... o forse no. Ma la rimozione delle informazioni sullo stato del cluster in DCS, come fa Stolon, Patroni, è l'opzione più praticabile.

Alexey, ho una domanda, forse più stupida. In uno dei primi esempi, hai spostato DCS dal computer locale a un host remoto. Capiamo che la rete è una cosa che ha le sue caratteristiche, vive di sé. E cosa succede se per qualche motivo il cluster DCS non è più disponibile? Non dirò i motivi, ce ne possono essere molti: dalle mani storte dei networker ai problemi reali.

Non l'ho detto ad alta voce, ma anche il cluster DCS deve essere failover, ovvero è un numero dispari di nodi, affinché venga raggiunto un quorum. Cosa succede se il cluster DCS non è più disponibile o non è possibile raggiungere un quorum, ad esempio un qualche tipo di divisione della rete o errore del nodo? In questo caso, il cluster Patroni entra in modalità di sola lettura. Il cluster Patroni non è in grado di determinare lo stato del cluster e cosa fare. Non può contattare il DCS e memorizzare lì il nuovo stato del cluster, quindi l'intero cluster va in sola lettura. E attende l'intervento manuale dell'operatore o il ripristino del DCS.

In parole povere, DCS diventa per noi un servizio importante quanto la base stessa?

Si si. In così tante aziende moderne, Service Discovery è parte integrante dell'infrastruttura. Viene implementato anche prima che esistesse un database nell'infrastruttura. Relativamente parlando, l'infrastruttura è stata lanciata, distribuita nel DC e abbiamo immediatamente Service Discovery. Se è Consul, è possibile creare DNS su di esso. Se questo è Etcd, potrebbe esserci una parte del cluster Kubernetes, in cui verrà distribuito tutto il resto. Mi sembra che Service Discovery sia già parte integrante delle moderne infrastrutture. E ci pensano molto prima che sui database.

Grazie!

Fonte: habr.com