Patroni Failure Stories eller hur du kraschar ditt PostgreSQL-kluster. Alexey Lesovsky

Huvudmålet med Patroni är att tillhandahålla hög tillgänglighet för PostgreSQL. Men Patroni är bara en mall, inte ett färdigt verktyg (vilket i allmänhet sägs i dokumentationen). Vid första anblicken, efter att ha ställt in Patroni i testlabbet, kan du se vilket bra verktyg det är och hur lätt det hanterar våra försök att bryta klustret. Men i praktiken, i en produktionsmiljö, händer allt inte alltid lika vackert och elegant som i ett testlabb.

Jag ska berätta lite om mig själv. Jag började som systemadministratör. Arbetade med webbutveckling. Jag har arbetat på Data Egret sedan 2014. Företaget bedriver konsultverksamhet inom Postgres-området. Och vi servar precis Postgres, och vi jobbar med Postgres varje dag, så vi har olika expertis relaterad till verksamheten.

Och i slutet av 2018 började vi långsamt använda Patroni. Och viss erfarenhet har samlats. Vi har på något sätt diagnostiserat det, trimmat det, kommit fram till våra bästa praxis. Och i denna rapport kommer jag att prata om dem.

Förutom Postgres älskar jag Linux. Jag gillar att peta runt i det och utforska, jag gillar att samla kärnor. Jag älskar virtualisering, containrar, docker, Kubernetes. Allt detta intresserar mig, eftersom de gamla administratörsvanorna påverkar. Jag gillar att syssla med övervakning. Och jag älskar postgres-saker relaterade till administration, dvs replikering, backup. Och på fritiden skriver jag i Go. Jag är ingen mjukvaruingenjör, jag skriver bara för mig själv i Go. Och det ger mig glädje.

• Jag tror att många av er vet att Postgres inte har HA (High Availability) ur lådan. För att få HA måste du installera något, konfigurera det, anstränga dig och skaffa det.
• Det finns flera verktyg och Patroni är ett av dem som löser HA ganska coolt och väldigt bra. Men genom att lägga allt i ett testlabb och köra det kan vi se att allt fungerar, vi kan reproducera några problem, se hur Patroni servar dem. Och vi kommer att se att det hela fungerar utmärkt.
• Men i praktiken stod vi inför olika problem. Och jag kommer att prata om dessa problem.
• Jag ska berätta hur vi diagnostiserade det, vad vi justerade - om det hjälpte oss eller inte.

• Jag kommer inte att berätta hur du installerar Patroni, eftersom du kan googla på Internet, du kan titta på konfigurationsfilerna för att förstå hur allt börjar, hur det är konfigurerat. Du kan förstå scheman, arkitekturer, hitta information om det på Internet.
• Jag kommer inte att prata om någon annans erfarenhet. Jag kommer bara att tala om de problem vi stod inför.
• Och jag kommer inte att prata om problem som ligger utanför Patroni och PostgreSQL. Om det till exempel är problem förknippade med balansering, när vårt kluster har kollapsat, ska jag inte prata om det.

Och en liten ansvarsfriskrivning innan vi börjar vår rapport.

Alla dessa problem som vi stötte på, vi hade dem under de första 6-7-8 månaderna av drift. Med tiden kom vi fram till våra interna bästa praxis. Och våra problem försvann. Därför tillkännagavs rapporten för ungefär ett halvår sedan, när allt var färskt i mitt huvud och jag mindes det hela perfekt.

Under utarbetandet av rapporten tog jag redan upp gamla obduktioner, tittade på loggarna. Och några av detaljerna kan glömmas bort, eller några av vissa detaljer kunde inte utredas helt under analysen av problemen, så vid vissa tillfällen kan det tyckas att problemen inte övervägs fullt ut, eller att det finns en viss brist på information. Och därför ber jag dig att ursäkta mig för detta ögonblick.

Vad är Patroni?

• Detta är en mall för att bygga HA. Så står det i dokumentationen. Och ur min synvinkel är detta ett mycket korrekt förtydligande. Patroni är inte en silverkula som kommer att lösa alla dina problem, det vill säga du måste anstränga dig för att få det att fungera och ge fördelar.
• Detta är en agenttjänst som är installerad på varje databastjänst och är ett slags init-system för din Postgres. Den startar Postgres, stoppar, startar om, konfigurerar om och ändrar topologin för ditt kluster.
• Följaktligen, för att lagra tillståndet för klustret, behövs dess nuvarande representation, som det ser ut, någon form av lagring. Och ur denna synvinkel tog Patroni vägen att lagra tillstånd i ett externt system. Det är ett lagringssystem för distribuerad konfiguration. Det kan vara Etcd, Consul, ZooKeeper eller kubernetes Etcd, dvs ett av dessa alternativ.
• Och en av funktionerna hos Patroni är att du får autofilerna ur lådan, bara genom att ställa in den. Om vi ​​tar Repmgr för jämförelse, så ingår filen där. Med Repmgr får vi en övergång, men om vi vill ha en autofiler måste vi konfigurera den ytterligare. Patroni har redan en autofiler ur kartongen.
• Och det finns många andra saker. Till exempel underhåll av konfigurationer, hällning av nya repliker, backup etc. Men detta ligger utanför rapportens ram, jag kommer inte att prata om det.

Och ett litet resultat är att huvuduppgiften för Patroni är att göra en autofil väl och tillförlitligt så att vårt kluster förblir i drift och applikationen inte märker förändringar i klustertopologin.

