Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

F'dan l-artikolu ser ngħidlek kif avviċinajna l-kwistjoni tat-tolleranza tal-ħsarat PostgreSQL, għaliex saret importanti għalina, u x'ġara fl-aħħar.

Għandna servizz mgħobbi ħafna: 2,5 miljun utent madwar id-dinja, 50K + utenti attivi kuljum. Is-servers jinsabu f'Amazone f'reġjun wieħed tal-Irlanda: 100+ servers differenti qegħdin joperaw kontinwament, kważi 50 minnhom b'databases.

Il-backend kollu huwa applikazzjoni Java monolitika kbira li żżomm konnessjoni persistenti tal-websocket mal-klijent. Meta diversi utenti jaħdmu simultanjament fuq l-istess bord, huma kollha jaraw bidliet f'ħin reali, għaliex aħna nirreġistraw kull bidla fid-database. Għandna madwar 10K talbiet kull sekonda għad-databases tagħna. Fl-ogħla tagħbija f'Redis niktbu 80-100K talbiet kull sekonda.
Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

Għaliex qlibna minn Redis għal PostgreSQL

Inizjalment, is-servizz tagħna ħadem ma 'Redis, ħażna ta' valur ewlieni li taħżen id-dejta kollha fir-RAM tas-server.

Vantaġġi ta' Redis:

  1. Veloċità għolja ta 'rispons, għaliex kollox huwa maħżun fil-memorja;
  2. Backup konvenjenti u replikazzjoni.

Żvantaġġi ta' Redis għalina:

  1. M'hemm l-ebda transazzjonijiet reali. Ippruvajna nimitawhom fil-livell tal-applikazzjoni tagħna. Sfortunatament, dan mhux dejjem ħadem tajjeb u kien jeħtieġ il-kitba ta 'kodiċi kumpless ħafna.
  2. L-ammont ta 'data huwa limitat mill-ammont ta' memorja. Hekk kif l-ammont ta 'dejta jiżdied, il-memorja se tikber, u, fl-aħħar, se nidħlu mal-karatteristiċi tal-istanza magħżula, li fl-AWS teħtieġ li twaqqaf is-servizz tagħna biex nibdlu t-tip ta' istanza.
  3. Huwa meħtieġ li kontinwament jinżamm livell baxx ta 'latenza, għaliex Għandna numru kbir ħafna ta' talbiet. L-aħjar livell ta 'latency għalina huwa 17-20 ms. F'livell ta '30-40 ms, niksbu tweġibiet twal għat-talbiet tagħna għall-applikazzjoni u d-degradazzjoni tas-servizz. Sfortunatament, dan ġara lilna f'Settembru 2018, meta waħda mill-istanzi ma' Redis għal xi raġuni rċeviet latenza li kienet 2 darbiet ogħla mis-soltu. Biex insolvu l-problema, waqqafna s-servizz f'nofs il-ġurnata tax-xogħol għal manutenzjoni mhux skedata u ssostitwijna l-istanza Redis problematika.
  4. Huwa faċli li tikseb data inkonsistenti anke bi żbalji minuri fil-kodiċi u mbagħad tqatta 'ħafna ħin tikteb kodiċi biex tirranġa dik id-data.

Ħadna kont tal-iżvantaġġi u rrealizzajna li rridu nimxu għal xi ħaġa aktar konvenjenti, bi tranżazzjonijiet normali u inqas dipendenza fuq il-latency. Għamilna r-riċerka tagħna, analizzajna ħafna għażliet u għażilna PostgreSQL.

Ilna nimxu għal database ġdida għal 1,5 snin issa u ttrasferijna biss parti żgħira tad-dejta, għalhekk issa qed naħdmu simultanjament ma 'Redis u PostgreSQL. Aktar informazzjoni dwar l-istadji taċ-ċaqliq u l-bidla tad-dejta bejn id-databases hija miktuba fiha artiklu mill-kollega tiegħi.

