Hlavním cílem Patroni je poskytovat vysokou dostupnost pro PostgreSQL. Patroni je ale jen šablona, nikoli hotový nástroj (což je obecně řečeno v dokumentaci). Na první pohled, po nastavení Patroni v testovací laboratoři, můžete vidět, jak skvělý nástroj to je a jak snadno si poradí s našimi pokusy o rozbití clusteru. V praxi se však v produkčním prostředí neděje vždy vše tak krásně a elegantně jako v testovací laboratoři.
Řeknu vám něco málo o sobě. Začínal jsem jako správce systému. Pracoval ve vývoji webu. Ve společnosti Data Egret pracuji od roku 2014. Společnost se zabývá poradenstvím v oblasti Postgres. A my obsluhujeme přesně Postgres a pracujeme s Postgresem každý den, takže máme různé odborné znalosti související s provozem.
A koncem roku 2018 jsme začali pomalu používat Patroni. A nasbíraly se nějaké zkušenosti. Nějak jsme to diagnostikovali, vyladili, došli k našim osvědčeným postupům. A v této zprávě o nich budu mluvit.
Kromě Postgresu miluji Linux. Rád se v tom hrabu a zkoumám, rád sbírám jádra. Miluji virtualizaci, kontejnery, docker, Kubernetes. To vše mě zajímá, protože to ovlivňují staré zvyky správce. Rád se zabývám monitoringem. A miluji postgresové věci spojené s administrací, tedy replikace, zálohování. A ve volném čase píšu do Go. Nejsem softwarový inženýr, v Go píšu jen pro sebe. A to mi dělá radost.
- Myslím, že mnoho z vás ví, že Postgres nemá HA (High Availability) po vybalení. Chcete-li získat HA, musíte něco nainstalovat, nakonfigurovat, vynaložit úsilí a získat to.
- Existuje několik nástrojů a Patroni je jedním z nich, který řeší HA docela v pohodě a velmi dobře. Ale tím, že to všechno dáme do testovací laboratoře a spustíme, můžeme vidět, že to všechno funguje, můžeme reprodukovat některé problémy, uvidíme, jak jim Patroni slouží. A uvidíme, že to všechno bude skvěle fungovat.
- V praxi jsme ale čelili jiným problémům. A o těchto problémech budu mluvit.
- Řeknu vám, jak jsme to diagnostikovali, co jsme vyladili - jestli nám to pomohlo nebo ne.
- Neřeknu vám, jak nainstalovat Patroni, protože můžete googlovat na internetu, můžete se podívat na konfigurační soubory, abyste pochopili, jak to všechno začíná, jak se to nastavuje. Můžete porozumět schématům, architektuře, najít informace o tom na internetu.
- Nebudu mluvit o zkušenosti někoho jiného. Budu mluvit pouze o problémech, kterým jsme čelili.
- A to nebudu mluvit o problémech, které jsou mimo Patroni a PostgreSQL. Pokud jsou například problémy spojené s balancováním, když se nám zhroutil cluster, nebudu o tom mluvit.
A malé vyloučení odpovědnosti, než začneme s naší zprávou.
Všechny tyto problémy, se kterými jsme se setkali, jsme měli v prvních 6-7-8 měsících provozu. Postupem času jsme dospěli k našim interním osvědčeným postupům. A naše problémy zmizely. Proto byla zpráva oznámena asi před šesti měsíci, kdy jsem to všechno měl čerstvé v hlavě a dokonale jsem si to všechno pamatoval.
V průběhu přípravy zprávy jsem již zvedl staré posmrtné nálezy, podíval se do protokolů. A některé detaily mohly být zapomenuty nebo některé detaily nemohly být během analýzy problémů plně prozkoumány, takže se v některých bodech může zdát, že problémy nejsou plně zohledněny, nebo je nedostatek informací. A tak vás žádám, abyste mě na tuto chvíli omluvili.
Co je Patroni?
- Toto je šablona pro budování HA. Tak se to píše v dokumentaci. A z mého pohledu je to velmi správné upřesnění. Patroni není stříbrná kulka, která vyřeší všechny vaše problémy, to znamená, že se musíte snažit, aby to fungovalo a přinášelo výhody.
- Toto je služba agenta, která je nainstalována na každé databázové službě a je jakýmsi iniciačním systémem pro váš Postgres. Spustí Postgres, zastaví, restartuje, překonfiguruje a změní topologii vašeho clusteru.
- Proto, aby se uložil stav clusteru, jeho aktuální reprezentace, jak to vypadá, je potřeba nějaký druh úložiště. A z tohoto pohledu se Patroni vydal cestou ukládání stavu do externího systému. Jedná se o distribuovaný systém ukládání konfigurace. Může to být Etcd, Consul, ZooKeeper nebo kubernetes Etcd, tedy jedna z těchto možností.
- A jednou z funkcí Patroni je, že autofiler dostanete z krabice pouze jeho nastavením. Pokud vezmeme pro srovnání Repmgr, pak je tam obsažen i filer. S Repmgr získáme přepnutí, ale pokud chceme autofiler, musíme ho nakonfigurovat dodatečně. Patroni již má automatický filtr z krabice.
- A je tu spousta dalších věcí. Například údržba konfigurací, nalévání nových replik, zálohování atd. Ale to je nad rámec zprávy, o tom nebudu mluvit.
A malým výsledkem je, že hlavním úkolem Patroni je dělat autofile dobře a spolehlivě, aby náš cluster zůstal funkční a aplikace nezaznamenala změny v topologii clusteru.
Ale když začneme používat Patroni, náš systém se trochu zkomplikuje. Pokud jsme dříve měli Postgres, pak při použití Patroni dostaneme samotné Patroni, dostaneme DCS, kde je uložen stav. A všechno to musí nějak fungovat. Co se tedy může pokazit?
Může se zlomit:
- Postgres se může zlomit. Může to být předloha nebo replika, jeden z nich může selhat.
- Patroni se může rozbít.
- DCS, kde je uložen stav, se může přerušit.
- A síť se může přerušit.
Všechny tyto body ve zprávě zvážím.
Případy budu zvažovat, až budou složitější, nikoli z toho hlediska, že případ zahrnuje mnoho složek. A z hlediska subjektivních pocitů, že tento obal byl pro mě náročný, bylo těžké ho rozebrat ... a naopak některé pouzdro bylo lehké a bylo snadné ho rozebrat.
A první případ je nejjednodušší. To je případ, kdy jsme vzali databázový cluster a nasadili naše úložiště DCS do stejného clusteru. Toto je nejčastější chyba. To je chyba při budování architektur, tedy kombinování různých komponent na jednom místě.
Takže tam byl pilník, pojďme se vypořádat s tím, co se stalo.
A tady nás zajímá, kdy k pilníku došlo. To znamená, že nás zajímá tento okamžik v čase, kdy se změnil stav clusteru.
Ale filtr není vždy okamžitý, to znamená, že nezabere žádnou jednotku času, může být zpožděn. Může být dlouhotrvající.
Proto má čas začátku a čas konce, tj. je to nepřetržitá událost. A všechny události rozdělíme do tří intervalů: máme čas před pilníkem, během pilníku a po pilníku. To znamená, že bereme v úvahu všechny události v této časové ose.
A první věc, když se stal pilník, hledáme příčinu toho, co se stalo, co bylo příčinou toho, co vedlo k pilníku.
Když se podíváme na logy, budou to klasické logy Patroni. Říká nám v nich, že server se stal masterem a role master přešla na tento uzel. Zde je to zvýrazněno.
Dále musíme porozumět tomu, proč k souboru došlo, tj. jaké události se staly, které způsobily přesun hlavní role z jednoho uzlu do druhého. A v tomto případě je vše jednoduché. Došlo k chybě při interakci s úložným systémem. Mistr si uvědomil, že nemůže pracovat s DCS, to znamená, že existuje nějaký problém s interakcí. A říká, že už nemůže být mistrem a rezignuje. Tento řádek „degradovaný sebe“ říká přesně to.
Podíváme-li se na události, které fileru předcházely, můžeme tam vidět právě důvody, které byly problémem pro pokračování průvodce.
Když se podíváme na protokoly Patroni, uvidíme, že máme spoustu chyb, timeoutů, tj. agent Patroni nemůže pracovat s DCS. V tomto případě se jedná o agenta Consul, který komunikuje na portu 8500.
A problém je v tom, že Patroni a databáze běží na stejném hostiteli. A servery Consul byly spuštěny na stejném uzlu. Vytvořením zátěže na serveru jsme způsobili problémy i serverům Consul. Nedokázali správně komunikovat.
Po nějaké době, když zátěž opadla, náš Patroni byl opět schopen komunikovat s agenty. Obnovena normální práce. A stejný server Pgdb-2 se stal znovu hlavním. To znamená, že došlo k malému převrácení, kvůli kterému uzel rezignoval na pravomoci mistra a poté je znovu převzal, to znamená, že se vše vrátilo tak, jak bylo.
A to může být považováno za falešný poplach, nebo to může být považováno za to, že Patroni udělal všechno správně. To znamená, že si uvědomil, že nemůže udržet stav shluku a odebral svou autoritu.
A zde nastal problém kvůli skutečnosti, že servery Consul jsou na stejném hardwaru jako základny. V souladu s tím jakékoli zatížení: ať už se jedná o zatížení disků nebo procesorů, ovlivňuje také interakci s clusterem Consul.
A rozhodli jsme se, že by to nemělo žít společně, vyčlenili jsme samostatný cluster pro konzula. A Patroni už pracoval se samostatným konzulem, to znamená, že existoval samostatný klastr Postgres, samostatný konzulát. To je základní návod, jak všechny tyto věci nosit a uchovávat, aby to nežilo pohromadě.
Volitelně můžete zkroutit parametry ttl, loop_wait, retry_timeout, tj. pokusit se přežít tyto krátkodobé špičky zatížení zvýšením těchto parametrů. Ale to není nejvhodnější možnost, protože toto zatížení může být dlouhé. A tyto hranice těchto parametrů prostě překročíme. A to možná opravdu nepomůže.
První problém, jak víte, je jednoduchý. Vzali jsme a dali DCS dohromady se základnou, máme problém.
Druhý problém je podobný prvnímu. Je to podobné v tom, že máme opět problémy s interoperabilitou se systémem DCS.
Pokud se podíváme do logů, uvidíme, že máme opět chybu v komunikaci. A Patroni říká, že nemohu komunikovat s DCS, takže aktuální master přejde do režimu repliky.
Ze starého mistra se stává replika, zde Patroni vychází, jak má být. Spustí pg_rewind, aby přetočil transakční protokol a poté se připojil k novému masteru, aby dohnal nového mastera. Tady Patroni funguje, jak má.
Zde musíme najít místo, které předcházelo fileru, tedy ty chyby, které způsobily, že máme filer. A v tomto ohledu se s protokoly Patroni docela pohodlně pracuje. V určitém intervalu píše stejné zprávy. A pokud začneme rychle procházet tyto protokoly, pak z protokolů uvidíme, že se protokoly změnily, což znamená, že začaly nějaké problémy. Rychle se vracíme na toto místo, uvidíme, co se stane.
A v normální situaci vypadají protokoly asi takto. Majitel zámku je kontrolován. A pokud se například změnil vlastník, pak mohou nastat nějaké události, na které musí Patroni reagovat. Ale v tomto případě jsme v pohodě. Hledáme místo, kde chyby začaly.
A když jsme přešli k bodu, kde se začaly objevovat chyby, vidíme, že jsme měli automatické překrytí. A protože naše chyby souvisely s interakcí s DCS a v našem případě jsme použili Consul, podíváme se také do Consul logs, co se tam stalo.
Při hrubém srovnání času filer a času v Consul logs vidíme, že naši sousedé v Consul clusteru začali pochybovat o existenci dalších členů Consul clusteru.
A když se podíváte i na logy dalších agentů Consul, můžete také vidět, že tam probíhá jakýsi kolaps sítě. A všichni členové skupiny konzulů pochybují o své existenci. A to byl impuls pro pilčíka.
Když se podíváte na to, co se stalo před těmito chybami, můžete vidět, že existují různé druhy chyb, například termín, RPC spadl, to znamená, že je zjevně nějaký problém ve vzájemné interakci členů clusteru Consul. .
Nejjednodušší odpovědí je opravit síť. Ale pro mě, když stojím na pódiu, se to říká snadno. Ale okolnosti jsou takové, že ne vždy si zákazník může dovolit opravit síť. Může žít v DC a nemusí být schopen opravit síť, ovlivnit zařízení. A tak jsou potřeba nějaké další možnosti.
Existují možnosti:
- Nejjednodušší možností, která je podle mého názoru napsána i v dokumentaci, je zakázat Consul checks, tedy jednoduše předat prázdné pole. A říkáme agentovi konzula, aby nepoužíval žádné šeky. Pomocí těchto kontrol můžeme ignorovat tyto síťové bouře a neiniciovat soubor.
- Další možností je dvojitá kontrola raft_multiplier. Toto je parametr samotného serveru Consul. Ve výchozím nastavení je nastavena na 5. Tato hodnota je doporučena v dokumentaci pro pracovní prostředí. Ve skutečnosti to ovlivňuje frekvenci zasílání zpráv mezi členy sítě konzulů. Ve skutečnosti tento parametr ovlivňuje rychlost servisní komunikace mezi členy clusteru Consul. A pro produkci se již doporučuje snížit, aby si uzly vyměňovaly zprávy častěji.
- Další možností, se kterou jsme přišli, je zvýšení priority procesů Consul mezi ostatními procesy pro plánovač procesů operačního systému. Existuje takový „hezký“ parametr, který jen určuje prioritu procesů, kterou bere v úvahu plánovač OS při plánování. Snížili jsme také pěknou hodnotu pro agenty Consul, tzn. zvýšila prioritu, takže operační systém dává procesům Consul více času na práci a spuštění jejich kódu. V našem případě to náš problém vyřešilo.
- Další možností je nepoužít Consul. Mám kamaráda, který je velkým zastáncem Etcd. A pravidelně se s ním dohadujeme, co je lepší Etcd nebo Consul. Ale pokud jde o to, co je lepší, obvykle s ním souhlasíme, že Consul má agenta, který by měl běžet na každém uzlu s databází. To znamená, že interakce Patroni se skupinou konzulů prochází tímto agentem. A tento agent se stává úzkým hrdlem. Pokud se agentovi něco stane, Patroni již nemůže pracovat s clusterem Consul. A to je ten problém. V plánu Etcd není žádný agent. Patroni může pracovat přímo se seznamem Etcd serverů a již s nimi komunikovat. V tomto ohledu, pokud používáte Etcd ve vaší společnosti, pak Etcd bude pravděpodobně lepší volbou než Consul. My u našich zákazníků jsme ale vždy limitováni tím, co si klient vybral a používá. A pro všechny klienty máme z velké části Consul.
- A posledním bodem je revize hodnot parametrů. Tyto parametry můžeme zvýšit v naději, že naše krátkodobé problémy se sítí budou krátké a nebudou mimo rozsah těchto parametrů. Tímto způsobem můžeme snížit agresivitu Patroni na autofile, pokud se vyskytnou nějaké problémy se sítí.
Myslím, že mnozí, kteří používají Patroni, jsou s tímto příkazem obeznámeni.
Tento příkaz zobrazuje aktuální stav clusteru. A na první pohled se tento obrázek může zdát normální. Máme předlohu, máme repliku, nedochází k žádnému zpoždění replikace. Ale tento obrázek je normální, dokud nebudeme vědět, že tento shluk by měl mít tři uzly, ne dva.
V souladu s tím došlo k automatickému souboru. A po tomto autofile naše replika zmizela. Musíme zjistit, proč zmizela a přivést ji zpět, obnovit ji. A znovu jdeme do protokolů a uvidíme, proč jsme měli automatické překrývání souborů.
V tomto případě se hlavní stala druhá replika. Tady je vše v pořádku.
A musíme se podívat na repliku, která spadla a která není v clusteru. Otevřeme protokoly Patroni a vidíme, že jsme měli problém během procesu připojování ke clusteru ve fázi pg_rewind. Chcete-li se připojit ke clusteru, musíte převinout transakční protokol, vyžádat si požadovaný transakční protokol od hlavního serveru a použít jej k dohnání hlavního serveru.
V tomto případě nemáme protokol transakcí a repliku nelze spustit. V souladu s tím zastavíme Postgres s chybou. A proto není v clusteru.
Musíme pochopit, proč není v clusteru a proč tam nebyly žádné protokoly. Jdeme k novému pánovi a podíváme se, co má v protokolech. Ukázalo se, že když bylo provedeno pg_rewind, došlo ke kontrolnímu bodu. A některé staré protokoly transakcí byly jednoduše přejmenovány. Když se starý master pokusil připojit k novému masteru a dotazoval se na tyto protokoly, byly již přejmenovány, prostě neexistovaly.
Porovnal jsem časová razítka, kdy se tyto události staly. A tam je rozdíl doslova 150 milisekund, to znamená, že kontrolní bod byl dokončen za 369 milisekund, segmenty WAL byly přejmenovány. A doslova v 517, po 150 milisekundách, začalo převíjení na staré replice. To znamená, že nám stačilo doslova 150 milisekund, aby se replika nemohla připojit a vydělat.
Jaké jsou možnosti?
Zpočátku jsme používali replikační sloty. Mysleli jsme si, že je to dobré. I když v první fázi provozu jsme sloty vypnuli. Zdálo se nám, že když se ve slotech nahromadí hodně segmentů WAL, můžeme master zahodit. On spadne. Nějakou dobu jsme trpěli bez slotů. A uvědomili jsme si, že potřebujeme sloty, vrátili jsme sloty.
Zde je ale problém, že když master přejde na repliku, vymaže sloty a vymaže segmenty WAL spolu se sloty. A abychom tento problém odstranili, rozhodli jsme se zvýšit parametr wal_keep_segments. Výchozí hodnota je 8 segmentů. Zvýšili jsme to na 1 000 a podívali jsme se, kolik volného místa máme. A darovali jsme 16 gigabajtů pro wal_keep_segments. To znamená, že při přepínání máme na všech uzlech vždy rezervu 16 gigabajtů transakčních logů.
A navíc - je stále relevantní pro úkoly dlouhodobé údržby. Řekněme, že potřebujeme aktualizovat jednu z replik. A my to chceme vypnout. Musíme aktualizovat software, možná operační systém, něco jiného. A když vypneme repliku, slot pro tuto repliku je také odstraněn. A pokud použijeme malý wal_keep_segments, pak při dlouhé absenci repliky se transakční protokoly ztratí. Vytvoříme repliku, bude vyžadovat ty transakční protokoly, kde se zastavila, ale nemusí být na hlavním serveru. A replika se také nebude moci připojit. Proto držíme velké zásoby časopisů.
Máme výrobní základnu. Již jsou rozpracované projekty.
Byl tam pilník. Šli jsme dovnitř a podívali jsme se - vše je v pořádku, repliky jsou na svém místě, nedochází k žádnému zpoždění replikace. Chyby nejsou ani v logech, vše je v pořádku.
Produktový tým říká, že by tam měla být nějaká data, ale vidíme je z jednoho zdroje, ale nevidíme je v databázi. A musíme pochopit, co se s nimi stalo.
Je jasné, že je pg_rewind minul. Okamžitě jsme to pochopili, ale šli jsme se podívat, co se děje.
V protokolech vždy najdeme, kdy se filer stal, kdo se stal mistrem a můžeme určit, kdo byl starý mistr a kdy se chtěl stát replikou, tj. tyto protokoly potřebujeme, abychom zjistili množství protokolů transakcí, které byl ztracen.
Náš starý mistr se restartoval. A Patroni byl zaregistrován v autorunu. Spuštěno Patroni. Poté založil Postgres. Přesněji řečeno, před spuštěním Postgresu a před vytvořením jeho repliky spustil Patroni proces pg_rewind. V souladu s tím vymazal část protokolů transakcí, stáhl nové a připojil se. Zde Patroni pracoval chytře, tedy podle očekávání. Cluster byl obnoven. Měli jsme 3 uzly, po fileru 3 uzly - vše v pohodě.
Ztratili jsme některá data. A musíme pochopit, kolik jsme ztratili. Hledáme právě ten okamžik, kdy jsme měli přetočení. Můžeme to najít v takových záznamech v deníku. Rewind začal, tam něco udělal a skončil.
Musíme najít pozici v transakčním protokolu, kde starý mistr skončil. V tomto případě se jedná o značku. A potřebujeme druhou značku, tedy vzdálenost, o kterou se starý mistr liší od nového.
Vezmeme obvyklý pg_wal_lsn_diff a porovnáme tyto dvě značky. A v tomto případě dostaneme 17 megabajtů. Hodně nebo málo, každý se rozhodne sám za sebe. Protože pro někoho je 17 mega málo, pro někoho hodně a nepřijatelné. Zde si každý určuje sám v souladu s potřebami podnikání.
Ale co jsme sami zjistili?
Nejprve se musíme rozhodnout sami - potřebujeme vždy, aby se Patroni po restartu systému automaticky spustil? Často se stává, že musíme jít za starým mistrem, podívat se, jak daleko zašel. Možná zkontrolujte segmenty transakčního protokolu a podívejte se, co tam je. A abychom pochopili, zda můžeme tato data ztratit, nebo zda musíme spustit starý master v samostatném režimu, abychom mohli tato data vytáhnout.
A teprve poté se musíme rozhodnout, zda můžeme tato data zahodit nebo je můžeme obnovit, připojit tento uzel jako repliku k našemu clusteru.
Navíc je zde parametr „maximum_lag_on_failover“. Standardně, pokud mě paměť neklame, má tento parametr hodnotu 1 megabajt.
Jak pracuje? Pokud je naše replika pozadu o 1 megabajt dat ve zpoždění replikace, pak se tato replika voleb neúčastní. A pokud náhle dojde k překrytí souborů, Patroni se podívá na to, které repliky zaostávají. Pokud jsou pozadu o velké množství transakčních protokolů, nemohou se stát mistrem. Jedná se o velmi dobrou bezpečnostní funkci, která zabraňuje ztrátě velkého množství dat.
Ale je tu problém v tom, že zpoždění replikace v clusteru Patroni a DCS je aktualizováno v určitém intervalu. Myslím, že 30 sekund je výchozí hodnota ttl.
V souladu s tím může nastat situace, kdy existuje jedno zpoždění replikace pro repliky v DCS, ale ve skutečnosti může existovat zcela jiné zpoždění nebo nemusí být žádné, tj. tato věc není v reálném čase. A ne vždy odráží skutečný obraz. A nemá cenu na tom dělat přepychovou logiku.
A riziko ztráty vždy zůstává. A v nejhorším případě jeden vzorec a v průměrném případě jiný vzorec. To znamená, že když plánujeme implementaci Patroni a vyhodnocujeme, o kolik dat můžeme přijít, musíme se na tyto vzorce spolehnout a zhruba si představit, o kolik dat můžeme přijít.
A je tu dobrá zpráva. Když starý mistr pokračoval, může pokračovat díky některým procesům na pozadí. To znamená, že došlo k nějakému autovakuu, zapsal data, uložil je do transakčního protokolu. A tato data můžeme snadno ignorovat a ztratit. V tomhle problém není.
A takto vypadají protokoly, pokud je nastaveno maximum_lag_on_failover a došlo k fileru a je třeba vybrat nový master. Replika se hodnotí jako nezpůsobilá k účasti ve volbách. A odmítá se zúčastnit závodu o lídra. A čeká, až se vybere nový pán, aby se k němu pak mohla připojit. Jedná se o dodatečné opatření proti ztrátě dat.
Zde máme produktový tým, který napsal, že jejich produkt má problémy s Postgres. K samotnému masteru se přitom nelze dostat, protože není dostupný přes SSH. A automatický soubor se také nestane.
Tento hostitel byl nucen restartovat. Kvůli restartu došlo k automatickému souboru, i když bylo možné provést ruční automatický soubor, jak nyní chápu. A po restartu se už jdeme podívat, co jsme měli se současným masterem.
Přitom jsme předem věděli, že máme problémy s disky, čili už z monitoringu jsme věděli, kde kopat a co hledat.
Dostali jsme se do postgres logu, začali jsme vidět, co se tam děje. Viděli jsme commity, které tam trvají jednu, dvě, tři sekundy, což není vůbec normální. Viděli jsme, že náš autovakuum se spouští velmi pomalu a podivně. A viděli jsme dočasné soubory na disku. To jsou všechny indikátory problémů s disky.
Podívali jsme se do systémového dmesg (protokol jádra). A viděli jsme, že máme problémy s jedním z disků. Diskovým subsystémem byl softwarový Raid. Podívali jsme se na /proc/mdstat a zjistili jsme, že nám chybí jeden disk. To znamená, že je zde raid 8 disků, jeden nám chybí. Když se pozorně podíváte na snímek, tak ve výstupu vidíte, že tam sde nemáme. U nás, podmíněně řečeno, disk vypadl. To vyvolalo problémy s diskem a aplikace také zaznamenaly problémy při práci s clusterem Postgres.
A v tomto případě by nám Patroni nijak nepomohl, protože Patroni nemá za úkol hlídat stav serveru, stav disku. A takové situace musíme sledovat externím monitorováním. K externímu sledování jsme rychle přidali sledování disku.
A byla taková myšlenka – mohl by nám pomoci software oplocení nebo hlídacího psa? Mysleli jsme si, že by nám v tomto případě sotva pomohl, protože během problémů Patroni pokračoval v interakci s clusterem DCS a neviděl žádný problém. Čili z pohledu DCS a Patroni bylo s clusterem vše v pořádku, i když ve skutečnosti byly problémy s diskem, byly problémy s dostupností databáze.
Podle mého názoru je to jeden z nejpodivnějších problémů, které jsem velmi dlouho zkoumal, přečetl jsem spoustu logů, znovu vybral a nazval ho cluster simulátor.
Problém byl v tom, že ze starého mistra se nemohla stát normální replika, tj. Patroni to spustil, Patroni ukázal, že tento uzel je přítomen jako replika, ale zároveň to nebyla normální replika. Nyní uvidíte proč. To je to, co jsem si nechal z analýzy tohoto problému.
A jak to všechno začalo? Začalo to, stejně jako u předchozího problému, kotoučovými brzdami. Měli jsme závazky na vteřinu, dvě.
Docházelo k přerušování spojení, tj. klienti byli trháni.
Docházelo k blokádám různé závažnosti.
A v souladu s tím diskový subsystém není příliš citlivý.
A nejzáhadnější je pro mě žádost o okamžité vypnutí, která dorazila. Postgres má tři režimy vypnutí:
- Je půvabné, když čekáme, až se všichni klienti sami odpojí.
- Když nutíme klienty k odpojení, protože se chystáme vypnout, je to rychlé.
- A hned. V tomto případě okamžitý ani neřekne klientům, aby se vypnuli, pouze se vypne bez varování. A všem klientům už operační systém posílá RST zprávu (TCP zpráva, že spojení je přerušeno a klient už nemá co chytit).
Kdo vyslal tento signál? Procesy na pozadí Postgres si takové signály navzájem neposílají, to znamená, že se jedná o kill-9. Takové věci si mezi sebou neposílají, pouze na takové reagují, tedy jde o nouzový restart Postgresu. Kdo to poslal, nevím.
Podíval jsem se na "poslední" příkaz a viděl jsem jednu osobu, která se s námi také přihlásila na tento server, ale byl jsem příliš plachý, abych se zeptal. Možná to bylo zabít -9. V logech bych viděl kill -9, protože Postgres říká, že to trvalo kill -9, ale v protokolech jsem to neviděl.
Když jsem se podíval dál, viděl jsem, že Patroni nezapisoval do logu poměrně dlouho - 54 sekund. A pokud porovnáme dvě časová razítka, nebyly tam žádné zprávy po dobu asi 54 sekund.
A během této doby došlo k automatickému souboru. Patroni zde opět odvedl skvělou práci. Náš starý pán byl nedostupný, něco se mu stalo. A začala volba nového mistra. Tady vše dobře dopadlo. Náš pgsql01 se stal novým lídrem.
Máme repliku, která se stala mistrem. A je tu druhá odpověď. A s druhou replikou byly problémy. Pokusila se překonfigurovat. Pokud tomu rozumím, zkusila změnit recovery.conf, restartovat Postgres a připojit se k novému masteru. Každých 10 sekund píše zprávy, že se snaží, ale nedaří se jí to.
A během těchto pokusů dorazí na starého mistra signál okamžitého vypnutí. Master se restartuje. A také se obnova zastaví, protože starý mistr přejde do restartu. To znamená, že se k němu replika nemůže připojit, protože je v režimu vypnutí.
V určitém okamžiku to fungovalo, ale replikace se nespustila.
Můj jediný odhad je, že v recovery.conf byla stará hlavní adresa. A když se objevil nový mistr, druhá replika se stále snažila připojit ke starému mistru.
Když se Patroni spustil na druhé replice, uzel se spustil, ale nemohl se replikovat. A vytvořilo se replikační zpoždění, které vypadalo asi takto. To znamená, že všechny tři uzly byly na svém místě, ale druhý uzel zaostával.
Pokud se zároveň podíváte na zapsané protokoly, uvidíte, že replikaci nelze spustit, protože protokoly transakcí byly odlišné. A ty transakční protokoly, které master nabízí a které jsou specifikovány v recovery.conf, prostě nevyhovují našemu aktuálnímu uzlu.
A tady jsem udělal chybu. Musel jsem se přijít podívat, co je v recovery.conf, abych otestoval svou hypotézu, že jsme se připojovali ke špatnému masteru. Ale pak jsem to jen řešil a nenapadlo mě to, nebo jsem viděl, že replika zaostává a bude se muset doplnit, čili jsem nějak neopatrně pracoval. Tohle byl můj joint.
Po 30 minutách už přišel admin, tedy restartoval jsem Patroni na replice. Už jsem to ukončil, myslel jsem, že se bude muset dolít. A říkal jsem si – restartuji Patroni, třeba se vyklube něco dobrého. Obnova začala. A základna se dokonce otevřela, byla připravena přijímat spojení.
Replikace byla zahájena. Ale o minutu později spadla s chybou, že transakční protokoly pro ni nejsou vhodné.
Myslel jsem, že to znovu restartuji. Znovu jsem restartoval Patroni a nerestartoval jsem Postgres, ale restartoval jsem Patroni v naději, že magicky spustí databázi.
Replikace začala znovu, ale značky v transakčním protokolu byly jiné, nebyly stejné jako předchozí pokus o spuštění. Replikace se opět zastavila. A zpráva už byla trochu jiná. A nebylo to pro mě moc informativní.
A pak mě napadá - co když restartuji Postgres, v tuto chvíli udělám kontrolní bod na aktuálním masteru, abych posunul bod v transakčním logu trochu dopředu, aby se obnova spustila od jiného okamžiku? Navíc jsme stále měli zásoby WAL.
Restartoval jsem Patroni, provedl pár kontrolních bodů na masteru, pár bodů restartu na replice, když se otevřela. A pomohlo to. Dlouho jsem přemýšlel, proč to pomohlo a jak to funguje. A replika začala. A replikace již nebyla trhána.
Takový problém je pro mě jeden z těch záhadnějších, nad kterým si dodnes lámu hlavu, co se tam vlastně stalo.
Jaké to má důsledky? Patroni může pracovat podle plánu a bez jakýchkoli chyb. Ale zároveň to není 100% záruka, že je u nás vše v pořádku. Replika se může spustit, ale může být v poloprovozním stavu a aplikace s takovou replikou nemůže pracovat, protože tam budou stará data.
A po fileru je vždy potřeba zkontrolovat, zda je s clusterem vše v pořádku, to znamená, že je tam požadovaný počet replik, nedochází k žádnému zpoždění replikace.
A když projdeme těmito problémy, dám doporučení. Zkusil jsem je spojit do dvou snímků. Pravděpodobně by se všechny příběhy daly spojit do dvou snímků a pouze vyprávět.
Když používáte Patroni, musíte mít monitorování. Vždy byste měli vědět, kdy došlo k automatickému přesouvání, protože pokud nevíte, že jste k automatickému přesouvání došlo, nemáte nad clusterem žádnou kontrolu. A to je špatně.
Po každém fileru musíme vždy ručně zkontrolovat cluster. Musíme se ujistit, že máme vždy aktuální počet replik, nedochází k žádnému zpoždění replikace, nejsou žádné chyby v protokolech souvisejících se streamovanou replikací, s Patroni, se systémem DCS.
Automatizace může úspěšně fungovat, Patroni je velmi dobrý nástroj. Může to fungovat, ale tím se klastr do požadovaného stavu nedostane. A pokud se to nedozvíme, budeme mít potíže.
A Patroni není žádná stříbrná kulka. Stále musíme rozumět tomu, jak Postgres funguje, jak funguje replikace a jak Patroni spolupracuje s Postgres a jak je zajištěna komunikace mezi uzly. To je nezbytné, abyste mohli vyřešit problémy s rukama.
Jak přistupuji k problematice diagnostiky? Stalo se, že pracujeme s různými klienty a nikdo nemá ELK stack a my musíme třídit logy otevřením 6 konzolí a 2 záložek. Na jedné kartě jsou to protokoly Patroni pro každý uzel, na druhé kartě jsou to protokoly Consul, případně Postgres. Diagnostikovat to je velmi obtížné.
Jaké přístupy jsem vyvinul? Nejprve se vždy podívám, kdy pilník dorazil. A pro mě je to předěl. Dívám se na to, co se stalo před pilníkem, během pilníku a po pilníku. Fileover má dvě značky: toto je čas začátku a konce.
Dále hledám v protokolech události před filerem, které předcházely fileru, tedy hledám důvody, proč k fileru došlo.
A to dává obrázek o pochopení toho, co se stalo a co lze v budoucnu udělat, aby k takovým okolnostem nedocházelo (a ve výsledku neexistuje žádný pilník).
A kam se obvykle díváme? Dívám se:
- Nejprve k protokolům Patroni.
- Dále se podívám na protokoly Postgres nebo protokoly DCS, podle toho, co bylo nalezeno v protokolech Patroni.
- A systémové protokoly také někdy poskytují pochopení toho, co způsobilo soubor.
Jak se cítím o Patroni? S Patronim mám velmi dobrý vztah. Podle mě je to dnes to nejlepší, co existuje. Znám mnoho dalších produktů. Jedná se o Stolon, Repmgr, Pg_auto_failover, PAF. 4 nástroje. Zkoušel jsem je všechny. Patroni je můj oblíbený.
Pokud se mě zeptají: "Doporučuji Patroni?". Řeknu ano, protože mám Patroni rád. A myslím, že jsem se to naučil vařit.
Pokud vás zajímá, jaké jsou další problémy s Patroni kromě problémů, které jsem zmínil, můžete se kdykoli podívat na stránku na GitHubu. Existuje mnoho různých příběhů a probírá se tam mnoho zajímavých problémů. A v důsledku toho byly zavedeny a vyřešeny některé chyby, to znamená, že je to zajímavé čtení.
Existuje několik zajímavých příběhů o lidech, kteří se stříleli do nohy. Velmi informativní. Čtete a chápete, že to není nutné. Zaškrtl jsem sám sebe.
A chtěl bych poděkovat Zalandovi za rozvoj tohoto projektu, jmenovitě Alexandru Kukushkinovi a Alexeji Klyukinovi. Jedním ze spoluautorů je Aleksey Klyukin, který již v Zalandu nepracuje, ale jedná se o dva lidi, kteří s tímto produktem začali pracovat.
A myslím, že Patroni je velmi skvělá věc. Jsem rád, že existuje, je to s ní zajímavé. A velké díky všem přispěvatelům, kteří píší patche do Patroni. Doufám, že Patroni bude s věkem dospělejší, chladnější a výkonnější. Už je funkční, ale doufám, že se to ještě zlepší. Proto, pokud plánujete používat Patroni, pak se nebojte. Toto je dobré řešení, lze jej implementovat a používat.
To je vše. Máte-li dotazy, ptejte se.
otázky
Díky za zprávu! Pokud se po zakladači stále potřebujete dívat velmi pečlivě, tak proč potřebujeme automatický zakladač?
Protože je to novinka. Jsme s ní teprve rok. Je lepší být v bezpečí. Chceme přijít a přesvědčit se, že vše opravdu klaplo tak, jak mělo. To je míra nedůvěry dospělých – je lepší si to zkontrolovat a vidět.
Například jsme šli ráno a podívali se, že?
Ráno ne, většinou se o autofile dozvíme téměř okamžitě. Dostáváme upozornění, vidíme, že došlo k automatickému souboru. Téměř okamžitě se jdeme podívat. Všechny tyto kontroly by však měly být přeneseny na úroveň monitorování. Pokud přistupujete k Patroni přes REST API, existuje historie. Podle historie můžete vidět časová razítka, kdy došlo k souboru. Na základě toho lze provádět monitorování. Můžete vidět historii, kolik akcí tam bylo. Pokud máme více událostí, došlo k automatickému souboru. Můžete se jít podívat. Nebo naše monitorovací automatika zkontrolovala, že máme všechny repliky na svém místě, nedochází k žádné prodlevě a vše je v pořádku.
Děkujeme!
Díky moc za skvělý příběh! Pokud jsme přesunuli cluster DCS někam daleko od clusteru Postgres, pak je třeba tento cluster také pravidelně obsluhovat? Jaké jsou osvědčené postupy, že některé části clusteru DCS je třeba vypnout, něco s nimi udělat atd.? Jak celá tato struktura přežije? A jak tyhle věci děláš?
Pro jednu společnost bylo nutné sestavit matici problémů, co se stane, když jedna z komponent nebo více komponent selže. Podle této matice postupně procházíme všechny komponenty a sestavujeme scénáře pro případ selhání těchto komponent. V souladu s tím můžete mít pro každý scénář selhání akční plán obnovy. A v případě DCS přichází jako součást standardní infrastruktury. A admin to spravuje a my už spoléháme na adminy, kteří to spravují, a jejich schopnost to opravit v případě nehod. Pokud tam DCS vůbec není, tak to nasadíme, ale zároveň to nijak zvlášť nemonitorujeme, protože nejsme zodpovědní za infrastrukturu, ale dáváme doporučení, jak a co monitorovat.
To znamená, pochopil jsem správně, že musím deaktivovat Patroni, deaktivovat filer, deaktivovat vše, než udělám cokoliv s hostiteli?
Záleží na tom, kolik uzlů máme v clusteru DCS. Pokud existuje mnoho uzlů a pokud zakážeme pouze jeden z uzlů (repliku), pak klastr udržuje kvorum. A Patroni zůstává funkční. A nic se nespustí. Pokud máme nějaké složité operace, které ovlivňují více uzlů, jejichž absence může zničit kvorum, pak – ano, mohlo by mít smysl dát Patroni do pauzy. Má odpovídající příkaz - patronictl pause, patronictl obnovit. Prostě se pozastavíme a automatický filtr v tu chvíli nefunguje. Provádíme údržbu na clusteru DCS, pak ukončíme pauzu a pokračujeme v provozu.
Děkuji moc!
Děkujeme mnohokrát za vaši zprávu! Jak se produktový tým staví ke ztrátě dat?
Produktovým týmům je to jedno a vedoucí týmů mají obavy.
Jaké jsou záruky?
Záruky jsou velmi obtížné. Alexander Kukushkin má zprávu „Jak vypočítat RPO a RTO“, tedy dobu obnovy a kolik dat můžeme ztratit. Myslím, že musíme najít tyto snímky a prostudovat je. Pokud si pamatuji, existují konkrétní kroky, jak tyto věci vypočítat. Kolik transakcí můžeme ztratit, kolik dat můžeme ztratit. Jako možnost můžeme použít synchronní replikaci na úrovni Patroni, ale to je dvojsečná zbraň: buď máme spolehlivost dat, nebo ztrácíme rychlost. Existuje synchronní replikace, ale také nezaručuje 100% ochranu před ztrátou dat.
Alexey, díky za skvělou zprávu! Máte nějaké zkušenosti s používáním Patroni pro nulovou úroveň ochrany? Tedy ve spojení se synchronním pohotovostním režimem? Toto je první otázka. A druhá otázka. Použili jste různá řešení. Použili jsme Repmgr, ale bez automatického filtrování a nyní plánujeme zahrnout automatický filtr. A Patroni považujeme za alternativní řešení. Co můžete říci jako výhody oproti Repmgr?
První otázka se týkala synchronních replik. Nikdo zde nepoužívá synchronní replikaci, protože se všichni bojí (několik klientů ji již používá, v zásadě nezaznamenali problémy s výkonem - Poznámka řečníka). Vyvinuli jsme si ale pravidlo, že v clusteru synchronní replikace by měly být alespoň tři uzly, protože pokud máme dva uzly a pokud selže hlavní nebo replika, Patroni přepne tento uzel do režimu Standalone, aby aplikace pokračovala v práce. V tomto případě hrozí ztráta dat.
Pokud jde o druhou otázku, Repmgr jsme používali a stále používáme s některými klienty z historických důvodů. Co lze říci? Patroni přichází s automatickým filtrem po vybalení, Repmgr přichází s automatickým filtrem jako další funkcí, kterou je třeba povolit. Potřebujeme spustit démona Repmgr na každém uzlu a poté můžeme nakonfigurovat autofiler.
Repmgr kontroluje, zda jsou uzly Postgres živé. Procesy Repmgr kontrolují existenci toho druhého, to není příliš efektivní přístup. mohou nastat složité případy síťové izolace, kdy se velký cluster Repmgr může rozpadnout na několik menších a pokračovat v práci. Repmgr už dlouho nesleduji, možná to bylo opraveno ... nebo možná ne. Ale odstranění informací o stavu clusteru v DCS, jak to dělá Stolon, Patroni, je nejschůdnější možností.
Alexey, mám otázku, možná hloupější. V jednom z prvních příkladů jste přesunuli DCS z místního počítače na vzdálený hostitel. Chápeme, že síť je věc, která má své vlastnosti, žije sama o sobě. A co se stane, když se cluster DCS z nějakého důvodu stane nedostupným? Důvody neřeknu, může jich být hodně: od křivých rukou networkerů až po skutečné problémy.
Neřekl jsem to nahlas, ale cluster DCS musí být také failover, tj. je to lichý počet uzlů, aby bylo splněno kvorum. Co se stane, když se cluster DCS stane nedostupným nebo nebude možné splnit kvorum, tj. dojde k nějakému rozdělení sítě nebo selhání uzlu? V tomto případě se cluster Patroni přepne do režimu pouze pro čtení. Cluster Patroni nemůže určit stav klastru a co dělat. Nemůže kontaktovat DCS a uložit tam nový stav clusteru, takže celý cluster přejde pouze pro čtení. A čeká buď na ruční zásah operátora, nebo na zotavení DCS.
Zhruba řečeno, DCS se pro nás stává službou stejně důležitou jako samotná základna?
Ano ano. V mnoha moderních společnostech je Service Discovery nedílnou součástí infrastruktury. Implementuje se ještě předtím, než v infrastruktuře vůbec existovala databáze. Relativně řečeno, infrastruktura byla spuštěna, nasazena v DC a hned máme Service Discovery. Pokud je to Consul, pak na něm lze postavit DNS. Pokud se jedná o Etcd, pak může existovat část z clusteru Kubernetes, ve které bude nasazeno vše ostatní. Zdá se mi, že Service Discovery je již nedílnou součástí moderních infrastruktur. A myslí na to mnohem dříve než na databáze.
Děkujeme!
Zdroj: www.habr.com