Men när vi börjar använda Patroni blir vårt system lite mer komplicerat. Om vi ​​tidigare hade Postgres, då när vi använder Patroni får vi Patroni själv, vi får DCS där tillståndet lagras. Och allt måste fungera på något sätt. Så vad kan gå fel?

Kan gå sönder:

• Postgres kan gå sönder. Det kan vara en mästare eller en replik, en av dem kan misslyckas.
• Patroni själv kan gå sönder.
• DCS där tillståndet lagras kan gå sönder.
• Och nätverket kan gå sönder.

Alla dessa punkter kommer jag att ta upp i betänkandet.

Jag kommer att överväga ärenden när de blir mer komplexa, inte utifrån att ärendet omfattar många komponenter. Och ur subjektiva känslors synvinkel, att det här fallet var svårt för mig, det var svårt att ta isär det ... och vice versa, något fall var lätt och det var lätt att plocka isär det.

Och det första fallet är det enklaste. Detta är fallet när vi tog ett databaskluster och distribuerade vår DCS-lagring på samma kluster. Detta är det vanligaste misstaget. Detta är ett misstag i byggnadsarkitekturer, det vill säga att kombinera olika komponenter på ett ställe.

Så det fanns en filur, låt oss ta itu med vad som hände.

Och här är vi intresserade av när filaren hände. Det vill säga, vi är intresserade av detta ögonblick då klustertillståndet förändrades.

Men filaren är inte alltid omedelbar, det vill säga det tar inte någon tidsenhet, det kan bli försenat. Det kan vara långvarigt.

Därför har den en starttid och en sluttid, dvs det är en kontinuerlig händelse. Och vi delar upp alla händelser i tre intervall: vi har tid före filaren, under filaren och efter filaren. Det vill säga vi tar hänsyn till alla händelser i denna tidslinje.

Och det första, när en filur hände, letar vi efter orsaken till det som hände, vad som var orsaken till det som ledde till filuraren.

Om vi ​​tittar på stockarna blir det klassiska Patroni-stockar. Han berättar i dem att servern har blivit mästaren, och rollen som master har gått över till denna nod. Här är det markerat.

Därefter måste vi förstå varför filen hände, det vill säga vilka händelser som inträffade som fick masterrollen att flytta från en nod till en annan. Och i det här fallet är allt enkelt. Vi har ett fel i interaktionen med lagringssystemet. Befälhavaren insåg att han inte kunde arbeta med DCS, det vill säga att det fanns något slags problem med interaktionen. Och han säger att han inte längre kan vara en mästare och säger upp sig. Den här raden "degraderat jag" säger precis det.

Om vi ​​tittar på händelserna som föregick filen, kan vi där se själva orsakerna som var problemet för att fortsätta med guiden.

Om vi ​​tittar på Patroni-loggarna kommer vi att se att vi har många fel, timeouts, d.v.s. Patroni-agenten kan inte arbeta med DCS. I det här fallet är detta Consul-agent, som kommunicerar på port 8500.

Och problemet här är att Patroni och databasen körs på samma värd. Och Consul-servrarna lanserades på samma nod. Genom att skapa en belastning på servern skapade vi problem även för Consul-servrarna. De kunde inte kommunicera ordentligt.

Efter en tid, när belastningen avtog, kunde vår Patroni kommunicera med agenter igen. Det normala arbetet återupptogs. Och samma Pgdb-2-server blev master igen. Det vill säga, det var en liten flip, på grund av vilken noden sa upp befälhavarens befogenheter och sedan tog över dem igen, det vill säga allt återvände som det var.

Och detta kan betraktas som ett falskt larm, eller så kan det anses att Patroni gjorde allt rätt. Det vill säga, han insåg att han inte kunde upprätthålla klustrets tillstånd och tog bort sin auktoritet.

Och här uppstod problemet på grund av att Consul-servrarna är på samma hårdvara som baserna. Följaktligen, vilken belastning som helst: oavsett om det är belastningen på diskar eller processorer, påverkar det också interaktionen med Consul-klustret.

Och vi bestämde att det inte skulle leva tillsammans, vi tilldelade ett separat kluster för Consul. Och Patroni arbetade redan med en separat konsul, det vill säga det fanns ett separat Postgres-kluster, ett separat Consul-kluster. Detta är en grundläggande instruktion om hur man bär och förvarar alla dessa saker så att det inte lever tillsammans.

Som ett alternativ kan du vrida parametrarna ttl, loop_wait, retry_timeout, dvs försöka överleva dessa kortvariga belastningstoppar genom att öka dessa parametrar. Men detta är inte det mest lämpliga alternativet, eftersom denna belastning kan vara lång i tiden. Och vi kommer helt enkelt att gå bortom dessa gränser för dessa parametrar. Och det kanske inte riktigt hjälper.

Det första problemet, som du förstår, är enkelt. Vi tog och satte ihop DCS med basen, vi fick ett problem.

Det andra problemet liknar det första. Det är liknande genom att vi återigen har interoperabilitetsproblem med DCS-systemet.

Om vi ​​tittar på loggarna ser vi att vi återigen har ett kommunikationsfel. Och Patroni säger att jag inte kan interagera med DCS så den nuvarande mastern går in i replikläge.

Den gamle mästaren blir en replik, här löser sig Patroni, som sig bör. Den kör pg_rewind för att spola tillbaka transaktionsloggen och sedan ansluta till den nya mastern för att komma ikapp med den nya mastern. Här tränar Patroni, som han ska.

