Patroni Failure Stories eller hvordan du går ned i din PostgreSQL-klynge. Alexey Lesovsky

Hovedmålet med Patroni er at levere høj tilgængelighed til PostgreSQL. Men Patroni er bare en skabelon, ikke et færdigt værktøj (hvilket generelt står i dokumentationen). Ved første øjekast, efter at have sat Patroni op i testlaboratoriet, kan du se, hvilket fantastisk værktøj det er, og hvor nemt det håndterer vores forsøg på at bryde klyngen. Men i praksis, i et produktionsmiljø, sker alt ikke altid lige så smukt og elegant som i et testlaboratorium.

Jeg vil fortælle dig lidt om mig selv. Jeg startede som systemadministrator. Arbejdede med webudvikling. Jeg har arbejdet hos Data Egret siden 2014. Virksomheden beskæftiger sig med rådgivning inden for Postgres. Og vi betjener lige præcis Postgres, og vi samarbejder med Postgres hver dag, så vi har forskellig ekspertise relateret til driften.

Og i slutningen af ​​2018 begyndte vi langsomt at bruge Patroni. Og nogle erfaringer er blevet samlet. Vi diagnosticerede det på en eller anden måde, tunede det, kom til vores bedste praksis. Og i denne rapport vil jeg tale om dem.

Bortset fra Postgres elsker jeg Linux. Jeg kan godt lide at rode rundt i det og udforske, jeg kan godt lide at samle kerner. Jeg elsker virtualisering, containere, docker, Kubernetes. Alt dette interesserer mig, fordi de gamle admin-vaner påvirker. Jeg kan godt lide at beskæftige mig med overvågning. Og jeg elsker postgres-ting relateret til administration, dvs. replikering, backup. Og i min fritid skriver jeg i Go. Jeg er ikke softwareingeniør, jeg skriver bare for mig selv i Go. Og det giver mig glæde.

• Jeg tror, ​​mange af jer ved, at Postgres ikke har HA (High Availability) ud af kassen. For at få HA skal du installere noget, konfigurere det, gøre en indsats og få det.
• Der er flere værktøjer og Patroni er et af dem, der løser HA ret cool og meget godt. Men ved at lægge det hele i et testlaboratorium og køre det, kan vi se, at det hele fungerer, vi kan genskabe nogle problemer, se hvordan Patroni betjener dem. Og vi vil se, at det hele fungerer fantastisk.
• Men i praksis stod vi over for forskellige problemer. Og jeg vil tale om disse problemer.
• Jeg vil fortælle dig, hvordan vi diagnosticerede det, hvad vi justerede – om det hjalp os eller ej.

• Jeg vil ikke fortælle dig, hvordan du installerer Patroni, fordi du kan google på internettet, du kan se på konfigurationsfilerne for at forstå, hvordan det hele starter, hvordan det er konfigureret. Du kan forstå ordningerne, arkitekturerne, finde information om det på internettet.
• Jeg vil ikke tale om en andens oplevelse. Jeg vil kun tale om de problemer, vi stod over for.
• Og jeg vil ikke tale om problemer, der er uden for Patroni og PostgreSQL. Hvis der for eksempel er problemer forbundet med balancering, når vores klynge er brudt sammen, vil jeg ikke tale om det.

Og en lille ansvarsfraskrivelse inden vi starter vores rapport.

Alle disse problemer, som vi stødte på, havde vi dem i de første 6-7-8 måneders drift. Med tiden kom vi til vores interne bedste praksis. Og vores problemer forsvandt. Derfor blev rapporten offentliggjort for omkring et halvt år siden, da det hele var frisk i mit hoved, og jeg huskede det hele perfekt.

I løbet af udarbejdelsen af ​​rapporten rejste jeg allerede gamle obduktioner, kiggede på loggene. Og nogle af detaljerne kunne være glemt, eller nogle af nogle detaljer kunne ikke undersøges fuldt ud under analysen af ​​problemerne, så på nogle punkter kan det se ud til, at problemerne ikke er helt overvejet, eller der mangler noget information. Så jeg beder dig undskylde mig for dette øjeblik.

Hvad er Patroni?

• Dette er en skabelon til at bygge HA. Det står der i dokumentationen. Og set fra mit synspunkt er det en meget korrekt præcisering. Patroni er ikke en sølvkugle, der vil løse alle dine problemer, det vil sige, du skal gøre en indsats for at få det til at fungere og give fordele.
• Dette er en agenttjeneste, der er installeret på hver databasetjeneste og er en slags init-system til din Postgres. Det starter Postgres, stopper, genstarter, omkonfigurerer og ændrer topologien for din klynge.
• Følgelig, for at gemme klyngens tilstand, er dets nuværende repræsentation, som det ser ud, nødvendigt med en form for lagring. Og fra dette synspunkt tog Patroni vejen til at lagre tilstand i et eksternt system. Det er et distribueret konfigurationslagringssystem. Det kan være Etcd, Consul, ZooKeeper eller kubernetes Etcd, altså en af ​​disse muligheder.
• Og en af ​​funktionerne ved Patroni er, at du får autofileren ud af kassen, kun ved at sætte den op. Hvis vi tager Repmgr til sammenligning, så er filen inkluderet der. Med Repmgr får vi en overgang, men hvis vi vil have en autofiler, så skal vi konfigurere den yderligere. Patroni har allerede en autofiler ud af æsken.
• Og der er mange andre ting. For eksempel vedligeholdelse af konfigurationer, hældning af nye replikaer, backup osv. Men dette er uden for rapportens rammer, jeg vil ikke tale om det.

Og et lille resultat er, at Patronis hovedopgave er at lave en autofil godt og pålideligt, så vores klynge forbliver operationel, og applikationen ikke bemærker ændringer i klyngetopologien.

