Failover Cluster PostgreSQL + Patroni. Kasinatian sa pagpatuman

Sa artikulo isulti ko kanimo kung giunsa namo pagduol ang isyu sa PostgreSQL fault tolerance, nganong kini nahimong importante alang kanamo ug unsa ang nahitabo sa katapusan.

Kami adunay daghan kaayo nga serbisyo: 2,5 milyon nga tiggamit sa tibuuk kalibutan, 50K+ aktibo nga tiggamit matag adlaw. Ang mga server nahimutang sa Amazone sa usa ka rehiyon sa Ireland: 100+ lain-laing mga server ang kanunay nga naglihok, diin hapit 50 ang adunay mga database.

Ang tibuuk nga backend usa ka dako nga monolithic stateful nga aplikasyon sa Java nga nagpadayon sa kanunay nga koneksyon sa websocket sa kliyente. Kung daghang mga tiggamit ang nagtrabaho sa parehas nga board sa parehas nga oras, silang tanan nakakita sa mga pagbag-o sa tinuud nga oras, tungod kay gisulat namon ang matag pagbag-o sa database. Adunay kami mga 10K nga hangyo matag segundo sa among mga database. Sa peak load sa Redis, nagsulat kami og 80-100K nga mga hangyo kada segundo.

Ngano nga mibalhin kami gikan sa Redis ngadto sa PostgreSQL

Sa sinugdan, ang among serbisyo nagtrabaho kauban ang Redis, usa ka tindahan nga hinungdanon nga kantidad nga nagtipig sa tanan nga datos sa RAM sa server.

Mga bentaha sa Redis:

1. Taas nga katulin sa pagtubag, tungod kay ang tanan gitipigan sa panumduman;
2. Kasayon ​​sa pag-backup ug pagkopya.

Kontra sa Redis alang kanato:

1. Walay tinuod nga mga transaksyon. Gisulayan namon nga i-simulate sila sa lebel sa among aplikasyon. Ikasubo, dili kini kanunay nga maayo ug gikinahanglan ang pagsulat sa komplikado kaayo nga code.
2. Ang gidaghanon sa datos limitado sa gidaghanon sa memorya. Samtang nagkadaghan ang datos, ang memorya motubo, ug, sa katapusan, kita modagan ngadto sa mga kinaiya sa pinili nga pananglitan, nga sa AWS nagkinahanglan sa paghunong sa atong serbisyo aron mausab ang matang sa pananglitan.
3. Gikinahanglan ang kanunay nga pagpadayon sa usa ka ubos nga lebel sa latency, tungod kay. daghan kaayo mig hangyo. Ang labing maayo nga lebel sa paglangan alang kanamo mao ang 17-20 ms. Sa lebel nga 30-40 ms, nakakuha kami taas nga tubag sa mga hangyo gikan sa among aplikasyon ug pagkadaot sa serbisyo. Ikasubo, nahitabo kini kanamo kaniadtong Septyembre 2018, kung ang usa sa mga higayon nga adunay Redis sa pila ka hinungdan nakadawat latency nga 2 ka beses nga labi pa sa naandan. Aron masulbad ang isyu, gihunong namo ang serbisyo sa tungang-adlaw alang sa wala ma-iskedyul nga pagmentinar ug gipulihan ang problema nga Redis nga pananglitan.
4. Sayon ang pagkuha sa data inconsistency bisan sa ginagmay nga mga sayop sa code ug unya mogahin ug daghang oras sa pagsulat sa code aron matul-id kini nga datos.

Among gikonsiderar ang mga disbentaha ug nakaamgo nga kinahanglan namong mobalhin sa usa ka butang nga mas sayon, nga adunay normal nga mga transaksyon ug dili kaayo pagsalig sa latency. Nagdumala sa panukiduki, nag-analisar sa daghang mga kapilian ug gipili ang PostgreSQL.