Meta bdejna nimxu għall-ewwel darba, l-applikazzjoni tagħna ħadmet direttament mad-database u aċċessat il-kaptan Redis u PostgreSQL. Il-cluster PostgreSQL kien jikkonsisti minn master u replika b'replikazzjoni asinkronika. Dan huwa kif deher il-fluss tax-xogħol tad-database:
Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

Timplimenta PgBouncer

Waqt li konna nimxu, il-prodott kien qed jiżviluppa wkoll: in-numru ta 'utenti u n-numru ta' servers li ħadmu ma 'PostgreSQL żdiedu, u bdejna nispiċċaw il-konnessjonijiet. PostgreSQL joħloq proċess separat għal kull konnessjoni u jikkonsma riżorsi. Tista 'żżid in-numru ta' konnessjonijiet sa ċertu punt, inkella hemm ċans li d-database ma taħdimx bl-aħjar mod. L-għażla ideali f'sitwazzjoni bħal din tkun li tagħżel maniġer tal-konnessjoni li se joqgħod quddiem id-database.

Kellna żewġ għażliet għall-maniġer tal-konnessjoni: Pgpool u PgBouncer. Iżda l-ewwel waħda ma tappoġġjax il-mod transazzjonali ta 'ħidma mad-database, għalhekk għażilna PgBouncer.

Aħna kkonfigurajna l-iskema ta 'xogħol li ġejja: l-applikazzjoni tagħna taċċessa PgBouncer wieħed, li warajha hemm masters PostgreSQL, u wara kull kaptan hemm replika waħda b'replikazzjoni asinkronika.
Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

Fl-istess ħin, ma stajniex naħżnu l-ammont kollu ta 'dejta f'PostgreSQL u l-veloċità tal-ħidma mad-database kienet importanti għalina, għalhekk bdejna sharding PostgreSQL fil-livell tal-applikazzjoni. L-iskema deskritta hawn fuq hija relattivament konvenjenti għal dan: meta żżid shard PostgreSQL ġdid, huwa biżżejjed li taġġorna l-konfigurazzjoni ta 'PgBouncer u l-applikazzjoni tista' immedjatament taħdem mal-shard il-ġdid.

Tolleranza għal Ħsara PgBouncer

Din l-iskema ħadmet sakemm mietet l-unika istanza PgBouncer. Aħna qegħdin f'AWS, fejn l-istanzi kollha huma mnedija fuq ħardwer li jmut perjodikament. F'każijiet bħal dawn, l-istanza sempliċement timxi għal ħardwer ġdid u taħdem mill-ġdid. Dan ġara ma 'PgBouncer, iżda sar mhux disponibbli. Ir-riżultat ta' din il-ħabta kien li s-servizz tagħna ma kienx disponibbli għal 25 minuta. Għal sitwazzjonijiet bħal dawn, AWS jirrakkomanda li tuża redundancy min-naħa tal-utent, li aħna ma implimentajniex dak iż-żmien.

Wara dan, ħsibna bis-serjetà dwar it-tolleranza tal-ħsarat tal-clusters PgBouncer u PostgreSQL, minħabba li sitwazzjoni simili tista 'terġa' sseħħ bi kwalunkwe każ fil-kont AWS tagħna.

Bnejna l-iskema tat-tolleranza tal-ħsarat PgBouncer kif ġej: is-servers tal-applikazzjoni kollha jaċċessaw in-Netwerk Load Balancer, li warajh hemm żewġ PgBouncers. Kull wieħed mill-PgBouncers iħares lejn l-istess kaptan PostgreSQL ta 'kull shard. Jekk is-sitwazzjoni b'ħabta ta 'istanza AWS tirrepeti, it-traffiku kollu jiġi ridirett permezz ta' PgBouncer ieħor. It-tolleranza tal-ħsarat tan-Netwerk Load Balancer hija pprovduta minn AWS.

