Patroni rikke lood või kuidas oma PostgreSQL klastrit kokku kukutada. Aleksei Lesovski

Patroni peamine eesmärk on tagada PostgreSQL-i kõrge saadavus. Kuid Patroni on vaid mall, mitte valmis tööriist (nagu on ka dokumendis märgitud). Esmapilgul, testlaboratooriumis Patroni seadistades, võime näha, kui imeline see tööriist on ja kui lihtsalt ta meie katseid klastrit purustada käsitleb. Kuid praktikas tootmiskeskkonnas ei pruugi kõik alati nii kenasti ja elegantselt kulgeda kui testlaboratooriumis.

Räägin natuke endast. Alustasin süsteemiadministraatorina. Olen töötanud veebiarenduses. Alates 2014. aastast töötan Data Egreti juures. Firma tegeleb PostgreSQL-i konsultatsiooniga. Me hooldame just PostgreSQL-i ja töötame iga päev PostgreSQL-iga, seega on meil erinev kogemus, mis on seotud kasutamisega.

Ja 2018. aasta lõpus hakkasime tasahilju Patronit kasutama. Oleme kogunud teatud kogemuse. Oleme seda kuidagi diagnoosinud, häälestanud, jõudnud oma parimate praktikate juurde. Ja sellest ettekandest räägin ma.

Peale PostgreSQL-i armastan ma Linuxit. Mulle meeldib seal nokitseda ja uurida, armastan kernide koostamist. Armastan virtualiseerimist, konteinerite, Dockerit, Kuberneteset. See kõik huvitab mind, sest see peegeldab vana administraatori harjumusi. Mulle meeldib uurida monitooringute kohta. Ja armastan PostgreSQL-iga seotud administraatoriasju, st replikatsiooni, varundamist. Vabal ajal kirjutan Go-s. Ma ei ole tarkvarainsener, lihtsalt kirjutan Go-s enda jaoks. Ja see toob mulle rõõmu.

• Arvan, et paljud teist teavad, et PostgreSQL-is ei ole HA-d (kõrge saadavus) karbist välja. Et saavutada HA, tuleb midagi installida, seadistada, pingutada ja saavutada see.
• On mitu tööriista ja Patroni on üks neist, mis lahendab HA-d väga hästi ja tõhusalt. Kuid kui me kõik selle testlaboris üles seame ja käivitame, saame näha, et see töötab. Saame tekitada teatud probleeme ja vaadata, kuidas Patroni nendega tegeleb. Ja näeme, et kõik töötab suurepäraselt.
• Kuid praktikas oleme kokku puutunud erinevate probleemidega. Nendest probleemidest räägin ma.
• Räägin, kuidas me seda diagnoosisime, mida me reguleerisime – kas see aitas meid või mitte.

• Ma ei hakka rääkima, kuidas Patronit seadistada, sest seda saab internetist leida, samuti saab vaadata konfiguratsioonifaile, et mõista, kuidas see kõik tööle pannakse ja seadistatakse. Saate tutvuda skeemidega, arhitektuuridega, leides selle kohta teavet internetist.
• Ma ei hakka rääkima teiste kogemustest. Räägin ainult probleemidest, millega meie ise silmitsi seisisime.
• Ja ma ei hakka rääkima probleemidest, mis jäävad väljapoole Patronit ja PostgreSQL-i. Kui näiteks probleemid, mis on seotud koormuse jaotamisega, kui meie klaster lagunes, siis ma sellest rääkima ei hakka.

Ja väike ettekuulutus enne meie ettekande alustamist.

Kõik need probleemid, millega me silmitsi seisisime, ilmusid meil esimestel 6-7-8 kuudel kasutamise ajal. Aja jooksul jõudsime oma sisemiste parimate praktikate juurde. Ja probleemid lahendusid. Seetõttu esitati ettekande teema kuskil pool aastat tagasi, kui see kõik oli meil veel selgelt meeles ja ma mäletasin seda hästi.

Ettekande ettevalmistamise käigus vaatasin ma juba vanu postmortem'e, lugesin logisid. Ja osa detaile võis olla ununenud, või osa detaile ei pruukinud probleemide arutamisel piisavalt uuritud olla, mistõttu võib mõnes aspektis tunduda, et probleemid on käsitletud mittetäielikult või et teabe puudus on olemas. Seetõttu palun andestage mulle selle hetke pärast.

Mis on Patroni?

• See on Mall HA loomiseks. Nii on dokumentatsioonis kirjutatud. Minu arvates on see väga õige täpsustus. Patroni ei ole hõbedane kuul, mis lahendab kõik teie probleemid, st tuleb pingutada, et see hakkaks toimima ja kasu tooma.
• See on agentteenus, mis installitakse igasse teenusesse, kus on andmebaas, ja mis on omamoodi init-süsteem teie Postgresi jaoks. See käivitab Postgresi, peatab, taaskäivitab, muudab konfiguratsiooni ja muudab teie kasti topoloogiat.
• Seega, et salvestada klastriseisundit, selle praegust esitamist, nagu see välja näeb, on vaja mingisugust salvestusruumi. Ja sellega seoses on Patroni valinud lähenemise, mille kohaselt hoiab staatust välises süsteemis. See on jaotatud konfiguratsioonihalduse süsteem. Need võivad olla Etcd, Consul, ZooKeeper või Kubernetes'i Etcd, st mõni neist variantidest.
• Üks Patroni eripäradest on see, et saate automaatse failivahetuse otse karbist, kui see on seadistatud. Kui võrrelda Repmgr-i, siis seal kuulub failivahetus komplekti. Repmgr-i puhul saame switchover, kuid kui soovime automaatset failivahetust, siis tuleb see eraldi seadistada. Patronis on automaatne failivahetus juba olemas otse karbist.
• Ja palju on veel teisi asju. Näiteks konfiguratsioonide haldamine, uute koopiate seadmine, varundamine jne. Kuid see jääb ettekande piiridest välja, sellest ma rääkima ei hakka.