Men når vi begynder at bruge Patroni, bliver vores system lidt mere kompliceret. Hvis vi tidligere havde Postgres, så får vi Patroni selv, når vi bruger Patroni, vi får DCS, hvor tilstanden er gemt. Og det hele skal fungere på en eller anden måde. Så hvad kan gå galt?

Kan gå i stykker:

• Postgres kan gå i stykker. Det kan være en mester eller en replika, en af ​​dem kan mislykkes.
• Patroni selv kan gå i stykker.
• DCS'en, hvor tilstanden er gemt, kan gå i stykker.
• Og netværket kan gå i stykker.

Alle disse punkter vil jeg overveje i betænkningen.

Jeg vil overveje sager, efterhånden som de bliver mere komplekse, ikke ud fra det synspunkt, at sagen involverer mange komponenter. Og set fra subjektive følelsers synspunkt, at denne sag var svær for mig, var det svær at skille den ad ... og omvendt, en sag var let, og det var let at skille den ad.

Og det første tilfælde er det nemmeste. Dette er tilfældet, da vi tog en databaseklynge og implementerede vores DCS-lager på den samme klynge. Dette er den mest almindelige fejl. Dette er en fejl i bygningsarkitekturer, dvs. at kombinere forskellige komponenter på ét sted.

Så der var en filur, lad os gå til at beskæftige os med, hvad der skete.

Og her er vi interesserede i, hvornår filerne skete. Det vil sige, at vi er interesserede i dette øjeblik i tiden, hvor klyngetilstanden ændrede sig.

Men filen er ikke altid øjeblikkelig, dvs. den tager ikke nogen tidsenhed, den kan blive forsinket. Det kan være langtidsholdbart.

Derfor har det et starttidspunkt og et sluttidspunkt, dvs. det er en kontinuerlig begivenhed. Og vi deler alle begivenheder op i tre intervaller: vi har tid før fil, under fil og efter fil. Det vil sige, at vi overvejer alle begivenheder i denne tidslinje.

Og den første ting, når en filur skete, søger vi efter årsagen til det, der skete, hvad der var årsagen til, hvad der førte til filen.

Hvis vi ser på stokkene, vil de være klassiske Patroni-stammer. Han fortæller os i dem, at serveren er blevet master, og rollen som master er gået over til denne node. Her er det fremhævet.

Dernæst skal vi forstå, hvorfor fileren skete, dvs. hvilke hændelser der skete, der fik masterrollen til at flytte fra en node til en anden. Og i dette tilfælde er alt simpelt. Vi har en fejl i interaktion med lagersystemet. Mesteren indså, at han ikke kunne arbejde med DCS, det vil sige, at der var en form for problem med interaktionen. Og han siger, at han ikke længere kan være mester og siger op. Denne linje "degraderet selv" siger præcis det.

Hvis vi ser på de begivenheder, der gik forud for filen, kan vi se der netop de årsager, der var problemet for fortsættelsen af ​​guiden.

Hvis vi ser på Patroni-loggene, vil vi se, at vi har mange fejl, timeouts, dvs. Patroni-agenten kan ikke arbejde med DCS. I dette tilfælde er dette Consul-agent, som kommunikerer på port 8500.

Og problemet her er, at Patroni og databasen kører på den samme vært. Og Consul-serverne blev lanceret på den samme node. Ved at oprette en belastning på serveren skabte vi også problemer for Consul-serverne. De kunne ikke kommunikere ordentligt.

Efter nogen tid, da belastningen aftog, var vores Patroni i stand til at kommunikere med agenter igen. Det normale arbejde blev genoptaget. Og den samme Pgdb-2-server blev master igen. Det vil sige, at der var et lille flip, på grund af hvilket noden fratrådte mesterens beføjelser og derefter overtog dem igen, det vil sige alt vendte tilbage, som det var.

Og dette kan betragtes som en falsk alarm, eller det kan anses for, at Patroni gjorde alt rigtigt. Det vil sige, at han indså, at han ikke kunne opretholde klyngens tilstand og fjernede sin autoritet.

Og her opstod problemet på grund af, at Consul-serverne er på samme hardware som baserne. Følgelig enhver belastning: uanset om det er belastningen på diske eller processorer, påvirker det også interaktionen med Consul-klyngen.

Og vi besluttede, at det ikke skulle bo sammen, vi tildelte en separat klynge til konsul. Og Patroni arbejdede allerede med en separat konsul, det vil sige, der var en separat Postgres-klynge, en separat konsul-klynge. Dette er en grundlæggende instruktion i, hvordan man bærer og opbevarer alle disse ting, så det ikke lever sammen.

Som en mulighed kan du vride parametrene ttl, loop_wait, retry_timeout, dvs. forsøge at overleve disse kortsigtede belastningstoppe ved at øge disse parametre. Men dette er ikke den mest egnede mulighed, fordi denne belastning kan være lang i tid. Og vi vil simpelthen gå ud over disse grænser for disse parametre. Og det hjælper måske ikke rigtigt.

Det første problem, som du forstår, er enkelt. Vi tog og satte DCS'en sammen med basen, vi fik et problem.

Det andet problem ligner det første. Det ligner, at vi igen har interoperabilitetsproblemer med DCS-systemet.

Hvis vi ser på loggene, vil vi se, at vi igen har en kommunikationsfejl. Og Patroni siger, at jeg ikke kan interagere med DCS, så den nuværende master går i replikatilstand.

Den gamle mester bliver en replika, her fungerer Patroni, som det skal være. Den kører pg_rewind for at spole transaktionsloggen tilbage og derefter oprette forbindelse til den nye master for at indhente den nye master. Her træner Patroni, som han skal.

