Cluster di failover PostgreSQL + Patroni. Esperienza di implementazione

Nell'articolo ti racconterò come abbiamo affrontato la questione della tolleranza agli errori di PostgreSQL, perché è diventata importante per noi e cosa è successo alla fine.

Disponiamo di un servizio molto ricco: 2,5 milioni di utenti in tutto il mondo, oltre 50 utenti attivi ogni giorno. I server si trovano ad Amazone in una regione dell'Irlanda: oltre 100 server diversi funzionano costantemente, di cui quasi 50 con database.

L'intero backend è una grande applicazione Java monolitica con stato che mantiene una connessione websocket costante con il client. Quando più utenti lavorano contemporaneamente sulla stessa scheda, tutti vedono le modifiche in tempo reale, perché scriviamo ogni modifica nel database. Abbiamo circa 10 richieste al secondo nei nostri database. Al picco di carico in Redis, scriviamo 80-100 richieste al secondo.

Perché siamo passati da Redis a PostgreSQL

Inizialmente, il nostro servizio funzionava con Redis, un archivio di valori-chiave che archivia tutti i dati nella RAM del server.

Pro di Redis:

1. Alta velocità di risposta, perché tutto è archiviato in memoria;
2. Facilità di backup e replica.

Contro di Redis per noi:

1. Non ci sono transazioni reali. Abbiamo provato a simularli a livello della nostra applicazione. Sfortunatamente, questo non sempre funzionava bene e richiedeva la scrittura di un codice molto complesso.
2. La quantità di dati è limitata dalla quantità di memoria. All'aumentare della quantità di dati, la memoria crescerà e, alla fine, ci imbatteremo nelle caratteristiche dell'istanza selezionata, che in AWS richiede l'interruzione del nostro servizio per cambiare il tipo di istanza.
3. È necessario mantenere costantemente un basso livello di latenza, perché. abbiamo un numero molto elevato di richieste. Il livello di ritardo ottimale per noi è 17-20 ms. A un livello di 30-40 ms, otteniamo risposte lunghe alle richieste delle nostre applicazioni e al degrado del servizio. Sfortunatamente, questo ci è successo a settembre 2018, quando una delle istanze con Redis per qualche motivo ha ricevuto una latenza 2 volte superiore al solito. Per risolvere il problema, abbiamo interrotto il servizio nel bel mezzo della giornata lavorativa per manutenzione non programmata e abbiamo sostituito l'istanza Redis problematica.
4. È facile riscontrare un'incoerenza dei dati anche con errori minori nel codice e quindi dedicare molto tempo alla scrittura del codice per correggere questi dati.

Abbiamo preso in considerazione i contro e ci siamo resi conto che dovevamo passare a qualcosa di più conveniente, con transazioni normali e meno dipendenza dalla latenza. Ho condotto ricerche, analizzato molte opzioni e ho scelto PostgreSQL.

Ci stiamo trasferendo in un nuovo database già da 1,5 anni e abbiamo spostato solo una piccola parte dei dati, quindi ora stiamo lavorando contemporaneamente con Redis e PostgreSQL. Sono scritte ulteriori informazioni sulle fasi di spostamento e passaggio dei dati tra database l'articolo del mio collega.

Quando abbiamo iniziato a spostarci, la nostra applicazione funzionava direttamente con il database e accedeva al master Redis e PostgreSQL. Il cluster PostgreSQL era costituito da un master e da una replica con replica asincrona. Ecco come appariva lo schema del database:

Implementazione di PgBouncer

Mentre ci trasferivamo, anche il prodotto si sviluppava: aumentava il numero di utenti e il numero di server che funzionavano con PostgreSQL e cominciavano a mancarci le connessioni. PostgreSQL crea un processo separato per ogni connessione e consuma risorse. È possibile aumentare il numero di connessioni fino a un certo punto, altrimenti esiste la possibilità di ottenere prestazioni del database non ottimali. L'opzione ideale in una situazione del genere sarebbe quella di scegliere un gestore di connessione che si troverà di fronte alla base.