Nagbalhin-balhin kami sa usa ka bag-ong database sulod sa 1,5 ka tuig na ug nagbalhin lamang sa gamay nga bahin sa datos, mao nga karon kami nagtrabaho nga dungan sa Redis ug PostgreSQL. Ang dugang nga kasayuran bahin sa mga yugto sa paglihok ug pagbalhin sa datos sa taliwala sa mga database gisulat sa artikulo sa akong kauban.

Sa una namong pagsugod sa paglihok, ang among aplikasyon nagtrabaho direkta sa database ug na-access ang master Redis ug PostgreSQL. Ang PostgreSQL cluster naglangkob sa usa ka master ug usa ka replika nga adunay asynchronous nga replikasyon. Ingon niini ang hitsura sa laraw sa database:

Pagpatuman sa PgBouncer

Samtang kami naglihok, ang produkto nag-uswag usab: ang gidaghanon sa mga tiggamit ug ang gidaghanon sa mga server nga nagtrabaho uban sa PostgreSQL misaka, ug kami nagsugod nga kulang sa mga koneksyon. Ang PostgreSQL nagmugna og usa ka bulag nga proseso alang sa matag koneksyon ug naggamit sa mga kapanguhaan. Mahimo nimong madugangan ang gidaghanon sa mga koneksyon hangtod sa usa ka punto, kung dili adunay higayon nga makakuha og suboptimal nga pasundayag sa database. Ang sulundon nga kapilian sa ingon nga sitwasyon mao ang pagpili sa usa ka koneksyon manager nga mobarug sa atubangan sa base.

Adunay kami duha ka kapilian alang sa manager sa koneksyon: Pgpool ug PgBouncer. Apan ang una wala nagsuporta sa transactional mode sa pagtrabaho kauban ang database, mao nga gipili namon ang PgBouncer.

Gipahimutang namo ang mosunod nga laraw sa trabaho: ang among aplikasyon nag-access sa usa ka PgBouncer, sa likod niini mao ang PostgreSQL masters, ug luyo sa matag master adunay usa ka replica nga adunay asynchronous replication.


Sa samang higayon, dili namo matipigan ang tibuok nga gidaghanon sa datos sa PostgreSQL ug ang katulin sa pagtrabaho sa database importante alang kanamo, mao nga gisugdan namo ang pag-shard sa PostgreSQL sa lebel sa aplikasyon. Ang laraw nga gihulagway sa ibabaw medyo kombenyente alang niini: kung magdugang usa ka bag-ong PostgreSQL shard, igo na nga i-update ang configuration sa PgBouncer ug ang aplikasyon mahimo dayon nga magtrabaho sa bag-ong shard.

PgBouncer failover

Kini nga laraw nagtrabaho hangtod sa higayon nga ang bugtong PgBouncer nga pananglitan namatay. Anaa kami sa AWS, diin ang tanan nga mga higayon nagdagan sa hardware nga mamatay matag karon ug unya. Sa ingon nga mga kaso, ang pananglitan mobalhin lang sa bag-ong hardware ug molihok pag-usab. Nahitabo kini sa PgBouncer, apan wala kini magamit. Ang resulta niini nga pagkapukan mao ang pagkawala sa among serbisyo sulod sa 25 minutos. Girekomenda sa AWS ang paggamit sa user-side redundancy alang sa ingon nga mga sitwasyon, nga wala gipatuman sa atong nasud niadtong panahona.

Pagkahuman niana, seryoso namon nga gihunahuna ang bahin sa pagtugot sa sayup sa mga cluster sa PgBouncer ug PostgreSQL, tungod kay ang parehas nga sitwasyon mahimong mahitabo sa bisan unsang higayon sa among AWS account.

Gitukod namo ang PgBouncer fault tolerance scheme sama sa mosunod: ang tanang application servers nag-access sa Network Load Balancer, nga luyo niini adunay duha ka PgBouncers. Ang matag PgBouncer nagtan-aw sa parehas nga PostgreSQL master sa matag shard. Kung mahitabo pag-usab ang pagkahagsa sa AWS, ang tanang trapiko ma-redirect pinaagi sa laing PgBouncer. Ang network Load Balancer failover gihatag sa AWS.