Din l-iskema tippermettilek li faċilment iżżid servers PgBouncer ġodda.
Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

Ħolqien ta' Cluster ta' Failover PostgreSQL

Meta solvejna din il-problema, ikkunsidrajna għażliet differenti: failover awto-miktub, repmgr, AWS RDS, Patroni.

skripts miktuba minnha stess

Jistgħu jimmonitorjaw ix-xogħol tal-kaptan u, jekk ifalli, jippromwovu r-replika lill-kaptan u jaġġornaw il-konfigurazzjoni ta 'PgBouncer.

Il-vantaġġi ta 'dan l-approċċ huma sempliċità massima, għaliex tikteb l-iskripts lilek innifsek u tifhem eżattament kif jaħdmu.

Cons:

  • Il-kaptan seta' ma mietx; minflok, seta' kien hemm falliment tan-netwerk. Failover, mhux konxju ta 'dan, se jippromwovi r-replika lill-kaptan, u l-kaptan antik se jkompli jaħdem. Bħala riżultat, se jkollna żewġ servers fir-rwol ta 'kaptan u mhux se nkunu nafu liema minnhom għandu l-aħħar data attwali. Din is-sitwazzjoni tissejjaħ ukoll split-brain;
  • Bqajna bla tweġiba. Fil-konfigurazzjoni tagħna hemm kaptan u replika waħda, wara li taqleb ir-replika tiġi promossa għall-kaptan u m'għadx ikollna repliki, għalhekk irridu nżidu manwalment replika ġdida;
  • Neħtieġu monitoraġġ addizzjonali ta 'operazzjoni ta' failover, u għandna 12-il shards PostgreSQL, li jfisser li għandna bżonn nissorveljaw 12-il cluster. Meta żżid in-numru ta 'shards, trid tiftakar ukoll li taġġorna l-failover.

A failover miktub minnu nnifsu jidher ikkumplikat ħafna u jeħtieġ appoġġ mhux trivjali. B'raggruppament wieħed PostgreSQL, din se tkun l-aktar għażla sempliċi, iżda ma tiskalax, għalhekk mhix adattata għalina.

Remgr

Maniġer tar-replikazzjoni għal clusters PostgreSQL, li jistgħu jimmaniġġjaw l-operat ta 'cluster PostgreSQL. Fl-istess ħin, m'għandux failover awtomatiku barra mill-kaxxa, għalhekk biex taħdem ser ikollok bżonn tikteb "wrapper" tiegħek stess fuq is-soluzzjoni lesta. Allura kollox jista 'jirriżulta saħansitra aktar ikkumplikat milli bi skripts miktuba minnha stess, u huwa għalhekk li lanqas ippruvajna Repmgr.

AWS RDS

Jappoġġja dak kollu li għandna bżonn, jista 'jagħmel backups u jappoġġja ġabra ta' konnessjonijiet. Għandu swiċċjar awtomatiku: meta l-kaptan imut, ir-replika ssir il-kaptan il-ġdid, u AWS jibdel ir-rekord tad-DNS għall-kaptan il-ġdid, filwaqt li r-repliki jistgħu jinstabu f'AZs differenti.

L-iżvantaġġi jinkludu n-nuqqas ta 'settings multa. Bħala eżempju ta 'irfinar: l-istanzi tagħna għandhom restrizzjonijiet għal konnessjonijiet tcp, li, sfortunatament, ma jistgħux isiru f'RDS:

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

Barra minn hekk, AWS RDS jiswa kważi d-doppju tal-prezz regolari tal-istanza, li kienet ir-raġuni ewlenija għall-abbandun ta 'din is-soluzzjoni.

Patroni

Dan huwa mudell python għall-ġestjoni ta 'PostgreSQL b'dokumentazzjoni tajba, failover awtomatiku u kodiċi tas-sors fuq github.