Ja väike kokkuvõte – Patroni peamine ülesanne on teha automaatne failivahetus hästi ja usaldusväärselt, et meie klaster jääks toimivaks ja rakendus ei märkaks klastritopoloogia muutusi.

Aga kui hakkame Patronit kasutama, muutub meie süsteem veidi keerulisemaks. Kui varem oli meil Postgres, siis Patroni kasutades saame ise Patroni, saame DCS-i, kus salvestatakse olek. Ja kõik see peab kuidagi töötama. Nii et mis võib katki minna?

Võib minna katki:

• Võib minna katki Postgres. See võib olla peamine või koopia, üks neist võib ebaõnnestuda.
• Võib minna katki ka ise Patroni.
• Võib minna katki DCS, kus salvestatakse olek.
• Ja võib minna katki võrk.

Kõiki neid punkte käsitlen ettekandes.

Käsitlen juhtumeid nende keerukuse järgi, mitte selliselt, et juhtum hõlmab palju komponente. Vaid subjektiivsete tunnete järgi, et see juhtum oli minu jaoks keeruline, seda oli raske analüüsida... ja vastupidi, mõni juhtum oli lihtne ja seda oli kergem analüüsida.

Ja esimene juhtum on kõige lihtsam. See on juhtum, kui võtsime andmebaasi klastrisse ja käivitasime samas klastris DCS-i salvestuse. See on kõige levinum viga. See on arhitektuuri konstrueerimise viga, st erinevate komponentide ühendamine ühte kohta.

Nii, failivahetus toimus, lähme uurima, mis juhtus.

Ja siin meid huvitab, millal failivahetus toimus. St meid huvitatakse see hetk, mil klastris toimus oleku muutus.

Aga failivahetus ei toimu alati hetkega, st see ei võta mingit kindlat aega, see võib venida. See võib kesta pikalt.

Seetõttu on tal algus- ja lõpuajad, st tegu on pikaajalise sündmusega. Jagame kõik sündmused kolmeks ajavahemikuks: meil on aeg enne failimist, failimise ajal ja pärast failimist. Ootame, et vaatame kõiki sündmusi selle ajakava raames.

Ja esimesena, kui failimine toimus, otsime põhjust, mis juhtus, mis viis failimiseni.

Kui vaatame logisid, siis need on klassikalised Patroni logid. Need teavitavad meid, et serverist on saanud master ja masteri roll on läinud sellele sõlmele. Siin on see esile tõstetud.

Edasi peame mõistma, miks failimine juhtus, st millised sündmused viisid masteri rolli üleminekuni ühest sõlmest teise. Antud juhul on kõik lihtne. Meil on hoidlaga suhtlemisel tõrge. Master mõistis, et ei saa töötada DCS-iga, st ilmnes probleem suhtlemisel. Ja ta ütleb, et ei saa enam master olla ja loobub oma volitustest. See rida "demoted self" ütleb just sellest.

Kui vaatame sündmusi, mis eelnesid failimisele, näeme seal neid põhjuseid, mis tekitasid probleeme masteri edasises töös.

Kui vaatame Patroni logisid, siis näeme, et meil on palju erinevaid vigu, ajapiiranguid, st Patroni agent ei saa töötada DCS-iga. Antud juhul on see Consul agent, kellega suheldakse pordi 8500 kaudu.

Probleem seisneb selles, et Patroni ja andmebaas on käivitatud samal hostil. Ja samal sõlmel olid käivitatud Consul-serverid. Koormuse tekitamine serveris lõi probleeme ka serverid Consuliga. Nad ei suutnud normaalselt suhelda.

Mõne aja pärast, kui koormus taandus, suutis meie Patroni taas agentidega suhelda. Normaalsed tööd jätkusid. Ja sama server Pgdb-2 sai jälle masteriks. St toimus väike flip, mille tõttu sõlm loobus masteri volitustest ja võttis need hiljem taas üle, st kõik naasis oma endisse olekusse.

Seda võib käsitleda kui vale alarmi, või võime vaadata, et Patroni tegi kõik õigesti. St ta mõistis, et ei saa toetada klastriseisundit ja loobus oma volitustest.

Siin tekkis probleem seetõttu, et Consul-serverid asuvad samas riistvaras, kus ka andmebaasid. Seetõttu mõjutab iga koormus – olgu see siis ketaste või protsessorite koormus – ka suhtlemist Consul klastriga.

Otsustasime, et see ei peaks koos elama, ja eraldasime Consulile eraldi klastrit. Patroni töötas juba eraldi Consuliga, st oli eraldi Postgres klaster ja eraldi Consul klaster. See on põhijuhend, kuidas kõiki neid asju eraldada ja hoida, et need ei eksisteeriks koos.

Võimalusena võib katsetada ttl, loop_wait, retry_timeout parameetrite seadistamist, ehk proovida nende parameetrite suurendamisega taluda lühiajalisi koormuse tippe. Kuid see ei ole kõige sobivam lahendus, kuna need koormused võivad kesta pikka aega. Ja seega ületame lihtsalt nende parameetrite limiidid. See ei pruugi olla kõige tõhusam lahendus.

Esimene probleem, nagu te mõistate, on lihtne. Võtsime DCS-i ja panime selle koos andmebaasiga, mille tulemusena tekkis probleem.

Teine probleem sarnaneb esimesega. See on sarnane selle poolest, et meil on jälle DCS-iga suhtlemise probleemid.

Kui vaatame logisid, näeme, et meil on jälle suhtlusviga. Patroni ütleb, et ei saa suhelda DCS-iga, seetõttu läheb aktiivne master repliigi režiimi.

Vana master muutub replikaks, siin teeb Patroni kõike nagu peab. Ta käivitab pg_rewind, et pöörata tehingulog ja seejärel ühenduda uue masteriga ning järele jõuda uuele masterile. Patroni käitub siin nagu talle kohane.