Kini nga laraw nagpasayon ​​sa pagdugang sa bag-ong mga server sa PgBouncer.

Paghimo usa ka PostgreSQL Failover Cluster

Kung gisulbad kini nga problema, gikonsiderar namon ang lainlaing mga kapilian: self-written failover, repmgr, AWS RDS, Patroni.

Mga sinulat sa kaugalingon nga mga script

Mahimo nilang bantayan ang trabaho sa agalon ug, kung mapakyas kini, i-promote ang replika sa master ug i-update ang configuration sa PgBouncer.

Ang mga bentaha sa kini nga pamaagi mao ang labing kasayon, tungod kay ikaw mismo ang nagsulat sa mga script ug nahibal-an kung giunsa kini molihok.

Kahinumduman:

• Mahimong wala mamatay ang agalon, imbes usa ka pagkapakyas sa network mahimo’g nahitabo. Ang Failover, nga wala makahibalo niini, magpasiugda sa replika sa agalon, samtang ang tigulang nga agalon magpadayon sa pagtrabaho. Ingon usa ka sangputanan, makakuha kami duha nga mga server sa papel sa agalon ug dili namon mahibal-an kung kinsa sa kanila ang adunay labing bag-o nga datos. Kini nga sitwasyon gitawag usab nga split-brain;
• Gibiyaan mi nga walay tubag. Sa among configuration, ang master ug usa ka replica, human sa pagbalhin, ang replica mobalhin ngadto sa master ug wala na kami mga replika, mao nga kinahanglan namong idugang ang usa ka bag-ong replika;
• Kinahanglan namon ang dugang nga pag-monitor sa operasyon sa failover, samtang kami adunay 12 nga PostgreSQL shards, nga nagpasabut nga kinahanglan namon nga bantayan ang 12 nga mga kumpol. Sa pagdugang sa gidaghanon sa mga shards, kinahanglan nimo usab nga hinumdoman nga i-update ang failover.

Ang self-written failover morag komplikado kaayo ug nanginahanglan ug non-trivial nga suporta. Uban sa usa ka PostgreSQL cluster, kini ang labing kadali nga kapilian, apan dili kini sukod, busa dili kini angay alang kanamo.

Si Repmgr

Replication Manager alang sa PostgreSQL clusters, nga makadumala sa operasyon sa usa ka PostgreSQL cluster. Sa parehas nga oras, wala kini awtomatik nga failover gikan sa kahon, mao nga alang sa trabaho kinahanglan nimo nga isulat ang imong kaugalingon nga "wrapper" sa ibabaw sa nahuman nga solusyon. Mao nga ang tanan mahimong labi ka komplikado kaysa sa mga sinulat sa kaugalingon nga mga script, mao nga wala namon gisulayan ang Repmgr.

AWS RDS

Nagsuporta sa tanan nga kinahanglan namon, nahibal-an kung giunsa ang paghimo og mga backup ug pagpadayon sa usa ka pool sa mga koneksyon. Adunay kini awtomatik nga pagbalhin: kung mamatay ang agalon, ang replika mahimong bag-ong agalon, ug gibag-o sa AWS ang rekord sa dns sa bag-ong agalon, samtang ang mga replika mahimong makit-an sa lainlaing mga AZ.

Ang mga disbentaha naglakip sa kakulang sa maayong mga pag-adjust. Ingon usa ka pananglitan sa maayo nga pag-tune: ang among mga higayon adunay mga pagdili alang sa mga koneksyon sa tcp, nga, sa kasubo, dili mahimo sa RDS:

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

Dugang pa, ang AWS RDS hapit doble nga mahal kaysa sa regular nga presyo sa pananglitan, nga mao ang panguna nga hinungdan sa pagbiya niini nga solusyon.

Patroni