Her skal vi finde det sted, der gik forud for fileren, altså de fejl, der gjorde, at vi havde en fil. Og i denne henseende er Patroni-logfiler ret praktiske at arbejde med. Han skriver de samme beskeder med et bestemt interval. Og hvis vi begynder at scrolle gennem disse logs hurtigt, så vil vi se på logfilerne, at logfilerne er ændret, hvilket betyder, at nogle problemer er begyndt. Vi vender hurtigt tilbage til dette sted, se hvad der sker.

Og i en normal situation ser loggene nogenlunde sådan ud. Ejeren af ​​låsen kontrolleres. Og hvis ejeren for eksempel er skiftet, så kan der opstå nogle hændelser, som Patroni skal reagere på. Men i dette tilfælde har vi det fint. Vi leder efter det sted, hvor fejlene startede.

Og efter at have scrollet til det punkt, hvor fejlene begyndte at dukke op, ser vi, at vi har haft en auto-filover. Og da vores fejl var relateret til interaktion med DCS og i vores tilfælde brugte vi Consul, ser vi også på Consul logs, hvad der skete der.

Ved nogenlunde sammenligning af tiden for indgiveren og tiden i konsul-loggene, ser vi, at vores naboer i konsul-klyngen begyndte at tvivle på eksistensen af ​​andre medlemmer af konsul-klyngen.

Og hvis man også kigger på andre Consul-agenters logs, kan man også se, at der sker en form for netværkskollaps der. Og alle medlemmer af Consul-klyngen tvivler på hinandens eksistens. Og dette var drivkraften til filureren.

Hvis du ser på, hvad der skete før disse fejl, kan du se, at der er alle mulige fejl, for eksempel deadline, RPC faldt, det vil sige, at der helt klart er en form for problem i samspillet mellem Consul-klyngemedlemmerne med hinanden .

Det enkleste svar er at reparere netværket. Men for mig, der står på podiet, er det nemt at sige dette. Men omstændighederne er sådan, at kunden ikke altid har råd til at reparere netværket. Han bor muligvis i en DC og er muligvis ikke i stand til at reparere netværket, påvirke udstyret. Og så nogle andre muligheder er nødvendige.

Der er muligheder:

• Den enkleste mulighed, som efter min mening er skrevet, selv i dokumentationen, er at deaktivere konsul-tjek, det vil sige blot passere et tomt array. Og vi fortæller konsul-agenten ikke at bruge nogen checks. Med disse kontroller kan vi ignorere disse netværksstorme og ikke starte en fil.
• En anden mulighed er at dobbelttjekke raft_multiplier. Dette er en parameter for selve Consul-serveren. Som standard er den indstillet til 5. Denne værdi anbefales af dokumentationen til iscenesættelsesmiljøer. Faktisk påvirker dette hyppigheden af ​​beskeder mellem medlemmer af Consul-netværket. Faktisk påvirker denne parameter hastigheden af ​​servicekommunikation mellem medlemmer af Consul-klyngen. Og til produktion anbefales det allerede at reducere det, så noderne udveksler beskeder oftere.
• En anden mulighed, vi har fundet på, er at øge prioriteringen af ​​Consul-processer blandt andre processer til operativsystemets procesplanlægger. Der er sådan en "god" parameter, den bestemmer bare prioriteten af ​​processer, der tages i betragtning af OS-planlæggeren ved planlægning. Vi har også reduceret den pæne værdi for Consul-agenter, dvs. øget prioritet, så operativsystemet giver Consul-processer mere tid til at arbejde og eksekvere deres kode. I vores tilfælde løste dette vores problem.
• En anden mulighed er ikke at bruge Consul. Jeg har en ven, der er stor tilhænger af Etcd. Og vi skændes jævnligt med ham, hvad der er bedre Etcd eller Consul. Men i forhold til hvad der er bedre, er vi som regel enige med ham i, at Consul har en agent, der skal køre på hver node med en database. Det vil sige, at interaktionen mellem Patroni og Consul-klyngen går gennem denne agent. Og denne agent bliver en flaskehals. Hvis der sker noget med agenten, kan Patroni ikke længere arbejde med Consul-klyngen. Og dette er problemet. Der er ingen agent i Etcd-planen. Patroni kan arbejde direkte med en liste over Etcd-servere og allerede kommunikere med dem. I denne forbindelse, hvis du bruger Etcd i din virksomhed, så vil Etcd sandsynligvis være et bedre valg end Consul. Men vi hos vores kunder er altid begrænset af, hvad kunden har valgt og bruger. Og vi har Consul for det meste til alle kunder.
• Og det sidste punkt er at revidere parameterværdierne. Vi kan hæve disse parametre i håb om, at vores kortsigtede netværksproblemer bliver korte og ikke falder uden for disse parametres rækkevidde. På denne måde kan vi reducere Patronis aggressivitet til autofil, hvis der opstår nogle netværksproblemer.

Jeg tror, ​​at mange, der bruger Patroni, kender denne kommando.

Denne kommando viser den aktuelle tilstand for klyngen. Og ved første øjekast kan dette billede virke normalt. Vi har en master, vi har en replika, der er ingen replikationsforsinkelse. Men dette billede er normalt, præcis indtil vi ved, at denne klynge skal have tre noder, ikke to.

Derfor var der en autofil. Og efter denne autofil forsvandt vores replika. Vi skal finde ud af hvorfor hun forsvandt og bringe hende tilbage, genoprette hende. Og vi går igen til loggene og ser, hvorfor vi havde en auto-filover.

I dette tilfælde blev den anden replika mesteren. Det er okay her.

Og vi skal se på den replika, der faldt af, og som ikke er i klyngen. Vi åbner Patroni-logfilerne og ser, at vi havde et problem under processen med at oprette forbindelse til klyngen på pg_rewind-stadiet. For at oprette forbindelse til klyngen skal du spole transaktionsloggen tilbage, anmode om den nødvendige transaktionslog fra masteren og bruge den til at indhente masteren.

I dette tilfælde har vi ikke en transaktionslog, og replikaen kan ikke starte. Derfor stopper vi Postgres med en fejl. Og derfor er den ikke i klyngen.