Vantaġġi ta' Patroni:

  • Kull parametru ta 'konfigurazzjoni huwa deskritt, huwa ċar kif jaħdem;
  • Il-falliment awtomatiku jaħdem barra mill-kaxxa;
  • Miktub bil-python, u peress li aħna stess niktbu ħafna bil-python, ikun aktar faċli għalina li nittrattaw il-problemi u, forsi, anke ngħinu l-iżvilupp tal-proġett;
  • Jikkontrolla bis-sħiħ PostgreSQL, jippermettilek tibdel il-konfigurazzjoni fuq in-nodi kollha tal-cluster f'daqqa, u jekk l-applikazzjoni tal-konfigurazzjoni l-ġdida teħtieġ bidu mill-ġdid tal-cluster, dan jista 'jsir mill-ġdid bl-użu ta' Patroni.

Cons:

  • Mhuwiex ċar mid-dokumentazzjoni kif taħdem b'mod korrett ma 'PgBouncer. Għalkemm huwa diffiċli li ssejjaħ dan bħala minus, minħabba li l-kompitu ta 'Patroni huwa li jamministra PostgreSQL, u kif se jaħdmu l-konnessjonijiet ma' Patroni hija diġà l-problema tagħna;
  • Hemm ftit eżempji ta’ implimentazzjoni ta’ Patroni fuq skala kbira, filwaqt li hemm ħafna eżempji ta’ implimentazzjoni mill-bidu.

Bħala riżultat, għażilna Patroni biex noħolqu cluster ta' failover.

Proċess ta' implimentazzjoni ta' Patroni

Qabel Patroni, kellna 12-il shards PostgreSQL f'konfigurazzjoni kaptan waħda u replika waħda b'replikazzjoni asinkronika. Is-servers tal-applikazzjoni aċċessaw id-databases permezz ta 'Netwerk Load Balancer, li warajh kien hemm żewġ każijiet ma' PgBouncer, u warajhom kien hemm is-servers PostgreSQL kollha.
Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

Biex nimplimentaw Patroni, kellna nagħżlu ħażna ta 'konfigurazzjoni ta' cluster distribwita. Patroni jaħdem b'sistemi ta' ħażna ta' konfigurazzjoni distribwita bħal etcd, Zookeeper, Consul. Għandna raggruppament Konslu sħiħ fil-produzzjoni, li jaħdem flimkien mal-Vault u ma nużawhx aktar. Raġuni kbira biex tibda tuża l-Konsul għall-iskop maħsub tagħha.

Kif Patroni jaħdem mal-Konslu

Għandna cluster Konslu, li jikkonsisti fi tliet nodi, u cluster Patroni, li jikkonsisti minn mexxej u replika (fil Patroni, il-kaptan jissejjaħ il-mexxej tal-cluster, u l-iskjavi jissejħu repliki). Kull istanza tal-cluster Patroni kontinwament tibgħat informazzjoni dwar l-istat tal-cluster lill-Konslu. Għalhekk, mingħand Konslu tista’ dejjem issir taf il-konfigurazzjoni attwali tal-cluster Patroni u min hu l-mexxej bħalissa.

Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

Biex tgħaqqad Patroni mal-Konslu, studja biss id-dokumentazzjoni uffiċjali, li tgħid li għandek bżonn tispeċifika l-host f'format http jew https, skont kif naħdmu mal-Konslu, u d-dijagramma tal-konnessjoni, b'mod fakultattiv:

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

Jidher sempliċi, iżda dan huwa fejn jibdew in-nases. Mal-Konsul naħdmu fuq konnessjoni sigura permezz https u l-konfigurazzjoni tal-konnessjoni tagħna tidher bħal din:

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

Imma ma taħdimx hekk. Fl-istartjar, Patroni ma jistax jgħaqqad mal-Konslu għax xorta jipprova jmur permezz tal-http.

