Cluster di failover PostgreSQL + Patroni. Esperienza di implementazione

In l'articulu vi dicu cumu avemu avvicinatu u prublema di a tolleranza di difetti di PostgreSQL, perchè hè diventatu impurtante per noi è ciò chì hè accadutu à a fine.

Avemu un serviziu assai carricu: 2,5 milioni d'utilizatori in u mondu sanu, 50K+ utilizatori attivi ogni ghjornu. I servitori sò situati in Amazone in una regione di l'Irlanda: 100 + diversi servitori sò in permanenza in travagliu, di quale quasi 50 sò cun basa di dati.

Tuttu u backend hè una grande applicazione Java monolitica statale chì mantene una cunnessione websocket constante cù u cliente. Quandu parechji utilizatori travaglianu nantu à u stessu tavulinu à u stessu tempu, tutti vedenu i cambiamenti in tempu reale, perchè scrivimu ogni cambiamentu à a basa di dati. Avemu circa 10K richieste per seconda à e nostre basa di dati. À a carica massima in Redis, scrivimu 80-100K richieste per seconda.

Perchè avemu cambiatu da Redis à PostgreSQL

Inizialmente, u nostru serviziu hà travagliatu cù Redis, un magazinu di valore chjave chì guarda tutte e dati in a RAM di u servitore.

Pro di Redis:

1. Alta velocità di risposta, perchè tuttu hè guardatu in memoria;
2. Facilità di salvezza è replicazione.

Cons di Redis per noi:

1. Ùn ci hè micca transazzione vera. Avemu pruvatu à simule à u livellu di a nostra applicazione. Sfortunatamente, questu ùn hà micca sempre travagliatu bè è hà bisognu di scrive un codice assai cumplessu.
2. A quantità di dati hè limitata da a quantità di memoria. Cum'è a quantità di dati aumenta, a memoria cresce, è, à a fine, andemu in e caratteristiche di l'istanza selezziunata, chì in AWS hà bisognu di firmà u nostru serviziu per cambià u tipu d'istanza.
3. Hè necessariu di mantene constantemente un livellu di latenza bassu, perchè. avemu un gran numaru di richieste. U livellu di ritardu ottimale per noi hè 17-20 ms. À un livellu di 30-40 ms, avemu risposti longu à e dumande da a nostra applicazione è degradazione di u serviziu. Sfurtunatamente, questu hè accadutu à noi in settembre di u 2018, quandu unu di i casi cù Redis per una certa ragione hà ricevutu latenza 2 volte più di u solitu. Per risolve u prublema, avemu firmatu u serviziu à mità di ghjornu per un mantenimentu imprecisatu è rimpiazzatu l'istanza problematica Redis.
4. Hè facilitu pè ottene l'incoerenza di dati ancu cù errori minori in u codice è poi passanu assai tempu à scrive u codice per correggerà sta dati.

Avemu pigliatu in contu i contra è capitu chì avemu bisognu di passà à qualcosa più cunvene, cù transazzione normale è menu dependenza di latenza. Ricerca realizatu, analizatu parechje opzioni è sceltu PostgreSQL.

Avemu passatu à una nova basa di dati per 1,5 anni digià è avemu spustatu solu una piccula parte di e dati, cusì avà avemu travagliatu simultaneamente cù Redis è PostgreSQL. Più infurmazione nantu à e tappe di u muvimentu è u cambiamentu di dati trà e basa di dati hè scritta l'articulu di u mo cumpagnu.

Quandu avemu principiatu u muvimentu, a nostra applicazione hà travagliatu direttamente cù a basa di dati è accede à u maestru Redis è PostgreSQL. U cluster PostgreSQL hè custituitu da un maestru è una replica cù replicazione asincrona. Hè cusì chì u schema di basa di dati pareva:

Implementazione di PgBouncer

Mentre ci muviamu, u pruduttu era ancu sviluppatu: u numeru di utilizatori è u numeru di servitori chì travagliavanu cù PostgreSQL anu aumentatu, è avemu cuminciatu à manca di cunnessione. PostgreSQL crea un prucessu separatu per ogni cunnessione è cunsuma risorse. Pudete aumentà u nùmeru di cunnessione finu à un certu puntu, altrimenti ci hè una chance per ottene un rendimentu di basa di dati suboptimal. L'opzione ideale in una tale situazione seria di sceglie un gestore di cunnessione chì stà davanti à a basa.