Vi skal forstå, hvorfor det ikke er i klyngen, og hvorfor der ikke var nogen logfiler. Vi går til den nye mester og ser på, hvad han har i loggene. Det viser sig, at da pg_rewind blev udført, opstod der et kontrolpunkt. Og nogle af de gamle transaktionslogfiler blev simpelthen omdøbt. Da den gamle master forsøgte at oprette forbindelse til den nye master og forespørge på disse logfiler, var de allerede omdøbt, de eksisterede bare ikke.

Jeg sammenlignede tidsstempler, når disse begivenheder skete. Og dér er forskellen bogstaveligt talt 150 millisekunder, det vil sige checkpointet afsluttet på 369 millisekunder, WAL-segmenterne blev omdøbt. Og bogstaveligt talt i 517, efter 150 millisekunder, startede tilbagespoling på den gamle replika. Det vil sige, bogstaveligt talt 150 millisekunder var nok for os, så replikaen ikke kunne forbinde og tjene.

Hvad er mulighederne?

Vi brugte oprindeligt replikationsslots. Vi syntes det var godt. Selvom vi i den første fase af driften slukkede for spalterne. Det forekom for os, at hvis slots akkumulerer en masse WAL-segmenter, kan vi droppe masteren. Han vil falde. Vi led i nogen tid uden slots. Og vi indså, at vi har brug for pladser, vi returnerede pladserne.

Men der er et problem her, at når masteren går til replikaen, sletter den slotsene og sletter WAL-segmenterne sammen med slotsene. Og for at eliminere dette problem besluttede vi at hæve parameteren wal_keep_segments. Det er standard til 8 segmenter. Vi hævede det til 1 og så på, hvor meget ledig plads vi havde. Og vi donerede 000 gigabyte til wal_keep_segments. Det vil sige, at når vi skifter, har vi altid en reserve på 16 gigabyte transaktionslogfiler på alle noder.

Og plus - det er stadig relevant til langsigtede vedligeholdelsesopgaver. Lad os sige, at vi skal opdatere en af ​​replikaerne. Og vi vil gerne slå det fra. Vi skal opdatere softwaren, måske operativsystemet, noget andet. Og når vi slukker for en replika, fjernes spalten til den replika også. Og hvis vi bruger en lille wal_keep_segments, så vil transaktionsloggene gå tabt med et langt fravær af en replika. Vi vil rejse en replika, den vil anmode om de transaktionslogfiler, hvor den stoppede, men de er muligvis ikke på masteren. Og replikaen vil heller ikke kunne forbindes. Derfor har vi et stort lager af magasiner.

Vi har en produktionsbase. Der er allerede projekter i gang.

Der var en fil. Vi gik ind og kiggede – alt er i orden, replikaerne er på plads, der er ingen replikationsforsinkelse. Der er heller ingen fejl i loggene, alt er i orden.

Produktteamet siger, at der burde være nogle data, men vi ser det fra én kilde, men vi ser det ikke i databasen. Og vi skal forstå, hvad der skete med dem.

Det er tydeligt, at pg_rewind savnede dem. Vi forstod det straks, men gik for at se, hvad der skete.

I loggene kan vi altid finde, hvornår fileren skete, hvem der blev mester, og vi kan bestemme, hvem der var den gamle mester, og hvornår han ønskede at blive en replika, dvs. vi har brug for disse logfiler for at finde ud af mængden af ​​transaktionslogfiler, der var fortabt.

Vores gamle mester er genstartet. Og Patroni blev registreret i autorun. Lancerede Patroni. Så startede han Postgres. Mere præcist, før du startede Postgres og før du gjorde det til en replika, lancerede Patroni pg_rewind-processen. Derfor slettede han en del af transaktionsloggene, downloadede nye og tilsluttede. Her arbejdede Patroni smart, altså som forventet. Klyngen er blevet gendannet. Vi havde 3 noder, efter filerne 3 noder - alt er fedt.

Vi har mistet nogle data. Og vi skal forstå, hvor meget vi har mistet. Vi leder efter netop det øjeblik, hvor vi havde en tilbagespoling. Vi kan finde det i sådanne journaloptegnelser. Rewind startede, gjorde noget der og sluttede.

Vi skal finde den position i transaktionsloggen, hvor den gamle mester slap. I dette tilfælde er dette mærket. Og vi har brug for et andet mærke, det vil sige afstanden, hvormed den gamle mester adskiller sig fra den nye.

Vi tager den sædvanlige pg_wal_lsn_diff og sammenligner disse to mærker. Og i dette tilfælde får vi 17 megabyte. Meget eller lidt, bestemmer enhver selv. For for nogen er 17 megabyte ikke meget, for nogen er det meget og uacceptabelt. Her bestemmer hver enkelt selv i overensstemmelse med virksomhedens behov.

Men hvad har vi selv fundet ud af?

Først skal vi selv bestemme - har vi altid brug for, at Patroni automatisk starter efter en systemgenstart? Det sker ofte, at vi skal til den gamle mester, se hvor langt han er nået. Måske inspicere segmenter af transaktionsloggen, se hvad der er der. Og for at forstå, om vi kan miste disse data, eller om vi skal køre den gamle master i selvstændig tilstand for at trække disse data ud.

Og først efter det skal vi beslutte, om vi kan kassere disse data, eller vi kan gendanne dem, forbinde denne node som en replika til vores klynge.

Derudover er der en "maximum_lag_on_failover" parameter. Som standard, hvis min hukommelse tjener mig, har denne parameter en værdi på 1 megabyte.