Avevamo due opzioni per la gestione della connessione: Pgpool e PgBouncer. Ma il primo non supporta la modalità transazionale di lavoro con il database, quindi abbiamo scelto PgBouncer.

Abbiamo impostato il seguente schema di lavoro: la nostra applicazione accede a un PgBouncer, dietro il quale ci sono i master PostgreSQL, e dietro ogni master c'è una replica con replica asincrona.


Allo stesso tempo, non potevamo archiviare l'intera quantità di dati in PostgreSQL e per noi era importante la velocità di lavoro con il database, quindi abbiamo iniziato a condividere PostgreSQL a livello di applicazione. Lo schema sopra descritto è relativamente conveniente per questo: quando si aggiunge un nuovo shard PostgreSQL, è sufficiente aggiornare la configurazione di PgBouncer e l'applicazione potrà immediatamente funzionare con il nuovo shard.

Failover di PgBouncer

Questo schema ha funzionato fino al momento in cui è morta l'unica istanza di PgBouncer. Siamo in AWS, dove tutte le istanze sono in esecuzione su hardware che muore periodicamente. In questi casi, l'istanza si sposta semplicemente su un nuovo hardware e funziona di nuovo. Questo è successo con PgBouncer, ma non è più disponibile. Il risultato di questo autunno è stata l'indisponibilità del nostro servizio per 25 minuti. AWS consiglia di utilizzare la ridondanza lato utente per tali situazioni, che all'epoca non era implementata nel nostro Paese.

Successivamente, abbiamo pensato seriamente alla tolleranza agli errori dei cluster PgBouncer e PostgreSQL, perché una situazione simile potrebbe verificarsi con qualsiasi istanza nel nostro account AWS.

Abbiamo costruito lo schema di tolleranza agli errori di PgBouncer come segue: tutti i server delle applicazioni accedono al Network Load Balancer, dietro il quale ci sono due PgBouncer. Ogni PgBouncer esamina lo stesso master PostgreSQL di ogni frammento. Se si verifica nuovamente un arresto anomalo di un'istanza AWS, tutto il traffico viene reindirizzato tramite un altro PgBouncer. Il failover di Network Load Balancer è fornito da AWS.

Questo schema semplifica l'aggiunta di nuovi server PgBouncer.

Crea un cluster di failover PostgreSQL

Nel risolvere questo problema, abbiamo considerato diverse opzioni: failover autoscritto, repmgr, AWS RDS, Patroni.

Sceneggiature autoprodotte

Possono monitorare il lavoro del master e, in caso di guasto, promuovere la replica al master e aggiornare la configurazione di PgBouncer.

I vantaggi di questo approccio sono la massima semplicità, perché scrivi tu stesso gli script e capisci esattamente come funzionano.

contro:

• Il master potrebbe non essere morto, ma potrebbe essersi verificato un errore di rete. Il failover, ignaro di ciò, promuoverà la replica al master, mentre il vecchio master continuerà a funzionare. Di conseguenza, otterremo due server nel ruolo di master e non sapremo quale di essi ha i dati aggiornati più recenti. Questa situazione è anche chiamata cervello diviso;
• Siamo rimasti senza risposta. Nella nostra configurazione, il master e una replica, dopo il passaggio, la replica si sposta sul master e non abbiamo più repliche, quindi dobbiamo aggiungere manualmente una nuova replica;
• Abbiamo bisogno di un monitoraggio aggiuntivo dell'operazione di failover, mentre disponiamo di 12 frammenti PostgreSQL, il che significa che dobbiamo monitorare 12 cluster. Con l'aumento del numero di shard è necessario ricordarsi anche di aggiornare il failover.

Il failover autoprodotto sembra molto complicato e richiede un supporto non banale. Con un singolo cluster PostgreSQL, questa sarebbe l'opzione più semplice, ma non è scalabile, quindi non è adatta a noi.

Repmgr

Replication Manager per cluster PostgreSQL, che può gestire il funzionamento di un cluster PostgreSQL. Allo stesso tempo, non dispone di un failover automatico pronto all'uso, quindi per lavoro dovrai scrivere il tuo "wrapper" sopra la soluzione finita. Quindi tutto può rivelarsi ancora più complicato che con gli script scritti da noi, quindi non abbiamo nemmeno provato Repmgr.