Il-kodiċi tas-sors Patroni għen biex issolvi l-problema. Tajjeb li huwa miktub bil-python. Jirriżulta li l-parametru ospitanti ma jiġi analizzat bl-ebda mod, u l-protokoll għandu jiġi speċifikat fl-iskema. Hekk tidher għalina blokka ta' konfigurazzjoni li taħdem biex taħdem ma' Konslu:

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

Konslu-mudell

Allura, għażilna l-ħażna tal-konfigurazzjoni. Issa rridu nifhmu kif PgBouncer se jaqleb il-konfigurazzjoni tiegħu meta l-mexxej jinbidel fil-cluster Patroni. M'hemm l-ebda risposta għal din il-mistoqsija fid-dokumentazzjoni, għaliex... Fil-prinċipju, ix-xogħol ma 'PgBouncer mhuwiex deskritt hemmhekk.

Fit-tfittxija ta 'soluzzjoni, sibna artiklu (sfortunatament, ma niftakarx l-isem), fejn kien miktub li Consul-template kien ta' għajnuna kbira biex jgħaqqad PgBouncer u Patroni. Dan wassalna biex nistudjaw ix-xogħol ta’ Konslu-template.

Irriżulta li Consul-template kontinwament jimmonitorja l-konfigurazzjoni tal-cluster PostgreSQL f'Consul. Meta l-mexxej jinbidel, jaġġorna l-konfigurazzjoni ta 'PgBouncer u jibgħat kmand biex jerġa' jgħabbiha.

Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

Il-vantaġġ kbir tal-mudell huwa li jinħażen bħala kodiċi, għalhekk meta żżid shard ġdid, huwa biżżejjed li tagħmel impenn ġdid u taġġorna l-mudell awtomatikament, li tappoġġja l-prinċipju tal-Infrastruttura bħala kodiċi.

Arkitettura ġdida ma Patroni

Bħala riżultat, irċevejna l-iskema ta 'xogħol li ġejja:
Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

Is-servers tal-applikazzjoni kollha jaċċessaw il-balancer → warajh hemm żewġ każijiet ta’ PgBouncer → f’kull każ qed jaħdem mudell ta’ Konsul, li jimmonitorja l-istat ta’ kull cluster Patroni u jimmonitorja r-rilevanza tal-konfigurazzjoni ta’ PgBouncer, li jidderieġi t-talbiet lill-mexxej attwali ta’ kull cluster.

Ittestjar manwali

Qabel ma tnieda fil-produzzjoni, nedejna din l-iskema fuq ambjent ta 'test żgħir u ċċekkajna l-operat tal-bidla awtomatika. Huma fetħu l-bord, ċċaqalqu l-istiker u f'dak il-mument "qatlu" lill-mexxej tal-cluster. Fl-AWS, kull ma trid tagħmel hu li itfi l-istanza permezz tal-console.

Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

L-istiker reġgħet lura fi żmien 10-20 sekonda, u mbagħad reġgħet bdiet timxi b'mod normali. Dan ifisser li l-cluster Patroni ħadem b'mod korrett: biddel il-mexxej, bagħat informazzjoni lill-Konslu, u l-Konsul-template immedjatament qabad din l-informazzjoni, issostitwixxa l-konfigurazzjoni PgBouncer u bagħat kmand biex jerġa 'jikkarga.

Kif tgħix taħt tagħbija għolja u żżomm ħin ta 'waqfien minimu?

Kollox jaħdem perfettament! Iżda jqumu mistoqsijiet ġodda: Kif se taħdem taħt tagħbija għolja? Kif malajr u b'mod sikur roll out kollox fil-produzzjoni?