Peame leidma selle koha, mis eelnes failiruumi probleemile, st need vead, mis põhjustasid failiruumi tekkimise. Sel juhul on logide analüüsimine Patroniga üsna mugav. Ta kirjutab teatava aja jooksul samu sõnumeid. Kui hakkame logisid kiiresti kerima, näeme, et logid on muutunud, mis tähendab, et mingid probleemid on alanud. Me naaseme kiiresti sellele kohale ja vaatame, mis toimub.

Normaalsetes olukordades näevad logid välja umbes nii. Kontrollitakse lukustuse omanikku. Ja kui omanik, näiteks, on muutunud, võivad tekkida mingid sündmused, millele Patroni peab reageerima. Kuid antud juhul on meil kõik korras. Otsime seda hetke, mil vead algasid.

Ja kui me kerime tagasi sinna, kus vead hakkasid ilmuma, näeme, et meil on toimunud autofailover. Ja kuna meie vead olid seotud DCS-iga ning meie puhul kasutasime Consulit, vaatame ka Consuli logisid, mis seal toimus.

Umbes võrreldes failoveri aega ja Consuli logis olevat aega, näeme, et meie Consuli klastri naabrid hakkasid kahtlema teiste Consuli klastri liikmete olemasolus.

Ja kui vaadata ka teiste Consuli agentide logisid, siis seal on ka näha, et toimub mingi võrgu kokkuvarisemine. Ja kõik Consuli klastri liikmed kahtlevad teineteise olemasolus. See oli tõukeks failoverile.

Kui vaadata, mis enne neid vigu juhtus, siis võib näha, et seal on igasuguseid vigu, näiteks tähtaeg, RPC vigastus, s.t. ilmselgelt on mingi probleem Consuli klastri liikmete vahelises suhtluses.

Lihtsaim vastus on võrgu parandamine. Kuid mulle on kergem sellest rääkida seistes poodiumil. Kuid tingimused on sellised, et kliendil ei pruugi alati olla võimalik võrku parandada. Ta võib elada andmekeskuses ja tal ei pruugi olla võimalusi võrgu parandamiseks või seadmetele mõju avaldamiseks. Seetõttu on vajalikud muud alternatiivid.

Alternatiive on:

• Lihtsaim lahendus, mis on kirjutatud, minu arvates isegi dokumentatsioonis, on välja lülitada Consuli kontrollid, s.t. edastada lihtsalt tühi massiiv. Sellega ütleme Consuli agendile, et mitte kasutada mingeid kontrolle. Need kontrollid võimaldavad meil ignoreerida võrgu torme ja mitte algatada failoverit.
• Teine variant on kontrollida raft_multiplier'i. See on Consuli serveri parameeter. Vaikimisi on see seadistatud väärtusele 5. See väärtus on dokumentatsioonis soovitatud staging keskkondade jaoks. Sisuliselt mõjutab see sõnumite vahetamise sagedust Consuli võrgu osaliste vahel. Üldiselt mõjutab see parameeter teenuste vaheliste sõnumite vahetamise kiirus. Ja tootmisrežiimis on soovitatav seda vähendada, et sõlmed vahetaksid sõnumeid sagedamini.
• Teine variant, mida hakkasime kasutama, on Consul-protsesside prioriteedi suurendamine teiste protsesside seas operatsioonisüsteemi protsessoriplaneerijas. On olemas parameeter „nice“, mis määrab protsesside prioriteedi, mida OS protsessoriplaneerija arvesse võtab. Me vähendasime Consul-agendi nice väärtust, st suurendasime prioriteeti, et operatsioonisüsteem annaks Consul-protsessidele rohkem tööaega ja võimaluse oma koodi täita. Meie puhul lahendas see meie probleemi.
• Teine variant on mitte kasutada Consulit. Mul on sõber, kes on suur Etcd-i toetaja. Ja me vaidleme pidevalt, kumb on parem, Etcd või Consul. Aga tavaliselt lepime kokku, et Consulil on agent, mis peab olema igas andmebaasi sõlmes töötamas. See tähendab, et Patroni suhtleb Consul-klastriga läbi selle agendi. Ja see agent muutub kitsaskohaks. Kui agendiga juhtub midagi, ei suuda Patroni enam Consul-klastriga töötada. Ja see on probleem. Etcd puhul ei ole mingit agenti. Patroni saab otse töötada Etcd-serverite nimekirjaga ja nendega suhelda. Nii et kui teie ettevõttes kasutatakse Etcd-d, siis on see ilmselt parem valik kui Consul. Kuid meie klientide puhul oleme alati piiratud sellega, mida klient on valinud ja kasutab. Meie peaaegu kõikidel klientidel on Consul.
• Ja viimane punkt on parameetrite väärtuste ülevaatamine. Saame neid parameetreid tõsta, lootes, et meie lühiajalised võrguprobleemid on lühikesed ja ei ületa nende parameetrite vahemikku. Nii saame vähendada Patroni agressiivsust automaatfaili tegemisel, kui tekivad mingid võrguprobleemid.

Ma arvan, et paljud, kes kasutavad Patronit, tunnevad seda käsku.

See käsk näitab klasteri praegust seisundit. Esmapilgul võib see olukord tunduda normaalne. Meil on master, meil on koopia, ja replikatsiooni viivitus puudub. Kuid see olukord on normaalne just seni, kuni me ei tea, et selles klastris peaks olema kolm sõlme, mitte kaks.

Seetõttu toimus autofailover. Ja pärast seda autofailoverit kadus meil replika. Peame välja selgitama, miks see kadus ja taastama selle tagasi. Ja jälle vaatame logisid, et näha, miks meil autofailover juhtus.

Sel juhul sai teine replika meistriks. Siin on kõik korras.

Ja peame vaatama juba replika peale, mis katkeb ja mis ei ole klastris. Avame Patroni logid ja vaatame, et meil tekkis klastriga ühendamisel probleem faasis pg_rewind. Klastrisse ühendamiseks tuleb taastada tehingute logi, küsida vajalik tehingute logi meistrilt ja selle põhjal jõuda meistrini tagasi.