Hvordan arbejder han? Hvis vores replika er bagud med 1 megabyte data i replikeringsforsinkelsen, så deltager denne replika ikke i valget. Og hvis der pludselig er en filover, ser Patroni på, hvilke replikaer der halter bagefter. Hvis de er bagud med et stort antal transaktionslogfiler, kan de ikke blive en master. Dette er en meget god sikkerhedsfunktion, der forhindrer dig i at miste en masse data.

Men der er et problem i, at replikationsforsinkelsen i Patroni-klyngen og DCS opdateres med et bestemt interval. Jeg tror, ​​30 sekunder er standard ttl værdi.

Følgelig kan der være en situation, hvor der er én replikationsforsinkelse for replikaer i DCS, men faktisk kan der være en helt anden forsinkelse, eller der er muligvis ingen forsinkelse overhovedet, dvs. denne ting er ikke realtime. Og det afspejler ikke altid det virkelige billede. Og det er ikke værd at lave fancy logik på det.

Og risikoen for tab består altid. Og i værste fald én formel, og i gennemsnitstilfældet en anden formel. Det vil sige, at når vi planlægger implementeringen af ​​Patroni og evaluerer, hvor meget data vi kan miste, skal vi stole på disse formler og groft forestille os, hvor meget data vi kan miste.

Og der er gode nyheder. Når den gamle mester er gået videre, kan han gå videre på grund af nogle baggrundsprocesser. Det vil sige, der var en form for autovakuum, han skrev dataene, gemte dem i transaktionsloggen. Og vi kan nemt ignorere og miste disse data. Der er intet problem i dette.

Og sådan ser logfilerne ud, hvis maximum_lag_on_failover er indstillet, og der er opstået en filer, og du skal vælge en ny master. Replikaen vurderer sig selv som ude af stand til at deltage i valget. Og hun nægter at deltage i kapløbet om lederen. Og hun venter på, at der bliver udvalgt en ny mester, så hun så kan forbinde sig til den. Dette er en yderligere foranstaltning mod tab af data.

Her har vi et produktteam, som skrev, at deres produkt har problemer med Postgres. Samtidig kan selve masteren ikke tilgås, fordi den ikke er tilgængelig via SSH. Og autofilen sker heller ikke.

Denne vært blev tvunget til at genstarte. På grund af genstarten skete der en auto-fil, selvom det var muligt at lave en manuel auto-fil, som jeg nu forstår. Og efter genstarten skal vi allerede se, hvad vi havde med den nuværende master.

Samtidig vidste vi på forhånd, at vi havde problemer med diske, det vil sige, at vi allerede fra overvågningen vidste, hvor vi skulle grave, og hvad vi skulle kigge efter.

Vi kom ind i postgres-loggen, begyndte at se, hvad der skete der. Vi så commits, der varede der i et, to, tre sekunder, hvilket slet ikke er normalt. Vi så, at vores autovakuum starter meget langsomt og mærkeligt. Og vi så midlertidige filer på disken. Det vil sige, disse er alle indikatorer for problemer med diske.

Vi kiggede ind i systemet dmesg (kernelog). Og vi så, at vi har problemer med en af ​​diskene. Diskens undersystem var software Raid. Vi kiggede på /proc/mdstat og så, at vi manglede et drev. Det vil sige, at der er et Raid på 8 diske, vi mangler en. Hvis du omhyggeligt ser på diaset, så kan du i outputtet se, at vi ikke har sde der. Hos os er disken betinget faldet ud. Dette udløste diskproblemer, og applikationer oplevede også problemer, når de arbejdede med Postgres-klyngen.

Og i dette tilfælde ville Patroni ikke hjælpe os på nogen måde, fordi Patroni ikke har til opgave at overvåge serverens tilstand, diskens tilstand. Og vi skal overvåge sådanne situationer ved ekstern overvågning. Vi tilføjede hurtigt diskovervågning til ekstern overvågning.

Og der var sådan en tanke - kunne fægtning eller vagthund-software hjælpe os? Vi troede, at han næppe ville have hjulpet os i dette tilfælde, for under problemerne fortsatte Patroni med at interagere med DCS-klyngen og så ikke noget problem. Det vil sige, fra DCS's og Patronis synspunkt var alt fint med klyngen, selvom der faktisk var problemer med disken, var der problemer med tilgængeligheden af ​​databasen.

Efter min mening er dette et af de mærkeligste problemer, som jeg har undersøgt i meget lang tid, jeg har læst en masse logs, omplukket og kaldt det en klyngesimulator.

Problemet var, at den gamle mester ikke kunne blive en normal replika, dvs. Patroni startede den, Patroni viste, at denne node var til stede som en replika, men samtidig var det ikke en normal replika. Nu vil du se hvorfor. Dette er, hvad jeg har holdt fra analysen af ​​det problem.

Og hvordan startede det hele? Det startede, som i det forrige problem, med skivebremser. Vi havde commits for et sekund, to.

Der var brud i forbindelserne, det vil sige, at klienter blev revet i stykker.

Der var blokeringer af varierende sværhedsgrad.

Og følgelig er diskens undersystem ikke særlig lydhør.

Og det mest mystiske for mig er den øjeblikkelige nedlukningsanmodning, der ankom. Postgres har tre nedlukningstilstande:

• Det er yndefuldt, når vi venter på, at alle klienter afbryder forbindelsen på egen hånd.
• Der er hurtigt, når vi tvinger klienter til at afbryde forbindelsen, fordi vi skal lukke ned.
• Og straks. I dette tilfælde fortæller omgående ikke engang kunderne om at lukke ned, det lukker bare ned uden varsel. Og til alle klienter sender operativsystemet allerede en RST-meddelelse (en TCP-meddelelse om, at forbindelsen er afbrudt, og klienten ikke har mere at fange).

Hvem sendte dette signal? Postgres baggrundsprocesser sender ikke sådanne signaler til hinanden, dvs. dette er kill-9. De sender ikke sådanne ting til hinanden, de reagerer kun på sådanne ting, dvs. dette er en nødsituation Postgres genstart. Hvem der har sendt det, ved jeg ikke.