Kini usa ka template sa python alang sa pagdumala sa PostgreSQL nga adunay maayong dokumentasyon, awtomatikong failover ug source code sa github.

Mga bentaha sa Patroni:

• Gihubit ang matag parameter sa pagsumpo, klaro kung giunsa kini molihok;
• Ang awtomatik nga failover nagtrabaho sa gawas sa kahon;
• Gisulat sa python, ug tungod kay kami mismo nagsulat og daghan sa python, mas sayon ​​​​alang kanamo ang pag-atubang sa mga problema ug, tingali, makatabang pa sa pagpalambo sa proyekto;
• Hingpit nga nagdumala sa PostgreSQL, nagtugot kanimo sa pag-usab sa configuration sa tanan nga mga node sa cluster sa makausa, ug kung ang cluster kinahanglan nga i-restart aron magamit ang bag-ong configuration, nan kini mahimo pag-usab gamit ang Patroni.

Kahinumduman:

• Dili klaro gikan sa dokumentasyon kung giunsa ang pagtrabaho sa PgBouncer sa husto. Bisan tuod lisud ang pagtawag niini nga usa ka minus, tungod kay ang tahas ni Patroni mao ang pagdumala sa PostgreSQL, ug kung giunsa ang mga koneksyon sa Patroni moadto mao na ang among problema;
• Adunay pipila ka mga pananglitan sa pagpatuman sa Patroni sa daghang mga volume, samtang adunay daghang mga pananglitan sa pagpatuman gikan sa wala.

Ingon usa ka sangputanan, gipili namon ang Patroni nga maghimo usa ka failover cluster.

Proseso sa Pagpatuman sa Patroni

Sa wala pa ang Patroni, kami adunay 12 ka PostgreSQL shards sa usa ka configuration sa usa ka master ug usa ka replica nga adunay asynchronous replication. Ang mga server sa aplikasyon nag-access sa mga database pinaagi sa Network Load Balancer, sa luyo niini adunay duha ka mga higayon nga adunay PgBouncer, ug sa likod niini ang tanan nga mga PostgreSQL server.


Aron ma-implementar ang Patroni, kinahanglan namong mopili og distributed storage cluster configuration. Ang Patroni nagtrabaho kauban ang gipang-apod-apod nga mga sistema sa pagtipig sa pagsumpo sama sa etcd, Zookeeper, Consul. Naa ra kami usa ka bug-os nga cluster sa Consul sa merkado, nga nagtrabaho kauban ang Vault ug wala na namon kini gigamit. Usa ka maayo nga rason sa pagsugod sa paggamit sa Consul alang sa iyang gituyo nga katuyoan.

Giunsa pagtrabaho ni Patroni sa Consul

Kita adunay usa ka Consul cluster, nga naglangkob sa tulo ka mga nodes, ug usa ka Patroni cluster, nga naglangkob sa usa ka lider ug usa ka replica (sa Patroni, ang agalon gitawag nga cluster lider, ug ang mga ulipon gitawag replicas). Ang matag instance sa Patroni cluster kanunay nga nagpadala og impormasyon mahitungod sa estado sa cluster ngadto sa Consul. Busa, gikan sa Consul kanunay nimo mahibal-an ang kasamtangan nga configuration sa Patroni cluster ug kinsa ang nanguna sa pagkakaron.

Aron makonektar ang Patroni sa Consul, igo na nga tun-an ang opisyal nga dokumentasyon, nga nag-ingon nga kinahanglan nimo nga ipiho ang usa ka host sa format nga http o https, depende kung giunsa namo pagtrabaho ang Consul, ug ang laraw sa koneksyon, opsyonal:

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

Kini tan-awon nga yano, apan dinhi nagsugod ang mga lit-ag. Uban sa Consul, nagtrabaho kami sa usa ka luwas nga koneksyon pinaagi sa https ug ang among config sa koneksyon mahimong ingon niini:

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

Apan dili kana molihok. Sa pagsugod, si Patroni dili makakonektar sa Consul, tungod kay kini naningkamot sa pag-agi sa http bisan pa niana.