Sel juhul meil tehingute logi ei ole ja replika ei saa käivituda. Seetõttu peatame Postgresi veaga. Ja seetõttu pole seda klastris.

Peame aru saama, miks seda klastris ei ole ja miks logisid ei olnud. Läheme uue meistri juurde ja vaatame, mis tal logides on. Selgub, et kui tehti pg_rewind, toimus checkpoint. Ja osa vanadest tehingute logidest lihtsalt nimetati ümber. Kui vana meister üritas uuele meistrile ühenduda ja neid logisid küsida, olid need juba ümber nimetatud, neid ei olnud lihtsalt.

Võrdlesin ajastamisi, millal need sündmused juhtusid. Ja seal oli vahe vaid 150 millisekundit, st checkpoint lõppes 369 millisekundiga, WAL-segmendid olid nimetatud ümber. Ja täpselt 517 millisekundi pärast, 150 millisekundi möödudes, käivitati rewind vanal replikal. St 150 millisekundit oli piisav, et replika ei saaks ühendust ja töötada.

Millised on variandid?

Kasutame algselt replikatsiooni kohti. Me arvasime, et see on hea. Kuigi esimesel kasutamisetapil me kohti välja lülitasime. Me arvasime, et kui kohad koguvad palju WAL-segmente, võime meistri kukutada. Ta kukub. Oleme paar päeva ilmas kohtadeta vaeva näinud. Ja mõistsime, et kohad on vajalikud, me tõime kohad tagasi.

Aga siin on probleem, et kui meister läheb replika juurde, eemaldab ta slotid ja koos slotidega eemaldab WAL-segmendid. Ja et vältida selle probleemi ilmnemist, otsustasime tõsta wal_keep_segments parameetri. See on vaikimisi 8 segmenti. Me tõstsime selle 1000-le ja vaatasime, kui palju meil vaba ruumi on. Nii et me andsime wal_keep_segments'ile 16 gigabaiti. St. vahetamise ajal on meil kõigil sõlmedel alati 16 gigabaiti tehinguajalugu varuks.

Ja lisaks - see on endiselt aktuaalne pikaajaliste hooldustööde jaoks. Oletame, et peame värskendama ühte replika. Ja me tahame selle välja lülitada. Peame värskendama tarkvara, võib-olla operatsioonisüsteemi, midagi veel. Ja kui me lülitame replika välja, eemaldatakse selle replika jaoks ka slot. Ja kui me kasutame madalat wal_keep_segments'i, siis pikkade replika puudumise korral mängitakse tehinguajalugu läbi. Me käivitame replika, see küsib neid tehinguajalugu, kus ta peatub, kuid meistril võib neid seal mitte olla. Ja replika ei saa ka ühendust luua. Seetõttu hoiame meil palju ajalugu.

Meil on tootmisandmebaas. Seal töötavad juba projektid.

Toimus failihäire. Me sisenesime ja vaatasime - kõik on korras, replikad on kohal, replikatsiooni viivitus puudub. Vigade kohta ajalukes ei ole, kõik on korras.

Toote meeskond ütleb, et tundub, et peaks olema mingeid andmeid, kuid me näeme neid ühes allikas, kuid andmebaasis me ei näe. Ja peame aru saama, mis nendega juhtus.

Selge, et pg_rewind on need üle kirjoitanud. Me saime selle kohe aru, kuid läksime vaatama, mis juhtus.

Logidest leiame alati, millal toimus failihäire, kes sai meistriks ja saame määrata, kes oli vana meister ja millal ta soovis saada replikaks, st. meil on vaja neid logisid, et välja selgitada, kui palju tehinguajalugu oli kadunud.

Meie vana meister taaskäivitati. Ja autoalguses oli kirjutatud Patroni. Patroni käivitus. Ta käivitas järgmisena Postgres'i. Täpsemalt, enne Postgres'i käivitamist ja enne, kui teha sellest replik, käivitas Patroni pg_rewind protsessi. Vastavalt sellele kustutas ta osa tehinguajaloost, allalaadib uusi ja ühendas. Siin töötas Patroni suurepäraselt, nagu peab. Meie klaster taastati. Meil oli 3 sõlme, pärast failihäiret oli 3 sõlme - kõik on suurepärane.

Me kaotasime osa andmeid. Ja meil on vaja aru saada, kui palju me kaotasime. Otsime just seda hetke, mil meil toimus rewind. Saame seda leida selliste logikirjete järgi. Rewind käivitati, midagi tehti ja lõpetati.

Peame leidma selle positsiooni tehingulogis, kus vana master peatus. Antud juhul on see see märge. Ja me vajame teist märget, st seda vahet, millega vana master erineb uuest.

Võtame tavalise pg_wal_lsn_diff ja võrdleme neid kahte märget. Antud juhul saame 17 megabaidi. Kas see on palju või vähe, otsustab igaüks ise. Sest kellegi jaoks on 17 megabaidi vähe, kellegi jaoks palju ja vastuvõetamatu. Siin peab igaüks isiklikult määrama vastavalt äri vajadustele.

Aga mida oleme endale selgeks teinud?

Esiteks peame endale otsustada – kas me vajame alati pärast süsteemi taaskäivitamist Patroni automaatset käivitamist? Sageli on nii, et peame minema vana masteri juurde, vaatama, kui kaugele ta on läinud. Võib-olla inspekteerima tehingulogide lõike, vaata, mis seal toimub. Ja aru saama – kas saame need andmed kaotada või peame vanat masterit käitama standalone-režiimis, et need andmed välja võtta.

Ja alles pärast seda peame otsustama, kas saame need andmed kõrvale jätta või saame need taastada, ühendades selle sõlme meie klastrisse replikana.

Lisaks on olemas parameeter „maximum_lag_on_failover”. Vaikimisi, kui ma ei eksi, on selle parameetri väärtus 1 megabaidi.