Här måste vi finna platsen som föregick filaren, d. v. s. de felen som gjorde att vi hade en filare. Och i detta avseende är Patroni-loggar ganska bekväma att arbeta med. Han skriver samma meddelanden med ett visst intervall. Och om vi snabbt börjar bläddra igenom dessa loggar, så kommer vi att se från loggarna att loggarna har ändrats, vilket betyder att vissa problem har börjat. Vi återvänder snabbt till denna plats, se vad som händer.

Och i en normal situation ser stockarna ut ungefär så här. Ägaren till låset kontrolleras. Och om ägaren till exempel har ändrats kan det inträffa vissa händelser som Patroni måste svara på. Men i det här fallet mår vi bra. Vi letar efter platsen där felen började.

Och efter att ha scrollat ​​till den punkt där felen började dyka upp ser vi att vi har haft en auto-fileover. Och eftersom våra fel var relaterade till interaktion med DCS och i vårt fall använde vi Consul tittar vi också på Consul-loggarna, vad som hände där.

Om vi ​​grovt jämför tidpunkten för inlämnaren och tiden i konsulloggarna ser vi att våra grannar i konsulklustret började tvivla på att andra medlemmar i konsulklustret fanns.

Och om du tittar på loggar från andra Consul-agenter kan du också se att det pågår någon form av nätverkskollaps där. Och alla medlemmar i konsulklustret tvivlar på varandras existens. Och detta var drivkraften för filuren.

Om du tittar på vad som hände före dessa fel, kan du se att det finns alla möjliga fel, till exempel, deadline, RPC föll, det vill säga att det helt klart finns något slags problem i interaktionen mellan Consul klustermedlemmarna med varandra .

Det enklaste svaret är att reparera nätverket. Men för mig som står på pallen är det lätt att säga så här. Men omständigheterna är sådana att kunden inte alltid har råd att reparera nätet. Han kanske bor i en DC och kanske inte kan reparera nätverket, påverka utrustningen. Och så det behövs några andra alternativ.

Det finns alternativ:

• Det enklaste alternativet, som enligt min mening är skrivet, även i dokumentationen, är att inaktivera Consul-kontroller, det vill säga helt enkelt passera en tom array. Och vi säger åt konsulagenten att inte använda några checkar. Med dessa kontroller kan vi ignorera dessa nätverksstormar och inte initiera en fil.
• Ett annat alternativ är att dubbelkolla raft_multiplier. Detta är en parameter för själva Consul-servern. Som standard är det inställt på 5. Detta värde rekommenderas av dokumentationen för iscensättningsmiljöer. Faktum är att detta påverkar frekvensen av meddelanden mellan medlemmar i Consul-nätverket. Faktum är att denna parameter påverkar hastigheten på tjänstekommunikation mellan medlemmar i Consul-klustret. Och för produktion rekommenderas det redan att minska det så att noderna utbyter meddelanden oftare.
• Ett annat alternativ vi har kommit fram till är att öka prioriteringen av Consul-processer bland andra processer för operativsystemets processplanerare. Det finns en sådan "trevlig" parameter, den bestämmer bara prioriteten för processer som tas med i beräkningen av OS-schemaläggaren vid schemaläggning. Vi har även minskat det fina värdet för Consul-ombud, d.v.s. ökat prioritet så att operativsystemet ger Consul-processer mer tid att arbeta och exekvera sin kod. I vårt fall löste detta vårt problem.
• Ett annat alternativ är att inte använda Consul. Jag har en vän som är en stor anhängare av Etcd. Och vi bråkar regelbundet med honom vad som är bättre Etcd eller Consul. Men när det gäller vilket som är bättre brukar vi hålla med honom om att Consul har en agent som ska köras på varje nod med en databas. Det vill säga, Patroni interagerar med Consul-klustret genom denna agent. Och den här agenten blir en flaskhals. Om något händer med agenten kan Patroni inte längre arbeta med Consul-klustret. Och detta är problemet. Det finns ingen agent i Etcd-planen. Patroni kan arbeta direkt med en lista över Etcd-servrar och redan kommunicera med dem. I detta avseende, om du använder Etcd i ditt företag, kommer Etcd förmodligen att vara ett bättre val än Consul. Men vi på våra kunder är alltid begränsade av vad kunden har valt och använder. Och vi har Consul för det mesta för alla kunder.
• Och den sista punkten är att revidera parametervärdena. Vi kan höja dessa parametrar i hopp om att våra kortsiktiga nätverksproblem ska bli korta och inte falla utanför räckvidden för dessa parametrar. På så sätt kan vi minska Patronis aggressivitet att autofila om vissa nätverksproblem uppstår.

Jag tror att många som använder Patroni är bekanta med detta kommando.

Detta kommando visar det aktuella tillståndet för klustret. Och vid första anblicken kan den här bilden verka normal. Vi har en master, vi har en replik, det finns ingen replikeringsfördröjning. Men den här bilden är normal exakt tills vi vet att detta kluster ska ha tre noder, inte två.

Följaktligen fanns det en autofil. Och efter den här autofilen försvann vår replik. Vi måste ta reda på varför hon försvann och ta tillbaka henne, återställa henne. Och vi går igen till loggarna och ser varför vi hade en auto-fileover.

I det här fallet blev den andra repliken mästaren. Det är okej här.

Och vi måste titta på repliken som ramlade av och som inte finns i klustret. Vi öppnar Patroni-loggarna och ser att vi hade ett problem under processen att ansluta till klustret i pg_rewind-stadiet. För att ansluta till klustret måste du spola tillbaka transaktionsloggen, begära den nödvändiga transaktionsloggen från mastern och använda den för att komma ikapp mastern.