Ang source code sa Patroni nakatabang sa pag-atubang sa problema. Maayo kay gisulat ni sa python. Kini nahimo nga ang host parameter wala ma-parse sa bisan unsang paagi, ug ang protocol kinahanglan nga itakda sa laraw. Mao kini ang hitsura sa working configuration block alang sa pagtrabaho uban sa Consul alang kanamo:

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

konsul-template

Busa, gipili namo ang storage alang sa configuration. Karon kinahanglan naton nga masabtan kung giunsa ang pagbag-o sa PgBouncer sa pag-configure niini kung gibag-o ang lider sa cluster sa Patroni. Walay tubag niini nga pangutana sa dokumentasyon, tungod kay. didto, sa baruganan, pagtrabaho uban sa PgBouncer wala gihulagway.

Sa pagpangita sa usa ka solusyon, nakakaplag kami og usa ka artikulo (I subo nga wala mahinumdom sa titulo) diin kini gisulat nga ang Сonsul-template nakatabang pag-ayo sa pagpares sa PgBouncer ug Patroni. Kini nag-aghat kanamo sa pagsusi kung giunsa ang paggana sa Consul-template.

Nahibal-an nga ang Consul-template kanunay nga nag-monitor sa configuration sa PostgreSQL cluster sa Consul. Kung magbag-o ang lider, gi-update niini ang configuration sa PgBouncer ug nagpadala og command aron i-reload kini.

Ang usa ka dako nga dugang sa template mao nga kini gitipigan ingon nga code, mao nga sa pagdugang sa usa ka bag-o nga shard, kini igo na sa paghimo sa usa ka bag-o nga pasalig ug pag-update sa template awtomatik, pagsuporta sa Infrastructure ingon code prinsipyo.

Bag-ong arkitektura kauban si Patroni

Ingon usa ka sangputanan, nakuha namon ang mosunud nga laraw sa trabaho:


Ang tanan nga mga server sa aplikasyon nag-access sa balancer → adunay duha ka mga higayon sa PgBouncer sa likod niini → sa matag higayon, ang Consul-template gilunsad, nga nagmonitor sa kahimtang sa matag Patroni cluster ug nagmonitor sa kalabutan sa PgBouncer config, nga nagpadala sa mga hangyo ngadto sa kasamtangan nga lider sa matag cluster.

Manwal nga pagsulay

Gipadagan namon kini nga laraw sa wala pa kini ilunsad sa usa ka gamay nga palibot sa pagsulay ug gisusi ang operasyon sa awtomatikong pagbalhin. Ilang giablihan ang pisara, gibalhin ang sticker, ug niadtong higayona ilang "gipatay" ang lider sa cluster. Sa AWS, kini yano ra sama sa pagsira sa instance pinaagi sa console.

Ang sticker mibalik pag-usab sulod sa 10-20 ka segundo, ug dayon nagsugod na usab sa paglihok nga normal. Kini nagpasabot nga ang Patroni cluster nagtrabaho sa husto: kini giusab ang lider, gipadala ang impormasyon ngadto sa Сonsul, ug Сonsul-template diha-diha dayon mikuha niini nga impormasyon, gipulihan sa PgBouncer configuration ug nagpadala sa sugo sa reload.

Sa unsa nga paagi nga mabuhi ubos sa taas nga karga ug magpabilin nga gamay ang downtime?

Ang tanan nagtrabaho nga hingpit! Apan adunay bag-ong mga pangutana: Sa unsang paagi kini molihok ubos sa taas nga karga? Giunsa ang dali ug luwas nga paglansad sa tanan sa produksiyon?