Kuidas see töötab? Kui meie replika on 1 megabaidi võrra andmete replikatsiooni hilinemises, ei võta see replika valimistest osa. Ja kui juhtub failover, vaatab Patroni, millised replikad hilinevad. Kui nad hilinevad suure hulga tehingulogide võrra, ei saa nad masteriks saada. See on väga hea kaitsefunktsioon, mis aitab vältida suurte andmekao juhtumeid.

Kuid siin on probleem selles, et klastris Patroni ja DCS replikatsiooni hilinemine uuendatakse kindla intervalliga. Minu mäletamist mööda on vaikimisi ttl väärtus 30 sekundit.

Seega võib tekkida olukord, kus DCS-i replikate replikatsioonilagg on ühesugune, kuid tegelikult võib see olla täiesti erinev või seda ei pruugi olla üldse, st see asi ei ole reaalajas. Ja see ei kajasta alati tegelikku pilti. Seega ei tasu keerulist loogikat sellele tuginedes ehitada.

Ja risk kaduda jääb alati. Halvimal juhul on üks valem, keskmisel juhul aga teine valem. St kui plaanime Patroni rakendamist ja hindame, kui palju andmeid me võime kaotada, peame arvestama nende valemitega ja umbes ette kujutama, kui palju andmeid me võime kaotada.

Ja hea uudis on. Kui vana meister on ette läinud, võib ta edasi liikuda teatud taustprotsesside tõttu. St kui mõni automaatne vakuum oli, kirjutas ta andmed ja salvestas need tehingute ajaloosse. Ja neid andmeid saame me lihtsalt ignorida ja kaotada. Sellega pole probleemi.

Nii näevad logid välja, kui on seadistatud maximum_lag_on_failover ja toimus failover ning tuleb valida uus meister. Replika hindab end kui osalemisvõimetuks valimistel. Ja ta keeldub osalemast liidri valimisvõistluses. Ja ta ootab, kuni uus meister on valitud, et hiljem tema juurde ühenduda. See on täiendav meede andmete kaotuse vältimiseks.

Siin on meie tootemeeskond kirjutanud, et nende toode kogeb probleeme Postgresiga töötamisel. Sel ajal ei saa aga meistrisse sisse logida, kuna see pole SSH kaudu kättesaadav. Ja automaatset failoverit samuti ei toimu.

See host saadeti sunniviisiliselt taaskäivitamisele. Taaskäivitamise tõttu toimus automaatne failover, kuigi oleks olnud võimalik teha ka käsitsi automaatne failover, nagu ma nüüd aru saan. Ja pärast taaskäivitamist hakkame vaatama, mis meie praeguse meistriga juhtus.

Samas teadsime ette, et meil olid probleemid ketastega, st me teadsime juba seire põhjal, kus kaevata ja mida otsida.

Hakkasime postgres'i logisse sukelduma ja vaatama, mis seal juhtus. Nägime commit'e, mis kestavad seal ühe, kahe või kolme sekundi, mis pole kindlasti normaalne. Nägime, et meil käivitub automaatne vakuum väga kaua ja kummaliselt. Ja nägime ajutisi faileketastes. St need on kõik märk diskide probleemidest.

Me vaatasime süsteemi dmesg'i (tuumasaadete logi). Ja nägime, et meil on probleeme ühe ketasega. Kõvakettasüsteem koosnes software Raid'ist. Vaatasime /proc/mdstat ja nägime, et meil puudub üks ketas. T. e. siin on Raid 8 diskiga, meil puudub üks. Kui slaidi hoolikalt vaadata, siis väljendis on näha, et meil puudub sde. Ütleme nii, et üks ketas kukkus välja. See käivitas kettaprobleemid, ja rakendused kogesid ka probleeme Postgresi klastriga töötamisel.

Ja sel juhul ei aitaks meid Patroni, kuna Patrnoni ülesanne ei ole serveri ja ketas staatuse jälgimine. Me peame selliseid olukordi jälgima välistest monitooringutest. Me lisasime välistesse monitooringutesse kettamonitooringu.

Ja oli mõte - kas aitaks meid fencing või tarkvaraline watchdog? Me mõtlesime, et see ei aitaks meid, kuna probleemide ajal suhtles Patroni jätkuvalt DCS-iga ja ei näinud mingeid probleeme. T. e. DCS ja Patroni jaoks oli klaster korras, kuigi tegelikult olid kettaga ja andmebaasi kättesaadavusega probleemid.

Minu arvates on see üks kummalisemaid probleeme, mida olen pikalt uurinud, lugenud palju logisid, läbi töötanud ja nimetanud selle klaster-simulaatoriks.

Probleem oli selles, et vana master ei saanud normaalseks replikaks, t. e. Patroni käivitas selle, Patroni näitas, et see sõlm on replikana olemas, kuid samas ei olnud ta normaalne replik. Nüüd näete, miks. See jäi mul alles selle probleemi analüüsiga.

Ja kuidas kõik algas? Algus oli, nagu eelmise probleemi puhul, ketta viivitustega. Meil oli sekundis üks või kaks commiti.

Oli ühenduse katkestusi, st. kliendid katkestasid.

Oli erineva raskusastmega blokeeringud.

Ja seega ei olnud ketassüsteem eriti reageeriv.

Ja kõige salapärasem minu jaoks oli see, et tuli kohene shutdown-päring. PostgreSQL-il on kolm väljalülitusrežiimi:

• See on graceful, kui me ootame, et kõik kliendid väljuksid ise.
• On fast, kui me sunnime kliente välja minema, kuna me plaanime väljalülitust.
• Ja on kohene. Antud juhul ei teata klientidele isegi, et tuleb välja logida, ta lihtsalt sulgub ilma hoiatamata. Ja kõigile klientidele saadetakse operatsioonisüsteemi kaudu RST teade (TCP-teade, et ühendus on katkestatud ja kliendil pole enam midagi teha).