Jeg kiggede på den "sidste" kommando, og jeg så en person, der også loggede på denne server hos os, men jeg var for genert til at stille et spørgsmål. Måske var det kill -9. Jeg ville se kill -9 i logfilerne, fordi Postgres siger, at det tog kill -9, men jeg så det ikke i loggene.

Når jeg kiggede videre, så jeg, at Patroni ikke skrev til loggen i ret lang tid - 54 sekunder. Og hvis vi sammenligner to tidsstempler, var der ingen beskeder i omkring 54 sekunder.

Og i løbet af denne tid var der en autofil. Patroni gjorde et godt stykke arbejde her igen. Vores gamle mester var utilgængelig, noget skete med ham. Og valget af en ny mester begyndte. Alt fungerede godt her. Vores pgsql01 er blevet den nye leder.

Vi har en kopi, der er blevet en mester. Og der er et andet svar. Og der var problemer med den anden kopi. Hun forsøgte at omkonfigurere. Som jeg forstår det, forsøgte hun at ændre recovery.conf, genstarte Postgres og oprette forbindelse til den nye master. Hun skriver beskeder hvert 10. sekund om, at hun prøver, men det lykkes ikke.

Og under disse forsøg ankommer et øjeblikkeligt nedlukningssignal til den gamle mester. Masteren genstartes. Og også gendannelse stopper, fordi den gamle mester går i genstart. Det vil sige, at replikaen ikke kan oprette forbindelse til den, fordi den er i shutdown-tilstand.

På et tidspunkt virkede det, men replikeringen startede ikke.

Mit eneste gæt er, at der var en gammel masteradresse i recovery.conf. Og da en ny mester dukkede op, forsøgte den anden replika stadig at oprette forbindelse til den gamle mester.

Da Patroni startede op på den anden replika, startede noden op, men kunne ikke replikere. Og der blev dannet en replikationsforsinkelse, som så nogenlunde sådan her ud. Det vil sige, at alle tre noder var på plads, men den anden node haltede bagefter.

På samme tid, hvis man ser på de logfiler, der blev skrevet, kunne man se, at replikering ikke kunne starte, fordi transaktionsloggene var forskellige. Og de transaktionslogfiler, som masteren tilbyder, som er specificeret i recovery.conf, passer simpelthen ikke til vores nuværende node.

Og her tog jeg fejl. Jeg var nødt til at komme og se, hvad der var i recovery.conf for at teste min hypotese om, at vi havde forbindelse til den forkerte mester. Men så beskæftigede jeg mig bare med det her, og det faldt mig ikke ind, eller jeg så, at replikaen haltede og skulle fyldes op igen, det vil sige, at jeg på en eller anden måde arbejdede skødesløst. Dette var min joint.

Efter 30 minutter kom administratoren allerede, dvs. jeg genstartede Patroni på replikaen. Jeg har allerede sat en stopper for det, jeg tænkte, at det skulle fyldes op igen. Og jeg tænkte - jeg genstarter Patroni, måske dukker der noget godt ud. Genopretningen startede. Og basen åbnede endda, den var klar til at acceptere forbindelser.

Replikering er startet. Men et minut senere faldt hun af med en fejl om, at transaktionslogfiler ikke passer til hende.

Jeg troede, jeg ville genstarte igen. Jeg genstartede Patroni igen, og jeg genstartede ikke Postgres, men genstartede Patroni i håb om, at det på magisk vis ville starte databasen.

Replikeringen startede igen, men mærkerne i transaktionsloggen var anderledes, de var ikke de samme som det forrige startforsøg. Replikationen stoppede igen. Og budskabet var allerede lidt anderledes. Og det var ikke særlig informativt for mig.

Og så går det op for mig - hvad hvis jeg genstarter Postgres, på dette tidspunkt laver jeg et checkpoint på den aktuelle master for at flytte punktet i transaktionsloggen lidt frem, så gendannelsen starter fra et andet øjeblik? Derudover havde vi stadig lagre af WAL.

Jeg genstartede Patroni, lavede et par kontrolpunkter på masteren, et par genstartpunkter på replikaen, da den åbnede. Og det hjalp. Jeg tænkte længe over, hvorfor det hjalp, og hvordan det virkede. Og replikken startede. Og replikationen blev ikke længere revet i stykker.

Sådan et problem for mig er et af de mere mystiske, som jeg stadig undrer mig over, hvad der virkelig skete der.

Hvad er implikationerne her? Patroni kan fungere efter hensigten og uden fejl. Men det er samtidig ikke en 100% garanti for, at alt er i orden hos os. Replikaen starter muligvis, men den kan være i en semi-fungerende tilstand, og applikationen kan ikke fungere med en sådan replika, fordi der vil være gamle data.

Og efter filerne skal du altid kontrollere, at alt er i orden med klyngen, det vil sige, at der er det nødvendige antal replikaer, der er ingen replikationsforsinkelse.

Og efterhånden som vi gennemgår disse spørgsmål, vil jeg komme med anbefalinger. Jeg prøvede at kombinere dem i to slides. Sandsynligvis kunne alle historierne kombineres til to slides og kun fortælles.

Når du bruger Patroni, skal du have overvågning. Du bør altid vide, hvornår en autofileover fandt sted, for hvis du ikke ved, du havde en autofileover, har du ingen kontrol over klyngen. Og det er slemt.

Efter hver fil skal vi altid manuelt kontrollere klyngen. Vi skal sikre os, at vi altid har et opdateret antal replikaer, der er ingen replikeringsforsinkelse, der er ingen fejl i logfilerne relateret til streaming replikering, med Patroni, med DCS-systemet.

Automatisering kan fungere med succes, Patroni er et meget godt værktøj. Det kan fungere, men dette vil ikke bringe klyngen til den ønskede tilstand. Og hvis vi ikke finder ud af det, får vi problemer.