Avemu avutu duie opzioni per u gestore di cunnessione: Pgpool è PgBouncer. Ma u primu ùn sustene micca u modu transazionale di travaglià cù a basa di dati, cusì avemu sceltu PgBouncer.

Avemu stabilitu u seguente schema di travagliu: a nostra applicazione accede à un PgBouncer, daretu à quale sò i maestri PostgreSQL, è daretu à ogni maestru hè una replica cù replicazione asincrona.


À u listessu tempu, ùn pudemu micca almacenà tutta a quantità di dati in PostgreSQL è a rapidità di travaglià cù a basa di dati era impurtante per noi, cusì avemu cuminciatu à sharding PostgreSQL à u livellu di l'applicazione. U schema descrittu sopra hè relativamente cunvenutu per questu: quandu aghjunghje un novu shard PostgreSQL, hè abbastanza per aghjurnà a cunfigurazione PgBouncer è l'applicazione pò travaglià immediatamente cù u novu shard.

PgBouncer failover

Stu schema hà travagliatu finu à u mumentu chì l'unica istanza di PgBouncer hè morta. Semu in AWS, induve tutte e istanze sò in esecuzione nantu à hardware chì mori periodicamente. In tali casi, l'istanza si move solu à un novu hardware è funziona di novu. Questu hè accadutu cù PgBouncer, ma hè diventatu indisponibile. U risultatu di sta caduta era a indisponibilità di u nostru serviziu per 25 minuti. AWS ricumanda di utilizà a redundanza di l'utilizatori per tali situazioni, chì ùn era micca implementatu in u nostru paese à quellu tempu.

Dopu questu, avemu pensatu seriamente à a tolleranza di difetti di i clusters PgBouncer è PostgreSQL, perchè una situazione simile puderia accade cù qualsiasi istanza in u nostru contu AWS.

Avemu custruitu u schema di tolleranza di difetti PgBouncer cum'è seguente: tutti i servitori di l'applicazioni accede à u Network Load Balancer, daretu à quale ci sò dui PgBouncers. Ogni PgBouncer vede u stessu maestru PostgreSQL di ogni shard. Se un crash di l'istanza AWS si verifica di novu, tuttu u trafficu hè redirezzione attraversu un altru PgBouncer. U failover di Network Load Balancer hè furnitu da AWS.

Stu schema facilita l'aghjunghje novi servitori PgBouncer.

Crea un Cluster di Failover PostgreSQL

Quandu risolve stu prublema, avemu cunsideratu diverse opzioni: failover auto-scrittu, repmgr, AWS RDS, Patroni.

Scritti auto-scritti

Puderanu monitorà u travagliu di u maestru è, se falla, prumove a replica à u maestru è aghjurnà a cunfigurazione PgBouncer.

I vantaghji di stu approcciu sò a simplicità massima, perchè scrivite scripts sè stessu è capisce esattamente cumu travaglianu.

Cons:

• U maestru puderia micca esse mortu, invece un fallimentu di a rete puderia esse accadutu. Failover, inconsciente di questu, prumove a replica à u maestru, mentre chì u vechju maestru continuarà à travaglià. In u risultatu, averemu dui servitori in u rolu di maestru è ùn sapemu micca quale di elli hà l'ultime data up-to-date. Sta situazione hè ancu chjamata split-brain;
• Semu stati lasciati senza risposta. In a nostra cunfigurazione, u maestru è una replica, dopu à cambià, a replica si move finu à u maestru è ùn avemu più rèplichi, cusì avemu da aghjunghje manualmente una nova replica;
• Avemu bisognu di monitoraghju supplementu di l'operazione di failover, mentri avemu 12 shards PostgreSQL, chì significa chì avemu da monitorà 12 clusters. Cù un aumentu di u numeru di shards, devi ancu ricurdà di aghjurnà u failover.

U failover auto-scrittu pare assai cumplicatu è richiede un supportu micca trivial. Cù un solu cluster PostgreSQL, questu seria l'opzione più faciule, ma ùn scala micca, per quessa ùn hè micca adattatu per noi.

Remgr

Replication Manager per i clusters PostgreSQL, chì ponu gestisce l'operazione di un cluster PostgreSQL. À u listessu tempu, ùn hà micca un failover automaticu fora di a scatula, cusì per u travagliu avete bisognu di scrive u vostru propiu "wrapper" nantu à a suluzione finita. Allora tuttu pò esce ancu più cumplicatu chè cù script scritti da sè stessu, cusì ùn avemu mancu pruvatu Repmgr.

