Í greininni mun ég segja þér hvernig við nálguðumst málið um PostgreSQL bilanaþol, hvers vegna það varð mikilvægt fyrir okkur og hvað gerðist á endanum.
Við erum með mjög hlaðna þjónustu: 2,5 milljónir notenda um allan heim, 50 þúsund virkir notendur á hverjum degi. Netþjónarnir eru staðsettir í Amazone á einu svæði á Írlandi: 100+ mismunandi netþjónar eru stöðugt í gangi, þar af tæplega 50 með gagnagrunnum.
Allur bakendinn er stórt einhæft, ríkjandi Java forrit sem heldur stöðugri nettengingu við viðskiptavininn. Þegar nokkrir notendur vinna á sama borði á sama tíma sjá þeir allar breytingarnar í rauntíma, því við skrifum hverja breytingu í gagnagrunninn. Við höfum um 10K beiðnir á sekúndu í gagnagrunna okkar. Við hámarksálag í Redis skrifum við 80-100K beiðnir á sekúndu.
Af hverju við skiptum úr Redis yfir í PostgreSQL
Upphaflega virkaði þjónustan okkar með Redis, lykilgildaverslun sem geymir öll gögn í vinnsluminni miðlarans.
Kostir Redis:
- Mikill viðbragðshraði, vegna þess að allt er geymt í minni;
- Auðvelt að taka öryggisafrit og afritun.
Gallar Redis fyrir okkur:
- Það eru engin raunveruleg viðskipti. Við reyndum að líkja eftir þeim á stigi umsóknar okkar. Því miður virkaði þetta ekki alltaf vel og þurfti að skrifa mjög flókinn kóða.
- Gagnamagnið er takmarkað af minnismagninu. Eftir því sem gagnamagnið eykst mun minnið stækka og á endanum munum við lenda í einkennum valins tilviks, sem í AWS krefst þess að stöðva þjónustu okkar til að breyta gerð tilviks.
- Það er nauðsynlegt að halda stöðugt lágu leynistigi, vegna þess að. við höfum mjög mikinn fjölda beiðna. Ákjósanlegasta seinkun fyrir okkur er 17-20 ms. Á stigi 30-40 ms fáum við löng svör við beiðnum frá umsókn okkar og niðurbroti á þjónustunni. Því miður gerðist þetta fyrir okkur í september 2018, þegar eitt af tilvikunum með Redis af einhverjum ástæðum fékk töf tvisvar sinnum meira en venjulega. Til að leysa málið stöðvuðum við þjónustuna um miðjan dag vegna ótímasetts viðhalds og skiptum út vandræðalega Redis tilvikinu.
- Það er auðvelt að fá ósamræmi í gögnum jafnvel með minniháttar villur í kóðanum og eyða síðan miklum tíma í að skrifa kóða til að leiðrétta þessi gögn.
Við tókum tillit til gallanna og komumst að því að við þyrftum að fara í eitthvað þægilegra, með eðlilegum viðskiptum og minna háð leynd. Framkvæmdi rannsóknir, greindi marga möguleika og valdi PostgreSQL.
Við höfum verið að færa okkur yfir í nýjan gagnagrunn í 1,5 ár þegar og höfum fært aðeins lítinn hluta af gögnunum, þannig að nú erum við að vinna samtímis með Redis og PostgreSQL. Nánari upplýsingar um stig flutnings og skiptingar gagna á milli gagnagrunna eru skrifaðar inn .
Þegar við byrjuðum fyrst að flytja virkaði forritið okkar beint með gagnagrunninum og fékk aðgang að meistara Redis og PostgreSQL. PostgreSQL þyrpingin samanstóð af meistara og eftirmynd með ósamstilltri afritun. Svona leit gagnagrunnskerfið út:
Innleiðing PgBouncer
Á meðan við vorum að flytja var varan einnig að þróast: fjöldi notenda og fjölda netþjóna sem unnu með PostgreSQL fjölgaði og okkur fór að vanta tengingar. PostgreSQL býr til sérstakt ferli fyrir hverja tengingu og eyðir auðlindum. Þú getur aukið fjölda tenginga upp að ákveðnum tímapunkti, annars er möguleiki á að fá óákjósanlegur árangur gagnagrunnsins. Kjörinn kostur í slíkum aðstæðum væri að velja tengistjóra sem mun standa fyrir framan grunninn.
Við höfðum tvo valkosti fyrir tengistjórann: Pgpool og PgBouncer. En sá fyrsti styður ekki viðskiptahaminn til að vinna með gagnagrunninn, svo við völdum PgBouncer.
Við höfum sett upp eftirfarandi vinnukerfi: forritið okkar hefur aðgang að einum PgBouncer, á bak við hann eru PostgreSQL meistarar, og á bak við hvern meistara er ein eftirmynd með ósamstilltri afritun.
Á sama tíma gátum við ekki geymt allt gagnamagnið í PostgreSQL og hraði vinnunnar með gagnagrunninn var mikilvægur fyrir okkur, svo við byrjuðum að klippa PostgreSQL á forritastigi. Kerfið sem lýst er hér að ofan er tiltölulega þægilegt fyrir þetta: þegar þú bætir við nýjum PostgreSQL shard, það er nóg að uppfæra PgBouncer stillingar og forritið getur strax unnið með nýja shard.
PgBouncer bilun
Þetta kerfi virkaði þar til eina PgBouncer tilvikið dó. Við erum í AWS, þar sem öll tilvik keyra á vélbúnaði sem deyr reglulega. Í slíkum tilvikum færist tilvikið einfaldlega yfir í nýjan vélbúnað og virkar aftur. Þetta gerðist með PgBouncer, en það varð ófáanlegt. Niðurstaðan af þessu hausti var að þjónusta okkar var ekki tiltæk í 25 mínútur. AWS mælir með því að nota offramboð á notendahlið fyrir slíkar aðstæður, sem var ekki innleitt í okkar landi á þeim tíma.
Eftir það hugsuðum við alvarlega um bilanaþol PgBouncer og PostgreSQL klasa, vegna þess að svipað ástand gæti gerst með hvaða tilvik sem er á AWS reikningnum okkar.
Við smíðuðum PgBouncer bilanaþolskerfið sem hér segir: allir forritaþjónar fá aðgang að Network Load Balancer, á bak við hann eru tveir PgBouncers. Hver PgBouncer lítur á sama PostgreSQL meistara hvers brots. Ef AWS tilvik hrun á sér stað aftur, er allri umferð vísað í gegnum annan PgBouncer. Network Load Balancer bilun er veitt af AWS.
Þetta kerfi gerir það auðvelt að bæta við nýjum PgBouncer netþjónum.
Búðu til PostgreSQL failover þyrping
Þegar við leystum þetta vandamál, skoðuðum við mismunandi valkosti: sjálfskrifað bilun, repmgr, AWS RDS, Patroni.
Sjálfskrifuð handrit
Þeir geta fylgst með vinnu meistarans og, ef það mistekst, kynnt eftirmyndina til meistarans og uppfært PgBouncer stillinguna.
Kostir þessarar aðferðar eru hámarks einfaldleiki, því þú skrifar handrit sjálfur og skilur nákvæmlega hvernig þau virka.
Gallar:
- Skipstjórinn gæti ekki hafa dáið, í staðinn gæti netbilun átt sér stað. Bilun, án þess að vita af þessu, mun kynna eftirmyndina til meistarans, en gamli meistarinn mun halda áfram að vinna. Fyrir vikið fáum við tvo netþjóna í hlutverk meistara og við vitum ekki hver þeirra er með nýjustu uppfærðu gögnin. Þetta ástand er einnig kallað klofningsheila;
- Við stóðum eftir án svars. Í uppsetningu okkar, master og ein eftirmynd, eftir að skipt hefur verið um, færist eftirmyndin upp á masterinn og við höfum ekki lengur eftirlíkingar, þannig að við verðum að bæta við nýrri eftirmynd handvirkt;
- Við þurfum viðbótareftirlit með bilunaraðgerðinni á meðan við erum með 12 PostgreSQL shards, sem þýðir að við verðum að fylgjast með 12 þyrpingum. Með aukningu á fjölda shards verður þú líka að muna að uppfæra failover.
Sjálfskrifuð failover lítur mjög flókið út og krefst ekki-léttvægs stuðnings. Með einum PostgreSQL klasa væri þetta auðveldasti kosturinn, en hann skalast ekki, svo hann hentar okkur ekki.
Repmgr
Afritunarstjóri fyrir PostgreSQL klasa, sem getur stjórnað rekstri PostgreSQL klasa. Á sama tíma hefur það ekki sjálfvirka bilun úr kassanum, svo fyrir vinnu þarftu að skrifa þinn eigin „umbúðir“ ofan á fullunna lausnina. Svo allt getur reynst enn flóknara en með sjálfskrifuðum handritum, svo við reyndum ekki einu sinni Repmgr.
AWS RDS
Styður allt sem við þurfum, veit hvernig á að taka öryggisafrit og viðheldur hópi tenginga. Það hefur sjálfvirka skiptingu: þegar húsbóndinn deyr, verður eftirlíkingin nýr meistari og AWS breytir dns skránni í nýja meistarann, á meðan eftirlíkingarnar geta verið staðsettar í mismunandi AZ.
Ókostirnir eru meðal annars skortur á fínstillingum. Sem dæmi um fínstillingu: tilvik okkar hafa takmarkanir fyrir tcp tengingar, sem því miður er ekki hægt að gera í RDS:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
Að auki er AWS RDS næstum tvöfalt dýrari en venjulegt tilviksverð, sem var aðalástæðan fyrir því að hætt var við þessa lausn.
Patroni
Þetta er python sniðmát til að stjórna PostgreSQL með góðum skjölum, sjálfvirkri failover og frumkóða á github.
Kostir Patroni:
- Hverri stillingarbreytu er lýst, það er ljóst hvernig það virkar;
- Sjálfvirk bilun virkar úr kassanum;
- Skrifað í python, og þar sem við sjálf skrifum mikið í python, verður auðveldara fyrir okkur að takast á við vandamál og jafnvel hjálpa til við þróun verkefnisins;
- Stjórnar PostgreSQL að fullu, gerir þér kleift að breyta stillingum á öllum hnútum þyrpingarinnar í einu, og ef endurræsa þarf þyrpinguna til að nota nýju stillingarnar, þá er hægt að gera þetta aftur með Patroni.
Gallar:
- Það er ekki ljóst af skjölunum hvernig á að vinna með PgBouncer rétt. Þó það sé erfitt að kalla það mínus, vegna þess að verkefni Patroni er að stjórna PostgreSQL, og hvernig tengingar við Patroni munu ganga er nú þegar vandamál okkar;
- Það eru fá dæmi um útfærslu á Patroni á stórum bindum á meðan það eru mörg dæmi um útfærslu frá grunni.
Fyrir vikið völdum við Patroni til að búa til failover þyrping.
Framkvæmdaferli Patroni
Áður en Patroni áttum við 12 PostgreSQL shards í uppsetningu á einum meistara og einni eftirmynd með ósamstilltri afritun. Forritaþjónarnir fengu aðgang að gagnagrunnunum í gegnum Network Load Balancer, á bak við hann voru tvö tilvik með PgBouncer, og á bak við þá voru allir PostgreSQL netþjónarnir.
Til að innleiða Patroni þurftum við að velja dreifða geymsluklasa uppsetningu. Patroni vinnur með dreifðum geymslukerfum eins og etcd, Zookeeper, Consul. Við erum bara með fullgildan Consul klasa á markaðnum, sem virkar í tengslum við Vault og við notum hann ekki lengur. Frábær ástæða til að byrja að nota Consul í tilætluðum tilgangi.
Hvernig Patroni vinnur með ræðismanni
Við höfum Consul þyrping, sem samanstendur af þremur hnútum, og Patroni þyrping, sem samanstendur af leiðtoga og eftirmynd (í Patroni er húsbóndinn kallaður klasaleiðtogi og þrælarnir kallaðir eftirmyndir). Hvert tilvik af Patroni klasanum sendir stöðugt upplýsingar um stöðu klasans til Consul. Þess vegna, frá Consul geturðu alltaf fundið út núverandi uppsetningu Patroni þyrpingarinnar og hver er leiðtogi í augnablikinu.
Til að tengja Patroni við Consul er nóg að kynna sér opinberu skjölin, sem segja að þú þurfir að tilgreina gestgjafa á http eða https sniði, allt eftir því hvernig við vinnum með Consul, og tengingarkerfi, valfrjálst:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpÞað lítur einfalt út, en hér byrja gildrurnar. Með Consul vinnum við yfir öruggri tengingu í gegnum https og tengistillingar okkar munu líta svona út:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}En það gengur ekki. Við ræsingu getur Patroni ekki tengst Consul, því það reynir samt að fara í gegnum http.
Frumkóði Patroni hjálpaði til við að takast á við vandamálið. Gott ef það er skrifað í python. Það kemur í ljós að hýsilbreytan er ekki þáttuð á nokkurn hátt og samskiptareglur verða að vera tilgreindar í skema. Svona lítur vinnustillingarblokkin fyrir að vinna með Consul út fyrir okkur:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}ræðismaður-sniðmát
Þannig að við höfum valið geymsluna fyrir uppsetninguna. Nú þurfum við að skilja hvernig PgBouncer mun breyta stillingum sínum þegar skipt er um leiðtoga í Patroni þyrpingunni. Það er ekkert svar við þessari spurningu í skjölunum, vegna þess að. þar er í grundvallaratriðum vinnu með PgBouncer ekki lýst.
Í leit að lausn fundum við grein (ég man því miður ekki titilinn) þar sem skrifað var að Сonsul-sniðmát hjálpaði mikið við að para PgBouncer og Patroni. Þetta varð til þess að við könnuðum hvernig Consul-sniðmát virkar.
Það kom í ljós að Consul-template fylgist stöðugt með uppsetningu PostgreSQL klasans í Consul. Þegar leiðtoginn breytist uppfærir hann PgBouncer stillinguna og sendir skipun um að endurhlaða hana.
Stór plús við sniðmát er að það er geymt sem kóða, þannig að þegar þú bætir við nýju broti er nóg að gera nýja skuldbindingu og uppfæra sniðmátið sjálfkrafa, sem styður innviði sem kóða meginregluna.
Nýr arkitektúr með Patroni
Fyrir vikið fengum við eftirfarandi vinnuáætlun:
Allir forritaþjónar fá aðgang að jafnvægisbúnaðinum → það eru tvö tilvik af PgBouncer á bak við hann → á hverju tilviki er Consul-sniðmát sett af stað, sem fylgist með stöðu hvers Patroni klasa og fylgist með mikilvægi PgBouncer stillingarinnar, sem sendir beiðnir til núverandi leiðtoga af hverjum klasa.
Handvirk prófun
Við keyrðum þetta kerfi áður en það var ræst í litlu prófunarumhverfi og athuguðum virkni sjálfvirkrar skiptingar. Þeir opnuðu spjaldið, færðu límmiðann til og á því augnabliki „drápu“ þeir leiðtoga klasans. Í AWS er þetta eins einfalt og að slökkva á tilvikinu í gegnum stjórnborðið.
Límmiðinn kom aftur innan 10-20 sekúndna og byrjaði svo aftur að hreyfast eðlilega. Þetta þýðir að Patroni þyrpingin virkaði rétt: hann breytti leiðtoganum, sendi upplýsingarnar til Сonsul, og Сonsul-sniðmát tók þessar upplýsingar strax upp, skipti um PgBouncer uppsetninguna og sendi skipunina til að endurhlaða.
Hvernig á að lifa af undir miklu álagi og halda niðritíma í lágmarki?
Allt virkar fullkomlega! En það eru nýjar spurningar: Hvernig mun það virka undir miklu álagi? Hvernig á að rúlla út allt í framleiðslu fljótt og örugglega?
Prófumhverfið sem við framkvæmum álagsprófun á hjálpar okkur að svara fyrstu spurningunni. Það er alveg eins og framleiðslu hvað varðar arkitektúr og hefur framleitt prófunargögn sem eru um það bil jafnt magn og framleiðslu. Við ákveðum að „drepa“ bara einn af PostgreSQL meistaranum meðan á prófinu stendur og sjáum hvað gerist. En áður en það er mikilvægt að athuga sjálfvirka veltinguna, vegna þess að í þessu umhverfi höfum við nokkra PostgreSQL shards, svo við munum fá framúrskarandi prófun á stillingarforskriftum fyrir framleiðslu.
Bæði verkefnin líta út fyrir að vera metnaðarfull, en við erum með PostgreSQL 9.6. Getum við uppfært strax í 11.2?
Við ákveðum að gera það í 2 skrefum: fyrst að uppfæra í 11.2, ræsa síðan Patroni.
PostgreSQL uppfærsla
Notaðu valkostinn til að uppfæra PostgreSQL útgáfuna fljótt -k, þar sem harðir tenglar eru búnir til á diski og engin þörf er á að afrita gögnin þín. Á grunni 300-400 GB tekur uppfærslan 1 sekúndu.
Við eigum mikið af brotum, þannig að uppfærslan þarf að fara fram sjálfkrafa. Til að gera þetta skrifuðum við Ansible leikbók sem sér um allt uppfærsluferlið fyrir okkur:
/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='Það er mikilvægt að hafa í huga hér að áður en þú byrjar uppfærsluna verður þú að framkvæma hana með færibreytunni --athugaðutil að tryggja að þú getir uppfært. Handritið okkar skiptir líka út stillingum á meðan uppfærslan stendur yfir. Handritið okkar kláraðist á 30 sekúndum, sem er frábær árangur.
Ræstu Patroni
Til að leysa annað vandamálið, skoðaðu bara Patroni uppsetninguna. Opinbera geymslan hefur dæmi um uppsetningu með initdb, sem er ábyrgur fyrir því að frumstilla nýjan gagnagrunn þegar þú byrjar Patroni fyrst. En þar sem við erum nú þegar með tilbúinn gagnagrunn, fjarlægðum við einfaldlega þennan hluta úr stillingunum.
Þegar við byrjuðum að setja upp Patroni á PostgreSQL þyrping sem þegar var til og keyra hann lentum við í nýju vandamáli: báðir netþjónarnir byrjuðu sem leiðtogi. Patroni veit ekkert um snemma ástand klasans og reynir að ræsa báða netþjóna sem tvo aðskilda klasa með sama nafni. Til að leysa þetta vandamál þarftu að eyða möppunni með gögnum um þrælinn:
rm -rf /var/lib/postgresql/Þetta þarf aðeins að gera á þrælnum!
Þegar hrein eftirmynd er tengd, býr Patroni til grunnafritunarleiðtoga og endurheimtir hana á eftirmyndina og nær síðan núverandi ástandi samkvæmt veggskrám.
Annar erfiðleiki sem við lentum í er að allir PostgreSQL klasar eru sjálfgefið nefndir aðal. Þegar hver þyrping veit ekkert um annan er þetta eðlilegt. En þegar þú vilt nota Patroni, þá verða allir klasar að hafa einstakt nafn. Lausnin er að breyta klasaheitinu í PostgreSQL stillingunum.
álagspróf
Við höfum sett af stað próf sem líkir eftir notendaupplifun á borðum. Þegar álagið náði meðalgildi okkar daglega endurtókum við nákvæmlega sama prófið, við slökktum á einu tilviki með PostgreSQL leiðtoganum. Sjálfvirka bilunin virkaði eins og við bjuggumst við: Patroni skipti um leiðtoga, Consul-sniðmát uppfærði PgBouncer uppsetninguna og sendi skipun um að endurhlaða. Samkvæmt línuritum okkar í Grafana var ljóst að það eru 20-30 sekúndur tafir og smá villur frá netþjónum sem tengjast tengingu við gagnagrunninn. Þetta er eðlilegt ástand, slík gildi eru ásættanleg fyrir bilun okkar og eru örugglega betri en niður í miðbæ.
Að koma Patroni í framleiðslu
Í kjölfarið komum við fram með eftirfarandi áætlun:
- Settu upp Consul-sniðmát á PgBouncer netþjóna og ræstu;
- PostgreSQL uppfærslur í útgáfu 11.2;
- Breyttu nafni klasans;
- Byrja á Patroni þyrpingunni.
Á sama tíma gerir kerfið okkar okkur kleift að setja fyrsta punktinn næstum hvenær sem er, við getum fjarlægt hvern PgBouncer frá vinnu eftir á og dreift og keyrt ræðismannssniðmát á það. Svo við gerðum það.
Til að dreifa hratt notuðum við Ansible, þar sem við höfum nú þegar prófað allar leikbækur í prófunarumhverfi, og framkvæmdartími heildarhandritsins var frá 1,5 til 2 mínútur fyrir hvert brot. Við gætum rúllað út öllu í röð á hvern shard án þess að hætta þjónustu okkar, en við þyrftum að slökkva á hverjum PostgreSQL í nokkrar mínútur. Í þessu tilviki gátu notendur sem hafa gögn á þessu broti ekki unnið að fullu eins og er og þetta er óviðunandi fyrir okkur.
Leiðin út úr þessari stöðu var fyrirhugað viðhald sem fer fram á 3ja mánaða fresti. Þetta er gluggi fyrir áætlaða vinnu, þegar við leggjum algjörlega niður þjónustu okkar og uppfærum gagnagrunnstilvikin okkar. Það var ein vika í næsta glugga og við ákváðum að bíða bara og undirbúa okkur frekar. Á biðtímanum tryggðum við okkur að auki: fyrir hverja PostgreSQL-brot, söfnuðum við vara eftirmynd ef ekki tókst að geyma nýjustu gögnin, og bættum við nýju tilviki fyrir hvert brot, sem ætti að verða ný eftirmynd í Patroni-þyrpingunni, til að framkvæma ekki skipun til að eyða gögnum. Allt þetta hjálpaði til við að lágmarka hættuna á mistökum.
Við endurræstum þjónustuna okkar, allt virkaði eins og það átti að gera, notendur héldu áfram að vinna, en á línuritunum tókum við eftir óeðlilega miklu álagi á Consul netþjóna.
Af hverju sáum við þetta ekki í prófunarumhverfinu? Þetta vandamál sýnir mjög vel að það er nauðsynlegt að fylgja innviðareglunni sem kóða og betrumbæta alla innviðina, frá prófunarumhverfi til framleiðslu. Annars er mjög auðvelt að fá vandamálið sem við fengum. Hvað gerðist? Consul kom fyrst fram í framleiðslu, og síðan í prófunarumhverfi, þar af leiðandi, á prófunarumhverfi, var útgáfan af Consul hærri en á framleiðslu. Bara í einni af útgáfunum var CPU leki leystur þegar unnið var með ræðissniðmát. Þess vegna uppfærðum við einfaldlega Consul og leystum þannig vandamálið.
Endurræstu Patroni þyrpinguna
Hins vegar fengum við nýtt vandamál, sem okkur grunaði ekki einu sinni. Þegar þú uppfærir Consul fjarlægjum við einfaldlega Consul hnútinn úr þyrpingunni með því að nota consul leave skipunina → Patroni tengist öðrum Consul netþjóni → allt virkar. En þegar við komumst að síðasta tilvikinu af Consul þyrpingunni og sendum ræðismanns leyfi skipunina til hans, restartuðust allir Patroni klasar einfaldlega og í loggunum sáum við eftirfarandi villu:
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 þyrpingin gat ekki sótt upplýsingar um þyrpinguna sína og endurræsti.
Til að finna lausn höfðum við samband við höfunda Patroni í gegnum vandamál á github. Þeir lögðu til endurbætur á stillingarskrám okkar:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Við gátum endurtekið vandamálið í prófunarumhverfi og prófuðum þessa valkosti þar, en því miður virkuðu þeir ekki.
Vandamálið er enn óleyst. Við ætlum að prófa eftirfarandi lausnir:
- Notaðu Consul-agent á hverju Patroni klasatilviki;
- Lagaðu vandamálið í kóðanum.
Við skiljum hvar villan átti sér stað: vandamálið er líklega notkun á sjálfgefnum tímamörkum, sem er ekki hnekkt í gegnum stillingarskrána. Þegar síðasti Consul þjónninn er fjarlægður úr þyrpingunni hangir allur Consul þyrpingin í meira en sekúndu, vegna þessa getur Patroni ekki fengið stöðu þyrpingarinnar og endurræsir allan þyrpinguna algjörlega.
Sem betur fer lentum við ekki í fleiri villum.
Niðurstöður notkunar Patroni
Eftir árangursríka kynningu á Patroni bættum við við viðbótar eftirmynd í hverjum klasa. Núna er í hverjum klasa líkingu af sveit: einn leiðtogi og tvær eftirmyndir, fyrir öryggisnet ef heili er sundraður þegar skipt er um.
Patroni hefur unnið að framleiðslu í meira en þrjá mánuði. Á þessum tíma hefur honum þegar tekist að hjálpa okkur. Nýlega lést leiðtogi eins þyrpingarinnar í AWS, sjálfvirk bilun virkaði og notendur héldu áfram að vinna. Patroni sinnti aðalverkefni sínu.
Smá samantekt á notkun Patroni:
- Auðvelt að breyta stillingum. Það er nóg að breyta stillingum á einu tilviki og það verður dregið upp í allan klasann. Ef endurræsa þarf til að beita nýju stillingunum mun Patroni láta þig vita. Patroni getur endurræst allan klasann með einni skipun, sem er líka mjög þægilegt.
- Sjálfvirk bilun virkar og hefur þegar tekist að hjálpa okkur.
- PostgreSQL uppfærsla án niður í miðbæ. Þú verður fyrst að uppfæra eftirlíkingarnar í nýju útgáfuna, síðan breyta leiðtoganum í Patroni þyrpingunni og uppfæra gamla leiðarann. Í þessu tilviki á sér stað nauðsynleg prófun á sjálfvirkri bilun.
Heimild: www.habr.com