Kes saatis selle signaali? PostgreSQL-i taustprotsessid ei saada üksteisele selliseid signaale, st see on kill -9. Nad ei saada üksteisele selliseid signaale, nad reageerivad ainult sellele, st see on PostgreSQL-i hädaseade taaskäivitamiseks. Kes selle saatis, ei tea.

Vaatasin käsu „last” järgi ja nägin ühte inimest, kes logis samuti sellele serverile sisse koos meiega, kuid mul oli piinlik küsida. Võib-olla oli see kill -9. Oleksin logides näinud kill -9, kuna PostgreSQL kirjutab, et sai kill -9, kuid ma ei näinud seda logides.

Edasi uurides märkasin, et Patroni ei olnud juba kaua aega loginud – 54 sekundit. Ja kui võrrelda kahte ajamärki, siis siin puudusid sõnumid umbes 54 sekundit.

Ja selle aja jooksul toimus automaatne failivahetus. Patroni töötas siin jälle suurepäraselt. Meie vana master oli kätkes, midagi juhtus temaga. Ja algasid uue masteri valimised. Siin kõik töötas hästi. Meie pgsql01 sai uuest liidriks.

Meil on replikatsioon, mis sai masteriks. Ja on teine replikatsioon. Teise replikatsiooniga olid just probleemid. Ta üritas ümber konfigureerida. Nagu ma aru sain, üritas ta muuta recovery.conf-i, taaskäivitada PostgreSQL-i ja ühenduda uue masteriga. Iga 10 sekundi järel kirjutab ta sõnumeid, et ta üritab, aga tal ei õnnestu.

Ja nende katsete ajal saab vana master kohe aktiivse sulgemise signaali. Master taaskäivitub. Ja ka taastumismehhanism peatub, kuna vana master läheb taaskäivitamise režiimi. St replikatsioon ei saa temaga ühendust, kuna ta on välja lülitatud.

Mõnes kohas töötas ta, kuid replikatsioon ei käivitunud.

Mul on ainus hüpotees, et recovery.conf-is oli vana masteri aadress. Ja kui uus master ilmnes, siis teine replikatsioon üritas ikka veel ühenduda vana masteriga.

Kui Patroni käivitati teises replikatsioonis, käivitati sõlm, kuid ei suutnud replikatsiooniga ühenduda. Ja tekkis replikatsiooni viivitus, mis nägi välja umbes nii. St kõik kolm sõlme olid kohal, kuid teine sõlm jäi maha.

Kui vaadata logisid, mis olid kirjutatud, sai näha, et replikatsioon ei saa käivituda, kuna tehingulood erinevad. Ja need tehingulood, mida master pakub, mis on märgitud recovery.conf-is, ei sobi meie praegusele sõlmele.

Ja siin tegin ma vea. Ma oleks pidanud tulema ja vaatama, mis seal recovery.conf-is on, et kontrollida oma hüpoteesi, et me ühendame vale masteriga. Aga tol hetkel alles õppisin, et see ei tulnud mulle pähe, või siis nägin, et replikatsioon jääb maha ja seda tuleb taastada, st tegin seda kuidagi pealiskaudselt. See oli minu eksimus.

Kakskümmend minutit hiljem tuli admin, st ta restartis Patroni repliika peal. Ma juba olin temaga lõpetanud, arvasin, et seda tuleb taastada. Ja mõtlesin – restartin Patroni, äkki õnnestub midagi head. Taaskäivitus recovery. Ja andmebaas avanes, ta oli valmis ühendusi vastu võtma.

Replikatsioon käivitus. Kuid minuti pärast ebaõnnestus see vea tõttu, et tehingulood ei sobinud.

Mõtlesin, et teen veel ühe taaskäivituse. Taaskäivitasin Patroni veel kord, märkides, et ma ei taaskäivitanud Postgres't, vaid taaskäivitasin just Patroni lootuses, et ta imeliselt käivitab andmebaasi.

Replikatsioon käivitus taas, kuid tehingulood olid erinevad, nad ei olnud need, mis olid eelmise käivituse ajal. Replikatsioon seiskus jälle. Ja sõnum oli juba veidi erinev. See ei olnud minu jaoks eriti informatiivne.

Ja siis tuli mulle mõte – mis siis, kui ma taaskäivitan Postgres'i, samal ajal teen kohaliku masteriga checkpoint'i, et edastada tehingulood natuke ettepoole, et taastamine algaks teisest punktist? Pluss seal olid ka meie WAL'i varud.

Taaskäivitasin Patroni, tegin paar checkpoint'i masteril, paar restart-pointi repliika peal, kui see avanes. Ja see aitas. Ma mõtlesin kaua, miks see aitas ja kuidas see töötas. Ja replikatsioon käivitus. Ja replikatsioon ei katkestanud enam.

See probleem on minu jaoks üks kõige salapärasemaid, mille üle ma siiani pean pead murdma, mis seal tegelikult toimus.

Millised on järeldused? Patroni võib töötada nagu ette nähtud ja ilma vigadeta. Kuid see ei tähenda, et meil oleks kõik korras. Replika võib käivituda, kuid see võib olla poolikult toimivas seisundis ning rakendus ei tohi sellise replikaga töötada, kuna seal võivad olla vanad andmed.

Ja pärast failide ülevõtmist on alati vaja kontrollida, et meie klaster toimib korralikult, st on vajalik arv replikaid ja replikatsiooni viivitust ei ole.

Probleemide käsitlemise käigus annan soovitusi. Olen püüdnud need kahel slaidil kokku koondada. Tõenäoliselt võis kõik lood kokku panna kaheks slaidiks ja lihtsalt neist rääkida.

Kui te kasutate Patronit, peab teil kindlasti olema jälgimine. Te peate alati teadma, millal toimus automaatne failide ülevõtmine, sest kui te ei tea, et see juhtus, siis te ei kontrolli klastrit. See on halb.