I det här fallet har vi ingen transaktionslogg och repliken kan inte starta. Följaktligen stoppar vi Postgres med ett fel. Och därför är det inte i klustret.

Vi måste förstå varför det inte finns i klustret och varför det inte fanns några loggar. Vi går till den nya mästaren och tittar på vad han har i stockarna. Det visar sig att när pg_rewind gjordes inträffade en kontrollpunkt. Och några av de gamla transaktionsloggarna döptes helt enkelt om. När den gamla mastern försökte ansluta till den nya mastern och fråga efter dessa loggar, döptes de redan om, de fanns helt enkelt inte.

Jag jämförde tidsstämplar när dessa händelser inträffade. Och där är skillnaden bokstavligen 150 millisekunder, det vill säga kontrollpunkten slutförd på 369 millisekunder, WAL-segmenten döptes om. Och bokstavligen år 517, efter 150 millisekunder, startade tillbakaspolningen på den gamla repliken. Det vill säga, bokstavligen räckte 150 millisekunder för oss så att repliken inte kunde ansluta och tjäna.

Vad är alternativen?

Vi använde initialt replikeringsplatser. Vi tyckte det var bra. Även om vi i det första steget stängde av slitsarna. Det verkade för oss att om slots ackumulerar många WAL-segment kan vi släppa mastern. Han kommer att falla. Vi led en tid utan slots. Och vi insåg att vi behöver slots, vi lämnade tillbaka platserna.

Men det finns ett problem här, att när mastern går till repliken, tar den bort luckorna och raderar WAL-segmenten tillsammans med luckorna. Och för att eliminera detta problem bestämde vi oss för att höja parametern wal_keep_segments. Den har som standard 8 segment. Vi höjde det till 1 000 och tittade på hur mycket ledigt utrymme vi hade. Och vi donerade 16 gigabyte för wal_keep_segments. Det vill säga, vid byte har vi alltid en reserv på 16 gigabyte transaktionsloggar på alla noder.

Och plus - det är fortfarande relevant för långsiktiga underhållsuppgifter. Låt oss säga att vi behöver uppdatera en av replikerna. Och vi vill stänga av den. Vi måste uppdatera programvaran, kanske operativsystemet, något annat. Och när vi stänger av en replika tas också spåret för den repliken bort. Och om vi använder ett litet wal_keep_segments, kommer transaktionsloggarna att gå förlorade med en lång frånvaro av en replik. Vi kommer att ta fram en replik, den kommer att begära de transaktionsloggarna där den slutade, men de kanske inte finns på mastern. Och repliken kommer inte heller att kunna ansluta. Därför har vi ett stort lager av tidningar.

Vi har en produktionsbas. Det pågår redan projekt.

Det fanns en filare. Vi gick in och tittade – allt är i sin ordning, replikerna är på plats, det finns ingen replikeringsfördröjning. Det finns inga fel i loggarna heller, allt är i sin ordning.

Produktteamet säger att det borde finnas en del data, men vi ser det från en källa, men vi ser det inte i databasen. Och vi måste förstå vad som hände med dem.

Det är tydligt att pg_rewind missade dem. Vi förstod direkt detta, men gick för att se vad som hände.

I loggarna kan vi alltid hitta när filen hände, vem som blev mästaren, och vi kan bestämma vem som var den gamla mästaren och när han ville bli en replik, dvs vi behöver dessa loggar för att ta reda på mängden transaktionsloggar som var borta.

Vår gamla mästare har startat om. Och Patroni var registrerad i autorun. Lanserade Patroni. Han startade sedan Postgres. Närmare bestämt, innan du startade Postgres och innan han gjorde det till en replik, lanserade Patroni pg_rewind-processen. Följaktligen raderade han en del av transaktionsloggarna, laddade ner nya och ansluter. Här jobbade Patroni smart, det vill säga som förväntat. Klustret har återställts. Vi hade 3 noder, efter filaren 3 noder - allt är coolt.

Vi har förlorat en del data. Och vi måste förstå hur mycket vi har förlorat. Vi letar efter just ögonblicket då vi hade en återspolning. Vi kan hitta det i sådana journalanteckningar. Rewind startade, gjorde något där och slutade.

Vi måste hitta positionen i transaktionsloggen där den gamla mästaren slutade. I det här fallet är detta märket. Och vi behöver ett andra märke, det vill säga avståndet med vilket den gamla mästaren skiljer sig från den nya.

Vi tar den vanliga pg_wal_lsn_diff och jämför dessa två märken. Och i det här fallet får vi 17 megabyte. Mycket eller lite, var och en bestämmer själv. För för någon är 17 megabyte inte mycket, för någon är det mycket och oacceptabelt. Här bestämmer varje individ själv i enlighet med verksamhetens behov.

Men vad har vi själva tagit reda på?

Först måste vi bestämma oss själva - behöver vi alltid Patroni för att autostarta efter en omstart av systemet? Det händer ofta att vi måste gå till den gamle husbonden, se hur långt han har gått. Inspektera kanske segment av transaktionsloggen, se vad som finns där. Och för att förstå om vi kan förlora denna data eller om vi behöver köra den gamla mastern i fristående läge för att dra ut dessa data.

Och först efter det måste vi bestämma om vi kan kassera denna data eller om vi kan återställa den, koppla denna nod som en replik till vårt kluster.

Dessutom finns det en parameter "maximum_lag_on_failover". Som standard, om mitt minne tjänar mig, har denna parameter ett värde på 1 megabyte.