AWS RDS

Supporta tuttu ciò chì avemu bisognu, sà cumu fà backups è mantene una piscina di cunnessione. Hà un cambiamentu automaticu: quandu u maestru mori, a replica diventa u novu maestru, è AWS cambia u record dns à u novu maestru, mentre chì e repliche ponu esse situate in diverse AZ.

I svantaghji includenu a mancanza di fine adjustments. Cum'è un esempiu di fine tuning: i nostri casi anu restrizioni per e cunnessione tcp, chì, sfurtunatamenti, ùn ponu micca esse fattu 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 hè quasi duie volte più caru di u prezzu di l'istanza regulare, chì era u mutivu principale per abbandunà sta suluzione.

Patroni

Questu hè un mudellu python per a gestione di PostgreSQL cù una bona documentazione, failover automaticu è codice fonte in github.

Avanti di Patroni:

• Ogni paràmetru di cunfigurazione hè descrittu, hè chjaru cumu si travaglia;
• U failover automaticu funziona fora di a scatula;
• Scrittu in python, è postu chì noi stessi scrivemu assai in python, serà più faciule per noi di trattà di prublemi è, forsi, ancu aiutà à u sviluppu di u prugettu;
• Gestisce cumplettamente PostgreSQL, permette di cambià a cunfigurazione in tutti i nodi di u cluster in una volta, è se u cluster deve esse riavviatu per applicà a nova cunfigurazione, allora questu pò esse fattu di novu cù Patroni.

Cons:

• Ùn hè micca chjaru da a documentazione cumu travaglià cù PgBouncer currettamente. Ancu s'ellu hè difficiule di chjamà un minus, perchè u compitu di Patroni hè di gestisce PostgreSQL, è cumu andaranu e cunnessione à Patroni hè digià u nostru prublema;
• Ci sò pochi esempi di implementazione di Patroni nantu à volumi grossi, mentri ci sò parechji esempi di implementazione da zero.

In u risultatu, avemu sceltu Patroni per creà un cluster failover.

Prucessu di Implementazione Patroni

Prima di Patroni, avemu avutu 12 shards PostgreSQL in una cunfigurazione di un maestru è una replica cù replicazione asincrona. I servitori di l'applicazioni accede à e basa di dati attraversu u Network Load Balancer, daretu à quale ci eranu dui casi cù PgBouncer, è daretu à elli eranu tutti i servitori PostgreSQL.


Per implementà Patroni, avemu bisognu di selezziunà una cunfigurazione di cluster di almacenamiento distribuitu. Patroni travaglia cù sistemi di almacenamentu di cunfigurazione distribuitu cum'è etcd, Zookeeper, Consul. Avemu ghjustu un cluster Full-fledged Consul nant'à u mercatu, chì travaglia in cunghjunzione cù Vault è noi ùn aduprà più. Un gran mutivu per cumincià à aduprà Consul per u so propiu scopu.

Cumu Patroni travaglia cun Consul

Avemu un cluster Consul, chì hè custituitu di trè nodi, è un cluster Patroni, chì hè custituitu da un capu è una replica (in Patroni, u maestru hè chjamatu u capu di cluster, è i schiavi sò chjamati replica). Ogni casu di u cluster Patroni constantemente manda infurmazione nantu à u statu di u cluster à u Consul. Dunque, da u Consul pudete sempre truvà a cunfigurazione attuale di u cluster Patroni è quale hè u capu à u mumentu.

Per cunnette Patroni à Consul, hè abbastanza à studià a ducumentazione ufficiale, chì dice chì avete bisognu di specificà un òspite in u formatu http o https, secondu cumu avemu travagliatu cù Consul, è u schema di cunnessione, optionally:

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

Sembra sèmplice, ma quì cumincianu i trappule. Cù Consul, travagliammu nantu à una cunnessione sicura via https è a nostra cunfigurazione di cunnessione serà cusì:

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

Ma questu ùn viaghja micca. À l'iniziu, Patroni ùn pò micca cunnette à Consul, perchè prova di passà per http in ogni modu.

U codice fonte di Patroni hà aiutatu à trattà cù u prublema. Hè bè chì hè scrittu in python. Ci hè chì u paràmetru di l'ospite ùn hè micca analizatu in ogni modu, è u protocolu deve esse specificatu in schema. Questu hè cumu u bloccu di cunfigurazione di travagliu per travaglià cù Consul pare per noi:

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

