Hlavným cieľom Patroni je poskytovať vysokú dostupnosť pre PostgreSQL. Patroni je však len šablóna, nie hotový nástroj (čo sa vo všeobecnosti hovorí v dokumentácii). Na prvý pohľad, po nastavení Patroni v testovacom laboratóriu, môžete vidieť, aký je to skvelý nástroj a ako ľahko zvláda naše pokusy prelomiť klaster. V praxi sa však v produkčnom prostredí nie vždy všetko deje tak krásne a elegantne ako v testovacom laboratóriu.
Poviem vám niečo o sebe. Začínal som ako správca systému. Pracoval vo vývoji webu. V Data Egret pracujem od roku 2014. Spoločnosť sa zaoberá poradenstvom v oblasti Postgres. A obsluhujeme presne Postgres a pracujeme s Postgresom každý deň, takže máme rôzne odborné znalosti súvisiace s prevádzkou.
A koncom roka 2018 sme začali pomaly používať Patroni. A nazbierali sa nejaké skúsenosti. Nejako sme to diagnostikovali, vyladili, prišli na naše osvedčené postupy. A v tejto správe o nich budem hovoriť.
Okrem Postgresu milujem Linux. Rád sa v nej hrabem a skúmam, rád zbieram jadierka. Milujem virtualizáciu, kontajnery, docker, Kubernetes. Toto všetko ma zaujíma, pretože to ovplyvňujú staré zvyky správcov. Rád sa zaoberám monitorovaním. A milujem postgres veci spojené s administráciou, teda replikácia, zálohovanie. A vo svojom voľnom čase píšem v Go. Nie som softvérový inžinier, v Go píšem len pre seba. A to mi robí radosť.
- Myslím, že mnohí z vás vedia, že Postgres nemá HA (High Availability) hneď po vybalení. Ak chcete získať HA, musíte si niečo nainštalovať, nakonfigurovať, vynaložiť úsilie a získať to.
- Existuje niekoľko nástrojov a Patroni je jedným z nich, ktorý rieši HA celkom v pohode a veľmi dobre. Ale tým, že to všetko dáme do testovacieho laboratória a spustíme to, môžeme vidieť, že to všetko funguje, môžeme reprodukovať niektoré problémy, vidieť, ako im Patroni slúži. A uvidíme, že to všetko funguje skvele.
- V praxi sme však čelili rôznym problémom. A o týchto problémoch budem hovoriť.
- Poviem vám, ako sme to diagnostikovali, čo sme upravili - či nám to pomohlo alebo nie.
- Nepoviem vám, ako nainštalovať Patroni, pretože môžete googliť na internete, môžete sa pozrieť na konfiguračné súbory, aby ste pochopili, ako to všetko začína, ako je nakonfigurované. Môžete pochopiť schémy, architektúry, nájsť informácie o tom na internete.
- Nebudem hovoriť o skúsenostiach niekoho iného. Budem hovoriť len o problémoch, ktorým sme čelili.
- A to nebudem hovoriť o problémoch, ktoré sú mimo Patroni a PostgreSQL. Ak sú napríklad problémy spojené s balansovaním, keď sa nám zrútil klaster, nebudem o tom hovoriť.
A malé vylúčenie zodpovednosti predtým, než začneme s našou správou.
Všetky tieto problémy, s ktorými sme sa stretli, sme mali v prvých 6-7-8 mesiacoch prevádzky. Postupom času sme dospeli k našim interným osvedčeným postupom. A naše problémy zmizli. Preto bola správa ohlásená asi pred šiestimi mesiacmi, keď som to všetko mala čerstvo v hlave a dokonale som si to všetko zapamätala.
V priebehu prípravy správy som už zdvihol staré posmrtné správy, pozrel som si záznamy. A na niektoré detaily sa mohlo zabudnúť alebo niektoré detaily nebolo možné úplne preskúmať počas analýzy problémov, takže v niektorých bodoch sa môže zdať, že problémy nie sú úplne zohľadnené, alebo je nedostatok informácií. A preto vás žiadam, aby ste ma na túto chvíľu ospravedlnili.
Čo je Patroni?
- Toto je šablóna na budovanie HA. Tak sa to píše v dokumentácii. A z môjho pohľadu je to veľmi správne vysvetlenie. Patroni nie je strieborná guľka, ktorá vyrieši všetky vaše problémy, to znamená, že sa musíte snažiť, aby to fungovalo a prinášalo výhody.
- Toto je služba agenta, ktorá je nainštalovaná na každej databázovej službe a je akýmsi init systémom pre váš Postgres. Spustí Postgres, zastaví, reštartuje, prekonfiguruje a zmení topológiu vášho klastra.
- Preto, aby sa uložil stav klastra, jeho aktuálna reprezentácia, ako vyzerá, je potrebný nejaký druh úložiska. A z tohto pohľadu sa Patroni vydal cestou ukladania stavu do externého systému. Ide o distribuovaný úložný systém konfigurácie. Môže to byť Etcd, Consul, ZooKeeper alebo kubernetes Etcd, teda jedna z týchto možností.
- A jednou z vlastností Patroni je, že autofiler dostanete z krabice iba jeho nastavením. Ak si na porovnanie vezmeme Repmgr, tak je tam zahrnutý aj filer. S Repmgr získame prepnutie, ale ak chceme automatický filter, musíme ho nakonfigurovať dodatočne. Patroni už má autofiler z krabice.
- A je tu veľa iných vecí. Napríklad údržba konfigurácií, nalievanie nových replík, zálohovanie atď. Ale to je nad rámec správy, o tom nebudem hovoriť.
A malým výsledkom je, že hlavnou úlohou Patroni je robiť autofile dobre a spoľahlivo, aby náš klaster zostal funkčný a aplikácia nezaznamenala zmeny v topológii klastra.
Keď však začneme používať Patroni, náš systém sa trochu skomplikuje. Ak sme predtým mali Postgres, potom pri použití Patroni dostaneme samotného Patroni, dostaneme DCS, kde je uložený stav. A to všetko musí nejako fungovať. Čo sa teda môže pokaziť?
Môže sa zlomiť:
- Postgres sa môže zlomiť. Môže to byť predloha alebo replika, jeden z nich môže zlyhať.
- Samotný Patroni sa môže zlomiť.
- DCS, kde je uložený stav, sa môže pokaziť.
- A sieť sa môže zlomiť.
Všetky tieto body zvážim v správe.
Prípady budem posudzovať, keď sa stanú zložitejšími, nie z toho hľadiska, že prípad zahŕňa veľa komponentov. A z pohľadu subjektívnych pocitov, že tento obal bol pre mňa náročný, bolo ťažké ho rozobrať ... a naopak, niektoré puzdro bolo ľahké a bolo ľahké ho rozobrať.
A prvý prípad je najjednoduchší. Toto je prípad, keď sme vzali databázový klaster a nasadili naše úložisko DCS do toho istého klastra. Toto je najčastejšia chyba. Toto je chyba pri budovaní architektúr, t.j. kombinovaní rôznych komponentov na jednom mieste.
Takže tam bol pilčík, poďme sa zaoberať tým, čo sa stalo.
A tu nás zaujíma, kedy sa pilčík stal. To znamená, že nás zaujíma tento moment v čase, keď sa zmenil stav klastra.
Ale nie vždy je filtrovanie okamžité, t.j. nezaberie žiadnu jednotku času, môže byť oneskorené. Môže to byť dlhotrvajúce.
Preto má čas začiatku a čas ukončenia, t. j. ide o nepretržitú udalosť. A všetky udalosti rozdeľujeme do troch intervalov: máme čas pred pilčíkom, počas pilčíka a po pilníku. To znamená, že zvažujeme všetky udalosti v tejto časovej osi.
A prvá vec, keď sa stal pilčík, hľadáme príčinu toho, čo sa stalo, čo bolo príčinou toho, čo viedlo k pilníku.
Ak sa pozrieme na polená, budú to klasické polená Patroni. Hovorí nám v nich, že server sa stal majstrom a úloha majstra prešla na tento uzol. Tu je to zvýraznené.
Ďalej musíme pochopiť, prečo došlo k súboru, t. j. aké udalosti nastali, ktoré spôsobili presun hlavnej roly z jedného uzla do druhého. A v tomto prípade je všetko jednoduché. Pri interakcii s úložným systémom došlo k chybe. Majster si uvedomil, že nemôže pracovať s DCS, to znamená, že existuje nejaký problém s interakciou. A povie, že už nemôže byť pánom a dáva výpoveď. Tento riadok „degradovaný seba“ hovorí presne to.
Ak sa pozrieme na udalosti, ktoré predchádzali fileru, môžeme tam vidieť práve dôvody, ktoré boli problémom pokračovania čarodejníka.
Ak sa pozrieme na protokoly Patroni, uvidíme, že máme veľa chýb, timeoutov, t.j. agent Patroni nemôže pracovať s DCS. V tomto prípade ide o zástupcu konzula, ktorý komunikuje na porte 8500.
A problém je v tom, že Patroni a databáza bežia na rovnakom hostiteľovi. A servery Consul boli spustené na rovnakom uzle. Vytvorením záťaže na serveri sme spôsobili problémy aj serverom Consul. Nevedeli správne komunikovať.
Po nejakom čase, keď záťaž opadla, náš Patroni bol opäť schopný komunikovať s agentmi. Obnovila sa normálna práca. A ten istý server Pgdb-2 sa opäť stal majstrom. To znamená, že došlo k malému prevráteniu, kvôli ktorému uzol rezignoval na právomoci majstra a potom ich znova prevzal, to znamená, že sa všetko vrátilo tak, ako bolo.
A to možno považovať za falošný poplach, alebo možno považovať Patroniho za všetko správne. To znamená, že si uvedomil, že nedokáže udržať stav klastra a odstránil svoju autoritu.
A tu nastal problém v dôsledku skutočnosti, že servery Consul sú na rovnakom hardvéri ako základne. Podľa toho akékoľvek zaťaženie: či už ide o zaťaženie diskov alebo procesorov, ovplyvňuje to aj interakciu s klastrom Consul.
A rozhodli sme sa, že by to nemalo žiť spolu, pridelili sme konzulovi samostatný klaster. A Patroni už pracoval so samostatným konzulom, to znamená, že existoval samostatný klaster Postgres, samostatný klaster konzulov. Toto je základný návod, ako všetky tieto veci nosiť a držať, aby to spolu nežilo.
Voliteľne môžete skrútiť parametre ttl, loop_wait, retry_timeout, t.j. pokúsiť sa prežiť tieto krátkodobé špičky zaťaženia zvýšením týchto parametrov. Ale to nie je najvhodnejšia možnosť, pretože toto zaťaženie môže byť dlhé. A tieto hranice týchto parametrov jednoducho prekročíme. A to možno naozaj nepomôže.
Prvý problém, ako viete, je jednoduchý. Vzali sme a dali DCS spolu so základňou, máme problém.
Druhý problém je podobný prvému. Je to podobné v tom, že opäť máme problémy s interoperabilitou so systémom DCS.
Ak sa pozrieme na protokoly, uvidíme, že máme opäť chybu v komunikácii. A Patroni hovorí, že nemôžem interagovať s DCS, takže aktuálny master prejde do režimu repliky.
Zo starého majstra sa stáva replika, tu Patroni vychádza, ako sa patrí. Spustí sa pg_rewind na previnutie protokolu transakcií a potom sa pripojí k novému hlavnému serveru, aby sa dostal k novému hlavnému serveru. Tu Patroni funguje, ako sa patrí.
Tu musíme nájsť miesto, ktoré predchádzalo fileru, teda tie chyby, ktoré spôsobili, že máme filer. A v tomto ohľade je práca s protokolmi Patroni celkom pohodlná. V určitom intervale píše rovnaké správy. A ak začneme rýchlo listovať v týchto protokoloch, potom z protokolov uvidíme, že sa protokoly zmenili, čo znamená, že sa začali nejaké problémy. Rýchlo sa vraciame na toto miesto, uvidíme, čo sa stane.
A v bežnej situácii vyzerajú protokoly asi takto. Vlastník zámku je kontrolovaný. A ak sa napríklad zmenil majiteľ, môže dôjsť k udalostiam, na ktoré musí Patroni reagovať. Ale v tomto prípade sme v pohode. Hľadáme miesto, kde sa chyby začali.
A keď sme prešli do bodu, kde sa začali objavovať chyby, vidíme, že sme mali automatické prekrytie. A keďže naše chyby súviseli s interakciou s DCS a v našom prípade sme použili Consul, pozrieme sa aj na Consul logs, čo sa tam stalo.
Pri hrubom porovnaní času filer a času v Consul logs vidíme, že naši susedia v Consul cluster začali pochybovať o existencii iných členov Consul clusteru.
A ak sa pozriete aj na protokoly iných agentov Consul, môžete tiež vidieť, že tam dochádza k nejakému kolapsu siete. A všetci členovia zhluku konzulov navzájom pochybujú o svojej existencii. A to bol impulz pre pilčíka.
Ak sa pozriete na to, čo sa stalo pred týmito chybami, môžete vidieť, že existujú najrôznejšie chyby, napríklad konečný termín, RPC klesla, to znamená, že je evidentne nejaký problém vo vzájomnej interakcii členov klastra Consul. .
Najjednoduchšia odpoveď je opraviť sieť. Ale mne, keď stojím na pódiu, sa to hovorí ľahko. Ale okolnosti sú také, že nie vždy si zákazník môže dovoliť opraviť sieť. Môže žiť v DC a nemusí byť schopný opraviť sieť, ovplyvniť zariadenie. A preto sú potrebné ďalšie možnosti.
Existujú možnosti:
- Najjednoduchšia možnosť, ktorá je podľa môjho názoru napísaná aj v dokumentácii, je vypnúť kontroly Consul, to znamená jednoducho odovzdať prázdne pole. A hovoríme agentovi konzula, aby nepoužíval žiadne šeky. Pomocou týchto kontrol môžeme ignorovať tieto sieťové búrky a neiniciovať súbor.
- Ďalšou možnosťou je dvojitá kontrola raft_multiplier. Toto je parameter samotného servera Consul. Štandardne je nastavená na 5. Táto hodnota je odporúčaná dokumentáciou pre prípravné prostredia. V skutočnosti to ovplyvňuje frekvenciu posielania správ medzi členmi siete konzulov. V skutočnosti tento parameter ovplyvňuje rýchlosť servisnej komunikácie medzi členmi klastra Consul. A pre produkciu sa to už odporúča znížiť, aby si uzly vymieňali správy častejšie.
- Ďalšou možnosťou, s ktorou sme prišli, je zvýšiť prioritu procesov Consul medzi ostatnými procesmi pre plánovač procesov operačného systému. Existuje taký „pekný“ parameter, ktorý len určuje prioritu procesov, ktoré plánovač OS berie do úvahy pri plánovaní. Znížili sme aj peknú hodnotu pre agentov Consul, t.j. zvýšila prioritu tak, aby operačný systém poskytol procesom Consul viac času na prácu a spustenie ich kódu. V našom prípade to vyriešilo náš problém.
- Ďalšou možnosťou je nepoužiť Consul. Mám priateľa, ktorý je veľkým zástancom Etcd. A pravidelne sa s ním hádame, čo je lepšie Etcd alebo Consul. Ale pokiaľ ide o to, čo je lepšie, zvyčajne s ním súhlasíme, že Consul má agenta, ktorý by mal bežať na každom uzle s databázou. To znamená, že interakcia Patroni so zhlukom konzulov prechádza cez tohto agenta. A tento agent sa stáva prekážkou. Ak sa agentovi niečo stane, Patroni už nebude môcť pracovať s klastrom Consul. A toto je ten problém. V pláne Etcd nie je žiadny agent. Patroni môže pracovať priamo so zoznamom Etcd serverov a už s nimi komunikovať. V tomto ohľade, ak používate Etcd vo vašej spoločnosti, potom Etcd bude pravdepodobne lepšou voľbou ako Consul. Ale my u našich zákazníkov sme vždy limitovaní tým, čo si klient vybral a používa. A máme Consul z väčšej časti pre všetkých klientov.
- A posledným bodom je revízia hodnôt parametrov. Tieto parametre môžeme zvýšiť v nádeji, že naše krátkodobé problémy so sieťou budú krátke a nebudú mimo rozsahu týchto parametrov. Týmto spôsobom môžeme znížiť agresivitu Patroni na automatické súbory, ak sa vyskytnú nejaké problémy so sieťou.
Myslím, že mnohí, ktorí používajú Patroni, poznajú tento príkaz.
Tento príkaz zobrazuje aktuálny stav klastra. A na prvý pohľad sa tento obrázok môže zdať normálny. Máme predlohu, máme repliku, nedochádza k oneskoreniu replikácie. Ale tento obrázok je normálny presne dovtedy, kým nevieme, že tento klaster by mal mať tri uzly, nie dva.
V súlade s tým došlo k automatickému súboru. A po tomto automatickom súbore naša replika zmizla. Musíme zistiť, prečo zmizla a priviesť ju späť, obnoviť. A znova ideme do denníkov a uvidíme, prečo sme mali automatické prekrytie.
V tomto prípade sa predlohou stala druhá replika. Tu je všetko v poriadku.
A musíme sa pozrieť na repliku, ktorá odpadla a ktorá nie je v zhluku. Otvoríme protokoly Patroni a vidíme, že sme mali problém počas procesu pripájania sa ku klastru vo fáze pg_rewind. Ak sa chcete pripojiť ku klastru, musíte pretočiť protokol transakcií, vyžiadať si požadovaný protokol transakcií od hlavného servera a použiť ho na dobehnutie hlavného servera.
V tomto prípade nemáme protokol transakcií a replika sa nemôže spustiť. V súlade s tým zastavíme Postgres s chybou. A preto nie je v klastri.
Musíme pochopiť, prečo nie je v klastri a prečo neexistujú žiadne protokoly. Ideme k novému pánovi a pozrieme sa, čo má v protokoloch. Ukazuje sa, že po vykonaní pg_rewind nastal kontrolný bod. A niektoré zo starých protokolov transakcií boli jednoducho premenované. Keď sa starý hlavný server pokúsil pripojiť k novému hlavnému zariadeniu a dotazoval sa na tieto protokoly, boli už premenované, jednoducho neexistovali.
Porovnal som časové pečiatky, kedy sa tieto udalosti stali. A tam je rozdiel doslova 150 milisekúnd, to znamená, že kontrolný bod bol dokončený za 369 milisekúnd, segmenty WAL boli premenované. A doslova v 517, po 150 milisekúndách, sa začalo pretáčanie na starej replike. To znamená, že nám stačilo doslova 150 milisekúnd, aby sa replika nemohla pripojiť a zarobiť.
Aké sú možnosti?
Spočiatku sme používali replikačné sloty. Mysleli sme si, že je to dobré. Aj keď sme v prvej fáze prevádzky vypli sloty. Zdalo sa nám, že ak sa v slotoch nahromadí veľa segmentov WAL, môžeme zahodiť master. On padne. Nejaký čas sme trpeli bez slotov. A uvedomili sme si, že potrebujeme sloty, vrátili sme sloty.
Ale je tu problém, že keď master prejde na repliku, vymaže sloty a vymaže aj segmenty WAL spolu so slotmi. A aby sme tento problém odstránili, rozhodli sme sa zvýšiť parameter wal_keep_segments. Predvolene je to 8 segmentov. Zvýšili sme to na 1 000 a pozreli sme sa, koľko voľného miesta máme. A darovali sme 16 gigabajtov pre wal_keep_segments. To znamená, že pri prepínaní máme na všetkých uzloch vždy rezervu 16 gigabajtov transakčných logov.
A plus - je to stále relevantné pre úlohy dlhodobej údržby. Povedzme, že potrebujeme aktualizovať jednu z replík. A chceme to vypnúť. Potrebujeme aktualizovať softvér, možno operačný systém, niečo iné. A keď vypneme repliku, odstráni sa aj slot pre túto repliku. A ak použijeme malé wal_keep_segments, potom sa pri dlhej absencii repliky stratia protokoly transakcií. Vytvoríme repliku, vyžiada si tie transakčné protokoly, kde sa zastavila, ale nemusia byť na hlavnom serveri. A replika sa tiež nebude môcť pripojiť. Preto držíme veľké zásoby časopisov.
Máme výrobnú základňu. Už sú rozpracované projekty.
Bol tam pilčík. Vošli sme dnu a pozreli sme sa - všetko je v poriadku, repliky sú na svojom mieste, nedochádza k oneskoreniu replikácie. Chyby nie sú ani v protokoloch, všetko je v poriadku.
Produktový tím hovorí, že by tam mali byť nejaké údaje, ale vidíme ich z jedného zdroja, ale nevidíme ich v databáze. A musíme pochopiť, čo sa s nimi stalo.
Je jasné, že ich pg_rewind minul. Okamžite sme to pochopili, ale išli sme sa pozrieť, čo sa deje.
V protokoloch vždy nájdeme, kedy sa stalo, že sa to stalo, kto sa stal majstrom a vieme určiť, kto bol starý majster a kedy sa chcel stať replikou, t. j. tieto protokoly potrebujeme na zistenie množstva protokolov transakcií, ktoré bol stratený.
Náš starý majster sa reštartoval. A Patroni bol zaregistrovaný v autorune. Spustený Patroni. Potom založil Postgres. Presnejšie, pred spustením Postgresu a pred vytvorením jeho repliky spustil Patroni proces pg_rewind. V súlade s tým vymazal časť protokolov transakcií, stiahol nové a pripojil sa. Tu Patroni pracoval šikovne, teda podľa očakávania. Klaster bol obnovený. Mali sme 3 uzly, po fileru 3 uzly - vsetko v pohode.
Stratili sme niektoré údaje. A musíme pochopiť, koľko sme stratili. Hľadáme práve moment, kedy sme mali pretáčanie. Môžeme to nájsť v takýchto zápisoch do denníka. Pretáčanie začalo, niečo tam urobilo a skončilo.
Musíme nájsť pozíciu v protokole transakcií, kde starý majster skončil. V tomto prípade ide o značku. A potrebujeme druhú značku, teda vzdialenosť, ktorou sa starý majster líši od nového.
Zoberieme zvyčajný pg_wal_lsn_diff a porovnáme tieto dve značky. A v tomto prípade dostaneme 17 megabajtov. Veľa alebo málo, každý sa rozhodne sám za seba. Pretože pre niekoho 17 megabajtov nie je veľa, pre niekoho veľa a neprijateľné. Tu si každý určuje sám za seba v súlade s potrebami podnikania.
Čo sme však sami zistili?
Najprv sa musíme rozhodnúť sami - potrebujeme vždy, aby sa Patroni po reštarte systému automaticky spustil? Často sa stáva, že musíme ísť za starým pánom, pozrieť sa, ako ďaleko zašiel. Možno skontrolujte segmenty denníka transakcií a pozrite sa, čo tam je. A aby sme pochopili, či môžeme tieto dáta stratiť, alebo či musíme spustiť starú predlohu v samostatnom režime, aby sme mohli tieto dáta vytiahnuť.
A až potom sa musíme rozhodnúť, či môžeme tieto dáta zahodiť, alebo ich môžeme obnoviť, pripojiť tento uzol ako repliku do nášho klastra.
Okrem toho existuje parameter „maximum_lag_on_failover“. Štandardne, ak ma pamäť neklame, má tento parameter hodnotu 1 megabajt.
ako pracuje? Ak naša replika zaostáva o 1 megabajt dát v oneskorení replikácie, potom sa táto replika nezúčastňuje volieb. A ak zrazu dôjde k prekrytiu súboru, Patroni sa pozrie na to, ktoré repliky zaostávajú. Ak zaostávajú za veľkým počtom transakčných protokolov, nemôžu sa stať majstrom. Ide o veľmi dobrú bezpečnostnú funkciu, ktorá zabráni strate veľkého množstva údajov.
Je tu však problém v tom, že oneskorenie replikácie v klastri Patroni a DCS sa aktualizuje v určitom intervale. Myslím, že 30 sekúnd je predvolená hodnota ttl.
V súlade s tým môže nastať situácia, keď existuje jedno oneskorenie replikácie pre repliky v DCS, ale v skutočnosti môže existovať úplne iné oneskorenie alebo nemusí byť žiadne, t. j. táto vec nie je v reálnom čase. A nie vždy odráža skutočný obraz. A neoplatí sa na tom robiť prepychovú logiku.
A riziko straty vždy zostáva. A v horšom prípade jeden vzorec a v priemernom prípade druhý vzorec. To znamená, že keď plánujeme implementáciu Patroni a vyhodnocujeme, koľko údajov môžeme stratiť, musíme sa spoľahnúť na tieto vzorce a približne si predstaviť, koľko údajov môžeme stratiť.
A je tu dobrá správa. Keď starý majster pokračoval, môže pokračovať v dôsledku niektorých procesov na pozadí. To znamená, že došlo k nejakému autovákuu, napísal údaje, uložil ich do denníka transakcií. A tieto údaje môžeme ľahko ignorovať a stratiť. V tomto problém nie je.
A takto vyzerajú protokoly, ak je nastavené maximum_lag_on_failover a došlo k súboru a musíte vybrať nový hlavný server. Replika sa hodnotí ako nespôsobilá zúčastniť sa volieb. A odmieta sa zúčastniť pretekov o lídra. A čaká, kým sa vyberie nový pán, aby sa k nemu potom mohla pripojiť. Toto je dodatočné opatrenie proti strate údajov.
Tu máme produktový tím, ktorý napísal, že ich produkt má problémy s Postgresom. Zároveň nie je možné pristupovať k samotnému masteru, pretože nie je dostupný cez SSH. A automatický súbor sa tiež nestane.
Tento hostiteľ bol nútený reštartovať. Kvôli reštartu došlo k automatickému súboru, aj keď bolo možné urobiť manuálne automatické súbory, ako teraz chápem. A po reštarte sa už ideme pozrieť, čo sme mali so súčasným majstrom.
Zároveň sme vopred vedeli, že máme problémy s diskami, teda už z monitoringu sme vedeli, kde treba kopať a čo hľadať.
Dostali sme sa do denníka postgres, začali sme vidieť, čo sa tam deje. Videli sme záväzky, ktoré tam trvajú jednu, dve, tri sekundy, čo nie je vôbec normálne. Videli sme, že naše autovákuum sa spúšťa veľmi pomaly a zvláštne. A na disku sme videli dočasné súbory. To znamená, že toto všetko sú indikátory problémov s diskami.
Pozreli sme sa do systémového dmesg (záznam jadra). A videli sme, že máme problémy s jedným z diskov. Diskovým subsystémom bol softvérový Raid. Pozreli sme sa na /proc/mdstat a zistili sme, že nám chýba jeden disk. To znamená, že existuje Raid 8 diskov, jeden nám chýba. Ak sa pozorne pozriete na snímku, tak vo výstupe vidíte, že tam nemáme sde. U nás, podmienečne povedané, disk vypadol. To vyvolalo problémy s diskom a aplikácie mali problémy aj pri práci s klastrom Postgres.
A v tomto prípade by nám Patroni nijako nepomohlo, pretože Patroni nemá za úlohu monitorovať stav servera, stav disku. A takéto situácie musíme monitorovať externým monitorovaním. K externému monitorovaniu sme rýchlo pridali aj monitorovanie disku.
A bola taká myšlienka – mohol by nám pomôcť softvér na oplotenie alebo strážny pes? Mysleli sme si, že v tomto prípade by nám sotva pomohol, pretože počas problémov Patroni pokračoval v interakcii s klastrom DCS a nevidel žiadny problém. To znamená, že z pohľadu DCS a Patroni bolo s klastrom všetko v poriadku, aj keď v skutočnosti boli problémy s diskom, boli problémy s dostupnosťou databázy.
Podľa môjho názoru je to jeden z najzvláštnejších problémov, ktoré som veľmi dlho skúmal, prečítal som veľa protokolov, znova som to vybral a nazval som to klastrový simulátor.
Problém bol v tom, že zo starého majstra sa nemohla stať normálna replika, teda Patroni to spustil, Patroni ukázal, že tento uzol bol prítomný ako replika, ale zároveň to nebola normálna replika. Teraz uvidíte prečo. Toto som si zachoval z analýzy tohto problému.
A ako to celé začalo? Začalo to, ako pri predošlom probléme, kotúčovými brzdami. Mali sme záväzky na sekundu, dve.
Dochádzalo k prerušeniu spojenia, t.j. klienti boli trhaní.
Boli tam blokády rôznej závažnosti.
A preto diskový subsystém nie je veľmi citlivý.
A najzáhadnejšia vec je pre mňa žiadosť o okamžité vypnutie, ktorá prišla. Postgres má tri režimy vypnutia:
- Je pôvabné, keď čakáme, kým sa všetci klienti sami odpoja.
- Keď nútime klientov odpojiť sa, pretože sa chystáme vypnúť, je to rýchle.
- A okamžite. V tomto prípade okamžitá ani nehovorí klientom, aby sa vypli, iba sa bez varovania vypne. A všetkým klientom už operačný systém posiela RST správu (TCP správa, že spojenie je prerušené a klient už nemá čo zachytiť).
Kto vyslal tento signál? Procesy na pozadí Postgres si navzájom takéto signály neposielajú, t.j. toto je kill-9. Takéto veci si navzájom neposielajú, iba na takéto veci reagujú, čiže ide o núdzový reštart Postgresu. Kto to poslal, neviem.
Pozrel som sa na "posledný" príkaz a videl som jednu osobu, ktorá sa tiež prihlásila na tento server s nami, ale bol som príliš hanblivý na to, aby som položil otázku. Možno to bolo zabitie -9. V logoch by som videl kill -9, lebo Postgres hovorí, že to trvalo kill -9, ale v protokoloch som to nevidel.
Keď som sa pozrel ďalej, videl som, že Patroni nezapísal do denníka pomerne dlho - 54 sekúnd. A ak porovnáme dve časové pečiatky, asi 54 sekúnd neboli žiadne správy.
A počas tejto doby existoval automatický súbor. Patroni tu opäť odviedol skvelú prácu. Náš starý pán bol nedostupný, niečo sa mu stalo. A začala sa voľba nového majstra. Všetko tu dobre dopadlo. Náš pgsql01 sa stal novým lídrom.
Máme repliku, ktorá sa stala majstrom. A je tu druhá odpoveď. A s druhou replikou boli problémy. Pokúsila sa prekonfigurovať. Ako som pochopil, pokúsila sa zmeniť recovery.conf, reštartovať Postgres a pripojiť sa k novému masterovi. Každých 10 sekúnd píše správy, že sa snaží, no nedarí sa jej to.
A počas týchto pokusov prichádza k starému pánovi signál okamžitého vypnutia. Master sa reštartuje. A tiež sa obnova zastaví, pretože starý majster sa reštartuje. To znamená, že replika sa k nemu nemôže pripojiť, pretože je v režime vypnutia.
V určitom okamihu to fungovalo, ale replikácia sa nespustila.
Môj jediný odhad je, že v recovery.conf bola stará hlavná adresa. A keď sa objavil nový majster, druhá replika sa stále pokúšala pripojiť k starému majstrovi.
Keď sa Patroni spustil na druhej replike, uzol sa spustil, ale nemohol sa replikovať. A vytvorilo sa oneskorenie replikácie, ktoré vyzeralo asi takto. To znamená, že všetky tri uzly boli na svojom mieste, ale druhý uzol zaostával.
Zároveň, ak sa pozriete na zapísané protokoly, môžete vidieť, že replikácia sa nemohla spustiť, pretože protokoly transakcií boli odlišné. A tie transakčné protokoly, ktoré master ponúka a ktoré sú špecifikované v recovery.conf, jednoducho nezodpovedajú nášmu aktuálnemu uzlu.
A tu som urobil chybu. Musel som sa prísť pozrieť, čo je v recovery.conf, aby som otestoval svoju hypotézu, že sa pripájame k nesprávnemu pánovi. Ale potom som sa tým len zaoberal a nenapadlo mi to, alebo som videl, že replika zaostáva a bude ju treba doplniť, čiže som nejako neopatrne pracoval. Toto bol môj joint.
Po 30 minútach už prišiel admin, t.j. reštartoval som Patroni na replike. Už som tomu dal koniec, myslel som, že to bude treba doplniť. A pomyslel som si – reštartujem Patroniho, možno z toho niečo dobré bude. Obnova sa začala. A základňa sa dokonca otvorila, bola pripravená prijímať spojenia.
Replikácia sa začala. Ale o minútu neskôr spadla s chybou, že protokoly transakcií nie sú pre ňu vhodné.
Myslel som, že sa znova spustím. Znovu som reštartoval Patroni a nereštartoval som Postgres, ale reštartoval som Patroni v nádeji, že magicky spustí databázu.
Replikácia sa začala znova, ale značky v protokole transakcií boli iné, neboli rovnaké ako pri predchádzajúcom pokuse o spustenie. Replikácia sa opäť zastavila. A posolstvo už bolo trochu iné. A nebolo to pre mňa veľmi informatívne.
A potom ma napadne - čo ak reštartujem Postgres, v tomto čase urobím kontrolný bod na aktuálnom masteri, aby som posunul bod v transakčnom protokole trochu dopredu, aby sa obnova začala od iného okamihu? Navyše sme stále mali zásoby WAL.
Reštartoval som Patroni, urobil som pár kontrolných bodov na masteri, pár bodov reštartu na replike, keď sa otvorila. A pomohlo to. Dlho som rozmýšľal, prečo to pomohlo a ako to funguje. A replika začala. A replikácia už nebola roztrhaná.
Takýto problém je pre mňa jeden z tých záhadnejších, nad ktorým si dodnes lámem hlavu nad tým, čo sa tam vlastne stalo.
Aké sú tu dôsledky? Patroni môže fungovať podľa plánu a bez akýchkoľvek chýb. Ale zároveň to nie je 100% záruka, že je u nás všetko v poriadku. Replika sa môže spustiť, ale môže byť v poloprevádzkovom stave a aplikácia s takouto replikou nemôže pracovať, pretože tam budú staré dáta.
A po súbore musíte vždy skontrolovať, či je všetko v poriadku s klastrom, to znamená, že existuje požadovaný počet replík, nedochádza k oneskoreniu replikácie.
A keď si prejdeme tieto problémy, dám vám odporúčania. Skúsil som ich spojiť do dvoch snímok. Pravdepodobne by sa všetky príbehy dali spojiť do dvoch snímok a iba rozprávať.
Keď používate Patroni, musíte mať monitorovanie. Vždy by ste mali vedieť, kedy došlo k automatickému prekrývaniu súborov, pretože ak neviete, že ste mali automatické prepínanie súborov, nemáte nad klastrom žiadnu kontrolu. A to je zle.
Po každom filerovi musíme vždy manuálne skontrolovať klaster. Musíme sa uistiť, že máme vždy aktuálny počet replík, nedochádza k oneskoreniu replikácie, v protokoloch sa nevyskytujú žiadne chyby súvisiace so streamingovou replikáciou, s Patroni, so systémom DCS.
Automatizácia môže úspešne fungovať, Patroni je veľmi dobrý nástroj. Môže to fungovať, ale klaster to neprivedie do požadovaného stavu. A ak sa o tom nedozvieme, budeme mať problémy.
A Patroni nie je strieborná guľka. Stále musíme pochopiť, ako funguje Postgres, ako funguje replikácia a ako Patroni spolupracuje s Postgres a ako je zabezpečená komunikácia medzi uzlami. Je to potrebné, aby ste mohli vyriešiť problémy s rukami.
Ako pristupujem k otázke diagnostiky? Stalo sa, že pracujeme s rôznymi klientmi a nikto nemá zásobník ELK, a preto musíme protokoly triediť otvorením 6 konzol a 2 kariet. Na jednej karte sú to protokoly Patroni pre každý uzol, na druhej karte sú to protokoly Consul, alebo v prípade potreby Postgres. Je veľmi ťažké to diagnostikovať.
Aké prístupy som zvolil? Po prvé, vždy sa pozriem, kedy príde pilník. A toto je pre mňa zlom. Pozerám, čo sa dialo pred pilníkom, počas pilníka a po pilníku. Fileover má dve značky: toto je čas začiatku a konca.
Ďalej hľadám v protokoloch udalosti pred filerom, ktoré predchádzali fileru, t.j. hľadám dôvody, prečo k fileru došlo.
A to dáva obraz o pochopení toho, čo sa stalo a čo možno v budúcnosti urobiť, aby k takýmto okolnostiam nedochádzalo (a v dôsledku toho neexistuje žiadny súbor).
A kam sa zvyčajne pozeráme? Pozerám sa:
- Najprv k protokolom Patroni.
- Ďalej sa pozriem na denníky Postgres alebo denníky DCS v závislosti od toho, čo sa našlo v denníkoch Patroni.
- A systémové protokoly tiež niekedy poskytujú pochopenie toho, čo spôsobilo súbor.
Ako vnímam Patroniho? S Patronim mám veľmi dobrý vzťah. Podľa mňa je to to najlepšie, čo dnes existuje. Poznám veľa iných produktov. Sú to Stolon, Repmgr, Pg_auto_failover, PAF. 4 nástroje. Vyskúšal som ich všetky. Patroni je môj obľúbený.
Ak sa ma spýtajú: „Odporúčam Patroni?“. Poviem áno, pretože mám Patroniho rád. A myslím, že som sa to naučil variť.
Ak máte záujem vidieť, aké sú ďalšie problémy s Patroni okrem problémov, ktoré som spomenul, vždy sa môžete pozrieť na stránku na GitHub. Existuje veľa rôznych príbehov a diskutuje sa o mnohých zaujímavých problémoch. A v dôsledku toho boli zavedené a vyriešené niektoré chyby, to znamená, že ide o zaujímavé čítanie.
Existuje niekoľko zaujímavých príbehov o ľuďoch, ktorí si strieľajú do nohy. Veľmi informatívne. Čítate a rozumiete, že to nie je potrebné. Zaškrtol som si.
A rád by som veľmi pekne poďakoval Zalandovi za rozvoj tohto projektu, menovite Alexandrovi Kukushkinovi a Alexejovi Klyukinovi. Aleksey Klyukin je jedným zo spoluautorov, v Zalande už nepracuje, no sú to dvaja ľudia, ktorí s týmto produktom začali pracovať.
A myslím si, že Patroni je veľmi skvelá vec. Som šťastný, že existuje, je to s ňou zaujímavé. A veľké ďakujem všetkým prispievateľom, ktorí píšu patche do Patroni. Dúfam, že Patroni bude s vekom zrelší, chladnejší a výkonnejší. Už je funkčný, ale dúfam, že sa to ešte zlepší. Preto, ak plánujete používať Patroni, potom sa nebojte. Toto je dobré riešenie, dá sa implementovať a použiť.
To je všetko. Ak máte otázky, pýtajte sa.
otázky
Ďakujeme za správu! Ak sa po zakladači stále potrebujete veľmi pozorne pozerať, prečo potom potrebujeme automatický zakladač?
Pretože sú to nové veci. Sme s ňou len rok. Je lepšie byť v bezpečí. Chceme prísť a vidieť, že všetko naozaj funguje tak, ako má. Toto je úroveň nedôvery dospelých - je lepšie skontrolovať a vidieť.
Napríklad sme išli ráno a pozreli, nie?
Ráno nie, väčšinou sa o autofile dozvieme takmer okamžite. Dostávame upozornenia, vidíme, že došlo k automatickému súboru. Takmer okamžite sa ideme pozrieť. Všetky tieto kontroly by sa však mali dostať na úroveň monitorovania. Ak pristupujete k Patroni cez REST API, existuje história. Podľa histórie môžete vidieť časové pečiatky, kedy došlo k súboru. Na základe toho je možné vykonávať monitorovanie. Môžete vidieť históriu, koľko udalostí tam bolo. Ak máme viac udalostí, došlo k automatickému súboru. Môžete sa ísť pozrieť. Alebo naša monitorovacia automatika skontrolovala, či máme všetky repliky na svojom mieste, nedochádza k oneskoreniu a všetko je v poriadku.
Ďakujeme!
Ďakujem pekne za skvelý príbeh! Ak sme presunuli klaster DCS niekam ďaleko od klastra Postgres, potom je potrebné pravidelne servisovať aj tento klaster? Aké sú osvedčené postupy, že niektoré časti klastra DCS je potrebné vypnúť, niečo s nimi urobiť atď.? Ako celá táto štruktúra prežije? A ako robíte tieto veci?
Pre jednu spoločnosť bolo potrebné urobiť maticu problémov, čo sa stane, ak zlyhá jedna z komponentov alebo viacero komponentov. Podľa tejto matice postupne prechádzame všetky komponenty a zostavujeme scenáre v prípade zlyhania týchto komponentov. V súlade s tým môžete mať pre každý scenár zlyhania akčný plán obnovy. A v prípade DCS prichádza ako súčasť štandardnej infraštruktúry. A admin to spravuje a už sa spoliehame na adminov, ktorí to spravujú a ich schopnosť opraviť to v prípade nehôd. Ak DCS vôbec neexistuje, tak ho nasadíme, no zároveň ho nijak zvlášť nemonitorujeme, pretože nezodpovedáme za infraštruktúru, ale dávame odporúčania, ako a čo monitorovať.
To znamená, pochopil som správne, že musím deaktivovať Patroni, deaktivovať filer, deaktivovať všetko predtým, ako urobím čokoľvek s hostiteľmi?
Závisí to od toho, koľko uzlov máme v klastri DCS. Ak existuje veľa uzlov a ak zakážeme iba jeden z uzlov (repliku), klaster si zachováva kvórum. A Patroni zostáva v prevádzke. A nič sa nespustí. Ak máme nejaké zložité operácie, ktoré ovplyvňujú viac uzlov, ktorých absencia môže zničiť kvórum, potom – áno, môže mať zmysel dať Patroni pauzu. Má zodpovedajúci príkaz - patronictl pause, patronictl resumé. Len sa pozastavíme a automatický filter v tom čase nefunguje. Vykonávame údržbu klastra DCS, potom prerušíme pauzu a pokračujeme v živote.
Ďakujem moc!
Ďakujeme veľmi pekne za vašu správu! Ako vníma produktový tím stratu údajov?
Produktovým tímom je to jedno a vedúci tímov majú obavy.
Aké sú záruky?
Záruky sú veľmi ťažké. Alexander Kukushkin má správu „Ako vypočítať RPO a RTO“, t. j. čas obnovy a koľko údajov môžeme stratiť. Myslím, že musíme nájsť tieto snímky a preštudovať si ich. Pokiaľ si pamätám, existujú konkrétne kroky, ako tieto veci vypočítať. Koľko transakcií môžeme stratiť, koľko dát môžeme stratiť. Ako možnosť môžeme použiť synchrónnu replikáciu na úrovni Patroni, ale toto je dvojsečná zbraň: buď máme spoľahlivosť údajov, alebo strácame rýchlosť. Existuje synchrónna replikácia, ktorá však tiež nezaručuje 100% ochranu pred stratou údajov.
Alexey, ďakujem za skvelú správu! Máte skúsenosti s používaním Patroni na nulovú úroveň ochrany? Teda v spojení so synchrónnym pohotovostným režimom? Toto je prvá otázka. A druhá otázka. Použili ste rôzne riešenia. Použili sme Repmgr, ale bez automatického filtra, a teraz plánujeme zahrnúť automatický filter. A Patroni považujeme za alternatívne riešenie. Čo môžete povedať ako výhody v porovnaní s Repmgr?
Prvá otázka sa týkala synchrónnych replík. Nikto tu nepoužíva synchrónnu replikáciu, pretože sa všetci bojí (viacerí klienti ju už používajú, v zásade si nevšimli problémy s výkonom - Poznámka rečníka). Ale vyvinuli sme pre seba pravidlo, že v synchrónnom replikačnom klastri by mali byť aspoň tri uzly, pretože ak máme dva uzly a ak zlyhá master alebo replika, tak Patroni prepne tento uzol do Standalone režimu, aby aplikácia pokračovala v práca. V tomto prípade existuje riziko straty údajov.
Čo sa týka druhej otázky, Repmgr sme používali a stále používame s niektorými klientmi z historických dôvodov. Čo sa dá povedať? Patroni je dodávaný s automatickým filtrom po vybalení, Repmgr prichádza s automatickým filtrom ako ďalšou funkciou, ktorú je potrebné povoliť. Musíme spustiť démona Repmgr na každom uzle a potom môžeme nakonfigurovať autofiler.
Repmgr kontroluje, či sú uzly Postgres živé. Procesy Repmgr kontrolujú svoju existenciu, nie je to veľmi efektívny prístup. môžu nastať zložité prípady izolácie siete, v ktorých sa veľký klaster Repmgr môže rozpadnúť na niekoľko menších a pokračovať v práci. Repmgr nesledujem už dlho, možno sa to vyriešilo ... alebo možno nie. Ale odstránenie informácií o stave klastra v DCS, ako to robí Stolon, Patroni, je najschodnejšou možnosťou.
Alexey, mám otázku, možno slabšiu. V jednom z prvých príkladov ste presunuli DCS z lokálneho počítača na vzdialený hostiteľ. Chápeme, že sieť je vec, ktorá má svoje vlastné charakteristiky, žije sama o sebe. A čo sa stane, ak z nejakého dôvodu nebude klaster DCS dostupný? Dôvody nepoviem, môže ich byť veľa: od pokrivených rúk networkerov až po skutočné problémy.
Nepovedal som to nahlas, ale klaster DCS musí byť aj failover, teda je to nepárny počet uzlov, aby bolo splnené kvórum. Čo sa stane, ak sa klaster DCS stane nedostupným alebo nebude možné splniť kvórum, t. j. nejaké rozdelenie siete alebo zlyhanie uzla? V tomto prípade sa klaster Patroni prepne do režimu len na čítanie. Klaster Patroni nedokáže určiť stav klastra a čo robiť. Nemôže kontaktovať DCS a uložiť tam nový stav klastra, takže celý klaster prejde len na čítanie. A čaká buď na manuálny zásah operátora, alebo na obnovenie DCS.
Zhruba povedané, DCS sa pre nás stáva rovnako dôležitou službou ako samotná základňa?
Áno áno. V toľkých moderných spoločnostiach je Service Discovery neoddeliteľnou súčasťou infraštruktúry. Implementuje sa ešte predtým, ako v infraštruktúre vôbec existovala databáza. Relatívne povedané, infraštruktúra bola spustená, nasadená v DC a hneď máme Service Discovery. Ak je to Consul, potom na ňom môže byť postavený DNS. Ak je toto Etcd, potom môže existovať časť z klastra Kubernetes, v ktorej bude nasadené všetko ostatné. Zdá sa mi, že vyhľadávanie služieb je už neoddeliteľnou súčasťou moderných infraštruktúr. A myslia na to oveľa skôr ako na databázy.
Ďakujeme!
Zdroj: hab.com