RDS AWS

Supporta tutto ciò di cui abbiamo bisogno, sa come eseguire i backup e mantiene un pool di connessioni. Ha una commutazione automatica: quando il master muore, la replica diventa il nuovo master e AWS cambia il record DNS nel nuovo master, mentre le repliche possono essere posizionate in AZ diverse.

Gli svantaggi includono la mancanza di regolazioni fini. Come esempio di messa a punto: le nostre istanze hanno restrizioni per le connessioni TCP, cosa che sfortunatamente non può essere eseguita in RDS:

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

Inoltre, AWS RDS costa quasi il doppio rispetto al prezzo di un’istanza normale, motivo principale per abbandonare questa soluzione.

patrono

Questo è un modello Python per la gestione di PostgreSQL con una buona documentazione, failover automatico e codice sorgente su github.

Pro di Patroni:

• Ogni parametro di configurazione è descritto, è chiaro come funziona;
• Il failover automatico funziona immediatamente;
• Scritto in python, e visto che noi stessi scriviamo molto in python, ci sarà più facile affrontare i problemi e, magari, anche aiutare lo sviluppo del progetto;
• Gestisce completamente PostgreSQL, consente di modificare la configurazione su tutti i nodi del cluster contemporaneamente e, se è necessario riavviare il cluster per applicare la nuova configurazione, è possibile farlo nuovamente utilizzando Patroni.

contro:

• Dalla documentazione non è chiaro come lavorare correttamente con PgBouncer. Anche se è difficile definirlo un aspetto negativo, perché il compito di Patroni è gestire PostgreSQL, e come andranno le connessioni a Patroni è già un nostro problema;
• Sono pochi gli esempi di implementazione di Patroni su grandi volumi, mentre sono molti gli esempi di implementazione ex novo.

Di conseguenza, abbiamo scelto Patroni per creare un cluster di failover.

Processo di implementazione di Patroni

Prima di Patroni, avevamo 12 frammenti PostgreSQL in una configurazione di un master e una replica con replica asincrona. I server delle applicazioni accedevano ai database tramite Network Load Balancer, dietro il quale c'erano due istanze con PgBouncer, e dietro di loro c'erano tutti i server PostgreSQL.


Per implementare Patroni, dovevamo selezionare una configurazione di cluster di archiviazione distribuito. Patroni funziona con sistemi di archiviazione di configurazioni distribuite come etcd, Zookeeper, Consul. Abbiamo solo un cluster Console a tutti gli effetti sul mercato, che funziona insieme a Vault e non lo utilizziamo più. Un ottimo motivo per iniziare a utilizzare Consul per lo scopo previsto.

Come Patroni collabora con Console

Abbiamo un cluster Consul, che consiste di tre nodi, e un cluster Patroni, che consiste in un leader e una replica (in Patroni, il master è chiamato leader del cluster e gli slave sono chiamati repliche). Ogni istanza del cluster Patroni invia costantemente informazioni sullo stato del cluster a Consul. Da Console potrai quindi sempre conoscere l'attuale configurazione del cluster Patroni e chi ne è il leader in questo momento.

Per connettere Patroni a Consul, è sufficiente studiare la documentazione ufficiale, che dice che è necessario specificare un host in formato http o https, a seconda di come lavoriamo con Consul, e lo schema di connessione, a scelta:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

Sembra semplice, ma qui iniziano le insidie. Con Consul, lavoriamo su una connessione sicura tramite https e la nostra configurazione di connessione sarà simile a questa:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

Ma questo non funziona. All'avvio Patroni non riesce a connettersi a Consul, perché tenta comunque di passare tramite http.

Il codice sorgente di Patroni ha aiutato ad affrontare il problema. È positivo che sia scritto in Python. Risulta che il parametro host non viene analizzato in alcun modo e il protocollo deve essere specificato nello schema. Ecco come appare per noi un blocco di configurazione funzionante per lavorare con Consul:

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