cunsul-tempulu

Dunque, avemu sceltu u almacenamentu per a cunfigurazione. Avà avemu bisognu di capiscenu cumu PgBouncer cambia a so cunfigurazione quandu cambia u capu in u cluster Patroni. Ùn ci hè micca risposta à sta quistione in a documentazione, perchè. quì, in principiu, u travagliu cù PgBouncer ùn hè micca scrittu.

In cerca di una suluzione, avemu trovu un articulu (sfurtunatamente ùn ricurdari lu tìtulu) induve hè statu scrittu chì Сonsul-template aiutau assai in pairing PgBouncer è Patroni. Questu ci hà incitatu à investigà cumu funziona Consul-template.

Hè risultatu chì Consul-template monitoreghja constantemente a cunfigurazione di u cluster PostgreSQL in Consul. Quandu u capu cambia, aghjurnà a cunfigurazione di PgBouncer è manda un cumandamentu per ricaricallu.

Un grande plus di u mudellu hè chì hè guardatu cum'è codice, cusì quandu aghjunghje un novu frammentu, hè abbastanza per fà un novu impegnu è aghjurnà u mudellu automaticamente, sustene l'Infrastruttura cum'è principiu di codice.

Architettura nova cù Patroni

In u risultatu, avemu avutu u schema di travagliu seguente:


Tutti i servitori di l'applicazioni accede à u balancer → ci sò dui casi di PgBouncer daretu à ellu → in ogni istanza, Consul-template hè lanciatu, chì monitorizza u statutu di ogni cluster Patroni è monitorizza a rilevanza di a cunfigurazione PgBouncer, chì manda richieste à u capu attuale. di ogni cluster.

Test manuale

Avemu eseguitu stu schema prima di lancià in un picculu ambiente di prova è verificatu u funziunamentu di u cambiamentu automaticu. Apertu u tavulinu, movenu u sticker, è in quellu mumentu "ammazzanu" u capu di u cluster. In AWS, questu hè simplice quant'è chjude l'istanza via a cunsola.

U sticker hà tornatu in 10-20 seconde, è poi di novu cuminciò à movi normalmente. Questu significa chì u cluster Patroni hà travagliatu bè: hà cambiatu u capu, hà mandatu l'infurmazioni à Сonsul, è Сonsul-template hà pigliatu immediatamente sta informazione, rimpiazzatu a cunfigurazione PgBouncer è hà mandatu u cumandamentu per ricaricà.

Cumu sopravvive sottu una carica alta è mantene u minimu di downtime?

Tuttu funziona perfettamente! Ma ci sò novi quistioni: Cumu travaglià sottu una carica alta? Cumu mette in modu rapidu è sicuru tuttu in a produzzione?

L'ambiente di prova nantu à quale facemu a prova di carica ci aiuta à risponde à a prima dumanda. Hè cumplettamente identica à a produzzione in quantu à l'architettura è hà generatu dati di prova chì hè apprussimatamente uguale in volume à a produzzione. Decidimu solu di "ammazzà" unu di i maestri PostgreSQL durante a prova è vede ciò chì succede. Ma prima di quessa, hè impurtante di verificà u rolling automaticu, perchè nantu à questu ambiente avemu parechji shards PostgreSQL, cusì averemu una prova eccellente di script di cunfigurazione prima di pruduzzione.

I dui travaglii pareanu ambiziosi, ma avemu PostgreSQL 9.6. Pudemu immediatamente aghjurnà à 11.2?

Decidiamu di fà in 2 passi: prima aghjurnà à 11.2, poi lanciate Patroni.

Actualizazione di PostgreSQL

Per aghjurnà rapidamente a versione PostgreSQL, utilizate l'opzione -k, in quale ligami duru sò creati nantu à u discu è ùn ci hè bisognu di cupià i vostri dati. In basa di 300-400 GB, l'aghjurnamentu dura 1 secondu.

Avemu assai shards, cusì l'aghjurnamentu deve esse fattu automaticamente. Per fà questu, avemu scrittu un Ansible playbook chì gestisce tuttu u prucessu di aghjurnamentu per noi:

/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='