L-ambjent tat-test li fuqu nagħmlu l-ittestjar tat-tagħbija jgħinna nwieġbu l-ewwel mistoqsija. Huwa kompletament identiku għall-produzzjoni fl-arkitettura u ġġenerat dejta tat-test, li hija bejn wieħed u ieħor ugwali fil-volum għall-produzzjoni. Aħna niddeċiedu li "noqtlu" biss wieħed mill-kaptani tal-PostgreSQL waqt it-test u naraw x'jiġri. Iżda qabel dan, huwa importanti li tiċċekkja t-tnedija awtomatika, għaliex fuq dan l-ambjent għandna diversi shards PostgreSQL, għalhekk se nġibu ttestjar eċċellenti ta 'skripts ta' konfigurazzjoni qabel il-produzzjoni.

Iż-żewġ kompiti jidhru ambizzjużi, iżda għandna PostgreSQL 9.6. Forsi nistgħu naġġornaw għal 11.2 minnufih?

Aħna niddeċiedu li nagħmlu dan f'2 stadji: l-ewwel taġġorna l-verżjoni għal 11.2, imbagħad inniedu Patroni.

Aġġornament PostgreSQL

Biex taġġorna malajr il-verżjoni PostgreSQL, trid tuża l-għażla -k, fejn tinħoloq hard link fuq id-diska u m'hemmx għalfejn tikkopja d-data tiegħek. Fuq databases ta '300-400 GB, l-aġġornament jieħu 1 sekonda.

Għandna ħafna shards, għalhekk l-aġġornament jeħtieġ li jsir awtomatikament. Biex nagħmlu dan, ktibna playbook Ansible li jwettaq il-proċess kollu ta 'aġġornament għalina:

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

Huwa importanti li wieħed jinnota hawnhekk li qabel ma tibda l-aġġornament, trid twettaqha bil-parametru --kontrollbiex tkun ċert li l-aġġornament huwa possibbli. L-iskript tagħna jissostitwixxi wkoll il-konfigurazzjonijiet waqt l-aġġornament. L-iskript tagħna tlesta fi 30 sekonda, li huwa riżultat eċċellenti.

Tnedija ta' Patroni

Biex issolvi t-tieni problema, ħares biss lejn il-konfigurazzjoni Patroni. Ir-repożitorju uffiċjali għandu konfigurazzjoni ta 'eżempju ma' initdb, li huwa responsabbli għall-inizjalizzazzjoni ta 'database ġdida meta Patroni titnieda għall-ewwel darba. Iżda peress li diġà għandna database lesta, sempliċement neħħejna din it-taqsima mill-konfigurazzjoni.

Meta bdejna ninstallaw Patroni fuq cluster PostgreSQL lest u nnieduh, iltqajna ma 'problema ġdida: iż-żewġ servers tnedew bħala mexxej. Patroni ma jaf xejn dwar l-istat bikri tal-cluster u jipprova jħaddem iż-żewġ servers bħala żewġ clusters separati bl-istess isem. Biex issolvi din il-problema, għandek bżonn tħassar id-direttorju tad-dejta fuq l-iskjav:

rm -rf /var/lib/postgresql/

Dan għandu jsir biss fuq l-iskjav!

Meta tgħaqqad replika nadifa, Patroni jagħmel mexxej tal-basebackup u jirrestawraha għar-replika, u mbagħad ilaħħaq mal-istat attwali billi juża l-wal logs.

Diffikultà oħra li ltqajna magħhom hija li l-clusters kollha PostgreSQL jissejħu prinċipali b'mod awtomatiku. Meta kull cluster ma jkun jaf xejn dwar l-ieħor, dan huwa normali. Imma meta trid tuża Patroni, ir-raggruppamenti kollha għandu jkollhom isem uniku. Is-soluzzjoni hija li tbiddel l-isem tal-cluster fil-konfigurazzjoni PostgreSQL.

Test tat-tagħbija

