Het belangrijkste doel van Patroni is het bieden van hoge beschikbaarheid voor PostgreSQL. Maar Patroni is slechts een sjabloon, geen kant-en-klare tool (wat in het algemeen in de documentatie wordt gezegd). Op het eerste gezicht, nadat je Patroni in het testlab hebt opgezet, kun je zien wat een geweldige tool het is en hoe gemakkelijk het onze pogingen om het cluster te doorbreken aankan. In de praktijk, in een productieomgeving, gaat echter niet altijd alles zo mooi en elegant als in een testlab.
Ik zal je wat over mezelf vertellen. Ik ben begonnen als systeembeheerder. Werkzaam geweest in webontwikkeling. Sinds 2014 werk ik bij Data Egret. Het bedrijf houdt zich bezig met advisering op het gebied van Postgres. En we bedienen precies Postgres, en we werken elke dag met Postgres, dus we hebben verschillende expertises met betrekking tot de operatie.
En eind 2018 begonnen we Patroni langzaam te gebruiken. En er is enige ervaring opgedaan. We hebben het op de een of andere manier gediagnosticeerd, afgestemd, kwamen tot onze best practices. En in dit rapport zal ik erover praten.
Naast Postgres ben ik dol op Linux. Ik vind het leuk om erin rond te snuffelen en te ontdekken, ik verzamel graag kernen. Ik hou van virtualisatie, containers, docker, Kubernetes. Dit alles interesseert me, omdat de oude admin-gewoonten van invloed zijn. Ik ben graag bezig met toezicht. En ik hou van postgres-dingen met betrekking tot administratie, d.w.z. replicatie, back-up. En in mijn vrije tijd schrijf ik in Go. Ik ben geen software-engineer, ik schrijf gewoon voor mezelf in Go. En het doet me plezier.
- Ik denk dat velen van jullie weten dat Postgres standaard geen HA (High Availability) heeft. Om HA te krijgen, moet je iets installeren, configureren, moeite doen en het krijgen.
- Er zijn verschillende tools en Patroni is er een van die HA behoorlijk cool en heel goed oplost. Maar door het allemaal in een testlaboratorium te plaatsen en het uit te voeren, kunnen we zien dat het allemaal werkt, we kunnen enkele problemen reproduceren, zien hoe Patroni ze van dienst is. En we zullen zien dat het allemaal geweldig werkt.
- Maar in de praktijk liepen we tegen andere problemen aan. En ik zal over deze problemen praten.
- Ik zal je vertellen hoe we het hebben gediagnosticeerd, wat we hebben aangepast - of het ons heeft geholpen of niet.
- Ik zal je niet vertellen hoe je Patroni moet installeren, want je kunt googlen op internet, je kunt de configuratiebestanden bekijken om te begrijpen hoe het allemaal begint, hoe het is geconfigureerd. U kunt de schema's, architecturen begrijpen en er informatie over vinden op internet.
- Ik zal niet praten over de ervaring van iemand anders. Ik zal het alleen hebben over de problemen waarmee we werden geconfronteerd.
- En ik zal het niet hebben over problemen die buiten Patroni en PostgreSQL liggen. Als er bijvoorbeeld problemen zijn met balanceren, wanneer ons cluster is ingestort, zal ik er niet over praten.
En een kleine disclaimer voordat we aan ons verslag beginnen.
Al deze problemen die we tegenkwamen, hadden we in de eerste 6-7-8 maanden van gebruik. Na verloop van tijd kwamen we tot onze interne best practices. En onze problemen verdwenen. Daarom werd het rapport ongeveer een half jaar geleden aangekondigd, toen het allemaal nog vers in mijn hoofd zat en ik het me allemaal perfect herinnerde.
Tijdens het voorbereiden van het rapport heb ik al oude postmortale documenten opgehaald en de logboeken bekeken. En sommige details kunnen worden vergeten, of sommige details kunnen niet volledig worden onderzocht tijdens de analyse van de problemen, dus op sommige punten kan het lijken alsof de problemen niet volledig worden overwogen, of er is een gebrek aan informatie. En dus vraag ik je me te verontschuldigen voor dit moment.
Wat is Patroni?
- Dit is een sjabloon voor het bouwen van HA. Dat staat in de documentatie. En vanuit mijn oogpunt is dit een zeer juiste verduidelijking. Patroni is geen wondermiddel dat al uw problemen zal oplossen, dat wil zeggen, u moet moeite doen om het te laten werken en voordelen te bieden.
- Dit is een agentservice die op elke databaseservice wordt geïnstalleerd en is een soort init-systeem voor uw Postgres. Het start Postgres, stopt, herstart, herconfigureert en verandert de topologie van uw cluster.
- Dienovereenkomstig is er, om de status van het cluster op te slaan, zijn huidige representatie, zoals het eruit ziet, enige vorm van opslag nodig. En vanuit dit oogpunt nam Patroni het pad om de staat op te slaan in een extern systeem. Het is een gedistribueerd configuratieopslagsysteem. Dit kan Etcd, Consul, ZooKeeper of kubernetes Etcd zijn, d.w.z. een van deze opties.
- En een van de kenmerken van Patroni is dat je de autofiler uit de doos haalt, alleen door hem in te stellen. Als we Repmgr ter vergelijking nemen, dan is de filer daar opgenomen. Met Repmgr krijgen we een omschakeling, maar als we een autofiler willen, moeten we deze extra configureren. Patroni heeft al een autofiler uit de doos.
- En er zijn nog veel meer dingen. Bijvoorbeeld onderhoud van configuraties, nieuwe replica's gieten, back-up, enz. Maar dit valt buiten de reikwijdte van het rapport, ik zal er niet over praten.
En een klein resultaat is dat de hoofdtaak van Patroni is om een autofile goed en betrouwbaar uit te voeren zodat ons cluster operationeel blijft en de applicatie veranderingen in de clustertopologie niet opmerkt.
Maar wanneer we Patroni gaan gebruiken, wordt ons systeem een beetje ingewikkelder. Als we eerder Postgres hadden, dan krijgen we bij het gebruik van Patroni Patroni zelf, we krijgen DCS waar de status wordt opgeslagen. En het moet allemaal op de een of andere manier werken. Dus wat kan er misgaan?
Kan breken:
- Postgres kan breken. Het kan een master of een replica zijn, een van hen kan mislukken.
- De Patroni zelf kan breken.
- De DCS waar de status is opgeslagen, kan breken.
- En het netwerk kan breken.
Op al deze punten zal ik in het verslag ingaan.
Ik zal zaken behandelen naarmate ze complexer worden, niet vanuit het standpunt dat de zaak uit veel componenten bestaat. En vanuit het oogpunt van subjectieve gevoelens, dat deze koffer moeilijk voor mij was, was het moeilijk om hem te demonteren ... en vice versa, een koffer was licht en gemakkelijk te demonteren.
En het eerste geval is het gemakkelijkst. Dit is het geval toen we een databasecluster namen en onze DCS-opslag op hetzelfde cluster implementeerden. Dit is de meest gemaakte fout. Dit is een fout bij het bouwen van architecturen, d.w.z. het combineren van verschillende componenten op één plek.
Dus er was een filer, laten we gaan om te gaan met wat er is gebeurd.
En hier zijn we geïnteresseerd in wanneer de filer gebeurde. Dat wil zeggen, we zijn geïnteresseerd in dit moment waarop de clusterstatus veranderde.
Maar de filer is niet altijd onmiddellijk, d.w.z. het kost geen enkele tijdseenheid, het kan worden uitgesteld. Het kan langdurig zijn.
Daarom heeft het een begintijd en een eindtijd, d.w.z. het is een doorlopende gebeurtenis. En we verdelen alle gebeurtenissen in drie intervallen: we hebben tijd voor de filer, tijdens de filer en na de filer. Dat wil zeggen, we beschouwen alle gebeurtenissen in deze tijdlijn.
En het eerste, als er een filer gebeurde, zoeken we naar de oorzaak van wat er gebeurde, wat de oorzaak was van wat leidde tot de filer.
Als we naar de logs kijken, zullen het klassieke Patroni-logs zijn. Hij vertelt ons daarin dat de server de meester is geworden en dat de rol van de meester is overgegaan op dit knooppunt. Hier wordt het uitgelicht.
Vervolgens moeten we begrijpen waarom de filer is gebeurd, d.w.z. welke gebeurtenissen hebben plaatsgevonden waardoor de hoofdrol van het ene knooppunt naar het andere is verhuisd. En in dit geval is alles eenvoudig. Er is een fout opgetreden bij de interactie met het opslagsysteem. De meester realiseerde zich dat hij niet met DCS kon werken, dat wil zeggen dat er een probleem was met de interactie. En hij zegt dat hij geen meester meer kan zijn en neemt ontslag. Deze regel "gedegradeerde zelf" zegt precies dat.
Als we kijken naar de gebeurtenissen die aan de filer voorafgingen, kunnen we daar precies de redenen zien die het probleem veroorzaakten om de wizard voort te zetten.
Als we naar de Patroni-logboeken kijken, zullen we zien dat we veel fouten en time-outs hebben, d.w.z. de Patroni-agent kan niet werken met DCS. In dit geval is dit Consul-agent, die communiceert op poort 8500.
En het probleem hier is dat Patroni en de database op dezelfde host draaien. En de Consul-servers werden op hetzelfde knooppunt gelanceerd. Door de server te belasten, creëerden we ook problemen voor de Consul-servers. Ze konden niet goed communiceren.
Na enige tijd, toen de belasting zakte, kon onze Patroni weer communiceren met agenten. Het normale werk werd hervat. En dezelfde Pgdb-2-server werd weer de master. Dat wil zeggen, er was een kleine omkering, waardoor het knooppunt afstand deed van de bevoegdheden van de meester en ze vervolgens weer overnam, dat wil zeggen, alles keerde terug zoals het was.
En dit kan worden beschouwd als een vals alarm, of het kan worden beschouwd als dat Patroni alles goed deed. Dat wil zeggen, hij besefte dat hij de toestand van het cluster niet kon handhaven en verwijderde zijn autoriteit.
En hier ontstond het probleem vanwege het feit dat de Consul-servers op dezelfde hardware staan als de bases. Dienovereenkomstig elke belasting: of het nu de belasting van schijven of processors is, het heeft ook invloed op de interactie met het Consul-cluster.
En we besloten dat het niet samen moest leven, we wezen een apart cluster toe voor Consul. En Patroni werkte al met een aparte Consul, dat wil zeggen, er was een aparte Postgres-cluster, een aparte Consul-cluster. Dit is een basisinstructie over hoe je al deze dingen moet dragen en bewaren, zodat het niet samen leeft.
Als optie kunt u de parameters ttl, loop_wait, retry_timeout verdraaien, d.w.z. proberen deze kortdurende belastingspieken te overleven door deze parameters te verhogen. Maar dit is niet de meest geschikte optie, omdat deze belasting lang kan duren. En we gaan gewoon verder dan deze grenzen van deze parameters. En dat helpt misschien niet echt.
Het eerste probleem is, zoals u begrijpt, eenvoudig. We hebben de DCS genomen en samengevoegd met de basis, we hebben een probleem.
Het tweede probleem is vergelijkbaar met het eerste. Het is vergelijkbaar omdat we opnieuw interoperabiliteitsproblemen hebben met het DCS-systeem.
Als we naar de logboeken kijken, zien we dat we opnieuw een communicatiefout hebben. En Patroni zegt dat ik geen interactie kan hebben met DCS, dus de huidige master gaat in replicamodus.
De oude meester wordt een replica, hier werkt Patroni uit, zoals het hoort. Het voert pg_rewind uit om het transactielogboek terug te spoelen en vervolgens verbinding te maken met de nieuwe master om bij te praten met de nieuwe master. Hier traint Patroni, zoals het hoort.
Hier moeten we de plaats vinden die aan de filer voorafging, d.w.z. die fouten die ervoor zorgden dat we een filer hadden. En in dit opzicht zijn Patroni-logboeken best handig om mee te werken. Hij schrijft dezelfde berichten met een bepaald interval. En als we snel door deze logboeken gaan bladeren, zullen we aan de logboeken zien dat de logboeken zijn gewijzigd, wat betekent dat er enkele problemen zijn begonnen. We keren snel terug naar deze plek, kijken wat er gebeurt.
En in een normale situatie zien de logboeken er ongeveer zo uit. De eigenaar van het slot wordt gecontroleerd. En als bijvoorbeeld de eigenaar is veranderd, dan kunnen er enkele gebeurtenissen plaatsvinden waar Patroni op moet reageren. Maar in dit geval zitten we goed. We zoeken naar de plek waar de fouten begonnen.
En nadat we naar het punt waren gescrolld waar de fouten begonnen te verschijnen, zien we dat we een automatische fileover hebben gehad. En aangezien onze fouten verband hielden met interactie met DCS en we in ons geval Consul gebruikten, kijken we ook naar de Consul-logboeken, wat daar gebeurde.
Als we de tijd van de indiener grofweg vergelijken met de tijd in de Consul-logboeken, zien we dat onze buren in de Consul-cluster begonnen te twijfelen aan het bestaan van andere leden van de Consul-cluster.
En als je ook naar de logboeken van andere Consul-agenten kijkt, kun je ook zien dat daar een soort netwerkinstorting plaatsvindt. En alle leden van de Consul-cluster twijfelen aan elkaars bestaan. En dit was de aanzet voor de filer.
Als je kijkt naar wat er vóór deze fouten gebeurde, kun je zien dat er allerlei soorten fouten zijn, bijvoorbeeld deadline, RPC is gevallen, dat wil zeggen, er is duidelijk een probleem in de interactie van de Consul-clusterleden met elkaar .
Het eenvoudigste antwoord is om het netwerk te repareren. Maar voor mij, staande op het podium, is het gemakkelijk om dit te zeggen. Maar de omstandigheden zijn zodanig dat de klant het zich niet altijd kan veroorloven om het netwerk te repareren. Hij woont mogelijk in een DC en is mogelijk niet in staat het netwerk te repareren of de apparatuur aan te tasten. En dus zijn er nog andere opties nodig.
Er zijn opties:
- De eenvoudigste optie, die naar mijn mening zelfs in de documentatie is geschreven, is om Consul-controles uit te schakelen, dat wil zeggen, gewoon een lege array doorgeven. En we vertellen de consul-agent geen cheques te gebruiken. Met deze controles kunnen we deze netwerkstormen negeren en geen filer starten.
- Een andere optie is om raft_multiplier dubbel te controleren. Dit is een parameter van de Consul-server zelf. Standaard is deze ingesteld op 5. Deze waarde wordt aanbevolen door de documentatie voor testomgevingen. Dit heeft in feite invloed op de frequentie van berichtenuitwisseling tussen leden van het Consul-netwerk. In feite beïnvloedt deze parameter de snelheid van servicecommunicatie tussen leden van de Consul-cluster. En voor productie is het al aan te raden om het te verkleinen zodat de nodes vaker berichten uitwisselen.
- Een andere optie die we hebben bedacht, is het verhogen van de prioriteit van Consul-processen naast andere processen voor de procesplanner van het besturingssysteem. Er is zo'n "leuke" parameter, het bepaalt gewoon de prioriteit van processen waarmee de OS-planner rekening houdt bij het plannen. We hebben ook de leuke waarde voor Consul-agenten verlaagd, d.w.z. verhoogde de prioriteit zodat het besturingssysteem Consul-processen meer tijd geeft om te werken en hun code uit te voeren. In ons geval loste dit ons probleem op.
- Een andere optie is om Consul niet te gebruiken. Ik heb een vriend die een groot voorstander is van Etcd. En we hebben regelmatig ruzie met hem wat beter is Etcd of Consul. Maar in termen van wat beter is, zijn we het meestal met hem eens dat Consul een agent heeft die op elk knooppunt met een database zou moeten draaien. Dat wil zeggen, de interactie van Patroni met het Consul-cluster gaat via deze agent. En deze agent wordt een bottleneck. Als er iets met de agent gebeurt, kan Patroni niet meer werken met de Consul-cluster. En dit is het probleem. Er is geen agent in het Etcd-plan. Patroni kan direct werken met een lijst met Etcd-servers en er al mee communiceren. Als u Etcd in uw bedrijf gebruikt, is Etcd in dit opzicht waarschijnlijk een betere keuze dan Consul. Maar wij bij onze klanten zijn altijd beperkt door wat de klant heeft gekozen en gebruikt. En we hebben Consul voor het grootste deel voor alle klanten.
- En het laatste punt is om de parameterwaarden te herzien. We kunnen deze parameters verhogen in de hoop dat onze netwerkproblemen op korte termijn van korte duur zijn en niet buiten het bereik van deze parameters vallen. Op deze manier kunnen we de agressiviteit van Patroni naar autofile verminderen als er netwerkproblemen optreden.
Ik denk dat velen die Patroni gebruiken bekend zijn met dit commando.
Deze opdracht toont de huidige status van het cluster. En op het eerste gezicht lijkt deze foto misschien normaal. We hebben een master, we hebben een replica, er is geen replicatievertraging. Maar dit beeld is precies normaal totdat we weten dat dit cluster drie knooppunten zou moeten hebben, niet twee.
Dienovereenkomstig was er een autofile. En na deze autofile verdween onze replica. We moeten uitzoeken waarom ze verdween en haar terugbrengen, herstellen. En we gaan opnieuw naar de logboeken en zien waarom we een automatische fileover hadden.
In dit geval werd de tweede replica de master. Het is in orde hier.
En we moeten kijken naar de replica die eraf viel en die niet in het cluster zit. We openen de Patroni-logboeken en zien dat we een probleem hadden tijdens het verbindingsproces met het cluster in de pg_rewind-fase. Om verbinding te maken met het cluster, moet u het transactielogboek terugspoelen, het vereiste transactielogboek opvragen bij de master en dit gebruiken om bij te praten met de master.
In dit geval hebben we geen transactielogboek en kan de replica niet starten. Dienovereenkomstig stoppen we Postgres met een fout. En daarom zit het niet in het cluster.
We moeten begrijpen waarom het zich niet in het cluster bevindt en waarom er geen logboeken waren. We gaan naar de nieuwe meester en kijken wat hij in de logboeken heeft. Het blijkt dat toen pg_rewind klaar was, er een checkpoint optrad. En sommige van de oude transactielogboeken zijn eenvoudigweg hernoemd. Toen de oude master probeerde verbinding te maken met de nieuwe master en deze logs op te vragen, waren ze al hernoemd, ze bestonden gewoon niet.
Ik vergeleek tijdstempels toen deze gebeurtenissen plaatsvonden. En daar is het verschil letterlijk 150 milliseconden, dat wil zeggen, het checkpoint voltooid in 369 milliseconden, de WAL-segmenten werden hernoemd. En letterlijk in 517, na 150 milliseconden, begon het terugspoelen op de oude replica. Dat wil zeggen, letterlijk 150 milliseconden was genoeg voor ons, zodat de replica geen verbinding kon maken en geld kon verdienen.
Wat zijn de opties?
We gebruikten aanvankelijk replicatieslots. We dachten dat het goed was. Hoewel we in de eerste fase van de operatie de slots hebben uitgeschakeld. Het leek ons dat als de slots veel WAL-segmenten verzamelen, we de master kunnen laten vallen. Hij zal vallen. We zaten een tijdje zonder slots. En we beseften dat we slots nodig hadden, we hebben de slots teruggegeven.
Maar er is hier een probleem, dat wanneer de master naar de replica gaat, deze de slots verwijdert en de WAL-segmenten samen met de slots verwijdert. En om dit probleem op te lossen, hebben we besloten om de parameter wal_keep_segments te verhogen. Het is standaard ingesteld op 8 segmenten. We verhoogden het naar 1 en keken hoeveel vrije ruimte we hadden. En we hebben 000 gigabyte gedoneerd voor wal_keep_segments. Dat wil zeggen dat we bij het overstappen altijd een reserve van 16 gigabyte aan transactielogboeken op alle knooppunten hebben.
En bovendien is het nog steeds relevant voor onderhoudstaken op de lange termijn. Laten we zeggen dat we een van de replica's moeten bijwerken. En die willen we uitschakelen. We moeten de software updaten, misschien het besturingssysteem, iets anders. En als we een replica uitzetten, wordt ook het slot voor die replica verwijderd. En als we een kleine wal_keep_segments gebruiken, gaan bij een lange afwezigheid van een replica de transactielogboeken verloren. We zullen een replica maken, het zal die transactielogboeken opvragen waar het is gestopt, maar ze staan mogelijk niet op de master. En de replica kan ook geen verbinding maken. Daarom houden we een grote voorraad tijdschriften aan.
We hebben een productiebasis. Er lopen al projecten.
Er was een filer. We gingen naar binnen en keken - alles is in orde, de replica's zijn op hun plaats, er is geen replicatievertraging. Er zijn ook geen fouten in de logboeken, alles is in orde.
Het productteam zegt dat er wat gegevens zouden moeten zijn, maar we zien het van één bron, maar we zien het niet in de database. En we moeten begrijpen wat er met hen is gebeurd.
Het is duidelijk dat pg_rewind ze heeft gemist. We begrepen dit meteen, maar gingen kijken wat er aan de hand was.
In de logs kunnen we altijd vinden wanneer de filer gebeurde, wie de master werd, en we kunnen bepalen wie de oude master was en wanneer hij een replica wilde worden, d.w.z. we hebben deze logs nodig om erachter te komen hoeveel transactielogs dat was verloren.
Onze oude meester is opnieuw opgestart. En Patroni was geregistreerd in de autorun. Patroni gelanceerd. Vervolgens startte hij Postgres. Preciezer gezegd, voordat Postgres werd gestart en voordat er een replica van werd gemaakt, lanceerde Patroni het pg_rewind-proces. Dienovereenkomstig wist hij een deel van de transactielogboeken, downloadde nieuwe en maakte verbinding. Hier werkte Patroni slim, dat wil zeggen, zoals verwacht. Het cluster is hersteld. We hadden 3 knooppunten, na de filer 3 knooppunten - alles is cool.
We zijn wat gegevens kwijtgeraakt. En we moeten begrijpen hoeveel we hebben verloren. We zoeken precies het moment waarop we terugspoelden. We kunnen het vinden in dergelijke dagboekaantekeningen. Rewind begon, deed daar iets en eindigde.
We moeten de positie in het transactielogboek vinden waar de oude meester was gebleven. In dit geval is dit het merkteken. En we hebben een tweede merkteken nodig, dat wil zeggen de afstand waarmee de oude meester verschilt van de nieuwe.
We nemen de gebruikelijke pg_wal_lsn_diff en vergelijken deze twee markeringen. En in dit geval krijgen we 17 megabytes. Veel of weinig, iedereen beslist voor zichzelf. Want voor iemand is 17 megabyte niet veel, voor iemand is het veel en onaanvaardbaar. Hier bepaalt elk individu voor zichzelf in overeenstemming met de behoeften van het bedrijf.
Maar wat hebben we zelf ontdekt?
Eerst moeten we voor onszelf beslissen: hebben we Patroni altijd nodig om automatisch te starten na een systeemherstart? Het gebeurt vaak dat we naar de oude meester moeten, kijken hoe ver hij is gegaan. Inspecteer misschien segmenten van het transactielogboek, kijk wat er is. En om te begrijpen of we deze gegevens kunnen verliezen of dat we de oude master in zelfstandige modus moeten uitvoeren om deze gegevens eruit te halen.
En pas daarna moeten we beslissen of we deze gegevens kunnen weggooien of dat we ze kunnen herstellen, dit knooppunt als replica aan ons cluster kunnen koppelen.
Daarnaast is er een parameter "maximum_lag_on_failover". Als ik me goed herinner, heeft deze parameter standaard een waarde van 1 megabyte.
Hoe werkt hij? Als onze replica 1 megabyte aan data achterloopt in de replicatievertraging, dan doet deze replica niet mee aan de verkiezingen. En als er ineens een fileover is, kijkt Patroni welke replica's achterblijven. Als ze achterlopen met een groot aantal transactielogboeken, kunnen ze geen master worden. Dit is een zeer goede beveiligingsfunctie die voorkomt dat u veel gegevens verliest.
Maar er is een probleem doordat de replicatievertraging in het Patroni-cluster en DCS met een bepaald interval wordt bijgewerkt. Ik denk dat 30 seconden de standaard ttl-waarde is.
Dienovereenkomstig kan er een situatie zijn waarin er één replicatievertraging is voor replica's in DCS, maar in feite kan er een geheel andere vertraging zijn of kan er helemaal geen vertraging zijn, d.w.z. dit ding is niet realtime. En het geeft niet altijd het echte beeld weer. En het is niet de moeite waard om er mooie logica aan te wijden.
En het risico van verlies blijft altijd bestaan. En in het ergste geval één formule, en in het gemiddelde geval nog een formule. Dat wil zeggen, wanneer we de implementatie van Patroni plannen en evalueren hoeveel gegevens we kunnen verliezen, moeten we op deze formules vertrouwen en ons grofweg voorstellen hoeveel gegevens we kunnen verliezen.
En er is goed nieuws. Als de oude meester vooruit is gegaan, kan hij door een aantal achtergrondprocessen vooruit. Dat wil zeggen, er was een soort autovacuüm, hij schreef de gegevens en bewaarde ze in het transactielogboek. En we kunnen deze gegevens gemakkelijk negeren en kwijtraken. Hierin is geen probleem.
En zo zien de logboeken eruit als maximum_lag_on_failover is ingesteld en er een filer is opgetreden en u een nieuwe master moet selecteren. De replica beoordeelt zichzelf als niet in staat om deel te nemen aan de verkiezingen. En ze weigert mee te doen aan de race om de leider. En ze wacht tot er een nieuwe master wordt geselecteerd, zodat ze daar verbinding mee kan maken. Dit is een extra maatregel tegen gegevensverlies.
Hier hebben we een productteam dat schreef dat hun product problemen heeft met Postgres. Tegelijkertijd is de master zelf niet bereikbaar, omdat deze niet via SSH bereikbaar is. En de autofile gebeurt ook niet.
Deze host is gedwongen opnieuw op te starten. Vanwege het opnieuw opstarten gebeurde er een auto-file, hoewel het mogelijk was om een handmatige auto-file te doen, zoals ik nu begrijp. En na de herstart gaan we al kijken wat we hadden met de huidige master.
Tegelijkertijd wisten we van tevoren dat we problemen hadden met schijven, dat wil zeggen, we wisten al van monitoring waar we moesten graven en waar we naar moesten zoeken.
We kwamen in het postgres-logboek en begonnen te zien wat daar gebeurde. We zagen commits die daar één, twee, drie seconden duurden, wat helemaal niet normaal is. We zagen dat onze autovacuüm heel langzaam en vreemd opstart. En we zagen tijdelijke bestanden op de schijf. Dat wil zeggen, dit zijn allemaal indicatoren van problemen met schijven.
We hebben gekeken naar het systeem dmesg (kernellogboek). En we zagen dat we problemen hebben met een van de schijven. Het schijfsubsysteem was software Raid. We keken naar /proc/mdstat en zagen dat we één schijf misten. Dat wil zeggen, er is een Raid van 8 schijven, we missen er een. Als je goed naar de dia kijkt, kun je in de uitvoer zien dat we daar geen sde hebben. Bij ons is de schijf voorwaardelijk uitgevallen. Dit veroorzaakte schijfproblemen en ook applicaties ondervonden problemen bij het werken met het Postgres-cluster.
En in dit geval zou Patroni ons op geen enkele manier helpen, omdat Patroni niet de taak heeft om de status van de server, de status van de schijf, te bewaken. En we moeten dergelijke situaties monitoren door externe monitoring. We hebben schijfmonitoring snel toegevoegd aan externe monitoring.
En er was zo'n gedachte - zou hekwerk- of waakhondsoftware ons kunnen helpen? We dachten dat hij ons in dit geval nauwelijks zou hebben geholpen, omdat Patroni tijdens de problemen bleef communiceren met het DCS-cluster en geen enkel probleem zag. Dat wil zeggen, vanuit het oogpunt van DCS en Patroni was alles in orde met het cluster, hoewel er in feite problemen waren met de schijf, er waren problemen met de beschikbaarheid van de database.
Naar mijn mening is dit een van de vreemdste problemen waar ik heel lang onderzoek naar heb gedaan, ik heb veel logboeken gelezen, opnieuw uitgekozen en het een clustersimulator genoemd.
Het probleem was dat de oude meester geen normale replica kon worden, d.w.z. Patroni startte ermee, Patroni liet zien dat deze knoop als replica aanwezig was, maar tegelijkertijd was het geen normale replica. Nu zul je zien waarom. Dit is wat ik heb overgehouden aan de analyse van dat probleem.
En hoe is het allemaal begonnen? Het begon, net als bij het vorige probleem, met schijfremmen. We hadden commits voor een seconde, twee.
Er waren breuken in verbindingen, d.w.z. klanten waren verscheurd.
Er waren blokkades van verschillende ernst.
En dienovereenkomstig reageert het schijfsubsysteem niet erg.
En het meest mysterieuze voor mij is het onmiddellijke stopverzoek dat binnenkwam. Postgres heeft drie afsluitmodi:
- Het is gracieus als we wachten tot alle klanten uit zichzelf de verbinding verbreken.
- Er is snel wanneer we klanten dwingen de verbinding te verbreken omdat we gaan afsluiten.
- En onmiddellijk. In dit geval vertelt direct clients niet eens om af te sluiten, het wordt gewoon afgesloten zonder waarschuwing. En naar alle clients stuurt het besturingssysteem al een RST-bericht (een TCP-bericht dat de verbinding verbroken is en de client niets meer te vangen heeft).
Wie heeft dit signaal afgegeven? Postgres-achtergrondprocessen sturen dergelijke signalen niet naar elkaar, d.w.z. dit is kill-9. Ze sturen zulke dingen niet naar elkaar, ze reageren alleen op zulke dingen, d.w.z. dit is een noodherstart van Postgres. Wie het heeft gestuurd, weet ik niet.
Ik keek naar het "laatste" commando en ik zag een persoon die ook bij ons op deze server inlogde, maar ik was te verlegen om een vraag te stellen. Misschien was het doden -9. Ik zou kill -9 in de logboeken zien, omdat Postgres zegt dat het kill -9 kostte, maar ik zag het niet in de logboeken.
Toen ik verder keek, zag ik dat Patroni vrij lang niet naar het logboek had geschreven - 54 seconden. En als we twee tijdstempels vergelijken, waren er ongeveer 54 seconden geen berichten.
En gedurende deze tijd was er een autofile. Patroni heeft hier weer geweldig werk geleverd. Onze oude meester was niet beschikbaar, er is iets met hem gebeurd. En de verkiezing van een nieuwe meester begon. Alles is hier goed gelukt. Onze pgsql01 is de nieuwe leider geworden.
We hebben een replica die een meester is geworden. En er is nog een tweede reactie. En er waren problemen met de tweede replica. Ze probeerde zich te herconfigureren. Zoals ik het begrijp, probeerde ze recovery.conf te wijzigen, Postgres opnieuw te starten en verbinding te maken met de nieuwe master. Ze schrijft elke 10 seconden berichtjes dat ze het probeert, maar dat het haar niet lukt.
En tijdens deze pogingen komt er een signaal voor onmiddellijke uitschakeling bij de oude meester. De master wordt opnieuw gestart. En ook het herstel stopt omdat de oude master opnieuw wordt opgestart. Dat wil zeggen, de replica kan er geen verbinding mee maken, omdat deze zich in de afsluitmodus bevindt.
Op een gegeven moment werkte het, maar de replicatie kwam niet op gang.
Mijn enige gok is dat er een oud masteradres was in recovery.conf. En toen er een nieuwe master verscheen, probeerde de tweede replica nog steeds verbinding te maken met de oude master.
Toen Patroni opstartte op de tweede replica, startte het knooppunt op maar kon het niet repliceren. En er ontstond een replicatievertraging, die er ongeveer zo uitzag. Dat wil zeggen, alle drie de knooppunten waren op hun plaats, maar het tweede knooppunt bleef achter.
Als u tegelijkertijd naar de logboeken kijkt die zijn geschreven, kunt u zien dat de replicatie niet kan worden gestart omdat de transactielogboeken anders zijn. En die transactielogboeken die de master aanbiedt, die gespecificeerd zijn in recovery.conf, passen gewoon niet in onze huidige node.
En hier heb ik een fout gemaakt. Ik moest komen kijken wat er in recovery.conf stond om mijn hypothese te testen dat we verbinding maakten met de verkeerde master. Maar toen was ik hier net mee bezig en het kwam niet bij me op, of ik zag dat de replica achterbleef en opnieuw moest worden gevuld, dat wil zeggen, ik werkte op de een of andere manier onzorgvuldig. Dit was mijn joint.
Na 30 minuten kwam de admin al, d.w.z. ik startte Patroni opnieuw op de replica. Ik heb er al een einde aan gemaakt, ik dacht dat het opnieuw moest worden gevuld. En ik dacht - ik zal Patroni opnieuw opstarten, misschien komt er iets goeds uit. Het herstel begon. En de basis ging zelfs open, hij was klaar om verbindingen te accepteren.
De replicatie is gestart. Maar een minuut later viel ze af met een fout dat transactielogboeken niet geschikt zijn voor haar.
Ik dacht ik herstart opnieuw. Ik herstartte Patroni opnieuw, en ik herstartte Postgres niet, maar herstartte Patroni in de hoop dat het op magische wijze de database zou starten.
De replicatie is opnieuw gestart, maar de markeringen in het transactielogboek waren anders, ze waren niet hetzelfde als de vorige startpoging. Replicatie stopte weer. En de boodschap was al iets anders. En het was niet erg informatief voor mij.
En dan komt het bij me op - wat als ik Postgres opnieuw start, op dit moment maak ik een checkpoint op de huidige master om het punt in het transactielogboek een beetje naar voren te verplaatsen zodat het herstel vanaf een ander moment begint? Bovendien hadden we nog steeds voorraden WAL.
Ik herstartte Patroni, deed een paar checkpoints op de master, een paar herstartpunten op de replica toen deze opende. En het hielp. Ik heb lang nagedacht waarom het hielp en hoe het werkte. En de replica begon. En de replicatie was niet langer gescheurd.
Zo'n probleem is voor mij een van de meer mysterieuze, waarover ik nog steeds puzzel over wat daar werkelijk is gebeurd.
Wat zijn hier de implicaties? Patroni kan werken zoals bedoeld en foutloos. Maar tegelijkertijd is dit geen 100% garantie dat alles goed komt met ons. De replica kan starten, maar kan zich in een semi-werkende staat bevinden en de applicatie kan niet werken met een dergelijke replica, omdat er oude gegevens zijn.
En na de filer moet u altijd controleren of alles in orde is met het cluster, dat wil zeggen dat er het vereiste aantal replica's is, er is geen replicatievertraging.
En terwijl we deze kwesties doornemen, zal ik aanbevelingen doen. Ik heb geprobeerd ze te combineren tot twee dia's. Waarschijnlijk zouden alle verhalen in twee dia's kunnen worden gecombineerd en alleen verteld.
Als u Patroni gebruikt, moet u toezicht hebben. U moet altijd weten wanneer er een autofileover heeft plaatsgevonden, want als u niet weet dat u een autofileover had, heeft u geen controle over het cluster. En dat is slecht.
Na elke filer moeten we het cluster altijd handmatig controleren. We moeten ervoor zorgen dat we altijd een up-to-date aantal replica's hebben, er is geen replicatievertraging, er zijn geen fouten in de logboeken met betrekking tot streamingreplicatie, met Patroni, met het DCS-systeem.
Automatisering kan succesvol werken, Patroni is een zeer goed hulpmiddel. Het kan werken, maar dit brengt het cluster niet in de gewenste staat. En als we er niet achter komen, zitten we in de problemen.
En Patroni is geen wondermiddel. We moeten nog steeds begrijpen hoe Postgres werkt, hoe replicatie werkt en hoe Patroni werkt met Postgres, en hoe communicatie tussen knooppunten wordt verzorgd. Dit is nodig om problemen met uw handen te kunnen verhelpen.
Hoe benader ik het vraagstuk van de diagnose? Het gebeurde zo dat we met verschillende klanten werken en niemand een ELK-stack heeft, en we moeten de logboeken sorteren door 6 consoles en 2 tabbladen te openen. Op het ene tabblad zijn dit de Patroni-logs voor elk knooppunt, op het andere tabblad zijn dit de Consul-logs, of eventueel Postgres. Het is erg moeilijk om dit te diagnosticeren.
Welke benaderingen heb ik gevolgd? Eerst kijk ik altijd wanneer de filer is gearriveerd. En voor mij is dit een keerpunt. Ik kijk naar wat er gebeurde vóór de indiener, tijdens de indiener en na de indiener. De fileover heeft twee markeringen: dit is de begin- en eindtijd.
Vervolgens zoek ik in de logboeken naar gebeurtenissen vóór de filer, die voorafgingen aan de filer, d.w.z. ik zoek naar de redenen waarom de filer plaatsvond.
En dit geeft een beeld van wat er is gebeurd en wat er in de toekomst kan worden gedaan, zodat dergelijke omstandigheden zich niet voordoen (en als gevolg daarvan is er geen filer).
En waar kijken we meestal? Ik kijk:
- Eerst naar de Patroni-logboeken.
- Vervolgens kijk ik naar de Postgres-logboeken of de DCS-logboeken, afhankelijk van wat er in de Patroni-logboeken is gevonden.
- En de systeemlogboeken geven soms ook inzicht in de oorzaak van de filer.
Wat vind ik van Patroni? Ik heb een zeer goede relatie met Patroni. Naar mijn mening is dit het beste dat er vandaag is. Ik ken nog veel meer producten. Dit zijn Stolon, Repmgr, Pg_auto_failover, PAF. 4 gereedschappen. Ik heb ze allemaal geprobeerd. Patroni is mijn favoriet.
Als ze me vragen: "Raad ik Patroni aan?". Ik zal ja zeggen, want ik hou van Patroni. En ik denk dat ik heb geleerd hoe ik het moet koken.
Als je geïnteresseerd bent om te zien welke andere problemen er zijn met Patroni naast de problemen die ik heb genoemd, kun je altijd de pagina bekijken op GitHub. Er zijn veel verschillende verhalen en er worden veel interessante kwesties besproken. En als gevolg daarvan werden enkele bugs geïntroduceerd en opgelost, dat wil zeggen, dit is interessant om te lezen.
Er zijn enkele interessante verhalen over mensen die zichzelf in de voet schieten. Erg informatief. U leest en begrijpt dat het niet nodig is om dit te doen. Ik heb mezelf aangevinkt.
En ik wil Zalando hartelijk bedanken voor het ontwikkelen van dit project, namelijk Alexander Kukushkin en Alexey Klyukin. Aleksey Klyukin is een van de co-auteurs, hij werkt niet meer bij Zalando, maar dit zijn twee mensen die met dit product aan de slag zijn gegaan.
En ik denk dat Patroni een heel cool ding is. Ik ben blij dat ze bestaat, het is interessant met haar. En een grote dank aan alle bijdragers die patches naar Patroni schrijven. Ik hoop dat Patroni met de jaren volwassener, cooler en efficiënter zal worden. Het is al functioneel, maar ik hoop dat het nog beter wordt. Wees daarom niet bang als u van plan bent om Patroni te gebruiken. Dit is een goede oplossing, het kan worden geïmplementeerd en gebruikt.
Dat is alles. Als je vragen hebt, stel ze dan.
vragen
Bedankt voor het verslag! Als je na een filer daar nog heel goed moet kijken, waarom hebben we dan een automatische filer nodig?
Omdat het nieuwe dingen zijn. We zijn pas een jaar bij haar. Het is beter om veilig te zijn. We willen binnenkomen en zien dat alles echt is verlopen zoals het zou moeten. Dit is het niveau van wantrouwen van volwassenen - het is beter om het dubbel te controleren en te zien.
We gingen bijvoorbeeld 's ochtends en keken, toch?
Niet 's ochtends, we leren meestal vrijwel onmiddellijk over de autofile. We ontvangen meldingen, we zien dat er een autofile is opgetreden. We gaan bijna meteen kijken. Maar al deze controles moeten op monitoringniveau worden gebracht. Als u Patroni benadert via de REST API, is er een geschiedenis. Door de geschiedenis kunt u de tijdstempels zien wanneer de filer plaatsvond. Op basis hiervan kan er gemonitord worden. Je kunt de geschiedenis zien, hoeveel evenementen er waren. Als we meer gebeurtenissen hebben, is er een autofile opgetreden. Je kunt gaan kijken. Of onze bewakingsautomatisering heeft gecontroleerd of we alle replica's op hun plaats hebben, er geen vertraging is en alles in orde is.
Dank je wel!
Heel erg bedankt voor het geweldige verhaal! Als we het DCS-cluster ergens ver van het Postgres-cluster hebben verplaatst, moet dit cluster dan ook periodiek worden onderhouden? Wat zijn de best practices dat sommige delen van het DCS-cluster moeten worden uitgeschakeld, dat er iets mee moet worden gedaan, enz.? Hoe overleeft deze hele structuur? En hoe doe je deze dingen?
Voor één bedrijf was het nodig om een matrix van problemen te maken, wat gebeurt er als een van de componenten of meerdere componenten uitvalt. Volgens deze matrix doorlopen we achtereenvolgens alle onderdelen en bouwen we scenario's op voor het geval deze onderdelen uitvallen. Dienovereenkomstig kunt u voor elk storingsscenario een actieplan voor herstel hebben. En in het geval van DCS komt het als onderdeel van de standaardinfrastructuur. En de beheerder beheert het, en we vertrouwen al op de beheerders die het beheren en hun vermogen om het te repareren in geval van ongelukken. Als er helemaal geen DCS is, zetten we het in, maar tegelijkertijd monitoren we het niet bijzonder, omdat we niet verantwoordelijk zijn voor de infrastructuur, maar we geven aanbevelingen over hoe en wat te monitoren.
Dat wil zeggen, heb ik goed begrepen dat ik Patroni moet uitschakelen, de filer moet uitschakelen, alles moet uitschakelen voordat ik iets met de hosts doe?
Het hangt ervan af hoeveel knooppunten we in het DCS-cluster hebben. Als er veel knooppunten zijn en als we slechts één van de knooppunten uitschakelen (de replica), behoudt het cluster een quorum. En Patroni blijft operationeel. En er wordt niets geactiveerd. Als we een aantal complexe operaties hebben die meer knooppunten beïnvloeden, waarvan de afwezigheid het quorum kan ruïneren, dan - ja, het kan zinvol zijn om Patroni op pauze te zetten. Het heeft een bijbehorend commando - patronictl pauze, patronictl hervatten. We pauzeren gewoon en de autofiler werkt op dat moment niet. We doen onderhoud aan het DCS-cluster, daarna halen we de pauze weg en leven we verder.
Thank you very much!
Hartelijk dank voor uw melding! Hoe denkt het productteam over het verlies van gegevens?
Productteams geven er niet om, en teamleiders maken zich zorgen.
Welke garanties zijn er?
Garanties zijn erg moeilijk. Alexander Kukushkin heeft een rapport "Hoe RPO en RTO berekenen", d.w.z. hersteltijd en hoeveel gegevens we kunnen verliezen. Ik denk dat we deze dia's moeten vinden en ze moeten bestuderen. Voor zover ik me herinner, zijn er specifieke stappen om deze dingen te berekenen. Hoeveel transacties we kunnen verliezen, hoeveel gegevens we kunnen verliezen. Als optie kunnen we synchrone replicatie op Patroni-niveau gebruiken, maar dit is een tweesnijdend zwaard: ofwel hebben we gegevensbetrouwbaarheid, ofwel verliezen we snelheid. Er is synchrone replicatie, maar het garandeert ook geen 100% bescherming tegen gegevensverlies.
Alexey, bedankt voor het geweldige verslag! Enige ervaring met het gebruik van Patroni voor bescherming op nulniveau? Dat wil zeggen, in combinatie met synchrone stand-by? Dit is de eerste vraag. En de tweede vraag. Je hebt verschillende oplossingen gebruikt. We gebruikten Repmgr, maar zonder autofiler, en nu zijn we van plan om autofiler toe te voegen. En we beschouwen Patroni als een alternatieve oplossing. Wat kun je zeggen als voordelen ten opzichte van Repmgr?
De eerste vraag ging over synchrone replica's. Niemand gebruikt hier synchrone replicatie, omdat iedereen bang is (meerdere klanten gebruiken het al, in principe merkten ze geen prestatieproblemen op - Opmerking van de spreker). Maar we hebben voor onszelf een regel ontwikkeld dat er minimaal drie knooppunten in een synchrone replicatiecluster moeten zijn, want als we twee knooppunten hebben en als de master of replica uitvalt, dan schakelt Patroni dit knooppunt in Standalone-modus zodat de applicatie doorgaat met werk. In dit geval bestaat het risico van gegevensverlies.
Wat de tweede vraag betreft, we hebben Repmgr gebruikt en doen dat om historische redenen nog steeds bij sommige klanten. Wat kan er gezegd worden? Patroni wordt standaard geleverd met een autofiler, Repmgr wordt geleverd met autofiler als een extra functie die moet worden ingeschakeld. We moeten de Repmgr-daemon op elk knooppunt uitvoeren en dan kunnen we de autofiler configureren.
Repmgr controleert of Postgres-knooppunten leven. Repmgr-processen controleren op elkaars bestaan, dit is niet erg efficiënt. er kunnen complexe gevallen van netwerkisolatie zijn waarbij een groot Repmgr-cluster uit elkaar kan vallen in meerdere kleinere en kan blijven werken. Ik volg Repmgr al een hele tijd niet, misschien is het opgelost ... of misschien niet. Maar het verwijderen van informatie over de status van het cluster in DCS, zoals Stolon en Patroni doen, is de meest haalbare optie.
Alexey, ik heb een vraag, misschien een mindere. In een van de eerste voorbeelden verplaatste u DCS van de lokale computer naar een externe host. We begrijpen dat het netwerk iets is dat zijn eigen kenmerken heeft, het leeft op zichzelf. En wat gebeurt er als om de een of andere reden het DCS-cluster niet meer beschikbaar is? Ik zal de redenen niet noemen, er kunnen er veel zijn: van de kromme handen van netwerkers tot echte problemen.
Ik zei het niet hardop, maar het DCS-cluster moet ook failover zijn, d.w.z. het is een oneven aantal nodes, om aan een quorum te voldoen. Wat gebeurt er als het DCS-cluster niet meer beschikbaar is of als er niet aan een quorum kan worden voldaan, d.w.z. een soort netwerksplitsing of een storing in een knooppunt? In dit geval gaat het Patroni-cluster in de modus alleen-lezen. Het Patroni-cluster kan de status van het cluster niet bepalen en wat te doen. Het kan geen contact maken met de DCS en de nieuwe clusterstatus daar opslaan, dus het hele cluster gaat naar alleen-lezen. En wacht ofwel op handmatige tussenkomst van de operator of tot DCS is hersteld.
Grofweg wordt DCS voor ons een dienst die net zo belangrijk is als de basis zelf?
Ja Ja. In zoveel moderne bedrijven is Service Discovery een integraal onderdeel van de infrastructuur. Het wordt geïmplementeerd nog voordat er zelfs maar een database in de infrastructuur was. Relatief gezien is de infrastructuur gelanceerd, ingezet in het DC en hebben we meteen Service Discovery. Als het Consul is, kan er DNS op worden gebouwd. Als dit Etcd is, dan kan er een deel uit het Kubernetes-cluster zijn, waarin al het andere wordt ingezet. Het lijkt mij dat Service Discovery al een integraal onderdeel is van moderne infrastructuren. En ze denken er veel eerder over na dan over databases.
Dank je wel!
Bron: www.habr.com