Hè impurtante di nutà quì chì prima di inizià l'aghjurnamentu, deve esse realizatu cù u paràmetru --verificàper assicurà chì pudete aghjurnà. U nostru script face ancu a sustituzione di cunfigurazioni per a durata di l'aghjurnamentu. U nostru script hè finitu in 30 seconde, chì hè un risultatu eccellente.

Lanciate Patroni

A risolviri lu siconda prublemu, basta à fighjulà a cunfigurazione Patroni. U repositoriu ufficiale hà un esempiu di cunfigurazione cù initdb, chì hè rispunsevule per l'inizializazione di una nova basa di dati quandu avete principiatu Patroni. Ma postu chì avemu digià una basa di dati pronta, simpricimenti sguassate sta sezione da a cunfigurazione.

Quandu avemu principiatu à installà Patroni nantu à un cluster PostgreSQL digià esistente è l'eseguimu, avemu avutu un novu prublema: i dui servitori cuminciaru cum'è un capu. Patroni ùn sapi nunda di u statu iniziale di u cluster è prova di inizià i dui servitori cum'è dui clusters separati cù u stessu nome. Per risolve stu prublema, avete bisognu di sguassà u cartulare cù dati nantu à u slave:

rm -rf /var/lib/postgresql/

Questu deve esse fattu solu nantu à u slave!

Quandu una rèplica pulita hè cunnessa, Patroni face un capu di basa di salvezza è restaurà à a rèplica, è poi chjappà cù u statu attuale secondu i wal logs.

Un'altra difficultà chì avemu scontru hè chì tutti i clusters PostgreSQL sò chjamati principali per automaticamente. Quandu ogni cluster ùn sapi nunda di l'altru, questu hè normale. Ma quandu vulete usà Patroni, allora tutti i clusters deve avè un nome unicu. A suluzione hè di cambià u nome di u cluster in a cunfigurazione PostgreSQL.

prova di carica

Avemu lanciatu una prova chì simula l'esperienza di l'utilizatori nantu à i bordi. Quandu a carica hà righjuntu u nostru valore mediu di ogni ghjornu, avemu ripetutu esattamente a stessa prova, avemu disattivatu una istanza cù u capu PostgreSQL. U failover automaticu hà travagliatu cum'è avemu aspittatu: Patroni hà cambiatu u capu, Consul-template hà aghjurnatu a cunfigurazione di PgBouncer è hà mandatu un cumandamentu per ricaricà. Sicondu i nostri grafichi in Grafana, era chjaru chì ci sò ritardi di 20-30 seconde è una piccula quantità di errore da i servitori assuciati cù a cunnessione à a basa di dati. Questa hè una situazione normale, tali valori sò accettabili per u nostru failover è sò definitivamente megliu cà u tempu d'inattività di u serviziu.

Purtendu Patroni à a pruduzzione

In u risultatu, avemu ghjuntu cù u pianu seguente:

• Implementa u mudellu Consul à i servitori PgBouncer è lanciari;
• PostgreSQL aghjurnamenti à a versione 11.2;
• Cambia u nome di u cluster;
• Accuminciamentu di u Cluster Patroni.

À u listessu tempu, u nostru schema ci permette di fà u primu puntu quasi in ogni mumentu, pudemu caccià ogni PgBouncer da u travagliu in turnu è implementà è eseguisce consul-template nantu à questu. Allora avemu fattu.

Per una implementazione rapida, avemu usatu Ansible, postu chì avemu digià pruvatu tutti i playbooks in un ambiente di prova, è u tempu di esecuzione di u script sanu era da 1,5 à 2 minuti per ogni shard. Pudemu sparghje tuttu in turnu à ogni shard senza piantà u nostru serviziu, ma duvemu disattivà ogni PostgreSQL per parechji minuti. In questu casu, l'utilizatori chì e so dati sò nantu à questu shard ùn puderanu micca travaglià cumplettamente à questu tempu, è questu hè inacceptable per noi.

A manera di fora di sta situazione era u mantenimentu pianificatu, chì si faci ogni 3 mesi. Questa hè una finestra per u travagliu pianificatu, quandu chjudemu cumplettamente u nostru serviziu è aghjurnà a nostra basa di dati. Ci era una settimana rimasta finu à a prossima finestra, è avemu decisu di aspittà solu è preparà più. Duranti u tempu d'attesa, avemu ancu assicuratu: per ogni shard PostgreSQL, avemu risuscitatu una replica di riserva in casu di fallimentu di mantene l'ultime dati, è aghjunghje una nova istanza per ogni shard, chì deve diventà una nova replica in u cluster Patroni, per ùn eseguisce un cumandamentu per sguassà dati. Tuttu chistu hà aiutatu à minimizzà u risicu di errore.


