ProHoster > Blogs > Administrācija > Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Rakstā pastāstÄ«Å”u, kā mēs piegājām PostgreSQL kļūdu tolerances jautājumam, kāpēc tas mums kļuva svarÄ«gi un kas beigās notika.

Mums ir ļoti noslogots pakalpojums: 2,5 miljoni lietotāju visā pasaulē, 50 100+ aktÄ«vo lietotāju katru dienu. Serveri atrodas Amazonē vienā ÄŖrijas reÄ£ionā: nepārtraukti strādā 50+ dažādi serveri, no kuriem gandrÄ«z XNUMX ir ar datu bāzēm.

Visa aizmugursistēma ir liela monolÄ«ta statusa saturoÅ”a Java lietojumprogramma, kas uztur pastāvÄ«gu tÄ«mekļa ligzdas savienojumu ar klientu. Kad vairāki lietotāji vienlaikus strādā pie vienas plates, viņi visi redz izmaiņas reāllaikā, jo katras izmaiņas mēs ierakstām datu bāzē. MÅ«su datu bāzēm ir aptuveni 10 80 pieprasÄ«jumu sekundē. Redis maksimālās slodzes laikā mēs rakstām 100ā€“XNUMX XNUMX pieprasÄ«jumu sekundē.
Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Kāpēc mēs pārgājām no Redis uz PostgreSQL

Sākotnēji mÅ«su pakalpojums strādāja ar Redis ā€” atslēgu vērtÄ«bu krātuvi, kas visus datus glabā servera RAM.

Redis plusi:

  1. Liels reakcijas ātrums, jo viss tiek saglabāts atmiņā;
  2. VienkārÅ”a dublÄ“Å”ana un replikācija.

Redis mīnusi mums:

  1. Reālu darījumu nav. Mēs mēģinājām tos simulēt mūsu lietojumprogrammas līmenī. Diemžēl tas ne vienmēr darbojās labi un bija jāieraksta ļoti sarežģīts kods.
  2. Datu apjomu ierobežo atmiņas apjoms. Palielinoties datu apjomam, atmiņa palielināsies, un galu galā mēs saskarsimies ar atlasÄ«tās instances Ä«paŔībām, kas AWS prasa apturēt mÅ«su pakalpojumu, lai mainÄ«tu instances veidu.
  3. Ir nepiecieÅ”ams pastāvÄ«gi uzturēt zemu latentuma lÄ«meni, jo. mums ir ļoti liels pieprasÄ«jumu skaits. Optimālais aizkaves lÄ«menis mums ir 17-20 ms. 30ā€“40 ms lÄ«menÄ« mēs saņemam ilgas atbildes uz pieprasÄ«jumiem no mÅ«su lietojumprogrammas un pakalpojuma degradāciju. Diemžēl mums tas notika 2018. gada septembrÄ«, kad viena no gadÄ«jumiem ar Redis nez kāpēc saņēma latentumu 2 reizes vairāk nekā parasti. Lai atrisinātu problēmu, mēs apturējām pakalpojumu dienas vidÅ« neplānotas apkopes dēļ un nomainÄ«jām problemātisko Redis instanci.
  4. Ir viegli iegÅ«t datu nekonsekvenci pat ar nelielām kļūdām kodā un pēc tam pavadÄ«t daudz laika, rakstot kodu, lai labotu Å”os datus.

Mēs ņēmām vērā mīnusus un sapratām, ka mums ir jāpāriet uz kaut ko ērtāku, ar normāliem darījumiem un mazāku atkarību no latentuma. Veica pētījumu, analizēja daudzas iespējas un izvēlējās PostgreSQL.

Jau 1,5 gadu esam pārgājuÅ”i uz jaunu datu bāzi un esam pārvietojuÅ”i tikai nelielu daļu datu, tāpēc tagad strādājam vienlaicÄ«gi ar Redis un PostgreSQL. PlaŔāka informācija par datu pārvietoÅ”anas un pārslēgÅ”anas posmiem starp datu bāzēm ir ierakstÄ«ta mana kolēģa raksts.

Kad mēs sākām pārvietoties, mÅ«su lietojumprogramma strādāja tieÅ”i ar datu bāzi un piekļuva galvenajam Redis un PostgreSQL. PostgreSQL klasteris sastāvēja no galvenā un replikas ar asinhrono replikāciju. Šādi izskatÄ«jās datu bāzes shēma:
Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