Pärast iga failide ülevõttu peame alati käsitsi kontrollima klastrit. Peame veenduma, et meil on alati õige arv replikaid, replikatsiooni viivitust ei ole, logides ei ole vigu, mis on seotud voogde replikatsiooniga, Patroniga või DCS süsteemiga.

Automaatika võib edukalt töötada, Patroni on väga hea tööriist. See võib töötada, aga see ei vii klastrit soovitud seisundisse. Kui me sellest teada ei saa, siis võivad tekkida probleemid.

Ja Patroni ei ole hõbedane kuul. Me peame ikkagi mõistma, kuidas Postgres töötab, kuidas replikatsioon töötab ning kuidas Patroni Postgresiga koos töötab ja kuidas toimub suhtlemine sõlmede vahel. See on vajalik, et osata käsitsi lahendada tekkivaid probleeme.

Kuidas ma lähenen diagnostika küsimusele? On nii juhtunud, et me töötame erinevate klientidega ja ühegi ELK tehnoloogiakiud ei ole, mistõttu tuleb logidesse süveneda, avades 6 konsooli ja 2 vahelehte. Ühel vahelehel on iga sõlme Patroni logid, teisel vahelehel on Consuli või vajadusel Postgresi logid. Selle diagnoosimine on väga keeruline.

Milliseid lähenemisviise olen välja töötanud? Esiteks, ma alati vaatan, millal failide ülevõtt toimus. See on minu jaoks teatud murdepunkt. Vaatan, mis juhtus enne failide ülevõttu, selle ajal ja pärast failide ülevõttu. Failide ülevõtmisel on kaks märki: algus- ja lõpuajad.

See, I check the logs for events leading up to the failover, looking for the reasons why the failover occurred.

This provides an understanding of what happened and what can be done in the future to prevent such circumstances from arising (and consequently, a failover).

So where do we usually look? I check:

• First, in the Patroni logs.
• Then I look at the Postgres logs or the DCS logs, depending on what I found in the Patroni logs.
• System logs sometimes also provide insight into what could have caused the failover.

What do I think of Patroni? I think very highly of it. In my opinion, it’s the best option available today. I'm aware of many other products: Stolon, Repmgr, Pg_auto_failover, PAF. Four tools. I have tried them all. Patroni impressed me the most.

If asked whether I recommend Patroni, I would say yes because I like it. And it seems I have learned how to configure it well.

If you are curious to see what other problems there may be with Patroni besides those I’ve mentioned, you can always check the page issues on GitHub. There are many different stories and many interesting issues discussed there. Some bugs have been reported and resolved, providing intriguing reading material.

There are fascinating stories about how people shoot themselves in the foot. It’s very educational. You read and understand that you shouldn’t do that. Checked it off my list.

I would also like to express my gratitude to Zalando for developing this project, specifically to Alexander Kukushkin and Alexey Klyukin. Alexey Klyukin is one of the co-authors; he no longer works at Zalando, but these are the two individuals who started working on this product.

I believe that Patroni is an extremely valuable tool. I’m glad it exists; it’s interesting to work with. My sincere thanks to all the contributors who write patches for Patroni. I hope that over time, Patroni will become more mature, powerful, and effective. It’s already operational, but I hope it will continue to improve. So if you plan to use Patroni, don’t be afraid. It’s a good solution that can be implemented and utilized.

That’s all for now. If you have any questions, please ask.

Küsimused

Thank you for the presentation! If we still need to look closely after a failover, why do we need an automatic failover at all?

Kuna see on uus asi. Oleme sellega töötanud vaid aasta. Paremini karta kui kahetseda. Soovime siseneda ja näha, et kõik töötab nii nagu peab. See on täiskasvanu tasemel umbusaldus – parem on uuesti kontrollida ja vaadata.

Näiteks, me käisime hommikul ja vaatasime, eks?

Ei hommikul, me saame tavaliselt auto failimise kohta teate kohe. Meie saame märguanded, näeme, et auto failimine on toimunud. Me käime praktiliselt kohe vaatamas. Kuid kõik need kontrollid peaksid olema viidud monitooringu tasandile. Kui pöörduda rest API kaudu Patroni poole, on olemas ajalugu. Ajaloo kaudu saab näha ajatempleid, millal toimus failimine. Selle põhjal saab teha monitooringu. Saab vaadata, kui palju seal sündmusi on olnud. Kui me oleme saanud rohkem sündmusi, siis on toimunud auto failimine. Saame minna ja vaadata. Või meie automaatika monitooringus kontrollis, et kõik meie koopiad on kohal, viivitust pole ja kõik on korras.

Aitäh!

Suur aitäh suurepärase jutustuse eest! Kui me liigutasime DCS klastrit kaugele Postgres klastrist, kas seda klastri tuleb ka perioodiliselt haldada? Millised on parimad praktikad, et osad DCS klastri osad välja lülitada, midagi nende kallal teha jne? Kuidas see konstruktsioon siis elab? Ja kuidas neid asju teha?

Ühe ettevõtte jaoks tuli koostada probleemide maatriks, mis juhtub, kui mõni komponent või mitmed komponendid ebaõnnestuvad. Selle maatriksi põhjal vaatame järjestikku üle kõik komponendid ja koostame stsenaariume nende komponentide rikke korral. Vastavalt iga rikke stsenaariumi jaoks võiks olla taastamisplaan. Ja DCS puhul on see osa tavalistest infrastruktuuridest. Ja administraator haldab seda ning me toetume juba nende administraatorite oskustele, kes seda haldavad ja suudavad seda õnnetuse korral parandada. Kui DCS-i üldse pole, siis me paigaldame selle, kuid ei jälgi seda eriti, kuna me ei vasta infrastruktuuri eest, vaid anname soovitusi, kuidas ja mida monitoorida.

Ehk ma sain õigesti aru, et tuleb välja lülitada Patroni, välja lülitada failimine, välja lülitada kõik, enne kui midagi hostidega teha?