Hur fungerar han? Om vår replik ligger efter med 1 megabyte data i replikeringsfördröjningen, så deltar inte denna replik i valet. Och om det plötsligt blir en filöver, tittar Patroni på vilka repliker som släpar efter. Om de ligger efter med ett stort antal transaktionsloggar kan de inte bli en mästare. Detta är en mycket bra säkerhetsfunktion som förhindrar att du förlorar mycket data.

Men det finns ett problem i att replikeringsfördröjningen i Patroni-klustret och DCS uppdateras med ett visst intervall. Jag tror att 30 sekunder är standardvärdet för ttl.

Följaktligen kan det finnas en situation där det finns en replikeringsfördröjning för repliker i DCS, men i själva verket kan det finnas en helt annan fördröjning eller så kan det inte finnas någon fördröjning alls, dvs. det här är inte realtid. Och det återspeglar inte alltid den verkliga bilden. Och det är inte värt att göra snygg logik på det.

Och risken för förlust kvarstår alltid. Och i värsta fall en formel, och i genomsnittsfallet en annan formel. Det vill säga när vi planerar implementeringen av Patroni och utvärderar hur mycket data vi kan förlora, måste vi förlita oss på dessa formler och ungefär föreställa oss hur mycket data vi kan förlora.

Och det finns goda nyheter. När den gamle mästaren har gått före kan han gå vidare på grund av vissa bakgrundsprocesser. Det vill säga, det fanns någon form av autovakuum, han skrev data, sparade dem i transaktionsloggen. Och vi kan lätt ignorera och förlora denna data. Det finns inga problem med detta.

Och så här ser loggarna ut om maximum_lag_on_failover är satt och en filer har inträffat, och du måste välja en ny master. Repliken bedömer sig själv som oförmögen att delta i valet. Och hon vägrar att delta i loppet om ledaren. Och hon väntar på att en ny mästare ska väljas, så att hon sedan kan ansluta till den. Detta är en ytterligare åtgärd mot dataförlust.

Här har vi ett produktteam som skrev att deras produkt har problem med Postgres. Samtidigt går det inte att komma åt själva mastern, eftersom den inte är tillgänglig via SSH. Och autofilen händer inte heller.

Denna värd tvingades starta om. På grund av omstarten inträffade en auto-fil, även om det var möjligt att göra en manuell auto-fil, som jag nu förstår. Och efter omstarten kommer vi redan att se vad vi hade med den nuvarande mastern.

Samtidigt visste vi i förväg att vi hade problem med diskar, det vill säga vi visste redan från övervakning var vi skulle gräva och vad vi skulle leta efter.

Vi kom in i postgres-loggen, började se vad som hände där. Vi såg commits som varar där i en, två, tre sekunder, vilket inte alls är normalt. Vi såg att vår autovakuum startar väldigt långsamt och konstigt. Och vi såg tillfälliga filer på disken. Det vill säga, dessa är alla indikatorer på problem med diskar.

Vi tittade på systemet dmesg (kärnlogg). Och vi såg att vi har problem med en av diskarna. Diskundersystemet var programvaran Raid. Vi tittade på /proc/mdstat och såg att vi saknade en enhet. Det vill säga, det finns en Raid på 8 diskar, vi saknar en. Om du noggrant tittar på bilden, så kan du i utgången se att vi inte har sde där. Hos oss har, villkorligt sett, disken tappats. Detta utlöste diskproblem och applikationer fick också problem när de arbetade med Postgres-klustret.

Och i det här fallet skulle Patroni inte hjälpa oss på något sätt, eftersom Patroni inte har till uppgift att övervaka serverns tillstånd, diskens tillstånd. Och vi måste övervaka sådana situationer genom extern övervakning. Vi lade snabbt till diskövervakning till extern övervakning.

Och det fanns en sådan tanke - kan fäktning eller vakthund-programvara hjälpa oss? Vi trodde att han knappast skulle ha hjälpt oss i det här fallet, för under problemen fortsatte Patroni att interagera med DCS-klustret och såg inga problem. Det vill säga, ur DCS och Patronis synvinkel var allt bra med klustret, även om det faktiskt fanns problem med disken, det fanns problem med tillgängligheten av databasen.

Enligt mig är detta ett av de märkligaste problemen som jag har forskat på på väldigt länge, jag har läst en hel del loggar, plockat om och kallat det en klustersimulator.

Problemet var att den gamla mästaren inte kunde bli en normal replik, d.v.s Patroni startade den, Patroni visade att denna nod fanns som en replik, men samtidigt var det inte en normal replik. Nu ska du se varför. Detta är vad jag har behållit från analysen av det problemet.

Och hur började det hela? Det började, som i förra problemet, med skivbromsar. Vi hade åtaganden för en sekund, två.

Det förekom avbrott i anslutningarna, det vill säga att klienterna slets.

Det fanns blockeringar av olika svårighetsgrad.

Och följaktligen är diskundersystemet inte särskilt lyhört.

Och det mest mystiska för mig är den omedelbara avstängningsförfrågan som kom. Postgres har tre avstängningslägen:

• Det är graciöst när vi väntar på att alla kunder ska koppla av på egen hand.
• Det är snabbt när vi tvingar klienter att koppla bort eftersom vi kommer att stänga av.
• Och omedelbart. I det här fallet säger omedelbart inte ens till kunderna att stänga, det stänger bara av utan förvarning. Och till alla klienter skickar operativsystemet redan ett RST-meddelande (ett TCP-meddelande om att anslutningen är avbruten och klienten inte har något mer att fånga).