PgBouncer ievieŔana

Kamēr mēs pārvietojāmies, produkts arÄ« attÄ«stÄ«jās: pieauga lietotāju un serveru skaits, kas strādāja ar PostgreSQL, un mums sāka trÅ«kt savienojumu. PostgreSQL katram savienojumam izveido atseviŔķu procesu un patērē resursus. JÅ«s varat palielināt savienojumu skaitu lÄ«dz noteiktam punktam, pretējā gadÄ«jumā pastāv iespēja iegÅ«t neoptimālu datu bāzes veiktspēju. Ideāls variants Ŕādā situācijā bÅ«tu izvēlēties savienojumu pārvaldnieku, kas stāvēs pamatnes priekŔā.

Mums bija divas savienojuma pārvaldnieka iespējas: Pgpool un PgBouncer. Bet pirmais neatbalsta darījumu režīmu darbam ar datu bāzi, tāpēc mēs izvēlējāmies PgBouncer.

Mēs esam izveidojuÅ”i Ŕādu darba shēmu: mÅ«su lietojumprogramma piekļūst vienam PgBouncer, aiz kura atrodas PostgreSQL meistari, un aiz katra galvenā ir viena kopija ar asinhrono replikāciju.
Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Tajā paŔā laikā mēs nevarējām saglabāt visu datu apjomu PostgreSQL, un mums bija svarÄ«gs darba ātrums ar datu bāzi, tāpēc mēs sākām PostgreSQL sadalÄ«t lietojumprogrammu lÄ«menÄ«. Tam ir salÄ«dzinoÅ”i ērta iepriekÅ” aprakstÄ«tā shēma: pievienojot jaunu PostgreSQL shardu, pietiek ar PgBouncer konfigurācijas atjaunināŔanu un aplikācija var uzreiz strādāt ar jauno shard.

PgBouncer kļūmjpārlēce

Å Ä« shēma darbojās lÄ«dz brÄ«dim, kad nomira vienÄ«gā PgBouncer instance. Mēs atrodamies AWS, kur visi gadÄ«jumi darbojas ar aparatÅ«ru, kas periodiski nomirst. Šādos gadÄ«jumos gadÄ«jums vienkārÅ”i pāriet uz jaunu aparatÅ«ru un atkal darbojas. Tas notika ar PgBouncer, taču tas kļuva nepieejams. Å Ä« kritiena rezultāts bija mÅ«su pakalpojuma nepieejamÄ«ba 25 minÅ«tes. AWS iesaka Ŕādām situācijām izmantot lietotāja puses atlaiÅ”anu, kas tobrÄ«d mÅ«su valstÄ« netika ieviesta.

Pēc tam mēs nopietni domājām par PgBouncer un PostgreSQL klasteru kļūdu toleranci, jo līdzīga situācija var notikt ar jebkuru gadījumu mūsu AWS kontā.

Mēs izveidojām PgBouncer kļūdu tolerances shēmu Ŕādi: visi lietojumprogrammu serveri piekļūst tÄ«kla slodzes lÄ«dzsvarotājam, aiz kura atrodas divi PgBouncer. Katrs PgBouncer apskata vienu un to paÅ”u PostgreSQL katras Ŕķembas meistaru. Ja AWS instances avārija atkārtojas, visa trafika tiek novirzÄ«ta caur citu PgBouncer. TÄ«kla slodzes lÄ«dzsvara kļūmjpārlēci nodroÅ”ina AWS.

Å Ä« shēma atvieglo jaunu PgBouncer serveru pievienoÅ”anu.
Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Izveidojiet PostgreSQL kļūmjpārlēces kopu

Risinot Å”o problēmu, mēs apsvērām dažādas iespējas: paÅ”rakstÄ«ts failover, repmgr, AWS RDS, Patroni.

PaŔu rakstīti skripti

Viņi var pārraudzīt galvenās ierīces darbu un, ja tas neizdodas, reklamēt kopiju uz galveno un atjaunināt PgBouncer konfigurāciju.

Šīs pieejas priekŔrocības ir maksimāla vienkārŔība, jo jūs pats rakstāt skriptus un precīzi saprotat, kā tie darbojas.