modello-console

Quindi, abbiamo scelto lo spazio di archiviazione per la configurazione. Ora dobbiamo capire come PgBouncer cambierà la sua configurazione quando cambierà il leader nel cluster Patroni. Non c'è risposta a questa domanda nella documentazione, perché. lì, in linea di principio, il lavoro con PgBouncer non è descritto.

Alla ricerca di una soluzione, abbiamo trovato un articolo (purtroppo non ricordo il titolo) in cui era scritto che Сonsul-template ha aiutato molto nell'accoppiare PgBouncer e Patroni. Ciò ci ha spinto a indagare su come funziona il modello Console.

Si è scoperto che Consul-template monitora costantemente la configurazione del cluster PostgreSQL in Consul. Quando cambia il leader, aggiorna la configurazione di PgBouncer e invia un comando per ricaricarlo.

Un grande vantaggio del modello è che viene archiviato come codice, quindi quando si aggiunge un nuovo frammento, è sufficiente effettuare un nuovo commit e aggiornare automaticamente il modello, supportando il principio Infrastruttura come codice.

Nuova architettura con Patroni

Di conseguenza, abbiamo ottenuto il seguente schema di lavoro:


Tutti i server delle applicazioni accedono al bilanciatore → dietro di esso ci sono due istanze di PgBouncer → su ogni istanza è in esecuzione un modello Consul, che monitora lo stato di ciascun cluster Patroni e monitora la pertinenza della configurazione di PgBouncer, che indirizza le richieste all'attuale leader di ciascun cluster.

Test manuali

Abbiamo eseguito questo schema prima di lanciarlo in un piccolo ambiente di prova e abbiamo verificato il funzionamento della commutazione automatica. Hanno aperto il tabellone, spostato l'adesivo e in quel momento hanno "ucciso" il leader del cluster. In AWS, questo è semplice come spegnere l'istanza tramite la console.

L'adesivo è tornato indietro entro 10-20 secondi e poi ha ripreso a muoversi normalmente. Ciò significa che il cluster Patroni ha funzionato correttamente: ha cambiato il leader, ha inviato le informazioni a Сonsul, e Сonsul-template ha immediatamente raccolto queste informazioni, ha sostituito la configurazione di PgBouncer e ha inviato il comando di ricaricare.

Come sopravvivere sotto carico elevato e ridurre al minimo i tempi di inattività?

Tutto funziona perfettamente! Ma ci sono nuove domande: come funzionerà in condizioni di carico elevato? Come implementare in modo rapido e sicuro tutto in produzione?

L'ambiente di test su cui conduciamo i test di carico ci aiuta a rispondere alla prima domanda. È completamente identico alla produzione in termini di architettura e ha generato dati di test che sono approssimativamente uguali in volume alla produzione. Decidiamo di “uccidere” semplicemente uno dei master PostgreSQL durante il test e vedere cosa succede. Ma prima è importante controllare il rollio automatico, perché in questo ambiente abbiamo diversi frammenti PostgreSQL, quindi otterremo un eccellente test degli script di configurazione prima della produzione.

Entrambi i compiti sembrano ambiziosi, ma abbiamo PostgreSQL 9.6. Possiamo aggiornare immediatamente alla 11.2?

Decidiamo di farlo in 2 passaggi: prima l'aggiornamento alla 11.2, poi lancio Patroni.

Aggiornamento PostgreSQL

Per aggiornare rapidamente la versione PostgreSQL, utilizzare l'opzione -k, in cui i collegamenti reali vengono creati sul disco e non è necessario copiare i dati. Su basi da 300-400 GB l'aggiornamento richiede 1 secondo.

Abbiamo molti frammenti, quindi l'aggiornamento deve essere eseguito automaticamente. Per fare ciò, abbiamo scritto un playbook Ansible che gestisce per noi l'intero processo di aggiornamento:

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