Vem skickade denna signal? Postgres bakgrundsprocesser skickar inte sådana signaler till varandra, det vill säga detta är kill-9. De skickar inte sådana saker till varandra, de reagerar bara på sådana saker, det vill säga det här är en nödstart av Postgres. Vem som skickade det vet jag inte.

Jag tittade på det "sista" kommandot och jag såg en person som också loggade in på den här servern med oss, men jag var för blyg för att ställa en fråga. Kanske var det kill -9. Jag skulle se kill -9 i loggarna, eftersom Postgres säger att det tog kill -9, men jag såg det inte i loggarna.

När jag tittade vidare såg jag att Patroni inte skrev till loggen på ganska länge - 54 sekunder. Och om vi jämför två tidsstämplar så fanns det inga meddelanden på cirka 54 sekunder.

Och under den här tiden fanns det en autofil. Patroni gjorde ett bra jobb här igen. Vår gamle husse var otillgänglig, något hände honom. Och valet av en ny mästare började. Allt fungerade bra här. Vår pgsql01 har blivit den nya ledaren.

Vi har en replik som har blivit en mästare. Och det finns ett andra svar. Och det var problem med den andra repliken. Hon försökte konfigurera om. Som jag förstår det försökte hon ändra recovery.conf, starta om Postgres och ansluta till den nya mastern. Hon skriver meddelanden var tionde sekund att hon försöker, men hon lyckas inte.

Och under dessa försök kommer en omedelbar avstängningssignal till den gamla mästaren. Mastern startas om. Och även återställningen stoppas eftersom den gamla mastern går in i omstart. Det vill säga att repliken inte kan ansluta till den, eftersom den är i avstängt läge.

Vid något tillfälle fungerade det, men replikeringen startade inte.

Min enda gissning är att det fanns en gammal masteradress i recovery.conf. Och när en ny master dök upp försökte den andra repliken fortfarande ansluta till den gamla mastern.

När Patroni startade på den andra repliken startade noden men kunde inte replikera. Och en replikeringsfördröjning bildades, som såg ut ungefär så här. Det vill säga att alla tre noderna var på plats, men den andra noden släpade efter.

Samtidigt, om man tittar på loggarna som skrevs, kunde man se att replikeringen inte kunde starta eftersom transaktionsloggarna var olika. Och de transaktionsloggarna som mastern erbjuder, som specificeras i recovery.conf, passar helt enkelt inte vår nuvarande nod.

Och här gjorde jag ett misstag. Jag var tvungen att komma och se vad som fanns i recovery.conf för att testa min hypotes att vi kopplade till fel mästare. Men då sysslade jag bara med det här och det föll mig inte in, eller så såg jag att repliken släpade efter och skulle behöva fyllas på igen, det vill säga, jag arbetade på något sätt slarvigt. Det här var min joint.

Efter 30 minuter kom redan administratören, d.v.s. jag startade om Patroni på repliken. Jag har redan satt stopp för det, jag tänkte att det måste fyllas på igen. Och jag tänkte – jag startar om Patroni, det kanske blir något bra. Återhämtningen började. Och basen öppnade till och med, den var redo att acceptera anslutningar.

Replikeringen har startat. Men en minut senare ramlade hon av med ett fel att transaktionsloggar inte är lämpliga för henne.

Jag tänkte starta om igen. Jag startade om Patroni igen, och jag startade inte om Postgres, utan startade om Patroni i hopp om att det på magiskt sätt skulle starta databasen.

Replikeringen startade igen, men märkena i transaktionsloggen var annorlunda, de var inte samma som föregående startförsök. Replikeringen avbröts igen. Och budskapet var redan något annorlunda. Och det var inte särskilt informativt för mig.

Och då slår det mig - vad händer om jag startar om Postgres, vid det här laget gör jag en kontrollpunkt på den aktuella mastern för att flytta punkten i transaktionsloggen lite framåt så att återställningen startar från ett annat ögonblick? Dessutom hade vi fortfarande lager av WAL.

Jag startade om Patroni, gjorde ett par kontrollpunkter på mastern, ett par omstartpunkter på repliken när den öppnade. Och det hjälpte. Jag funderade länge på varför det hjälpte och hur det fungerade. Och repliken började. Och replikeringen slets inte längre.

Ett sådant problem för mig är ett av de mer mystiska, som jag fortfarande undrar över vad som verkligen hände där.

Vilka är konsekvenserna här? Patroni kan fungera som avsett och utan några fel. Men samtidigt är detta ingen 100% garanti för att allt är bra med oss. Repliken kan starta, men den kan vara i ett halvt fungerande tillstånd, och programmet kan inte fungera med en sådan replik, eftersom det kommer att finnas gamla data.

Och efter filerna måste du alltid kontrollera att allt är i sin ordning med klustret, det vill säga att det finns det antal repliker som krävs, det finns ingen replikeringsfördröjning.

Och när vi går igenom dessa frågor kommer jag att ge rekommendationer. Jag försökte kombinera dem till två bilder. Förmodligen kunde alla berättelser kombineras till två bilder och bara berättas.

När du använder Patroni måste du ha övervakning. Du bör alltid veta när en autofileover inträffade, för om du inte vet att du hade en autofileover har du ingen kontroll över klustret. Och det är dåligt.

Efter varje fil måste vi alltid kontrollera klustret manuellt. Vi måste se till att vi alltid har ett uppdaterat antal repliker, det finns ingen replikeringsfördröjning, det finns inga fel i loggarna relaterade till strömmande replikering, med Patroni, med DCS-systemet.