MÄ«nusi:

  • Iespējams, kapteinis nav miris, tā vietā var bÅ«t radusies tÄ«kla kļūme. Failover, to nezinot, paaugstinās kopiju meistaram, bet vecais meistars turpinās strādāt. Rezultātā mēs iegÅ«sim divus serverus meistara lomā un mēs nezināsim, kuram no tiem ir jaunākie jaunākie dati. Å o situāciju sauc arÄ« par smadzeņu sadalÄ«Å”anos;
  • Mēs palikām bez atbildes. MÅ«su konfigurācijā galvenais un viena kopija pēc pārslēgÅ”anās tiek pārvietota uz galveno, un mums vairs nav kopiju, tāpēc mums ir manuāli jāpievieno jauna kopija;
  • Mums ir nepiecieÅ”ama papildu kļūmjpārlēces darbÄ«bas uzraudzÄ«ba, savukārt mums ir 12 PostgreSQL shards, kas nozÄ«mē, ka mums ir jāuzrauga 12 klasteri. Palielinoties shardu skaitam, jāatceras arÄ« atjaunināt kļūmjpārlēci.

PaÅ”u rakstÄ«ta kļūmjpārlēce izskatās ļoti sarežģīta un prasa nenozÄ«mÄ«gu atbalstu. Izmantojot vienu PostgreSQL klasteru, tas bÅ«tu vienkārŔākais variants, taču tas netiek mērogots, tāpēc tas mums nav piemērots.

Repmgr

Replikācijas pārvaldnieks PostgreSQL klasteriem, kas var pārvaldÄ«t PostgreSQL klastera darbÄ«bu. Tajā paŔā laikā tam nav automātiskas kļūmjpārlēces no kastes, tāpēc darbam jums bÅ«s jāraksta savs ā€œiesaiņojumsā€ virs gatavā risinājuma. Tātad viss var izrādÄ«ties vēl sarežģītāk nekā ar paÅ”u rakstÄ«tiem skriptiem, tāpēc mēs pat nemēģinājām Repmgr.

AWS RDS

Atbalsta visu, kas mums nepiecieÅ”ams, zina, kā izveidot dublējumus un uztur savienojumu kopumu. Tam ir automātiska pārslēgÅ”anās: kad galvenais nomirst, replika kļūst par jauno galveno, un AWS maina dns ierakstu uz jauno galveno, savukārt kopijas var atrasties dažādos AZ.

TrÅ«kumi ietver smalku pielāgojumu trÅ«kumu. Kā precÄ«zas regulÄ“Å”anas piemērs: mÅ«su gadÄ«jumiem ir ierobežojumi tcp savienojumiem, ko diemžēl nevar izdarÄ«t RDS:

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

Turklāt AWS RDS ir gandrīz divas reizes dārgāka par parastās instances cenu, kas bija galvenais iemesls atteikŔanās no Ŕī risinājuma.

Patroni

Šī ir python veidne PostgreSQL pārvaldībai ar labu dokumentāciju, automātisku kļūmjpārlēci un pirmkodu vietnē github.

Patroni plusi:

  • Katrs konfigurācijas parametrs ir aprakstÄ«ts, ir skaidrs, kā tas darbojas;
  • Automātiskā kļūmjpārlēce darbojas jau no kastes;
  • RakstÄ«ts python, un tā kā mēs paÅ”i daudz rakstām python, tad mums bÅ«s vieglāk tikt galā ar problēmām un, iespējams, pat palÄ«dzēt projekta attÄ«stÄ«bai;
  • PilnÄ«bā pārvalda PostgreSQL, ļauj vienlaikus mainÄ«t konfigurāciju visos klastera mezglos un, ja klasteris ir jārestartē, lai lietotu jauno konfigurāciju, to var izdarÄ«t vēlreiz, izmantojot Patroni.

MÄ«nusi:

  • No dokumentācijas nav skaidrs, kā pareizi strādāt ar PgBouncer. Lai gan to ir grÅ«ti nosaukt par mÄ«nusu, jo Patroni uzdevums ir pārvaldÄ«t PostgreSQL, un tas, kā notiks savienojumi ar Patroni, jau ir mÅ«su problēma;
  • Ir maz Patroni ievieÅ”anas piemēru lielos apjomos, savukārt ir daudz piemēru ievieÅ”anai no nulles.

Tā rezultātā mēs izvēlējāmies Patroni, lai izveidotu kļūmjpārlēces kopu.

Patroni ievieŔanas process