È importante notare qui che prima di iniziare l'aggiornamento, è necessario eseguirlo con il parametro --controlloper assicurarti di poter eseguire l'aggiornamento. Il nostro script effettua anche la sostituzione delle configurazioni per la durata dell'aggiornamento. Il nostro script è stato completato in 30 secondi, il che è un risultato eccellente.

Lancia Patroni

Per risolvere il secondo problema basta guardare la configurazione Patroni. Il repository ufficiale ha una configurazione di esempio con initdb, che è responsabile dell'inizializzazione di un nuovo database al primo avvio di Patroni. Ma poiché disponiamo già di un database già pronto, abbiamo semplicemente rimosso questa sezione dalla configurazione.

Quando abbiamo iniziato a installare Patroni su un cluster PostgreSQL già esistente e a eseguirlo, ci siamo imbattuti in un nuovo problema: entrambi i server sono partiti come leader. Patroni non sa nulla dello stato iniziale del cluster e tenta di avviare entrambi i server come due cluster separati con lo stesso nome. Per risolvere questo problema è necessario eliminare la directory con i dati sullo slave:

rm -rf /var/lib/postgresql/

Questo deve essere fatto solo sullo schiavo!

Quando una replica pulita è connessa, Patroni crea un leader di backup di base e lo ripristina sulla replica, quindi si aggiorna con lo stato corrente in base ai registri wal.

Un'altra difficoltà che abbiamo riscontrato è che tutti i cluster PostgreSQL sono denominati main per impostazione predefinita. Quando ciascun cluster non sa nulla dell'altro, questo è normale. Ma quando vuoi usare Patroni, tutti i cluster devono avere un nome univoco. La soluzione è modificare il nome del cluster nella configurazione PostgreSQL.

test di carico

Abbiamo lanciato un test che simula l'esperienza dell'utente sulle board. Quando il carico ha raggiunto il nostro valore medio giornaliero, abbiamo ripetuto esattamente lo stesso test, abbiamo disattivato un'istanza con il leader PostgreSQL. Il failover automatico ha funzionato come ci aspettavamo: Patroni ha cambiato il leader, Consul-template ha aggiornato la configurazione di PgBouncer e ha inviato un comando per ricaricare. Secondo i nostri grafici in Grafana, era chiaro che ci sono ritardi di 20-30 secondi e una piccola quantità di errori dai server associati alla connessione al database. Questa è una situazione normale, tali valori sono accettabili per il nostro failover e sono decisamente migliori del tempo di inattività del servizio.

Portare Patroni in produzione

Di conseguenza, abbiamo elaborato il seguente piano:

• Distribuisci il modello Console sui server PgBouncer e avvialo;
• Aggiornamenti PostgreSQL alla versione 11.2;
• Modificare il nome del cluster;
• Avvio del Cluster Patroni.

Allo stesso tempo, il nostro schema ci consente di fare il primo punto quasi in qualsiasi momento, possiamo rimuovere dal lavoro ciascun PgBouncer a turno e distribuire ed eseguire consul-template su di esso. Così abbiamo fatto.

Per una distribuzione rapida, abbiamo utilizzato Ansible, poiché abbiamo già testato tutti i playbook in un ambiente di test e il tempo di esecuzione dello script completo è stato compreso tra 1,5 e 2 minuti per ogni shard. Potremmo distribuire tutto uno dopo l'altro su ogni frammento senza interrompere il nostro servizio, ma dovremmo disattivare ciascun PostgreSQL per diversi minuti. In questo caso, gli utenti i cui dati si trovano su questo frammento non potrebbero funzionare completamente in questo momento e questo è inaccettabile per noi.

La via d'uscita da questa situazione è stata la manutenzione programmata, che avviene ogni 3 mesi. Questa è una finestra per il lavoro pianificato, quando chiudiamo completamente il nostro servizio e aggiorniamo le istanze del nostro database. Mancava una settimana alla finestra successiva e abbiamo deciso di aspettare e prepararci ulteriormente. Durante il tempo di attesa, ci siamo ulteriormente protetti: per ogni frammento PostgreSQL, abbiamo creato una replica di riserva in caso di mancata conservazione dei dati più recenti e abbiamo aggiunto una nuova istanza per ogni frammento, che dovrebbe diventare una nuova replica nel cluster Patroni, in modo da non eseguire un comando per cancellare i dati. Tutto ciò ha contribuito a ridurre al minimo il rischio di errore.


