Patroni peamine eesmärk on pakkuda PostgreSQL-ile kõrget saadavust. Kuid Patroni on lihtsalt mall, mitte valmis tööriist (mida dokumentatsioonis üldiselt öeldakse). Esmapilgul, kui olete Patroni katselaboris seadistanud, näete, kui suurepärane tööriist see on ja kui hõlpsalt see saab hakkama meie katsetega klastrit murda. Praktikas ei toimu aga tootmiskeskkonnas alati kõik nii kaunilt ja elegantselt kui katselaboris.
Ma räägin teile natuke endast. Alustasin süsteemiadministraatorina. Töötanud veebiarenduses. Töötan Data Egretis alates 2014. aastast. Ettevõte tegeleb nõustamisega Postgresi valdkonnas. Ja me teenindame täpselt Postgres ja teeme Postgresiga iga päev koostööd, seega on meil operatsiooniga seotud eriteadmised.
Ja 2018. aasta lõpus hakkasime Patronit aeglaselt kasutama. Ja mingi kogemus on kogunenud. Diagnoosisime selle kuidagi, häälestasime, jõudsime oma parimate tavadeni. Ja selles raportis räägin neist.
Peale Postgresi armastan ma Linuxit. Mulle meeldib selles ringi tuhnida ja uudistada, mulle meeldib südamikke koguda. Armastan virtualiseerimist, konteinereid, dokkerit, Kubernetes. See kõik huvitab mind, sest vanad administraatori harjumused mõjutavad. Mulle meeldib tegeleda jälgimisega. Ja ma armastan postgresi asju, mis on seotud administreerimisega, st replikatsioon, varundamine. Ja vabal ajal kirjutan Go-sse. Ma ei ole tarkvarainsener, ma lihtsalt kirjutan Go-sse enda jaoks. Ja see pakub mulle rõõmu.
- Ma arvan, et paljud teist teavad, et Postgresil ei ole HA-d (kõrge saadavus). HA saamiseks peate midagi installima, seadistama, pingutama ja hankima.
- Tööriistu on mitu ja Patroni on üks neist, mis lahendab HA üsna lahedalt ja väga hästi. Kuid pannes selle kõik katselaborisse ja käivitades, näeme, et see kõik töötab, saame taasesitada mõningaid probleeme ja näha, kuidas Patroni neid teenindab. Ja me näeme, et see kõik töötab suurepäraselt.
- Kuid praktikas seisime silmitsi erinevate probleemidega. Ja ma räägin nendest probleemidest.
- Ma räägin teile, kuidas me selle diagnoosisime, mida me kohandasime – kas see aitas meid või mitte.
- Ma ei ütle teile, kuidas Patroni installida, sest saate Internetis googeldada, saate vaadata konfiguratsioonifaile, et mõista, kuidas see kõik algab, kuidas see on seadistatud. Saate aru skeemidest, arhitektuuridest, leides selle kohta teavet Internetist.
- Ma ei räägi kellegi teise kogemusest. Räägin ainult probleemidest, millega me silmitsi seisime.
- Ja ma ei räägi probleemidest, mis on väljaspool Patroni ja PostgreSQL. Kui näiteks tasakaalustamisega on seotud probleeme, siis kui meie klaster on kokku kukkunud, siis ma sellest ei räägi.
Ja väike lahtiütlus enne raporti alustamist.
Kõik need probleemid, millega me kokku puutusime, tekkisid meil esimese 6-7-8 töökuu jooksul. Aja jooksul jõudsime oma sisemiste parimate tavadeni. Ja meie probleemid kadusid. Seetõttu kuulutati raport välja umbes pool aastat tagasi, kui see kõik värskelt mu peas oli ja see kõik mulle suurepäraselt meelde jäi.
Aruande koostamise käigus tõstsin juba vanu postmorteme, vaatasin palke. Ja mõned detailid võivad ununeda või osa detaile ei suudetud probleemide analüüsi käigus lõpuni uurida, mistõttu võib mõnel hetkel tunduda, et probleeme ei mõelda lõpuni või on infopuudus. Ja seega ma palun teil vabandada mind selle hetke pärast.
Mis on Patroni?
- See on mall HA ehitamiseks. Nii on dokumentides kirjas. Ja minu seisukohast on see väga õige täpsustus. Patroni ei ole hõbekuul, mis lahendab kõik teie probleemid, see tähendab, et peate pingutama, et see toimiks ja kasu tooks.
- See on agenditeenus, mis on installitud igale andmebaasiteenusele ja on teie Postgresi omamoodi init-süsteem. See käivitab Postgresi, peatab, taaskäivitab, konfigureerib ümber ja muudab teie klastri topoloogiat.
- Sellest tulenevalt on klastri oleku, selle praeguse esituse salvestamiseks vaja mingit salvestusruumi. Sellest vaatenurgast lähtudes valis Patroni riigi välissüsteemi salvestamise tee. See on hajutatud konfiguratsioonisalvestussüsteem. See võib olla Etcd, Consul, ZooKeeper või kubernetes Etcd, st üks neist valikutest.
- Ja üks Patroni omadusi on see, et saate automaatfaili karbist välja võtta ainult selle seadistamisega. Kui võtta võrdluseks Repmgr, siis on fileer seal sees. Repmgr-iga saame ümberlülituse, aga kui tahame automaattäitjat, siis peame selle täiendavalt seadistama. Patronil on automaatfiler juba karbist väljas.
- Ja on palju muid asju. Näiteks konfiguratsioonide hooldus, uute koopiate valamine, varundamine jne. Aga see jääb aruandest välja, ma ei hakka sellest rääkima.
Ja väike tulemus on see, et Patroni põhiülesanne on teha autofaili hästi ja usaldusväärselt, et meie klaster püsiks töökorras ja rakendus ei märkaks muutusi klastri topoloogias.
Kuid kui hakkame Patronit kasutama, muutub meie süsteem veidi keerulisemaks. Kui varem oli meil Postgres, siis Patroni kasutamisel saame Patroni enda, saame DCS-i, kus olek on salvestatud. Ja see kõik peab kuidagi toimima. Mis võib siis valesti minna?
Võib katkeda:
- Postgres võib puruneda. See võib olla kapten või koopia, üks neist võib ebaõnnestuda.
- Patroni ise võib puruneda.
- DCS, kuhu olek on salvestatud, võib puruneda.
- Ja võrk võib puruneda.
Kõiki neid punkte käsitlen raportis.
Ma käsitlen juhtumeid, kui need muutuvad keerukamaks, mitte sellest seisukohast, et juhtum hõlmab paljusid komponente. Ja subjektiivsete tunnete seisukohalt, et see korpus oli minu jaoks raske, seda oli raske lahti võtta ... ja vastupidi, mõni korpus oli kerge ja seda oli lihtne lahti võtta.
Ja esimene juhtum on kõige lihtsam. See on juhtum, kui võtsime andmebaasi klastri ja juurutasime oma DCS-i salvestusruumi samas klastris. See on kõige levinum viga. See on viga arhitektuuride ehitamisel, st erinevate komponentide kombineerimisel ühes kohas.
Niisiis, oli viil, lähme tegeleme juhtunuga.
Ja siin huvitab meid, millal viilimine juhtus. See tähendab, et meid huvitab see ajahetk, mil klastri olek muutus.
Kuid viilimine ei ole alati hetkeline, st see ei võta ajaühikut, see võib viibida. See võib olla kauakestev.
Seetõttu on sellel algus- ja lõpuaeg, st see on pidev sündmus. Ja me jagame kõik sündmused kolmeks intervalliks: meil on aega enne faili, faili ajal ja pärast faili. See tähendab, et me võtame arvesse kõiki sellel ajateljel olevaid sündmusi.
Ja esimene asi, kui juhtus viil, siis otsime juhtunu põhjust, mis oli põhjus, mis viilisse viis.
Kui vaatame palke, siis need on klassikalised Patroni palgid. Ta ütleb meile neis, et serverist on saanud ülem ja ülemuse roll on üle antud sellele sõlmele. Siin on see esile tõstetud.
Järgmiseks peame mõistma, miks failer juhtus, st millised sündmused toimusid, mis põhjustasid põhirolli liikumise ühest sõlmest teise. Ja sel juhul on kõik lihtne. Meil on salvestussüsteemiga suhtlemisel viga. Kapten mõistis, et ta ei saa DCS-iga töötada, see tähendab, et suhtluses on mingi probleem. Ja ütleb, et ei saa enam peremeest ja astub tagasi. See rida "alandatud mina" ütleb täpselt seda.
Kui vaatame failirile eelnenud sündmusi, näeme seal just neid põhjuseid, mis olid viisardi jätkamise probleemiks.
Kui vaatame Patroni logisid, näeme, et meil on palju vigu, aegumist, st Patroni agent ei saa DCS-iga töötada. Antud juhul on see konsuli agent, kes suhtleb pordis 8500.
Ja siin on probleem selles, et Patroni ja andmebaas töötavad samas hostis. Ja Consul serverid käivitati samas sõlmes. Luues serverile koormuse, tekitasime probleeme ka Consul serveritele. Nad ei saanud korralikult suhelda.
Mõne aja pärast, kui koormus rauges, sai meie Patroni uuesti agentidega suhelda. Tavaline töö jätkus. Ja seesama Pgdb-2 server sai taas peremeheks. See tähendab, et toimus väike pööre, mille tõttu sõlm loobus kapteni volitustest ja võttis need siis uuesti üle, see tähendab, et kõik naasis nii nagu oli.
Ja seda võib pidada valehäireks või siis seda, et Patroni tegi kõik õigesti. See tähendab, et ta mõistis, et ta ei suuda klastri seisundit säilitada, ja eemaldas oma volitused.
Ja siin tekkis probleem sellest, et Consul serverid on baasidega samal riistvaral. Sellest lähtuvalt mõjutab igasugune koormus: olgu see siis ketaste või protsessorite koormus, see mõjutab ka suhtlemist Consul-klastriga.
Ja me otsustasime, et see ei peaks koos elama, eraldasime konsuli jaoks eraldi klastri. Ja Patroni töötas juba eraldi konsuliga, see tähendab, et oli eraldi Postgresi klaster, eraldi konsulite klaster. See on põhiline õpetus, kuidas kõiki neid asju kaasas kanda ja hoida, et need ei elaks koos.
Võimalusena saab parameetreid ttl, loop_wait, retry_timeout väänata, st proovida neid lühiajalisi koormustippe neid parameetreid suurendades üle elada. Kuid see pole kõige sobivam variant, sest see koormus võib ajaliselt pikaks venida. Ja me lihtsalt ületame nende parameetrite piirid. Ja see ei pruugi tõesti aidata.
Esimene probleem, nagu te mõistate, on lihtne. Võtsime ja panime DCS koos alusega kokku, tekkis probleem.
Teine probleem sarnaneb esimesega. See on sarnane selle poolest, et meil on jällegi DCS-süsteemiga koostalitlusprobleeme.
Kui vaatame logisid, näeme, et meil on jälle sideviga. Ja Patroni ütleb, et ma ei saa DCS-iga suhelda, nii et praegune juht läheb koopiarežiimi.
Vanameistrist saab koopia, siin töötab Patroni, nagu peab. See käivitab pg_rewind, et kerida tehingulogi tagasi ja seejärel luua ühendus uue ülemseadmega, et uuele juhile järele jõuda. Siin töötab Patroni, nagu peab.
Siit tuleb leida koht, mis eelnes viilile, st need vead, mis põhjustasid meile failifaili. Ja sellega seoses on Patroni palke üsna mugav töötada. Ta kirjutab samu sõnumeid teatud intervalliga. Ja kui me hakkame neid logisid kiiresti kerima, siis näeme logidest, et logid on muutunud, mis tähendab, et mingid probleemid on alanud. Naaseme kiiresti sellesse kohta, vaatame, mis juhtub.
Ja tavaolukorras näevad palgid välja umbes sellised. Kontrollitakse luku omanikku. Ja kui omanik on näiteks vahetunud, võib juhtuda mõni sündmus, millele Patroni peab reageerima. Aga sel juhul on meil kõik hästi. Otsime kohta, kust vead alguse said.
Ja kui oleme kerinud punktini, kus vead hakkasid ilmnema, näeme, et meil on automaatne failivahetus. Ja kuna meie vead olid seotud suhtlemisega DCS-iga ja meie puhul kasutasime Consulit, siis vaatame ka Consuli logisid, mis seal toimus.
Võrreldes umbkaudu esitaja aega ja aega konsuli logides, näeme, et meie naabrid konsulite klastris hakkasid kahtlema teiste konsulite klastri liikmete olemasolus.
Ja kui vaadata ka teiste konsuli agentide logisid, siis on ka näha, et seal toimub mingi võrgukrahh. Ja kõik konsulite klastri liikmed kahtlevad üksteise olemasolus. Ja see andis viilijale tõuke.
Kui vaadata, mis juhtus enne neid tõrkeid, siis on näha, et seal on igasuguseid vigu, näiteks tähtaeg, RPC langes, see tähendab, et konsulite klastri liikmete omavahelises suhtluses on selgelt mingi probleem. .
Lihtsaim vastus on võrgu parandamine. Aga minu jaoks, poodiumil seistes, on seda lihtne öelda. Kuid asjaolud on sellised, et alati ei saa klient võrgu remonti lubada. Ta võib elada alalisvooluvõrgus ega saa võrku parandada, seadmeid mõjutada. Ja seega on vaja muid võimalusi.
Seal on valikud:
- Lihtsaim võimalus, mis on minu arvates isegi dokumentatsioonis kirjas, on konsuli kontrollide keelamine, see tähendab lihtsalt tühja massiivi läbimine. Ja me ütleme konsuli agendile, et ta ei kasuta tšekke. Nende kontrollidega saame neid võrgutorme ignoreerida ja failirit mitte algatada.
- Teine võimalus on raft_multiplier uuesti kontrollida. See on Consul serveri enda parameeter. Vaikimisi on see väärtuseks 5. Seda väärtust soovitatakse lavastuskeskkondade dokumentatsioonis. Tegelikult mõjutab see konsulite võrgustiku liikmete vahelise sõnumivahetuse sagedust. Tegelikult mõjutab see parameeter konsulite klastri liikmete vahelise teenusesuhtluse kiirust. Ja tootmiseks soovitatakse seda juba vähendada, et sõlmed tihedamini sõnumeid vahetaksid.
- Teine võimalus, mille oleme välja mõelnud, on suurendada operatsioonisüsteemi protsesside ajakava muude protsesside hulgas Consuli protsesside prioriteeti. Seal on selline "kena" parameeter, see määrab lihtsalt protsesside prioriteedi, mida OS-i planeerija ajakava koostamisel arvesse võtab. Oleme vähendanud ka Konsuli agentide kena väärtust, st. suurendas prioriteeti, nii et operatsioonisüsteem annaks Consul protsessidele rohkem aega töötamiseks ja koodi täitmiseks. Meie puhul lahendas see meie probleemi.
- Teine võimalus on mitte kasutada Consulit. Mul on sõber, kes on Etcd suur toetaja. Ja me vaidleme temaga regulaarselt, kumb on parem jne või konsul. Kuid selles osas, mis on parem, nõustume temaga tavaliselt, et konsulil on agent, mis peaks töötama igas andmebaasiga sõlmes. See tähendab, et Patroni suhtlemine konsuliklastriga toimub selle agendi kaudu. Ja sellest agentist saab kitsaskoht. Kui agendiga midagi juhtub, ei saa Patroni enam konsulite klastriga koostööd teha. Ja see probleem ongi. Etcd plaanis agenti pole. Patroni saab töötada otse Etcd-serverite loendiga ja nendega juba suhelda. Sellega seoses, kui kasutate oma ettevõttes Etcd-d, on Etcd tõenäoliselt parem valik kui Consul. Kuid meid, kliente, piirab alati see, mida klient on valinud ja kasutab. Ja meil on enamjaolt kõigi klientide jaoks konsul.
- Ja viimane punkt on parameetrite väärtuste ülevaatamine. Saame neid parameetreid tõsta lootuses, et meie lühiajalised võrguprobleemid on lühikesed ega jää nende parameetrite piiridest välja. Nii saame mõne võrguprobleemi ilmnemisel vähendada Patroni automaatfailimise agressiivsust.
Arvan, et paljud Patroni kasutajad on selle käsuga tuttavad.
See käsk näitab klastri praegust olekut. Ja esmapilgul võib see pilt normaalne tunduda. Meil on master, meil on koopia, replikatsiooni viivitust pole. Kuid see pilt on normaalne täpselt seni, kuni me teame, et sellel klastris peaks olema kolm sõlme, mitte kaks.
Sellest lähtuvalt oli olemas automaatfail. Ja pärast seda automaatfaili kadus meie koopia. Peame välja selgitama, miks ta kadus, ja tooma ta tagasi, taastama. Ja me läheme uuesti logide juurde ja vaatame, miks meil oli automaatne failivahetus.
Sel juhul sai meistriks teine koopia. Siin on kõik korras.
Ja me peame vaatama koopiat, mis kukkus maha ja mida klastris pole. Avame Patroni logid ja näeme, et pg_rewind etapis klastriga ühenduse loomisel tekkis probleem. Klastriga ühenduse loomiseks tuleb tehingulogi tagasi kerida, nõutav tehingulogi ülemseadmelt nõuda ja kasutada seda ülemseadmele järele jõudmiseks.
Sel juhul meil tehingulogi pole ja koopiat ei saa käivitada. Sellest lähtuvalt peatame Postgresi veaga. Ja seetõttu pole see klastris.
Peame mõistma, miks seda klastris pole ja miks palke ei olnud. Läheme uue meistri juurde ja vaatame, mis tal palkides on. Selgub, et kui pg_rewind tehti, tekkis kontrollpunkt. Ja mõned vanad tehingute logid nimetati lihtsalt ümber. Kui vana peremees proovis uue masteriga ühendust luua ja nendest logidest päringuid teha, olid need juba ümber nimetatud, neid lihtsalt polnud.
Võrdlesin nende sündmuste toimumise ajatempleid. Ja seal on vahe sõna otseses mõttes 150 millisekundit, see tähendab, et kontrollpunkt täitus 369 millisekundiga, WAL-i segmendid nimetati ümber. Ja sõna otseses mõttes aastal 517, pärast 150 millisekundit, algas vanal koopial tagasikerimine. See tähendab, et meile piisas sõna otseses mõttes 150 millisekundist, et koopia ei saaks ühendust luua ega teenida.
Millised on võimalused?
Algselt kasutasime replikatsioonipesasid. Meie arvates oli see hea. Kuigi töö esimeses etapis lülitasime pesad välja. Meile tundus, et kui pesadesse koguneb palju WAL-segmente, võime masteri ära visata. Ta kukub. Kannatasime mõnda aega ilma teenindusaegadeta. Ja saime aru, et vajame teenindusaegu, tagastasime need.
Kuid siin on probleem, et kui master läheb koopiasse, kustutab ta pesad ja kustutab koos pesadega ka WAL segmendid. Ja selle probleemi kõrvaldamiseks otsustasime tõsta parameetrit wal_keep_segments. Vaikimisi on see 8 segmenti. Tõstsime selle 1 peale ja vaatasime, kui palju vaba ruumi meil on. Ja me annetasime wal_keep_segmentsi jaoks 000 gigabaiti. See tähendab, et ümberlülitamisel on meil alati kõigis sõlmedes 16 gigabaiti tehingulogide reservi.
Ja pluss - see on endiselt asjakohane pikaajaliste hooldustööde jaoks. Oletame, et peame värskendama üht koopiat. Ja me tahame selle välja lülitada. Peame värskendama tarkvara, võib-olla operatsioonisüsteemi või midagi muud. Ja kui me replica välja lülitame, eemaldatakse ka selle koopia pesa. Ja kui me kasutame väikest wal_keep_segments, siis pika koopia puudumise korral lähevad tehingulogid kaotsi. Tõstame koopia, see taotleb neid tehinguloge, kus see peatus, kuid need ei pruugi olla põhiseadmes. Ja ka koopia ei saa ühendust luua. Seetõttu hoiame suures koguses ajakirju.
Meil on tootmisbaas. Projekte on juba töös.
Seal oli viil. Läksime sisse ja vaatasime - kõik on korras, koopiad paigas, replikatsiooni viivitust pole. Ka logides pole vigu, kõik on korras.
Tootetiim ütleb, et andmed peaksid olema, kuid me näeme neid ühest allikast, kuid me ei näe neid andmebaasis. Ja me peame mõistma, mis nendega juhtus.
On selge, et pg_rewind jättis need vahele. Saime sellest kohe aru, aga läksime vaatama, mis toimub.
Logidest leiame alati, millal esitaja juhtus, kellest sai peremees, ja saame kindlaks teha, kes oli vanameister ja millal ta tahtis saada koopiaks, st vajame neid logisid, et teada saada, kui palju tehinguloge oli kadunud.
Meie vanameister on taaskäivitanud. Ja Patroni registreeriti autorunnis. Käivitas Patroni. Seejärel alustas ta Postgresi. Täpsemalt, enne Postgresi käivitamist ja enne selle koopia tegemist käivitas Patroni protsessi pg_rewind. Sellest lähtuvalt kustutas ta osa tehingulogidest, laadis alla uued ja lõi ühenduse. Siin töötas Patroni nutikalt, st ootuspäraselt. Klaster on taastatud. Meil oli 3 sõlme, pärast filerit 3 sõlme - kõik on lahe.
Oleme kaotanud mõned andmed. Ja me peame mõistma, kui palju oleme kaotanud. Otsime just seda hetke, mil saime tagasikerimise. Leiame selle sellistest päevikukirjetest. Tagasikerimine algas, tegi seal midagi ja lõppes.
Peame leidma tehingute logist selle positsiooni, kus vanameister pooleli jäi. Sel juhul on see märk. Ja me vajame teist märki, see tähendab vahemaad, mille võrra vana meister erineb uuest.
Võtame tavalise pg_wal_lsn_diff ja võrdleme neid kahte märki. Ja sel juhul saame 17 megabaiti. Kas palju või vähe, otsustab igaüks ise. Sest kellegi jaoks pole 17 megabaiti palju, kellegi jaoks palju ja vastuvõetamatu. Siin määrab iga inimene ise vastavalt ettevõtte vajadustele.
Aga mida me ise avastasime?
Esiteks peame ise otsustama – kas vajame alati Patroni automaatset käivitumist pärast süsteemi taaskäivitamist? Tihti juhtub, et peame minema vanameistri juurde, vaatama, kui kaugele ta on jõudnud. Võib-olla kontrollige tehingulogi segmente ja vaadake, mis seal on. Ja selleks, et mõista, kas me võime need andmed kaotada või peame nende andmete väljatõmbamiseks käivitama vana masteri eraldiseisvas režiimis.
Ja alles pärast seda peame otsustama, kas saame need andmed ära visata või saame need taastada, ühendage see sõlm koopiana meie klastriga.
Lisaks on parameeter "maximum_lag_on_failover". Vaikimisi, kui mu mälu mind ei peta, on selle parameetri väärtus 1 megabait.
Kuidas ta töötab? Kui meie replika on replikatsiooni viivituses 1 megabaidi andmetega maas, siis see koopia valimistel ei osale. Ja kui äkki toimub failivahetus, vaatab Patroni, millised koopiad on maha jäänud. Kui nad jäävad suure hulga tehingulogide taha, ei saa nad meistriks. See on väga hea turvafunktsioon, mis ei lase sul palju andmeid kaotada.
Kuid probleem on selles, et Patroni klastri ja DCS-i replikatsiooni viivitust värskendatakse teatud ajavahemike järel. Ma arvan, et ttl vaikeväärtus on 30 sekundit.
Sellest lähtuvalt võib tekkida olukord, kus DCS-is on replikatsioonide jaoks üks replikatsiooniviivitus, kuid tegelikult võib olla hoopis teistsugune viivitus või ei pruugi viivitust üldse olla, st see asi ei ole reaalajas. Ja see ei peegelda alati tegelikku pilti. Ja selle peale ei tasu väljamõeldud loogikat teha.
Ja kaotuse oht jääb alati alles. Ja halvimal juhul üks valem ja keskmisel juhul teine valem. See tähendab, et kui planeerime Patroni juurutamist ja hindame, kui palju andmeid võime kaotada, peame tuginema nendele valemitele ja umbkaudu ette kujutama, kui palju andmeid võime kaotada.
Ja on häid uudiseid. Kui vanameister on ette läinud, saab ta mõne taustaprotsessi tõttu edasi minna. See tähendab, et seal oli mingi autovaakum, ta kirjutas andmed, salvestas need tehingute logisse. Ja me võime neid andmeid kergesti ignoreerida ja kaotada. Selles pole probleemi.
Ja logid näevad välja sellised, kui on seatud max_lag_on_failover ja fail on toimunud ning peate valima uue masteri. Replica hindab end võimetuks valimistel osalema. Ja ta keeldub liidri võidujooksus osalemast. Ja ta ootab, kuni valitakse uus peremees, et saaks seejärel sellega ühenduse luua. See on täiendav meede andmete kadumise vastu.
Siin on meil tootetiim, kes kirjutas, et nende tootel on probleeme Postgresiga. Samas masterile endale ligi ei pääse, kuna see pole SSH kaudu kättesaadav. Ja ka automaatfaili ei toimu.
See host oli sunnitud taaskäivitama. Taaskäivitamise tõttu juhtus automaatne fail, kuigi, nagu ma nüüd aru saan, oli võimalik käsitsi automaatfaili teha. Ja peale taaskäivitamist hakkame juba vaatama, mis meil praeguse masteriga oli.
Samas teadsime ette, et meil on ketastega probleeme ehk teadsime juba jälgimisest, kuhu kaevama ja mida otsida.
Jõudsime postgresi logi sisse, hakkasime vaatama, mis seal toimub. Nägime kohustusi, mis kestavad seal üks, kaks, kolm sekundit, mis pole üldse normaalne. Nägime, et meie autovaakum käivitub väga aeglaselt ja kummaliselt. Ja me nägime kettal ajutisi faile. See tähendab, et need kõik näitavad ketastega seotud probleeme.
Uurisime süsteemi dmesg (kerneli logi). Ja nägime, et meil on ühe kettaga probleeme. Ketta alamsüsteemiks oli tarkvara Raid. Vaatasime /proc/mdstat ja nägime, et meil on üks draiv puudu. See tähendab, et on 8 ketta Raid, meil on üks puudu. Kui slaidi hoolikalt vaadata, siis väljundis on näha, et meil pole seal sde. Meil tinglikult öeldes on ketas välja kukkunud. See käivitas kettaprobleemid ja ka rakendustel tekkis probleeme Postgresi klastriga töötamisel.
Ja sellisel juhul ei aitaks Patroni meid kuidagi, sest Patronil pole ülesannet jälgida serveri olekut, ketta olekut. Ja me peame jälgima selliseid olukordi välise järelevalve abil. Kiiresti lisasime välisele monitooringule kettaseire.
Ja tekkis selline mõte – kas vehklemis- või valvetarkvara võiks meid aidata? Arvasime, et vaevalt ta meid sel juhul aidanud oleks, sest probleemide ajal jätkas Patroni DCS-klastriga suhtlemist ega näinud probleemi. See tähendab, et DCS-i ja Patroni seisukohast oli klastriga kõik korras, kuigi tegelikult oli probleeme kettaga, probleeme oli andmebaasi saadavusega.
See on minu meelest üks kummalisemaid probleeme, mida olen väga pikalt uurinud, palju logisid lugenud, ümber valinud ja klastrisimulaatoriks nimetanud.
Probleem oli selles, et vanast meistrist ei saanud normaalset koopiat, st Patroni käivitas selle, Patroni näitas, et see sõlm oli replikana olemas, kuid samas ei olnud see tavaline koopia. Nüüd näete, miks. Seda ma olen selle probleemi analüüsist hoidunud.
Ja kuidas see kõik alguse sai? Algas nagu ka eelmise probleemi puhul ketaspiduritest. Meil oli kohustus sekundiks, kaheks.
Ühendustes esines katkestusi, st kliendid olid rebenenud.
Tekkisid erineva raskusastmega ummistused.
Ja vastavalt sellele pole ketta alamsüsteem eriti tundlik.
Ja minu jaoks on kõige müstilisem asi kohe saabunud sulgemistaotlus. Postgresil on kolm väljalülitusrežiimi:
- See on graatsiline, kui ootame, kuni kõik kliendid ühenduse katkestavad.
- Kui me sunnime kliente ühenduse katkestama, siis on kiire.
- Ja kohe. Sellisel juhul ei käsi kohene isegi klientidel välja lülitada, vaid lihtsalt lülitub välja ilma hoiatuseta. Ja kõikidele klientidele saadab operatsioonisüsteem juba RST-teate (TCP-teate, et ühendus on katkenud ja kliendil pole enam midagi püüda).
Kes selle signaali saatis? Postgresi taustprotsessid ei saada selliseid signaale üksteisele, st see on kill-9. Nad ei saada selliseid asju üksteisele, nad ainult reageerivad sellistele asjadele, st see on Postgresi avarii taaskäivitamine. Kes saatis, ma ei tea.
Vaatasin "viimast" käsku ja nägin ühte inimest, kes ka meiega sellesse serverisse sisse logis, kuid olin liiga häbelik, et küsimust esitada. Võib-olla oli see tapmine -9. Palkides näeksin kill -9, sest Postgres ütleb, et see võttis kill -9, aga ma ei näinud seda logides.
Edasi vaadates nägin, et Patroni ei kirjutanud logisse päris pikalt - 54 sekundit. Ja kui võrrelda kahte ajatemplit, siis umbes 54 sekundi jooksul polnud ühtegi sõnumit.
Ja selle aja jooksul oli automaatfail. Patroni tegi siin jälle suurepärast tööd. Meie vanameister oli kättesaamatu, temaga juhtus midagi. Ja algas uue meistri valimine. Siin läks kõik hästi. Meie pgsql01 on saanud uueks juhiks.
Meil on koopia, millest on saanud meister. Ja on ka teine vastus. Ja teise koopiaga oli probleeme. Ta proovis ümber seadistada. Nagu ma aru saan, proovis ta muuta recovery.conf-i, taaskäivitada Postgres ja luua ühenduse uue masteriga. Ta kirjutab iga 10 sekundi järel sõnumeid, et ta proovib, kuid tal ei õnnestu.
Ja nende katsete ajal saabub vanameistrile kohese väljalülitamise signaal. Master taaskäivitatakse. Ja ka taastamine peatub, kuna vanameister läheb taaskäivitusse. See tähendab, et koopia ei saa sellega ühendust luua, kuna see on väljalülitusrežiimis.
Mingil hetkel see töötas, kuid replikatsioon ei käivitunud.
Ainus oletus on, et failis recovery.conf oli vana põhiaadress. Ja kui ilmus uus meister, proovis teine koopia ikkagi vana meistriga ühendust saada.
Kui Patroni käivitas teise koopia, käivitus sõlm, kuid ei saanud paljundada. Ja tekkis replikatsiooni lag, mis nägi välja umbes selline. See tähendab, et kõik kolm sõlme olid paigas, kuid teine sõlm jäi maha.
Samas, kui vaadata kirjutatud logisid, on näha, et replikatsiooni ei saanud alustada, kuna tehingulogid olid erinevad. Ja need tehingulogid, mida master pakub ja mis on määratud failis recovery.conf, lihtsalt ei sobi meie praegusesse sõlme.
Ja siin ma tegin vea. Pidin tulema ja vaatama, mis failis recovery.conf on, et kontrollida oma hüpoteesi, et ühendame vale meistriga. Aga siis ma lihtsalt tegelesin sellega ja see ei tulnud mulle pähe või nägin, et koopia oli maha jäänud ja seda tuleb uuesti täita, see tähendab, et töötasin kuidagi hooletult. See oli minu ühine.
30 minuti pärast tuli juba admin, st ma taaskäivitasin Patroni replical. Panin sellele juba punkti, mõtlesin, et tuleb uuesti täita. Ja mõtlesin – panen Patroni uuesti käima, äkki tuleb midagi head välja. Algas taastumine. Ja baas isegi avanes, see oli valmis ühendusi vastu võtma.
Replikatsioon on alanud. Kuid minut hiljem kukkus ta välja veaga, et tehingulogid ei sobi talle.
Mõtlesin, et alustan uuesti. Taaskäivitasin Patroni uuesti ja ma ei taaskäivitanud Postgresi, vaid taaskäivitasin Patroni lootuses, et see käivitab andmebaasi võluväel.
Replikatsioon algas uuesti, kuid tehingulogis olid märgid erinevad, need ei olnud samad, mis eelmisel käivitamiskatsel. Replikatsioon peatus uuesti. Ja sõnum oli juba veidi erinev. Ja see ei olnud minu jaoks väga informatiivne.
Ja siis tuleb mulle pähe – mis siis, kui ma taaskäivitan Postgresi, siis teen praegusel masteril kontrollpunkti, et liigutada punkti tehingulogis veidi ettepoole, et taastamine algaks teisest hetkest? Lisaks oli meil veel WAL-i varud.
Taaskäivitasin Patroni, tegin paar kontrollpunkti masteril, paar restart punkti replical, kui see avanes. Ja see aitas. Mõtlesin kaua, miks see aitas ja kuidas see toimis. Ja replika algas. Ja replikatsioon ei olnud enam rebenenud.
Selline probleem on minu jaoks üks müstilisemaid, mille üle ma siiani mõistan, mis seal tegelikult juhtus.
Millised on selle tagajärjed? Patroni võib töötada nii, nagu ette nähtud ja ilma vigadeta. Kuid samas pole see 100% garantii, et meiega on kõik hästi. Replica võib käivituda, kuid see võib olla pooltöötavas olekus ja rakendus ei saa sellise koopiaga töötada, kuna seal on vanu andmeid.
Ja pärast fileerit tuleb alati kontrollida, kas klastriga on kõik korras ehk kas replikaid on vajalik arv, replikatsiooni viivitust pole.
Ja kui me neid probleeme lahendame, annan soovitusi. Üritasin need kaheks slaidiks ühendada. Tõenäoliselt saaks kõik lood kaheks slaidiks kokku panna ja ainult jutustada.
Patroni kasutamisel peab teil olema jälgimine. Peaksite alati teadma, millal automaatne failivahetus toimus, sest kui te ei tea, et teil oli automaatne failivahetus, pole teil klastri üle kontrolli. Ja see on halb.
Pärast iga failirit peame alati klastri käsitsi kontrollima. Peame hoolitsema selle eest, et meil oleks alati ajakohane koopiate arv, ei esineks replikatsiooni viivitust, voogesituse replikatsiooniga, Patroni, DCS-süsteemiga seotud logides pole vigu.
Automatiseerimine võib edukalt töötada, Patroni on väga hea tööriist. See võib töötada, kuid see ei vii klastri soovitud olekusse. Ja kui me sellest teada ei saa, jääme hätta.
Ja Patroni pole hõbekuul. Peame siiski mõistma, kuidas Postgres töötab, kuidas toimib replikatsioon ja kuidas Patroni Postgresiga töötab ning kuidas sõlmede vahelist suhtlust pakutakse. See on vajalik kätega seotud probleemide lahendamiseks.
Kuidas läheneda diagnoosi küsimusele? Juhtus nii, et töötame erinevate klientidega ja kellelgi pole ELK virna ning peame logid välja sorteerima 6 konsooli ja 2 saki avades. Ühel vahekaardil on need iga sõlme Patroni logid, teisel vahekaardil Consuli logid või vajadusel Postgres. Seda on väga raske diagnoosida.
Milliseid lähenemisviise olen välja töötanud? Esiteks vaatan alati, millal viilija on saabunud. Ja minu jaoks on see veelahe. Vaatan, mis toimus enne viilijat, viilimise ajal ja pärast viilijat. Fileoveril on kaks märki: see on algus- ja lõppaeg.
Järgmisena otsin logidest failirile eelnevaid sündmusi enne faili, st otsin põhjuseid, miks failer juhtus.
Ja see annab pildi mõistmisest, mis juhtus ja mida saab edaspidi teha, et selliseid asjaolusid ei tekiks (ja sellest tulenevalt ka viilijat).
Ja kuhu me tavaliselt vaatame? Ma vaatan:
- Esiteks Patroni palkide juurde.
- Järgmisena vaatan Postgresi logisid või DCS-i logisid, olenevalt sellest, mida Patroni logidest leiti.
- Ja süsteemi logid annavad mõnikord ka aru, mis faili põhjustas.
Kuidas ma Patronisse suhtun? Mul on Patroniga väga head suhted. Minu arvates on see täna parim. Tean palju muid tooteid. Need on Stolon, Repmgr, Pg_auto_failover, PAF. 4 tööriista. Proovisin neid kõiki. Patroni on minu lemmik.
Kui nad küsivad minult: "Kas ma soovitan Patronit?". Ma ütlen jah, sest mulle meeldib Patroni. Ja ma arvan, et õppisin seda küpsetama.
Kui teil on huvi näha, mis probleeme on Patroniga peale minu mainitud probleemide veel, võite alati vaadata lehte GitHubis. Seal on palju erinevaid lugusid ja seal arutatakse palju huvitavaid küsimusi. Selle tulemusena võeti kasutusele ja lahendati mõned vead, see tähendab, et see on huvitav lugemine.
Huvitavad lood on inimestest, kes tulistavad endale jalga. Väga informatiivne. Loed ja saad aru, et seda pole vaja teha. Panin endale linnukese.
Ja ma tahaksin öelda Zalandole selle projekti arendamise eest suur aitäh, nimelt Aleksander Kukuškinile ja Aleksei Kljukinile. Aleksey Klyukin on üks kaasautoritest, ta ei tööta enam Zalandos, kuid need on kaks inimest, kes selle tootega tööd alustasid.
Ja ma arvan, et Patroni on väga lahe asi. Olen õnnelik, et ta olemas on, temaga on huvitav. Ja suur aitäh kõigile kaastöölistele, kes Patronile plaastreid kirjutavad. Loodan, et Patroni muutub vanusega küpsemaks, lahedamaks ja tõhusamaks. See on juba toimiv, kuid loodan, et see muutub veelgi paremaks. Seetõttu, kui kavatsete Patronit kasutada, siis ärge kartke. See on hea lahendus, seda saab rakendada ja kasutada.
See on kõik. Kui teil on küsimusi, küsige.
küsimused
Täname raporti eest! Kui pärast viilijat on ikka väga hoolikalt vaja sinna vaadata, siis milleks meil automaatset viilijat vaja on?
Sest see on uus asi. Oleme temaga koos olnud ainult aasta. Parem olla ohutu. Tahame sisse tulla ja näha, et kõik läks tõesti nii, nagu peab. See on täiskasvanute usaldamatuse tase – parem on üle vaadata ja näha.
Näiteks käisime hommikul ja vaatasime, eks?
Mitte hommikul, tavaliselt saame autofailist teada peaaegu kohe. Saame teateid, näeme, et on toimunud automaatfail. Peaaegu kohe läheme vaatama. Kuid kõik need kontrollid tuleks viia järelevalve tasemele. Kui pääsete Patronile juurde REST API kaudu, on ajalugu olemas. Ajaloo järgi näete faili esitamise ajatempleid. Selle põhjal saab teha monitooringut. Näete ajalugu, kui palju sündmusi seal oli. Kui meil on rohkem sündmusi, siis on toimunud automaatfail. Võid minna vaatama. Või meie jälgimisautomaatika kontrollis, et meil on kõik koopiad paigas, viivitust pole ja kõik on korras.
Tänan!
Suur tänu suurepärase loo eest! Kui me kolisime DCS klastri kuskile kaugele Postgresi klastrist, siis ka seda klastrit tuleb perioodiliselt hooldada? Millised on parimad tavad, et mõned DCS-klastri tükid tuleb välja lülitada, midagi nendega teha jne? Kuidas kogu see struktuur ellu jääb? Ja kuidas sa neid asju teed?
Ühe ettevõtte jaoks oli vaja teha probleemide maatriks, mis saab siis, kui mõni komponent või mitu komponenti ebaõnnestuvad. Selle maatriksi järgi läbime järjestikku kõik komponendid ja koostame stsenaariumid nende komponentide rikke korral. Sellest lähtuvalt võib teil olla iga ebaõnnestumise stsenaariumi jaoks taastamise tegevuskava. Ja DCS-i puhul on see osa standardsest infrastruktuurist. Ja administraator haldab seda ja me loodame juba administraatoritele, kes seda haldavad, ja nende võimele seda õnnetuste korral parandada. Kui DCS-i üldse pole, siis võtame selle kasutusele, aga samas eriti ei jälgi, sest me ei vastuta infrastruktuuri eest, vaid anname soovitusi, kuidas ja mida jälgida.
See tähendab, kas ma sain õigesti aru, et enne hostidega midagi ette võtmist pean Patroni keelama, failiri välja lülitama, kõik keelama?
See sõltub sellest, kui palju sõlme meil DCS-klastris on. Kui sõlme on palju ja kui me keelame ainult ühe sõlme (koopia), säilitab klaster kvoorumi. Ja Patroni töötab jätkuvalt. Ja midagi ei vallandu. Kui meil on keerulised toimingud, mis mõjutavad rohkem sõlme, mille puudumine võib kvoorumi rikkuda, siis - jah, võib olla mõttekas Patroni pausile panna. Sellel on vastav käsk - patronictl pause, patronictl resume. Peatame lihtsalt pausi ja automaatfilter sel ajal ei tööta. Teeme DCS-klastri hooldust, siis võtame pausi maha ja jätkame elamist.
Tänan teid väga!
Tänan teid väga teie aruande eest! Kuidas suhtub tootetiim andmete kadumisse?
Tootemeeskonnad ei hooli ja meeskonnajuhid on mures.
Millised garantiid on olemas?
Garantiid on väga rasked. Aleksander Kukushkinil on aruanne “Kuidas arvutada RPO ja RTO”, st taastumisaeg ja kui palju andmeid võime kaotada. Ma arvan, et me peame need slaidid üles otsima ja neid uurima. Minu mäletamist mööda on konkreetsed sammud, kuidas neid asju arvutada. Kui palju tehinguid võime kaotada, kui palju andmeid võime kaotada. Võimalusena saame kasutada sünkroonset replikatsiooni Patroni tasemel, kuid see on kahe teraga mõõk: meil on kas andmete usaldusväärsus või kaotame kiiruse. Sünkroonne replikatsioon on olemas, kuid see ei taga ka 100% kaitset andmete kadumise eest.
Aleksei, aitäh suurepärase aruande eest! Kas teil on kogemusi Patroni kasutamisega nulltaseme kaitseks? See tähendab, et koos sünkroonse ooterežiimiga? See on esimene küsimus. Ja teine küsimus. Olete kasutanud erinevaid lahendusi. Kasutasime Repmgr-i, kuid ilma automaatfailita, ja nüüd plaanime lisada ka automaatfaili. Ja me käsitleme Patronit alternatiivse lahendusena. Mida saate Repmgriga võrreldes eelistena öelda?
Esimene küsimus oli sünkroonsete koopiate kohta. Keegi ei kasuta siin sünkroonset replikatsiooni, sest kõik on hirmul (mitu klienti juba kasutavad seda, põhimõtteliselt ei märganud nad jõudlusprobleeme - Kõneleja märkus). Kuid oleme enda jaoks välja töötanud reegli, et sünkroonses replikatsiooniklastris peaks olema vähemalt kolm sõlme, sest kui meil on kaks sõlme ja kui juht või koopia ebaõnnestub, lülitab Patroni selle sõlme Standalone režiimi, et rakendus jätkaks tööd. Sel juhul on andmete kadumise oht.
Teise küsimuse osas oleme Repmgr-i kasutanud ja kasutame seda ajaloolistel põhjustel mõnede klientidega siiani. Mida saab öelda? Patronil on karbist välja võetud automaatfiler, Repmgril on lisafunktsioon, mis tuleb lubada. Peame igas sõlmes käivitama Repmgr-deemoni ja seejärel saame automaatse faili konfigureerida.
Repmgr kontrollib, kas Postgresi sõlmed on elus. Repmgr protsessid kontrollivad üksteise olemasolu, see pole kuigi tõhus lähenemine. võib esineda keerulisi võrgu isoleerimise juhtumeid, kus suur Repmgr-klaster võib laguneda mitmeks väiksemaks ja jätkata tööd. Ma pole Repmgr-i kaua jälginud, võib-olla sai korda ... või võib-olla mitte. Kuid DCS-i klastri oleku kohta teabe eemaldamine, nagu seda teeb Stolon, Patroni, on kõige elujõulisem valik.
Alexey, mul on küsimus, võib-olla lonkavam. Ühes esimestest näidetest teisaldasite DCS-i kohalikust masinast kaughosti. Mõistame, et võrk on asi, millel on oma omadused, see elab ise. Ja mis juhtub, kui DCS-klaster mingil põhjusel pole saadaval? Ma ei ütle põhjuseid, neid võib olla palju: võrgutegijate kõveratest kätest kuni tõeliste probleemideni.
Ma ei öelnud seda kõva häälega välja, kuid kvoorumi täitmiseks peab ka DCS-klaster olema tõrkeotsas, st see on paaritu arv sõlme. Mis juhtub, kui DCS-klaster muutub kättesaamatuks või kvoorumit ei suudeta täita, st tekib mingi võrgujaotus või sõlme rike? Sel juhul läheb Patroni klaster kirjutuskaitstud režiimi. Patroni klaster ei saa määrata klastri olekut ja mida teha. See ei saa DCS-iga ühendust võtta ja uut klastri olekut sinna salvestada, nii et kogu klaster on kirjutuskaitstud. Ja ootab kas operaatori käsitsi sekkumist või DCS-i taastumist.
Jämedalt öeldes saab DCS-st meie jaoks sama oluline teenus kui baas ise?
Jah Jah. Paljudes kaasaegsetes ettevõtetes on Service Discovery infrastruktuuri lahutamatu osa. Seda rakendatakse isegi enne, kui infrastruktuuris oli isegi andmebaasi. Suhteliselt öeldes käivitati infrastruktuur, võeti kasutusele DC-s ja meil on kohe Service Discovery. Kui see on konsul, saab selle peale ehitada DNS-i. Kui see on Etcd, võib seal olla osa Kubernetese klastrist, kus kõik muu juurutatakse. Mulle tundub, et Service Discovery on juba kaasaegsete infrastruktuuride lahutamatu osa. Ja nad mõtlevad sellele palju varem kui andmebaasidele.
Tänan!
Allikas: www.habr.com