Pirms Patroni mums bija 12 PostgreSQL shards viena galvenā konfigurācijā un viena kopija ar asinhrono replikāciju. Lietojumprogrammu serveri piekļuva datu bāzēm, izmantojot Network Load Balancer, aiz kura atradās divi gadījumi ar PgBouncer, un aiz tiem atradās visi PostgreSQL serveri.
Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Lai ieviestu Patroni, mums bija jāizvēlas izplatÄ«ta krātuves klastera konfigurācija. Patroni strādā ar izplatÄ«tām konfigurācijas glabāŔanas sistēmām, piemēram, etcd, Zookeeper, Consul. Mums tikko tirgÅ« ir pilnvērtÄ«gs konsulu klasteris, kas darbojas kopā ar Vault, un mēs to vairs neizmantojam. Lielisks iemesls, lai sāktu lietot Consul paredzētajam mērÄ·im.

Kā Patroni strādā ar konsulu

Mums ir Consul klasteris, kas sastāv no trim mezgliem, un Patroni klasteris, kas sastāv no lÄ«dera un kopijas (Patroni valodā galveno sauc par klastera vadÄ«tāju, bet vergus sauc par replikām). Katrs Patroni klastera gadÄ«jums pastāvÄ«gi nosÅ«ta konsulam informāciju par klastera stāvokli. Tāpēc no Consul vienmēr varat uzzināt paÅ”reizējo Patroni klastera konfigurāciju un to, kurÅ” Å”obrÄ«d ir lÄ«deris.

Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Lai savienotu Patroni ar Consul, pietiek izpētīt oficiālo dokumentāciju, kurā teikts, ka jums ir jānorāda resursdators http vai https formātā atkarībā no tā, kā mēs strādājam ar Consul, un savienojuma shēmu, pēc izvēles:

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

Tas izskatās vienkārÅ”i, bet Å”eit sākas kļūmes. Ar Consul mēs strādājam, izmantojot droÅ”u savienojumu, izmantojot https, un mÅ«su savienojuma konfigurācija izskatÄ«sies Ŕādi:

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

Bet tas nedarbojas. StartÄ“Å”anas laikā Patroni nevar izveidot savienojumu ar Consul, jo tas tik un tā mēģina iet caur http.

Patroni pirmkods palīdzēja tikt galā ar problēmu. Labi, ka tas ir rakstīts python valodā. Izrādās, ka resursdatora parametrs nekādā veidā nav parsēts, un protokols ir jānorāda shēmā. Šādi mums izskatās darba konfigurācijas bloks darbam ar Consul:

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

konsuls-veidne

Tātad, mēs esam izvēlējuÅ”ies konfigurācijas krātuvi. Tagad mums ir jāsaprot, kā PgBouncer mainÄ«s savu konfigurāciju, mainot lÄ«deri Patroni klasterÄ«. Uz Å”o jautājumu dokumentācijā atbildes nav, jo. tur principā darbs ar PgBouncer nav aprakstÄ«ts.

Meklējot risinājumu, atradām rakstu (virsrakstu diemžēl neatceros), kur bija rakstÄ«ts, ka Š”onsul-template ļoti palÄ«dzēja PgBouncer un Patroni savienoÅ”anā. Tas pamudināja mÅ«s izpētÄ«t, kā darbojas Consul-veidne.

Izrādījās, ka Consul-template pastāvīgi uzrauga PostgreSQL klastera konfigurāciju Consul. Kad vadītājs mainās, tas atjaunina PgBouncer konfigurāciju un nosūta komandu, lai to atkārtoti ielādētu.

Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Liels veidnes pluss ir tas, ka tā tiek saglabāta kā kods, tāpēc, pievienojot jaunu shardu, pietiek ar jaunu commit un veidnes automātisku atjaunināŔanu, atbalstot Infrastructure as code principu.

Jauna arhitektūra ar Patroni

Rezultātā mēs saņēmām Ŕādu darba shēmu:
Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Visi lietojumprogrammu serveri piekļūst lÄ«dzsvarotājam ā†’ aiz tā ir divi PgBouncer gadÄ«jumi ā†’ katrā instancē tiek palaista Consul veidne, kas uzrauga katra Patroni klastera statusu un uzrauga PgBouncer konfigurācijas atbilstÄ«bu, kas nosÅ«ta pieprasÄ«jumus paÅ”reizējam lÄ«derim. katra klastera.

Manuāla pārbaude