Og Patroni er ikke en sølvkugle. Vi mangler stadig at forstå, hvordan Postgres fungerer, hvordan replikering fungerer, og hvordan Patroni arbejder med Postgres, og hvordan kommunikation mellem noder leveres. Dette er nødvendigt for at kunne løse problemer med dine hænder.

Hvordan griber jeg spørgsmålet om diagnose an? Det skete, at vi arbejder med forskellige klienter, og ingen har en ELK-stak, og vi skal sortere logfilerne ved at åbne 6 konsoller og 2 faner. I den ene fane er disse Patroni-logfilerne for hver node, i den anden fane er disse Consul-logfilerne eller Postgres, hvis det er nødvendigt. Det er meget svært at diagnosticere dette.

Hvilke tilgange har jeg taget? For det første kigger jeg altid, når filerne er ankommet. Og for mig er dette et vandskel. Jeg ser på, hvad der skete før arkiveren, under arkivet og efter arkivet. Fileover har to mærker: dette er start- og sluttidspunktet.

Dernæst kigger jeg i loggene efter begivenheder før filen, som gik forud for filen, dvs. jeg leder efter årsagerne til, hvorfor filen skete.

Og dette giver et billede af at forstå, hvad der skete, og hvad der kan gøres i fremtiden, så sådanne omstændigheder ikke opstår (og som følge heraf er der ingen filer).

Og hvor ser vi normalt hen? Jeg ser:

• Først til Patroni-loggene.
• Dernæst ser jeg på Postgres-loggene eller DCS-loggene, alt efter hvad der blev fundet i Patroni-loggene.
• Og systemlogfilerne giver også nogle gange en forståelse af, hvad der forårsagede filen.

Hvordan har jeg det med Patroni? Jeg har et meget godt forhold til Patroni. Efter min mening er dette det bedste, der findes i dag. Jeg kender mange andre produkter. Disse er Stolon, Repmgr, Pg_auto_failover, PAF. 4 værktøjer. Jeg prøvede dem alle. Patroni er min favorit.

Hvis de spørger mig: "Anbefaler jeg Patroni?". Jeg vil sige ja, fordi jeg kan lide Patroni. Og jeg tror, ​​jeg har lært at lave mad.

Hvis du er interesseret i at se, hvilke andre problemer der er med Patroni udover de problemer, jeg har nævnt, kan du altid tjekke siden ud spørgsmål på GitHub. Der er mange forskellige historier og mange interessante emner diskuteres der. Og som et resultat blev nogle fejl introduceret og løst, det vil sige, dette er en interessant læsning.

Der er nogle interessante historier om folk, der skyder sig selv i foden. Meget informativ. Du læser og forstår, at det ikke er nødvendigt at gøre det. Jeg satte kryds ved mig selv.

Og jeg vil gerne sige en stor tak til Zalando for at udvikle dette projekt, nemlig til Alexander Kukushkin og Alexey Klyukin. Aleksey Klyukin er en af ​​medforfatterne, han arbejder ikke længere hos Zalando, men det er to personer, der begyndte at arbejde med dette produkt.

Og jeg synes, at Patroni er en meget cool ting. Jeg er glad for, at hun findes, det er interessant med hende. Og en stor tak til alle de bidragydere, der skriver patches til Patroni. Jeg håber, at Patroni bliver mere moden, cool og effektiv med alderen. Det er allerede funktionelt, men jeg håber, det bliver endnu bedre. Derfor, hvis du planlægger at bruge Patroni, så vær ikke bange. Dette er en god løsning, den kan implementeres og bruges.

Det er alt. Spørg, hvis du har spørgsmål.

R'RѕRїSЂRѕSЃS <

Tak for rapporten! Hvis du efter en filer stadig skal kigge der meget omhyggeligt, hvorfor har vi så brug for en automatisk filer?

For det er nye ting. Vi har kun været sammen med hende i et år. Bedre at være sikker. Vi vil gerne ind og se, at alt virkelig fungerede, som det skulle. Dette er niveauet af voksen mistillid - det er bedre at dobbelttjekke og se.

For eksempel gik vi om morgenen og kiggede, ikke?

Ikke om morgenen, vi lærer normalt om autofilen næsten med det samme. Vi modtager meddelelser, vi ser, at der er opstået en autofil. Vi går næsten med det samme og kigger. Men alle disse kontroller bør bringes til overvågningsniveauet. Hvis du tilgår Patroni via REST API, er der en historie. Ved historik kan du se tidsstemplerne, når filen skete. Ud fra dette kan der foretages overvågning. Du kan se historien, hvor mange begivenheder der var der. Hvis vi har flere hændelser, er der opstået en autofil. Du kan gå og se. Eller vores overvågningsautomatisering kontrollerede, at vi har alle replikaerne på plads, der er ingen forsinkelse, og alt er i orden.

Tak!

Mange tak for den gode historie! Hvis vi flyttede DCS-klyngen et sted langt fra Postgres-klyngen, så skal denne klynge også serviceres med jævne mellemrum? Hvad er den bedste praksis, at nogle dele af DCS-klyngen skal slukkes, noget der skal gøres med dem osv.? Hvordan overlever hele denne struktur? Og hvordan gør du disse ting?

For en virksomhed var det nødvendigt at lave en matrix af problemer, hvad sker der hvis en af ​​komponenterne eller flere komponenter fejler. Ifølge denne matrix gennemgår vi sekventielt alle komponenterne og bygger scenarier i tilfælde af fejl på disse komponenter. Derfor kan du for hvert fejlscenarie have en handlingsplan for genopretning. Og i tilfælde af DCS kommer det som en del af standardinfrastrukturen. Og administratoren administrerer det, og vi er allerede afhængige af administratorerne, der administrerer det, og deres evne til at rette det i tilfælde af ulykker. Hvis der slet ikke er noget DCS, så implementerer vi det, men samtidig overvåger vi det ikke specielt, for vi er ikke ansvarlige for infrastrukturen, men vi giver anbefalinger til hvordan og hvad vi skal overvåge.