Nedejna test li jissimula kif l-utenti jaħdmu fuq il-bordijiet. Meta t-tagħbija laħqet il-medja ta 'kuljum tagħna, aħna rrepejna eżattament l-istess test, itfija każ wieħed mal-mexxej PostgreSQL. Il-failover awtomatiku ħadem kif stennejna: Patroni biddel il-mexxej, Consul-template aġġorna l-konfigurazzjoni ta 'PgBouncer u bagħat kmand biex jerġa' jitgħabbi. Skont il-graffs tagħna fi Grafana, kien ċar li kien hemm dewmien ta '20-30 sekonda u ammont żgħir ta' żbalji mis-servers relatati mal-konnessjoni mad-database. Din hija sitwazzjoni normali, valuri bħal dawn huma aċċettabbli għall-falliment tagħna u huma definittivament aħjar mill-waqfien tas-servizz.

Tnedija ta' Patroni fil-produzzjoni

Bħala riżultat, ħriġna bil-pjan li ġej:

  • Tiskjera Consul-template fis-server PgBouncer u tniedi;
  • PostgreSQL jaġġorna l-verżjoni 11.2;
  • Nibdlu l-isem tal-cluster;
  • Tnedija tal-cluster Patroni.

Fl-istess ħin, l-iskema tagħna tippermettilna nagħmlu l-ewwel punt kważi f'kull ħin; nistgħu nneħħu kull PgBouncer mix-xogħol wieħed wieħed u nwettqu skjerament u tnedija ta 'konsul-template fuqha. Hekk għamilna.

Għal ttestjar rapidu, użajna Ansible, peress li konna diġà ttestjajna l-playbook kollu fuq ambjent tat-test, u l-ħin ta 'eżekuzzjoni għall-iskript sħiħ kien minn 1,5 sa 2 minuti għal kull shard. Nistgħu noffru kollox wieħed wieħed għal kull shard mingħajr ma nwaqqfu s-servizz tagħna, iżda jkollna nitfi kull PostgreSQL għal diversi minuti. F'dan il-każ, l-utenti li d-dejta tagħhom tinsab fuq dan il-frak ma jkunux jistgħu jaħdmu bis-sħiħ f'dan il-ħin, u dan huwa inaċċettabbli għalina.

Il-mod kif toħroġ minn din is-sitwazzjoni kienet manutenzjoni ppjanata, li nagħmlu kull 3 xhur. Din hija tieqa għal xogħol skedat, meta nitfi kompletament is-servizz tagħna u naġġornaw l-istanzi tad-database. Kien fadal ġimgħa għat-tieqa li jmiss, u ddeċidejna li nistennew u nippreparaw aktar. Waqt l-istennija, aħna wkoll ħeġġejna l-imħatri tagħna: għal kull shard PostgreSQL ġibna replika żejda f’każ ta’ falliment, sabiex insalvaw l-aħħar data, u żidna istanza ġdida għal kull shard, li għandha ssir replika ġdida fil-Patroni. cluster, sabiex ma joħroġx kmand biex titħassar id-data . Dan kollu għen biex jitnaqqas ir-riskju ta 'żball.
Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

Erġajna bdejna s-servizz tagħna, kollox ħadem kif suppost, l-utenti komplew jaħdmu, iżda fuq il-graffs innutajna tagħbija anormalment għolja fuq is-servers tal-Konslu.
Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

Għaliex ma rajniex dan fl-ambjent tat-test? Din il-problema turi tajjeb ħafna li huwa meħtieġ li jiġi segwit il-prinċipju tal-Infrastruttura bħala kodiċi u tittejjeb l-infrastruttura kollha, mill-ambjenti tat-test sal-produzzjoni. Inkella, huwa faċli ħafna li tikseb il-problema li ltqajna. X'ġara? Konslu l-ewwel deher fil-produzzjoni, u mbagħad fl-ambjenti tat-test; bħala riżultat, f'ambjenti tat-test il-verżjoni tal-Konslu kienet ogħla milli fil-produzzjoni. Biss f'wieħed mir-rilaxxi, ġie solvut tnixxija tas-CPU meta taħdem ma 'konsul-template. Allura aħna sempliċement aġġornaw il-Konslu, u b'hekk insolvu l-problema.