Mēs palaidām Å”o shēmu pirms tās palaiÅ”anas nelielā testa vidē un pārbaudÄ«jām automātiskās pārslēgÅ”anas darbÄ«bu. Viņi atvēra dēli, pārvietoja uzlÄ«mi un tajā brÄ«dÄ« ā€œnogalinājaā€ klastera vadÄ«tāju. Pakalpojumā AWS tas ir tikpat vienkārÅ”i kā gadÄ«juma izslēgÅ”ana, izmantojot konsoli.

Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

UzlÄ«me atgriezās atpakaļ 10-20 sekunžu laikā un pēc tam atkal sāka kustēties kā parasti. Tas nozÄ«mē, ka Patroni klasteris darbojās pareizi: tas mainÄ«ja vadÄ«tāju, nosÅ«tÄ«ja informāciju Š”onsul, un Š”onsul-template nekavējoties paņēma Å”o informāciju, nomainÄ«ja PgBouncer konfigurāciju un nosÅ«tÄ«ja komandu pārlādēt.

Kā izdzīvot zem lielas slodzes un samazināt dīkstāves laiku?

Viss strādā perfekti! Bet rodas jauni jautājumi: kā tas darbosies pie lielas slodzes? Kā ātri un droÅ”i visu izrullēt ražoÅ”anā?

Testa vide, kurā mēs veicam slodzes testÄ“Å”anu, palÄ«dz mums atbildēt uz pirmo jautājumu. ArhitektÅ«ras ziņā tas ir pilnÄ«gi identisks ražoÅ”anai un ir Ä£enerējis testa datus, kas pēc apjoma ir aptuveni vienādi ar ražoÅ”anas apjomu. Mēs nolemjam testa laikā vienkārÅ”i "nogalināt" vienu no PostgreSQL meistariem un redzēt, kas notiks. Bet pirms tam ir svarÄ«gi pārbaudÄ«t automātisko ritināŔanu, jo Å”ajā vidē mums ir vairākas PostgreSQL shards, tāpēc mēs iegÅ«sim lielisku konfigurācijas skriptu testÄ“Å”anu pirms ražoÅ”anas.

Abi uzdevumi izskatās ambiciozi, taču mums ir PostgreSQL 9.6. Vai mēs varam nekavējoties jaunināt uz 11.2?

Mēs nolemjam to izdarīt divās darbībās: vispirms jauniniet uz 2, pēc tam palaidiet Patroni.

PostgreSQL atjauninājums

Lai ātri atjauninātu PostgreSQL versiju, izmantojiet opciju -k, kurā diskā tiek izveidotas cietās saites un nav nepiecieÅ”ams kopēt jÅ«su datus. Ja ietilpÄ«ba ir 300ā€“400 GB, atjaunināŔana aizņem 1 sekundi.

Mums ir daudz lauskas, tāpēc atjaunināŔana ir jāveic automātiski. Lai to izdarÄ«tu, mēs uzrakstÄ«jām Ansible rokasgrāmatu, kurā mÅ«su vietā tiek apstrādāts viss atjaunināŔanas process:

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

Å eit ir svarÄ«gi atzÄ«mēt, ka pirms jaunināŔanas uzsākÅ”anas tas ir jāveic ar parametru --pārbaudilai pārliecinātos, ka varat jaunināt. MÅ«su skripts arÄ« veic konfigurāciju aizstāŔanu jaunināŔanas laikā. MÅ«su skripts tika pabeigts 30 sekundēs, kas ir lielisks rezultāts.

Palaidiet Patroni

Lai atrisinātu otro problēmu, vienkārÅ”i apskatiet Patroni konfigurāciju. Oficiālajā repozitorijā ir konfigurācijas piemērs ar initdb, kas ir atbildÄ«gs par jaunas datu bāzes inicializÄ“Å”anu, kad pirmo reizi startējat Patroni. Bet, tā kā mums jau ir gatava datu bāze, mēs vienkārÅ”i noņēmām Å”o sadaļu no konfigurācijas.

Kad sākām instalēt Patroni jau esoŔā PostgreSQL klasterÄ« un palaist to, radās jauna problēma: abi serveri sāka darboties kā lÄ«deri. Patroni neko nezina par klastera agrÄ«no stāvokli un mēģina palaist abus serverus kā divus atseviŔķus klasterus ar tādu paÅ”u nosaukumu. Lai atrisinātu Å”o problēmu, jums ir jāizdzÄ“Å” direktorijs ar datiem par vergu:

rm -rf /var/lib/postgresql/

Tas jādara tikai vergam!