Automation kan fungera framgångsrikt, Patroni är ett mycket bra verktyg. Det kan fungera, men detta kommer inte att föra klustret till önskat tillstånd. Och om vi inte får reda på det kommer vi att hamna i trubbel.

Och Patroni är ingen silverkula. Vi behöver fortfarande förstå hur Postgres fungerar, hur replikering fungerar och hur Patroni fungerar med Postgres, och hur kommunikation mellan noder tillhandahålls. Detta är nödvändigt för att kunna åtgärda problem med dina händer.

Hur ställer jag mig till frågan om diagnos? Det blev så att vi arbetar med olika klienter och ingen har en ELK-stack, och vi måste sortera loggarna genom att öppna 6 konsoler och 2 flikar. På den ena fliken är det Patroni-loggarna för varje nod, på den andra fliken är det Consul-loggarna eller Postgres om det behövs. Det är väldigt svårt att diagnostisera detta.

Vilka tillvägagångssätt har jag tagit? Först tittar jag alltid när filaren har kommit. Och för mig är detta en vattendelare. Jag tittar på vad som hände före inlämningen, under inlämningen och efter inlämningen. Överföringen har två markeringar: detta är start- och sluttid.

Därefter letar jag i loggarna efter händelser före filaren, som föregick filaren, d.v.s. jag letar efter orsakerna till att filaren hände.

Och detta ger en bild av att förstå vad som hände och vad som kan göras i framtiden så att sådana omständigheter inte inträffar (och som ett resultat finns det ingen fil).

Och var brukar vi titta? Jag ser:

• Först till Patroni-loggarna.
• Därefter tittar jag på Postgres-loggarna, eller DCS-loggarna, beroende på vad som hittades i Patroni-loggarna.
• Och systemloggarna ger ibland också en förståelse för vad som orsakade filen.

Hur känner jag för Patroni? Jag har en väldigt bra relation med Patroni. Enligt mig är detta det bästa som finns idag. Jag känner till många andra produkter. Dessa är Stolon, Repmgr, Pg_auto_failover, PAF. 4 verktyg. Jag provade dem alla. Patroni är min favorit.

Om de frågar mig: "Rekommenderar jag Patroni?". Jag säger ja, för jag gillar Patroni. Och jag tror att jag lärde mig att laga mat.

Om du är intresserad av att se vilka andra problem det finns med Patroni förutom problemen jag har nämnt, kan du alltid kolla in sidan problem på GitHub. Det finns många olika historier och många intressanta frågor diskuteras där. Och som ett resultat introducerades och löstes några buggar, det vill säga det här är en intressant läsning.

Det finns några intressanta historier om människor som skjuter sig själva i foten. Mycket informativt. Du läser och förstår att det inte är nödvändigt att göra det. Jag bockade för mig själv.

Och jag skulle vilja säga ett stort tack till Zalando för utvecklingen av detta projekt, nämligen till Alexander Kukushkin och Alexey Klyukin. Aleksey Klyukin är en av medförfattarna, han jobbar inte längre på Zalando, men det är två personer som började jobba med den här produkten.

Och jag tycker att Patroni är en väldigt cool grej. Jag är glad att hon finns, det är intressant med henne. Och ett stort tack till alla bidragsgivare som skriver patchar till Patroni. Jag hoppas att Patroni blir mer mogen, cool och effektiv med åren. Det är redan funktionellt, men jag hoppas att det blir ännu bättre. Därför, om du planerar att använda Patroni, var inte rädd. Detta är en bra lösning, den kan implementeras och användas.

Det är allt. Om du har frågor, fråga.

frågor

Tack för rapporten! Om du efter en filare fortfarande behöver titta där mycket noggrant, varför behöver vi då en automatisk filare?

För det är nya grejer. Vi har bara varit med henne i ett år. Bättre att vara säker. Vi vill komma in och se att allt verkligen fungerade som det skulle. Detta är nivån av vuxen misstro - det är bättre att dubbelkolla och se.

Vi gick till exempel på morgonen och tittade, eller hur?

Inte på morgonen, vi brukar lära oss om autofilen nästan direkt. Vi får aviseringar, vi ser att en autofil har inträffat. Vi går nästan direkt och tittar. Men alla dessa kontroller bör föras till övervakningsnivån. Om du kommer åt Patroni via REST API finns det en historik. Genom historik kan du se tidsstämplarna när filen hände. Utifrån detta kan övervakning göras. Du kan se historien, hur många händelser som var där. Om vi ​​har fler händelser har en autofil inträffat. Du kan gå och se. Eller så kontrollerade vår övervakningsautomation att vi har alla repliker på plats, det finns ingen fördröjning och allt är bra.

Tack!

Tack så mycket för den fantastiska berättelsen! Om vi ​​flyttade DCS-klustret någonstans långt från Postgres-klustret, behöver då detta kluster också servas med jämna mellanrum? Vilka är de bästa metoderna att vissa delar av DCS-klustret måste stängas av, något att göra med dem, etc.? Hur överlever hela denna struktur? Och hur gör man dessa saker?

För ett företag var det nödvändigt att göra en matris av problem, vad som händer om en av komponenterna eller flera komponenter går sönder. Enligt denna matris går vi sekventiellt igenom alla komponenter och bygger scenarier i händelse av fel på dessa komponenter. Följaktligen kan du för varje felscenario ha en handlingsplan för återhämtning. Och i fallet med DCS kommer det som en del av standardinfrastrukturen. Och administratören administrerar det, och vi litar redan på administratörerna som administrerar det och deras förmåga att fixa det i händelse av olyckor. Om det inte finns någon DCS alls, så distribuerar vi det, men samtidigt övervakar vi det inte särskilt, eftersom vi inte är ansvariga för infrastrukturen, men vi ger rekommendationer om hur och vad vi ska övervaka.