Ang palibot sa pagsulay diin nagpahigayon kami og pagsulay sa pagkarga makatabang kanamo nga matubag ang una nga pangutana. Kini hingpit nga parehas sa produksiyon sa mga termino sa arkitektura ug nakamugna mga datos sa pagsulay nga hapit parehas sa gidaghanon sa produksiyon. Nagdesisyon kami nga "patayon" lang ang usa sa mga master sa PostgreSQL sa panahon sa pagsulay ug tan-awon kung unsa ang mahitabo. Apan sa wala pa kana, hinungdanon nga susihon ang awtomatik nga pagligid, tungod kay sa kini nga palibot adunay daghang mga shards sa PostgreSQL, aron makakuha kami maayo nga pagsulay sa mga script sa pag-configure sa wala pa ang produksiyon.

Ang duha nga mga buluhaton tan-awon nga ambisyoso, apan kami adunay PostgreSQL 9.6. Mahimo ba naton nga mag-upgrade dayon sa 11.2?

Nagdesisyon kami nga buhaton kini sa 2 nga mga lakang: una nga pag-upgrade sa 11.2, dayon ilunsad ang Patroni.

Pag-update sa PostgreSQL

Aron dali nga ma-update ang bersyon sa PostgreSQL, gamita ang kapilian -k, diin ang mga gahi nga link gihimo sa disk ug dili kinahanglan nga kopyahon ang imong data. Sa mga sukaranan sa 300-400 GB, ang pag-update nagkinahanglan og 1 segundo.

Daghan kami mga shards, mao nga kinahanglan nga awtomatiko nga buhaton ang pag-update. Aron mahimo kini, nagsulat kami usa ka Ansible nga playbook nga nagdumala sa tibuuk nga proseso sa pag-update alang kanamo:

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

Mahinungdanon nga timan-an dinhi nga sa wala pa magsugod ang pag-upgrade, kinahanglan nimo nga buhaton kini gamit ang parameter --susihapara makasiguro ka nga maka-upgrade. Gihimo usab sa among script ang pag-ilis sa mga config alang sa gidugayon sa pag-upgrade. Ang among script nahuman sa 30 segundos, nga usa ka maayo kaayo nga resulta.

Ilunsad ang Patroni

Aron masulbad ang ikaduhang problema, tan-awa lang ang configuration sa Patroni. Ang opisyal nga repository adunay usa ka panig-ingnan nga pag-configure sa initdb, nga responsable sa pagsugod sa usa ka bag-ong database sa una nimo nga pagsugod sa Patroni. Apan tungod kay aduna na kami'y andam na nga database, among gikuha kini nga seksyon gikan sa configuration.

Sa diha nga kami nagsugod sa pag-instalar sa Patroni sa usa ka na nga PostgreSQL cluster ug sa pagpadagan niini, kami midagan ngadto sa usa ka bag-ong problema: ang duha ka mga server nagsugod isip usa ka lider. Wala’y nahibal-an si Patroni bahin sa sayo nga kahimtang sa kumpol ug gisulayan nga sugdan ang duha nga mga server ingon duha nga managsama nga mga kumpol nga adunay parehas nga ngalan. Aron masulbad kini nga problema, kinahanglan nimo nga papason ang direktoryo nga adunay datos sa ulipon:

rm -rf /var/lib/postgresql/

Kini kinahanglan nga buhaton lamang sa ulipon!

Kung konektado ang usa ka limpyo nga replika, si Patroni maghimo usa ka lider sa basebackup ug ibalik kini sa replika, ug dayon makuha ang karon nga kahimtang sumala sa mga wal log.

Laing kalisud nga among nasugatan mao nga ang tanan nga mga cluster sa PostgreSQL ginganlan nga panguna pinaagi sa default. Kung ang matag cluster walay nahibal-an bahin sa lain, normal kini. Apan kung gusto nimo gamiton ang Patroni, nan ang tanan nga mga kumpol kinahanglan adunay usa ka talagsaon nga ngalan. Ang solusyon mao ang pag-usab sa cluster name sa PostgreSQL configuration.

load test