Kad ir pievienota tÄ«ra kopija, Patroni izveido bāzes dublējuma lÄ«deri un atjauno to replikā, un pēc tam sasniedz paÅ”reizējo stāvokli saskaņā ar Wal logs.

Vēl viena problēma, ar kuru mēs saskārāmies, ir tā, ka visas PostgreSQL klasterus pēc noklusējuma nosauc par galvenajiem. Ja katrs klasteris neko nezina par otru, tas ir normāli. Bet, ja vēlaties izmantot Patroni, visām kopām ir jābūt unikālam nosaukumam. Risinājums ir mainīt klastera nosaukumu PostgreSQL konfigurācijā.

slodzes tests

Mēs esam uzsākuÅ”i testu, kas simulē lietotāja pieredzi uz dēļiem. Kad slodze sasniedza mÅ«su vidējo dienas vērtÄ«bu, mēs atkārtojām tieÅ”i to paÅ”u testu, izslēdzām vienu gadÄ«jumu ar PostgreSQL lÄ«deri. Automātiskā kļūmjpārlēce darbojās, kā mēs gaidÄ«jām: Patroni mainÄ«ja vadÄ«tāju, Consul-template atjaunināja PgBouncer konfigurāciju un nosÅ«tÄ«ja komandu atkārtoti ielādēt. Saskaņā ar mÅ«su Grafana diagrammām bija skaidrs, ka ir 20ā€“30 sekunžu aizkave un neliels kļūdu skaits no serveriem, kas saistÄ«ti ar savienojumu ar datu bāzi. Tā ir normāla situācija, Ŕādas vērtÄ«bas ir pieņemamas mÅ«su kļūmjpārlēcei un noteikti ir labākas par pakalpojuma dÄ«kstāvi.

Patroni ievieŔana ražoŔanā

Rezultātā mēs izstrādājām Ŕādu plānu:

  • Izvietot Consul veidni PgBouncer serveros un palaist;
  • PostgreSQL atjauninājumi versijai 11.2;
  • Mainiet klastera nosaukumu;
  • Patroni klastera uzsākÅ”ana.

Tajā paŔā laikā mÅ«su shēma ļauj mums izdarÄ«t pirmo punktu gandrÄ«z jebkurā laikā, mēs varam pēc kārtas noņemt katru PgBouncer no darba un tajā izvietot un palaist konsula veidni. Tā arÄ« izdarÄ«jām.

Ātrai izvietoÅ”anai mēs izmantojām Ansible, jo mēs jau esam testējuÅ”i visas rokasgrāmatas testa vidē, un pilna skripta izpildes laiks bija no 1,5 lÄ«dz 2 minÅ«tēm katram fragmentam. Mēs varētu izlikt visu pēc kārtas katrā shardā, neapturot mÅ«su pakalpojumu, taču mums uz dažām minÅ«tēm bÅ«tu jāizslēdz katrs PostgreSQL. Å ajā gadÄ«jumā lietotāji, kuru dati atrodas Å”ajā shardā, Å”obrÄ«d nevar pilnÄ«bā darboties, un tas mums nav pieņemami.

Izeja no Ŕīs situācijas bija plānveida apkope, kas notiek ik pēc 3 mēneÅ”iem. Å is ir plānotā darba logs, kad mēs pilnÄ«bā izslēdzam pakalpojumu un jauninām datu bāzes gadÄ«jumus. LÄ«dz nākamajam logam bija palikusi nedēļa, un mēs nolēmām vienkārÅ”i pagaidÄ«t un gatavoties tālāk. GaidÄ«Å”anas laikā mēs papildus nodroÅ”inājām sevi: katrai PostgreSQL fragmentam izveidojām rezerves kopiju gadÄ«jumam, ja neizdodas saglabāt jaunākos datus, un katrai fragmentam pievienojām jaunu gadÄ«jumu, kam vajadzētu kļūt par jaunu kopiju Patroni klasterÄ«, lai netiktu izpildÄ«ta datu dzÄ“Å”anas komanda. Tas viss palÄ«dzēja samazināt kļūdu risku.
Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Restartējām savu servisu, viss darbojās kā nākas, lietotāji turpināja strādāt, bet grafikos novērojām nenormāli lielu Consul serveru slodzi.
Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Kāpēc mēs to neredzējām testa vidē? Å Ä« problēma ļoti labi parāda, ka ir jāievēro infrastruktÅ«ras kā koda princips un jāpilnveido visa infrastruktÅ«ra, sākot no testa vidēm lÄ«dz ražoÅ”anai. Pretējā gadÄ«jumā ir ļoti viegli tikt galā ar raduÅ”os problēmu. Kas notika? Consul vispirms parādÄ«jās ražoÅ”anā, bet pēc tam testa vidēs, kā rezultātā testa vidēs Consul versija bija augstāka nekā sērijveida. Tikai vienā no laidieniem, strādājot ar konsul-veidni, tika novērsta CPU noplÅ«de. Tāpēc mēs vienkārÅ”i atjauninājām konsulu, tādējādi atrisinot problēmu.