Det vill säga, förstod jag rätt att jag måste inaktivera Patroni, inaktivera filen, inaktivera allt innan jag gör något med värdarna?

Det beror på hur många noder vi har i DCS-klustret. Om det finns många noder och om vi inaktiverar endast en av noderna (repliken), så upprätthåller klustret ett kvorum. Och Patroni förblir i drift. Och ingenting utlöses. Om vi ​​har några komplexa operationer som påverkar fler noder, vars frånvaro kan förstöra kvorumet, så - ja, det kan vara vettigt att sätta Patroni på paus. Den har ett motsvarande kommando - patronictl paus, patronictl resume. Vi pausar bara och autofilerna fungerar inte vid den tiden. Vi gör underhåll på DCS-klustret, sedan tar vi av pausen och fortsätter att leva.

Tack så mycket!

Tack så mycket för din rapport! Hur upplever produktteamet att data går förlorad?

Produktteam bryr sig inte, och teamledarna är oroliga.

Vilka garantier finns det?

Garantier är mycket svåra. Alexander Kukushkin har en rapport "Hur man beräknar RPO och RTO", dvs återhämtningstid och hur mycket data vi kan förlora. Jag tror att vi måste hitta dessa bilder och studera dem. Såvitt jag minns finns det specifika steg för hur man beräknar dessa saker. Hur många transaktioner vi kan förlora, hur mycket data vi kan förlora. Som ett alternativ kan vi använda synkron replikering på Patroni-nivå, men detta är ett tveeggat svärd: antingen har vi datatillförlitlighet eller så tappar vi hastighet. Det finns synkron replikering, men det garanterar inte heller 100 % skydd mot dataförlust.

Alexey, tack för den fantastiska rapporten! Någon erfarenhet av att använda Patroni för nollnivåskydd? Det vill säga i samband med synkron standby? Detta är den första frågan. Och den andra frågan. Du har använt olika lösningar. Vi använde Repmgr, men utan autofiler, och nu planerar vi att inkludera autofiler. Och vi betraktar Patroni som en alternativ lösning. Vad kan du säga som fördelar jämfört med Repmgr?

Den första frågan handlade om synkrona repliker. Ingen använder synkron replikering här, eftersom alla är rädda (Flera klienter använder det redan, i princip märkte de inte prestandaproblem - Talarens anteckning). Men vi har utvecklat en regel för oss själva att det ska finnas minst tre noder i ett synkront replikeringskluster, för om vi har två noder och om mastern eller repliken misslyckas, så växlar Patroni denna nod till fristående läge så att applikationen fortsätter att arbete. I det här fallet finns det risk för dataförlust.

När det gäller den andra frågan har vi använt Repmgr och gör det fortfarande med vissa klienter av historiska skäl. Vad kan man säga? Patroni kommer med en autofiler ur kartongen, Repmgr kommer med autofiler som en extra funktion som måste aktiveras. Vi måste köra Repmgr-demonen på varje nod och sedan kan vi konfigurera autofiler.

Repmgr kontrollerar om Postgres-noder är levande. Repmgr-processer kontrollerar att det finns varandra, detta är inte ett särskilt effektivt tillvägagångssätt. det kan finnas komplexa fall av nätverksisolering där ett stort Repmgr-kluster kan falla isär i flera mindre och fortsätta arbeta. Jag har inte följt Repmgr på länge, det kanske var fixat... eller kanske inte. Men borttagandet av information om tillståndet för klustret i DCS, som Stolon, Patroni gör, är det mest genomförbara alternativet.

Alexey, jag har en fråga, kanske en svårare fråga. I ett av de första exemplen flyttade du DCS från den lokala maskinen till en fjärrvärd. Vi förstår att nätverket är en sak som har sina egna egenskaper, det lever för sig själv. Och vad händer om DCS-klustret av någon anledning blir otillgängligt? Jag kommer inte att säga skälen, det kan finnas många av dem: från nätverkares krokiga händer till verkliga problem.

Jag sa det inte högt, men DCS-klustret måste också vara failover, det vill säga det är ett udda antal noder, för att ett kvorum ska uppfyllas. Vad händer om DCS-klustret blir otillgängligt eller om ett kvorum inte kan uppfyllas, det vill säga någon form av nätverksdelning eller nodfel? I det här fallet går Patroni-klustret i skrivskyddat läge. Patroni-klustret kan inte bestämma tillståndet för klustret och vad som ska göras. Den kan inte kontakta DCS och lagra det nya klustertillståndet där, så hela klustret går över i skrivskyddad. Och väntar antingen på manuellt ingripande från operatören eller på att DCS ska återhämta sig.

Grovt sett blir DCS en tjänst för oss lika viktig som själva basen?

Jaja. I så många moderna företag är Service Discovery en integrerad del av infrastrukturen. Det implementeras redan innan det ens fanns en databas i infrastrukturen. Relativt sett lanserades infrastrukturen, distribuerades i DC, och vi har omedelbart Service Discovery. Om det är Consul kan DNS byggas på det. Om detta är Etcd, så kan det finnas en del från Kubernetes-klustret, där allt annat kommer att distribueras. Det förefaller mig som att Service Discovery redan är en integrerad del av moderna infrastrukturer. Och de tänker på det mycket tidigare än på databaser.

Tack!

Källa: will.com