Ibda mill-ġdid il-cluster Patroni

Madankollu, aħna ltqajna problema ġdida li lanqas biss issuspettajna dwarha. Meta naġġornaw il-Konslu, aħna sempliċement inneħħu n-nodu tal-Konslu mill-cluster billi tuża l-kmand tal-leave tal-konslu → Patroni jgħaqqad ma' server Konslu ieħor → kollox jaħdem. Imma meta wasalna għall-aħħar istanza tar-raggruppament tal-Konslu u bgħattlu l-kmand tal-leave tal-konslu, il-clusters kollha tal-Patroni sempliċement reġgħu bdew, u fir-zkuk rajna l-iżball li ġej:

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 ma setax jikseb informazzjoni dwar il-cluster tiegħu u reġa' beda.

Biex insibu soluzzjoni, ikkuntattjajna lill-awturi ta' Patroni permezz ta' kwistjoni fuq github. Huma ssuġġerew titjib fil-fajls tal-konfigurazzjoni tagħna:

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

Konna kapaċi nirreplikaw il-kwistjoni f'ambjent tat-test u ttestjajna dawn is-settings hemmhekk, iżda sfortunatament ma ħadmux.

Il-problema għadha mhux solvuta. Qed nippjanaw li nippruvaw is-soluzzjonijiet li ġejjin:

  • Uża Konslu-aġent fuq kull istanza tal-cluster Patroni;
  • Waħħal il-problema fil-kodiċi.

Aħna nifhmu fejn seħħ l-iżball: probabbilment il-problema hija fl-użu tal-timeout default, li ma jinbidelx permezz tal-fajl tal-konfigurazzjoni. Meta l-aħħar server tal-Konsul jitneħħa mill-cluster, il-cluster kollu tal-Konslu jiffriża, li jdum aktar minn sekonda; minħabba dan, Patroni ma jistax jikseb l-istat tal-cluster u jerġa 'jibda kompletament il-cluster kollu.

Fortunatament, ma ltqajna aktar żbalji.

Riżultati tal-użu Patroni

Wara t-tnedija b'suċċess ta' Patroni, żidna replika addizzjonali f'kull cluster. Issa kull cluster għandu dehra ta' kworum: mexxej wieħed u żewġ repliki, biex jipproteġu kontra split-brain meta jaqilbu.
Raggruppament ta' failover PostgreSQL + Patroni. Esperjenza ta' implimentazzjoni

Patroni ilu jaħdem fil-produzzjoni għal aktar minn tliet xhur. Matul dan iż-żmien, huwa diġà rnexxielu jgħinna. Riċentement, il-mexxej ta 'wieħed mill-clusters miet fl-AWS, il-failover awtomatiku ħadem u l-utenti komplew jaħdmu. Patroni wettaq il-kompitu ewlieni tiegħu.

Sommarju qasir tal-użu ta' Patroni:

  • Faċilità tal-bidliet fil-konfigurazzjoni. Huwa biżżejjed li tinbidel il-konfigurazzjoni fuq istanza waħda u se tapplika għall-cluster kollu. Jekk ikun meħtieġ reboot biex tiġi applikata l-konfigurazzjoni l-ġdida, Patroni jinnotifikak b’dan. Patroni jista 'jerġa' jibda l-cluster kollu b'kmand wieħed, li huwa wkoll konvenjenti ħafna.
  • Il-falliment awtomatiku qed jaħdem u diġà għenuna.
  • Aġġornament ta' PostgreSQL mingħajr ħin ta' waqfien tal-applikazzjoni. L-ewwel trid taġġorna r-repliki għall-verżjoni l-ġdida, imbagħad ibiddel il-mexxej fil-grupp Patroni u taġġorna l-mexxej l-antik. F'dan il-każ, iseħħ l-ittestjar meħtieġ ta' failover awtomatiku.

Sors: www.habr.com

Żid kumment