Det vil sige, forstod jeg korrekt, at jeg skal deaktivere Patroni, deaktivere filerne, deaktivere alt, før jeg gør noget med værterne?

Det afhænger af, hvor mange noder vi har i DCS-klyngen. Hvis der er mange noder, og hvis vi kun deaktiverer én af noderne (replikaen), så opretholder klyngen et kvorum. Og Patroni forbliver i drift. Og intet udløses. Hvis vi har nogle komplekse operationer, der påvirker flere noder, hvis fravær kan ødelægge kvorummet, så - ja, det kan måske give mening at sætte Patroni på pause. Den har en tilsvarende kommando - patronictl pause, patronictl resume. Vi holder bare pause, og autofileren virker ikke på det tidspunkt. Vi laver vedligeholdelse på DCS-klyngen, så tager vi pausen og lever videre.

Mange tak!

Mange tak for din rapport! Hvordan har produktteamet det med, at data går tabt?

Produktteams er ligeglade, og teamledere er bekymrede.

Hvilke garantier er der?

Garantier er meget vanskelige. Alexander Kukushkin har en rapport "How to calculate RPO and RTO", dvs. restitutionstid og hvor meget data vi kan miste. Jeg tror, ​​vi skal finde disse slides og studere dem. Så vidt jeg husker, er der specifikke trin til, hvordan man beregner disse ting. Hvor mange transaktioner kan vi miste, hvor meget data kan vi miste. Som en mulighed kan vi bruge synkron replikering på Patroni-niveau, men dette er et tveægget sværd: enten har vi datapålidelighed, eller også mister vi hastighed. Der er synkron replikering, men det garanterer heller ikke 100% beskyttelse mod tab af data.

Alexey, tak for den gode rapport! Har du nogen erfaring med at bruge Patroni til beskyttelse på nulniveau? Altså i forbindelse med synkron standby? Dette er det første spørgsmål. Og det andet spørgsmål. Du har brugt forskellige løsninger. Vi brugte Repmgr, men uden autofiler, og nu planlægger vi at inkludere autofiler. Og vi betragter Patroni som en alternativ løsning. Hvad kan du sige som fordele sammenlignet med Repmgr?

Det første spørgsmål handlede om synkrone replikaer. Ingen bruger synkron replikering her, fordi alle er bange (Flere klienter bruger det allerede, i princippet bemærkede de ikke ydeevneproblemer - Talerens notat). Men vi har udviklet en regel for os selv, at der skal være mindst tre noder i en synkron replikeringsklynge, for hvis vi har to noder, og hvis masteren eller replikaen fejler, så skifter Patroni denne node til Standalone-tilstand, så applikationen fortsætter med at arbejde. I dette tilfælde er der risiko for datatab.

Med hensyn til det andet spørgsmål har vi brugt Repmgr og gør det stadig med nogle klienter af historiske årsager. Hvad kan man sige? Patroni kommer med en autofiler ud af æsken, Repmgr kommer med autofiler som en ekstra funktion, der skal aktiveres. Vi skal køre Repmgr-dæmonen på hver node, og så kan vi konfigurere autofileren.

Repmgr kontrollerer, om Postgres-noder er i live. Repmgr-processer tjekker for eksistensen af ​​hinanden, dette er ikke en særlig effektiv tilgang. der kan være komplekse tilfælde af netværksisolering, hvor en stor Repmgr-klynge kan falde fra hinanden i flere mindre og fortsætte med at arbejde. Jeg har ikke fulgt Repmgr i lang tid, måske blev det rettet ... eller måske ikke. Men fjernelse af oplysninger om klyngens tilstand i DCS, som Stolon, Patroni gør, er den mest levedygtige mulighed.

Alexey, jeg har et spørgsmål, måske et ringere. I et af de første eksempler flyttede du DCS fra den lokale maskine til en fjernvært. Vi forstår, at netværket er en ting, der har sine egne karakteristika, det lever af sig selv. Og hvad sker der, hvis DCS-klyngen af ​​en eller anden grund bliver utilgængelig? Jeg vil ikke sige årsagerne, der kan være mange af dem: fra netværkernes skæve hænder til reelle problemer.

Jeg sagde det ikke højt, men DCS-klyngen skal også være failover, dvs. det er et ulige antal noder, for at et kvorum kan opfyldes. Hvad sker der, hvis DCS-klyngen bliver utilgængelig, eller et kvorum ikke kan opfyldes, dvs. en form for netværksdeling eller knudefejl? I dette tilfælde går Patroni-klyngen i skrivebeskyttet tilstand. Patroni-klyngen kan ikke bestemme klyngens tilstand, og hvad der skal gøres. Den kan ikke kontakte DCS'en og gemme den nye klyngetilstand der, så hele klyngen går i skrivebeskyttet. Og venter enten på manuel indgriben fra operatøren eller på at DCS kommer sig.

Groft sagt bliver DCS en service for os lige så vigtig som selve basen?

Ja Ja. I så mange moderne virksomheder er Service Discovery en integreret del af infrastrukturen. Det bliver implementeret, allerede før der overhovedet var en database i infrastrukturen. Relativt set blev infrastrukturen lanceret, implementeret i DC, og vi har straks Service Discovery. Hvis det er Consul, så kan DNS bygges på det. Hvis dette er Etcd, så kan der være en del fra Kubernetes-klyngen, hvori alt andet vil blive installeret. Det forekommer mig, at Service Discovery allerede er en integreret del af moderne infrastrukturer. Og de tænker på det meget tidligere end på databaser.

Tak!

Kilde: www.habr.com