Naglunsad kami og usa ka pagsulay nga nagsundog sa kasinatian sa user sa mga tabla. Sa diha nga ang load nakaabot sa among kasagaran nga inadlaw nga bili, gisubli namo ang eksaktong samang pagsulay, among gipalong ang usa ka higayon uban sa lider sa PostgreSQL. Ang awtomatik nga failover nagtrabaho sama sa among gilauman: Gibag-o ni Patroni ang lider, gi-update sa Consul-template ang configuration sa PgBouncer ug nagpadala usa ka mando nga i-reload. Sumala sa among mga graph sa Grafana, klaro nga adunay mga paglangan sa 20-30 segundos ug gamay nga kantidad sa mga sayup gikan sa mga server nga may kalabotan sa koneksyon sa database. Kini usa ka normal nga kahimtang, ang ingon nga mga kantidad madawat alang sa among failover ug siguradong mas maayo kaysa sa downtime sa serbisyo.

Pagdala sa Patroni sa produksiyon

Ingon usa ka sangputanan, nahimo namon ang mosunud nga plano:

• I-deploy ang Consul-template sa mga server sa PgBouncer ug ilunsad;
• PostgreSQL updates ngadto sa bersyon 11.2;
• Usba ang ngalan sa cluster;
• Pagsugod sa Patroni Cluster.

Sa parehas nga oras, ang among laraw nagtugot kanamo sa paghimo sa una nga punto hapit bisan unsang oras, mahimo namon nga tangtangon ang matag PgBouncer gikan sa trabaho ug i-deploy ug ipadagan ang consul-template niini. Mao nga among gibuhat.

Alang sa dali nga pag-deploy, gigamit namon ang Ansible, tungod kay nasulayan na namon ang tanan nga mga playbook sa usa ka palibot sa pagsulay, ug ang oras sa pagpatuman sa tibuuk nga script gikan sa 1,5 hangtod 2 minuto alang sa matag shard. Mahimo namon nga i-roll out ang tanan sa matag shard nga dili mohunong sa among serbisyo, apan kinahanglan namon nga i-off ang matag PostgreSQL sa daghang minuto. Sa kini nga kaso, ang mga tiggamit kansang mga datos naa sa kini nga shard dili hingpit nga molihok karong panahona, ug kini dili madawat alang kanamo.

Ang paagi gikan niini nga kahimtang mao ang giplano nga pagmentinar, nga mahitabo matag 3 ka bulan. Kini usa ka bintana alang sa naka-iskedyul nga trabaho, kung hingpit namong gisirhan ang among serbisyo ug gi-upgrade ang among database nga mga higayon. Adunay usa ka semana nga nahabilin hangtod sa sunod nga bintana, ug nakahukom kami nga maghulat ug mag-andam pa. Atol sa oras sa paghulat, dugang namon nga gisiguro ang among kaugalingon: alang sa matag PostgreSQL shard, nagpataas kami usa ka ekstra nga kopya kung adunay kapakyasan sa pagtipig sa labing bag-ong datos, ug nagdugang usa ka bag-ong higayon alang sa matag shard, nga kinahanglan nga mahimong bag-ong replika sa cluster sa Patroni, aron dili magpatuman ug sugo sa pagtangtang sa datos . Kining tanan nakatabang sa pagpamenos sa risgo sa kasaypanan.


Gisugdan namon pag-usab ang among serbisyo, ang tanan nagtrabaho ingon nga kini kinahanglan, ang mga tiggamit nagpadayon sa pagtrabaho, apan sa mga graph among namatikdan ang usa ka abnormal nga taas nga load sa mga server sa Consul.


Ngano nga wala namo kini makita sa palibot sa pagsulay? Kini nga problema naghulagway pag-ayo nga gikinahanglan ang pagsunod sa Infrastructure isip code nga prinsipyo ug pagpino sa tibuok imprastraktura, gikan sa pagsulay nga mga palibot ngadto sa produksyon. Kung dili, dali ra kaayo makuha ang problema nga among nakuha. Unsay nahitabo? Una nga nagpakita ang Consul sa produksiyon, ug dayon sa mga palibot sa pagsulay, ingon usa ka sangputanan, sa mga palibot sa pagsulay, ang bersyon sa Consul mas taas kaysa sa produksiyon. Sa usa lang sa mga pagpagawas, usa ka pagtulo sa CPU ang nasulbad kung nagtrabaho kauban ang consul-template. Busa, gi-update lang namo ang Consul, aron masulbad ang problema.