Avemu ripigliatu u nostru serviziu, tuttu hà travagliatu cum'è duverebbe, l'utilizatori cuntinueghjanu à travaglià, ma nantu à i grafici avemu nutatu una carica anormalmente alta nantu à i servitori Consul.


Perchè ùn avemu micca vistu questu in l'ambiente di prova? Stu prublema illustra assai bè chì hè necessariu di seguità l'Infrastruttura cum'è principiu di codice è raffinà tutta l'infrastruttura, da l'ambienti di prova à a produzzione. Altrimenti, hè assai faciule per ottene u prublema chì avemu avutu. Chi hè successu? Cunsul prima apparsu nantu à a pruduzzione, è dopu in l'ambienti di prova, in u risultatu, in l'ambienti di prova, a versione di Cunsul era più altu ch'è in a pruduzzione. Solu in una di e versioni, una fuga di CPU hè stata risolta quandu si travaglia cun consul-template. Dunque, avemu solu aghjurnatu Consul, cusì risolve u prublema.

Restart Patroni cluster

Tuttavia, avemu un novu prublema, chì ùn avemu mancu suspettu. Quandu aghjurnà u Consul, avemu solu sguassà u node Consul da u cluster usendu u cumandimu di lascià consul → Patroni cunnetta à un altru servitore Consul → tuttu travaglia. Ma quandu avemu ghjuntu à l 'ultimu esempiu di u Cluster Consul è mandatu lu cumanda lascià consul, tutti i clusters Patroni simpricimenti riiniziata, è in i logs avemu vistu u 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>

U cluster Patroni ùn hà micca pussutu ricuperà l'infurmazioni nantu à u so cluster è riavviatu.

Per truvà una suluzione, avemu cuntattatu l'autori Patroni via un prublema in github. Anu suggeritu migliure à i nostri schedarii di cunfigurazione:

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

Pudemu riplicà u prublema in un ambiente di prova è pruvemu queste opzioni quì, ma sfurtunatamenti ùn anu micca travagliatu.

U prublema ferma sempre senza risolve. Avemu pensatu à pruvà i seguenti suluzioni:

• Aduprà Consul-agent in ogni istanza di cluster Patroni;
• Fix u prublema in u codice.

Capemu induve l'errore hè accadutu: u prublema hè probabilmente l'usu di u timeout predeterminatu, chì ùn hè micca annullatu attraversu u schedariu di cunfigurazione. Quandu l'ultimu servitore Consul hè sguassatu da u cluster, tuttu u cluster Consul pende per più di una seconda, per quessa, Patroni ùn pò micca ottene u statutu di u cluster è riavvia cumplettamente u cluster sanu.

Fortunatamente, ùn avemu micca scontru più errore.

Risultati di usu Patroni

Dopu à u lanciu successu di Patroni, avemu aghjustatu una replica supplementu in ogni cluster. Avà in ogni cluster ci hè una sembianza di quorum: un capu è duie rèpliche, per a rete di salvezza in casu di split-brain quandu si cambia.


Patroni travaglia dapoi più di trè mesi in a produzzione. Duranti stu tempu, hà digià riesciutu à aiutà ci. Ricertamenti, u capu di unu di i clusters hè mortu in AWS, u failover automaticu hà travagliatu è l'utilizatori cuntinuavanu à travaglià. Patroni hà rializatu u so compitu principalu.

Un picculu riassuntu di l'usu di Patroni:

• Facilità di cambiamenti di cunfigurazione. Hè abbastanza per cambià a cunfigurazione nantu à una istanza è serà tirata in tuttu u cluster. Se un reboot hè necessariu per applicà a nova cunfigurazione, Patroni vi farà sapè. Patroni pò ripiglià u cluster sanu cù una sola cumanda, chì hè ancu assai còmuda.
• U failover automaticu funziona è hà digià riesciutu à aiutà.
• Actualizazione di PostgreSQL senza tempi di inattività di l'applicazione. Duvete prima aghjurnà e repliche à a nova versione, dopu cambià u capu in u cluster Patroni è aghjurnà u vechju capu. In questu casu, a prova necessaria di failover automaticu si trova.

Source: www.habr.com