Abbiamo riavviato il nostro servizio, tutto ha funzionato come doveva, gli utenti hanno continuato a lavorare, ma sui grafici abbiamo notato un carico anormalmente elevato sui server Consul.


Perché non l'abbiamo visto nell'ambiente di test? Questo problema illustra molto bene la necessità di seguire il principio Infrastructure as code e perfezionare l'intera infrastruttura, dagli ambienti di test alla produzione. Altrimenti, è molto facile ottenere il problema che abbiamo riscontrato. Quello che è successo? Console è apparso per la prima volta in produzione e poi negli ambienti di test, di conseguenza, negli ambienti di test, la versione di Console era superiore a quella in produzione. Proprio in una delle versioni è stata risolta una perdita della CPU durante l'utilizzo del template console. Pertanto abbiamo semplicemente aggiornato Consul, risolvendo così il problema.

Riavviare il cluster Patroni

Tuttavia, abbiamo riscontrato un nuovo problema, di cui non sospettavamo nemmeno. Quando aggiorniamo Consul, rimuoviamo semplicemente il nodo Consul dal cluster usando il comando consul Leave → Patroni si connette ad un altro server Consul → tutto funziona. Ma quando abbiamo raggiunto l'ultima istanza del cluster Consul e gli abbiamo inviato il comando consul Leave, tutti i cluster Patroni si sono semplicemente riavviati e nei log abbiamo riscontrato il seguente errore:

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

Il cluster Patroni non è riuscito a recuperare le informazioni sul proprio cluster ed è stato riavviato.

Per trovare una soluzione abbiamo contattato gli autori Patroni tramite un problema su github. Hanno suggerito miglioramenti ai nostri file di configurazione:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

Siamo riusciti a replicare il problema in un ambiente di test e testare lì queste opzioni, ma sfortunatamente non hanno funzionato.

Il problema resta ancora irrisolto. Abbiamo intenzione di provare le seguenti soluzioni:

• Utilizza Consul-agent su ogni istanza del cluster Patroni;
• Risolvi il problema nel codice.

Capiamo dove si è verificato l'errore: probabilmente il problema è l'utilizzo del timeout predefinito, che non viene sovrascritto tramite il file di configurazione. Quando l'ultimo server Consul viene rimosso dal cluster, l'intero cluster Consul si blocca per più di un secondo, per questo motivo Patroni non può ottenere lo stato del cluster e riavvia completamente l'intero cluster.

Fortunatamente non abbiamo riscontrato più errori.

Risultati dell'utilizzo di Patroni

Dopo il successo del lancio di Patroni, abbiamo aggiunto un'ulteriore replica in ciascun cluster. Ora in ciascun cluster esiste una parvenza di quorum: un leader e due repliche, come rete di sicurezza in caso di split-brain durante il passaggio.


Patroni sta lavorando alla produzione da più di tre mesi. Durante questo periodo è già riuscito ad aiutarci. Recentemente, il leader di uno dei cluster è morto in AWS, il failover automatico ha funzionato e gli utenti hanno continuato a lavorare. Patroni ha adempiuto al suo compito principale.

Un piccolo riassunto dell'utilizzo di Patroni:

• Facilità di modifiche alla configurazione. È sufficiente modificare la configurazione su un'istanza e verrà trasferita all'intero cluster. Se è necessario un riavvio per applicare la nuova configurazione, Patroni ti avviserà. Patroni può riavviare l'intero cluster con un unico comando, il che è anche molto comodo.
• Il failover automatico funziona ed è già riuscito ad aiutarci.
• Aggiornamento PostgreSQL senza tempi di inattività dell'applicazione. È necessario prima aggiornare le repliche alla nuova versione, quindi modificare il leader nel cluster Patroni e aggiornare il vecchio leader. In questo caso, viene eseguito il test necessario del failover automatico.

Fonte: habr.com