I-restart ang Patroni cluster

Bisan pa, nakakuha kami usa ka bag-ong problema, nga wala kami nagduda. Sa pag-update sa Consul, tangtangon lang namo ang Consul node gikan sa cluster gamit ang consul leave command → Patroni connects to another Consul server → everything works. Apan sa dihang naabot na namo ang kataposang instance sa cluster sa Consul ug gipadala niini ang consul leave command, ang tanang Patroni clusters yanong nagsugod pag-usab, ug sa mga log nakita namo ang mosunod nga sayop:

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>

Ang Patroni cluster wala makakuha og impormasyon bahin sa cluster niini ug gi-restart.

Aron makapangita usa ka solusyon, gikontak namon ang mga tagsulat sa Patroni pinaagi sa usa ka isyu sa github. Gisugyot nila ang mga pagpaayo sa among mga file sa pag-configure:

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

Nahimo namon nga kopyahon ang problema sa usa ka palibot sa pagsulay ug gisulayan kini nga mga kapilian didto, apan sa kasubo wala kini molihok.

Ang problema nagpabilin nga wala masulbad. Nagplano kami nga sulayan ang mosunod nga mga solusyon:

• Gamita ang Consul-agent sa matag Patroni cluster instance;
• Ayuhon ang isyu sa code.

Among nasabtan kung diin nahitabo ang sayup: ang problema lagmit ang paggamit sa default timeout, nga dili ma-override pinaagi sa configuration file. Sa diha nga ang katapusan nga Consul server gikuha gikan sa cluster, ang tibuok Consul cluster nagbitay alang sa labaw pa kay sa usa ka segundo, tungod niini, Patroni dili makakuha sa kahimtang sa cluster ug sa hingpit nga restart ang tibuok cluster.

Maayo na lang, wala na kami makit-an nga mga sayup.

Mga resulta sa paggamit sa Patroni

Pagkahuman sa malampuson nga paglansad sa Patroni, gidugang namon ang dugang nga kopya sa matag cluster. Karon sa matag pungpong adunay usa ka panagway sa usa ka korum: usa ka lider ug duha ka replika, alang sa safety net sa kaso sa split-brain sa dihang mobalhin.


Si Patroni nagtrabaho sa produksiyon sobra sa tulo ka bulan. Niining panahona, nakahimo na siya sa pagtabang kanamo. Bag-ohay lang, ang lider sa usa sa mga cluster namatay sa AWS, ang automatic failover nagtrabaho ug ang mga tiggamit nagpadayon sa pagtrabaho. Gituman ni Patroni ang nag-unang tahas niini.

Usa ka gamay nga summary sa paggamit sa Patroni:

• Kasayon ​​sa mga kausaban sa pag-configure. Igo na ang pagbag-o sa pagsumpo sa usa ka higayon ug kini mabira sa tibuuk nga cluster. Kung gikinahanglan ang pag-reboot aron magamit ang bag-ong configuration, ipahibalo kanimo ni Patroni. Mahimong i-restart ni Patroni ang tibuuk nga kumpol nga adunay usa ka mando, nga dali usab kaayo.
• Ang awtomatikong failover nagtrabaho ug nakahimo na sa pagtabang kanamo.
• PostgreSQL update nga walay aplikasyon downtime. Kinahanglan nimo una nga i-update ang mga replika sa bag-ong bersyon, dayon usba ang lider sa cluster sa Patroni ug i-update ang daan nga lider. Sa kini nga kaso, ang gikinahanglan nga pagsulay sa awtomatikong failover mahitabo.

Source: www.habr.com