Restartējiet Patroni kopu

Tomēr mums radās jauna problēma, par kuru mums pat nebija aizdomas. Atjauninot Consul, mēs vienkārÅ”i noņemam Consul mezglu no klastera, izmantojot komandu konsuls atstāt ā†’ Patroni izveido savienojumu ar citu Consul serveri ā†’ viss darbojas. Bet, kad mēs nokļuvām pēdējā konsulu kopas instancē un nosÅ«tÄ«jām tai konsula atvaļinājuma komandu, visas Patroni kopas vienkārÅ”i restartējās, un žurnālos mēs redzējām Ŕādu kļūdu:

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>

Patroni klasteris nevarēja izgūt informāciju par savu kopu un tika restartēts.

Lai rastu risinājumu, mēs sazinājāmies ar Patroni autoriem, izmantojot github problēmu. Viņi ieteica uzlabojumus mūsu konfigurācijas failos:

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

Mēs varējām atkārtot problēmu testa vidē un tur pārbaudÄ«jām Ŕīs opcijas, taču diemžēl tās nedarbojās.

Problēma joprojām ir neatrisināta. Mēs plānojam izmēģināt Ŕādus risinājumus:

  • Izmantojiet Consul-agent katrā Patroni klastera instancē;
  • Novērsiet problēmu kodā.

Mēs saprotam, kur radās kļūda: problēma, iespējams, ir noklusējuma taimauta izmantoÅ”ana, kas netiek ignorēta konfigurācijas failā. Kad pēdējais Consul serveris tiek noņemts no klastera, viss Consul klasteris uzkaras ilgāk par sekundi, tāpēc Patroni nevar iegÅ«t klastera statusu un pilnÄ«bā restartē visu klasteru.

Par laimi, mēs vairs nesaskārāmies ar kļūdām.

Patroni lietoŔanas rezultāti

Pēc veiksmÄ«gas Patroni palaiÅ”anas mēs pievienojām papildu kopiju katrā klasterÄ«. Tagad katrā klasterÄ« ir kvoruma lÄ«dzÄ«ba: viens lÄ«deris un divas kopijas droŔības tÄ«klam smadzeņu sadalÄ«Å”anas gadÄ«jumā, pārslēdzoties.
Failover Cluster PostgreSQL + Patroni. IevieŔanas pieredze

Patroni ir strādājis pie ražoÅ”anas vairāk nekā trÄ«s mēneÅ”us. Å ajā laikā viņŔ jau ir paspējis mums palÄ«dzēt. Nesen AWS nomira viena klastera vadÄ«tājs, darbojās automātiskā kļūmjpārlēce un lietotāji turpināja strādāt. Patroni izpildÄ«ja savu galveno uzdevumu.

Neliels Patroni lietoŔanas kopsavilkums:

  • VienkārÅ”a konfigurācijas maiņa. Pietiek nomainÄ«t konfigurāciju vienā instancē, un tā tiks izvilkta uz visu klasteru. Ja, lai lietotu jauno konfigurāciju, ir nepiecieÅ”ama atsāknÄ“Å”ana, Patroni jÅ«s par to paziņos. Patroni var restartēt visu klasteru ar vienu komandu, kas arÄ« ir ļoti ērti.
  • Automātiskā kļūmjpārlēce darbojas un jau ir spējusi mums palÄ«dzēt.
  • PostgreSQL atjaunināŔana bez lietojumprogrammas dÄ«kstāves. Vispirms ir jāatjaunina replikas uz jauno versiju, pēc tam jāmaina Patroni klastera lÄ«deris un jāatjaunina vecais lÄ«deris. Å ajā gadÄ«jumā tiek veikta nepiecieÅ”amā automātiskās kļūmjpārlēces pārbaude.

Avots: www.habr.com

Pievieno komentāru