See sõltub sellest, kui palju on meil sõlmi DCS-klastris. Kui sõlmi on palju ja kui me väljutame vaid ühe sõlme (replikatsiooni), siis jääb klastris kvoorum alles. Ja Patroni jääb töötavaks. Ja mitte midagi ei aktiveeru. Kui meil on mingeid keerulisi operatsioone, mis hõlmavad rohkem sõlmi, mille puudumine võib kvoorumi rikkuda, siis – jah, võib-olla on mõistlik panna Patroni pausile. Tal on sellele vastav käsk – patronictl pause, patronictl resume. Me lihtsalt paneme pausile ja autofailover ei toimi sel ajal. Me teeme hooldust DCS-klastris, siis eemaldame pausi ja jätkame elu.

Aitäh palju!

Suur tänu ettekande eest! Kuidas toote meeskond suhtub andmete kadumise võimalusse?

Toote meeskondadele ei meeldi see, aga meeskonnajuhid on mures.

Millised garantiiid seal on?

Garantiidega on väga keeruline. On ettekandeid Aleksandr Kukushkini poolt teemal "Kuidas arvutada RPO ja RTO", st taastamisaeg ja kui palju andmeid me võime kaotada. Ma arvan, et tuleks neid slaide otsida ja uurida. Nagu ma mäletan, on seal konkreetsed sammud, kuidas neid asju arvutada. Kui palju tehinguid me võime kaotada, kui palju andmeid me võime kaotada. Variandina saame kasutada sünkroonset replikatsiooni Patroni tasemel, kuid see on ka kahe otsaga noa: kas me saavutasime andmete usaldusväärsuse või kaotasime kiirusest. On sünkroonne replikatsioon, kuid see ei taga ka 100%-list kaitset andmete kadumise eest.

Aleksei, aitäh suurepärase ettekande eest! Kas on kogemusi Patroni kasutamisel zero level kaitse jaoks? St koos sünkroonse standby'ga? See on esimene küsimus. Ja teine küsimus. Teie olete kasutanud erinevaid lahendusi. Me kasutasime Repmgr'i, aga ilma autofailoverita ja nüüd plaanime autofailoveri liita. Ja kaalume Patroni alternatiivina. Mida saate öelda plusside kohta võrreldes Repmgr'iga?

Esimene küsimus sünkroonsete replikate kohta oli. Meil ei kasutata keegi sünkroonset replikatsiooni, sest kõik kardavad (Mõned kliendid juba kasutavad, probleeme tootlikkusega pole põhimõtteliselt täheldatud — Ettekandja märkus). Kuid meie jaoks on välja kujunenud reegel, et sünkroonse replikeerimise klastris peab olema vähemalt kolm sõlme, kuna kui meil on kaks sõlme ja kui meistril või replikal on viga, siis Patroni viib selle sõlme iseseisva režiimi, et rakendus saaks edasi töötada. Sel juhul on andmete kadumise riskid.

Teise küsimuse osas kasutasime Repmgr-i ja kasutame seda endiselt mõnedes klientides ajaloolistel põhjustel. Mida saab öelda? Patronis on automaatne failover välja pakutud, Repmgr-is on automaatne failover lisaautona, mille tuleb sisse lülitada. Tuleb käivitada Repmgr deemon igas sõlmes ja siis saame automaatse failover'i seadistada.

Repmgr kontrollib, kas Postgres'i sõlmed on elus. Repmgr protsessid kontrollivad üksteise olemasolu, see pole väga tõhus lähenemine, kuna võivad esineda keerulised võrguisolatsiooni juhtumid, kus suur Repmgr klaster võib laguneda mitmeks väiksemaks ja jätkata tööd. Ma ei ole ammu Repmgr-i jälginud, võib-olla on nad selle probleemi lahendanud ... aga võib-olla ka mitte. Kuid teabe edastamine klastrisse DCS-sse, nagu teeb Stolon või Patroni, on kõige elujõulisem variant.

Aleksei, mul on küsimus, mis võibolla on algaja oma. Ühes esimeses DCS näites viidate kohalikult arvutilt kaugule. Saame aru, et võrk – see on asi, millel on oma eripärad, see elab oma elu. Mis juhtub, kui mingil põhjusel DCS-klaster muutub kättesaamatuks? Põhjuseid ei hakka nimetama, neid võib olla palju: alates ketserite käteõnnest kuni reaalsed probleemideni.

Ma ei öelnud seda valjusti, kuid DCS klaster peaks olema ka talitlushäirete suhtes vastupidav, s.t. see peab olema paaritu arv sõlmi, et kvoorum kokku saaks. Mis juhtub, kui DCS klaster muutub kättesaamatuks või ei suuda koguda kvoorumit, s.t. mingi võrgu lõhe või sõlmede rike? Sellel juhul üleminek klaster Patroni read only režiimi. Klaster Patroni ei suuda määrata klastriseisundit ja mida selle tegemiseks teha. Ta ei saa ühendust DCS-ga ning ei suuda seal uut klastriseisundit salvestada, mistõttu kogu klaster läheb read only režiimi. Ja ootab kas operaatori käsitsi sekkumist või kui DCS taastub.

Lihtsalt öeldes, kas DCS muutub meile sama tähtsaks teenuseks kui andmebaas ise?

Jah, jah. Paljuski kaasaegsetes ettevõtetes on teenuse avastamine infrastruktuuri lahutamatu osa. See rakendatakse isegi enne, kui andmebaas infrastruktuuri ilmub. Ütleme niimoodi, et infrastruktuur on käivitatud, andmekeskuses on loodud tingimused, ja meil on juba teenuse avastamine olemas. Kui see on Consul, siis võib selle peal DNS põhineda. Kui see on Etcd, siis võib olla osa Kubernetesest, kuhu kõik muu juba paigutatakse. Minu arvates on teenuse avastamine juba kaasaegse infrastruktuuri lahutamatu osa. Ja selle peale hakatakse mõtlema palju varem kui andmebaasidele.

Aitäh!

Allikas: habr.com