Engang i en fjern fremtid vil automatisk fjernelse af unødvendige data være en af de vigtige opgaver for DBMS [1]. I mellemtiden skal vi selv sørge for at slette eller flytte unødvendige data til billigere lagersystemer. Lad os sige, at du beslutter dig for at slette et par millioner rækker. En ret simpel opgave, især hvis tilstanden er kendt, og der er et passende indeks. "DELETE FROM table1 WHERE col1 = :value" - hvad kunne være enklere, ikke?
Video:
-
Jeg har siddet i Highload-programudvalget siden det første år, altså siden 2007.
-
Og jeg har været hos Postgres siden 2005. Har brugt det i mange projekter.
-
Gruppe med RuPostges også siden 2007.
-
Vi er vokset til 2100+ deltagere på Meetup. Det er nummer to i verden efter New York, overhalet af San Francisco i lang tid.
-
Jeg har boet i Californien i flere år. Jeg beskæftiger mig mere med amerikanske virksomheder, også store. De er aktive brugere af Postgres. Og der er alle mulige interessante ting.
er mit firma. Vi beskæftiger os med at automatisere opgaver, der eliminerer opbremsninger i udviklingen.
Hvis du laver noget, så er der nogle gange en slags propper omkring Postgres. Lad os sige, at du skal vente på, at administratoren sætter en teststand op for dig, eller du skal vente på, at DBA svarer dig. Og vi finder sådanne flaskehalse i udviklings-, test- og administrationsprocessen og forsøger at eliminere dem ved hjælp af automatisering og nye tilgange.
Jeg var for nylig på VLDB i Los Angeles. Dette er den største konference om databaser. Og der var en rapport om, at DBMS i fremtiden ikke kun vil gemme, men også automatisk slette data. Dette er et nyt emne.
Der er mere og mere data i zettabytes verden - det er 1 petabytes. Og nu vurderes det allerede, at vi har mere end 000 zettabyte data lagret i verden. Og dem bliver der flere og flere af.
Og hvad skal man gøre med det? Det skal selvfølgelig fjernes. Her er et link til denne interessante rapport. Men indtil videre er dette ikke blevet implementeret i DBMS.
De, der kan tælle penge, vil have to ting. De vil have os til at slette, så teknisk set burde vi kunne gøre det.
Det, jeg vil fortælle herefter, er en eller anden abstrakt situation, der inkluderer en masse virkelige situationer, dvs. en slags kompilering af, hvad der faktisk skete med mig og de omkringliggende databaser mange gange, mange år. Raker er overalt, og alle træder på dem hele tiden.
Lad os sige, at vi har en base eller flere baser, der vokser. Og nogle plader er åbenbart noget vrøvl. For eksempel begyndte brugeren at gøre noget der, men afsluttede det ikke. Og efter nogen tid ved vi, at dette ufærdige ikke længere kan opbevares. Det vil sige, at vi gerne vil rense nogle affaldsting for at spare plads, forbedre ydeevnen mv.
Generelt er opgaven at automatisere sletningen af specifikke ting, specifikke linjer i en eller anden tabel.
Og vi har sådan en anmodning, som vi vil tale om i dag, det vil sige om fjernelse af affald.
Vi bad en erfaren udvikler om at gøre det. Han tog denne anmodning, tjekkede den med sig selv - alt fungerer. Testet på iscenesættelse - alt er i orden. Udrullet - alt virker. En gang om dagen kører vi det - alt er fint.
Databasen vokser og vokser. Daily DELETE begynder at virke lidt langsommere.
Så forstår vi, at vi nu har et marketingfirma, og trafikken bliver flere gange større, så vi beslutter os for midlertidigt at sætte unødvendige ting på pause. Og glemmer at vende tilbage.
Et par måneder senere huskede de det. Og den udvikler stoppede eller har travlt med noget andet, instruerede en anden til at returnere det.
Han tjekkede på dev, på iscenesættelse - alt er OK. Naturligvis skal du stadig rydde op i det, der er ophobet. Han tjekkede alt virker.
Hvad sker der nu? Så falder alt fra hinanden for os. Det falder, så alt på et tidspunkt falder ned. Alle er i chok, ingen forstår, hvad der sker. Og så viser det sig, at sagen lå i denne SLET.
Noget gik galt? Her er en liste over, hvad der kunne være gået galt. Hvilken af disse er den vigtigste?
-
For eksempel var der ingen anmeldelse, det vil sige, at DBA-eksperten ikke kiggede på den. Han ville straks finde problemet med et erfarent øje, og desuden har han adgang til prod, hvor flere millioner linjer har samlet sig.
-
Måske har de tjekket noget forkert.
-
Måske er hardwaren forældet, og du skal opgradere denne base.
-
Eller der er noget galt med selve databasen, og vi skal flytte fra Postgres til MySQL.
-
Eller måske er der noget galt med operationen.
-
Måske er der nogle fejl i tilrettelæggelsen af arbejdet, og du skal fyre nogen og ansætte de bedste folk?
Der var ingen DBA-tjek. Hvis der var en DBA, ville han se disse adskillige millioner linjer og selv uden nogen eksperimenter ville han sige: "Det gør de ikke." Antag, at hvis denne kode var i GitLab, GitHub, og der ville være en kodegennemgangsproces, og det ikke var sådan, at uden DBA's godkendelse ville denne operation finde sted på prod, så ville DBA naturligvis sige: "Dette kan ikke lade sig gøre. ”
Og han ville sige, at du vil have problemer med disk IO, og alle processer vil gå amok, der kan være låse, og du vil også blokere autovakuum i en masse minutter, så det er ikke godt.
Den anden fejl - de tjekkede det forkerte sted. Vi så efter det faktum, at en masse uønsket data akkumulerede på prod, men udvikleren havde ikke akkumuleret data i denne database, og ingen oprettede dette uønsket under iscenesættelse. Derfor var der 1 linjer, der hurtigt lykkedes.
Vi forstår, at vores tests er svage, det vil sige, at den proces, der bygges, ikke fanger problemer. Et tilstrækkeligt DB-eksperiment blev ikke udført.
Et ideelt eksperiment udføres fortrinsvis på det samme udstyr. Det er ikke altid muligt at gøre dette på det samme udstyr, men det er meget vigtigt, at det er en kopi af databasen i fuld størrelse. Det er det, jeg har prædiket i flere år nu. Og for et år siden talte jeg om dette, du kan se det hele på YouTube.
Måske er vores udstyr dårligt? Hvis du ser efter, så sprang latensen. Vi har set, at udnyttelsen er 100%. Selvfølgelig, hvis disse var moderne NVMe-drev, så ville det nok være meget nemmere for os. Og måske ville vi ikke lægge os ned fra det.
Hvis du har skyer, så udføres opgraderingen nemt der. Rejste nye replikaer på den nye hardware. skifte over. Og alt er godt. Ret nemt.
Er det muligt på en eller anden måde at røre ved de mindre diske? Og her dykker vi bare med hjælp fra DBA ned i et bestemt emne, der hedder checkpoint tuning. Det viser sig, at vi ikke havde checkpoint tuning.
Hvad er checkpoint? Det er i enhver DBMS. Når du har data i hukommelsen, der ændrer sig, bliver de ikke umiddelbart skrevet til disken. Oplysningerne om, at dataene er ændret, skrives først til fremskrivningsloggen. Og på et tidspunkt beslutter DBMS, at det er tid til at dumpe rigtige sider til disken, så hvis vi har en fejl, kan vi gøre mindre REDO. Det er ligesom et legetøj. Hvis vi bliver dræbt, starter vi spillet fra det sidste kontrolpunkt. Og alle DBMS implementerer det.
Indstillingerne i Postgres halter bagefter. De er designet til 10-15 år gamle mængder af data og transaktioner. Og checkpoint er ingen undtagelse.
Her er oplysningerne fra vores Postgres-tjekrapport, det vil sige automatisk helbredstjek. Og her er en database med flere terabyte. Og det kan godt ses, at der i næsten 90% af tilfældene blev tvunget kontrolposter.
Hvad betyder det? Der er to indstillinger der. Checkpoint kan komme efter timeout, for eksempel på 10 minutter. Eller det kan komme, når ret mange data er blevet udfyldt.
Og som standard er max_wal_saze indstillet til 1 gigabyte. Faktisk sker dette virkelig i Postgres efter 300-400 megabyte. Du har ændret så mange data, og dit kontrolpunkt sker.
Og hvis ingen tunede den, og tjenesten voksede, og virksomheden tjener mange penge, den har mange transaktioner, så kommer kontrolpunktet en gang i minuttet, nogle gange hvert 30. sekund, og nogle gange endda overlapper det. Det her er ret dårligt.
Og vi skal sørge for, at det kommer sjældnere. Det vil sige, vi kan hæve max_wal_size. Og det vil komme sjældnere.
Men vi har udviklet en hel metode til, hvordan man gør det mere korrekt, altså hvordan man træffer en beslutning om valg af indstillinger, klart baseret på specifikke data.
Derfor laver vi to serier af eksperimenter på databaser.
Den første serie - vi ændrer max_wal_size. Og vi laver en massiv operation. Først gør vi det på standardindstillingen på 1 gigabyte. Og vi laver en massiv SLETNING af mange millioner linjer.
Du kan se, hvor svært det er for os. Vi ser, at disk IO er meget dårlig. Vi ser på, hvor mange WAL'er vi har genereret, for det er meget vigtigt. Lad os se, hvor mange gange checkpointet skete. Og vi ser, at det ikke er godt.
Dernæst øger vi max_wal_size. Vi gentager. Vi øger, vi gentager. Og så mange gange. I princippet er 10 point godt, hvor 1, 2, 4, 8 gigabyte. Og vi ser på et bestemt systems adfærd. Det er klart, at her skal udstyret være som på prod. Du skal have de samme diske, den samme mængde hukommelse og de samme Postgres-indstillinger.
Og på denne måde vil vi udveksle vores system, og vi ved, hvordan DBMS vil opføre sig i tilfælde af en dårlig masse SLET, hvordan det vil checkpoint.
Checkpoint på russisk er checkpoints.
Eksempel: SLET flere millioner rækker efter indeks, rækker er "spredt" på tværs af sider.
Her er et eksempel. Dette er en base. Og med standardindstillingen på 1 gigabyte for max_wal_size, er det meget tydeligt, at vores diske går til hylden til optagelse. Dette billede er et typisk symptom på en meget syg patient, det vil sige, at han virkelig havde det dårligt. Og der var en enkelt operation, der var bare en SLETT på flere millioner linjer.
Hvis sådan en operation tillades i prod, så lægger vi os bare ned, for det er klart, at en SLETT slår os ihjel i regimentet.
Yderligere, hvor 16 gigabyte, er det tydeligt, at tænderne allerede er gået. Tænder er allerede bedre, det vil sige, vi banker på loftet, men ikke så slemt. Der var noget frihed der. Til højre er posten. Og antallet af operationer - den anden graf. Og det er klart, at vi allerede trækker vejret lidt lettere, når 16 gigabyte.
Og hvor 64 gigabyte kan ses, at det er blevet helt bedre. Allerede tænderne er udtalte, der er flere muligheder for at overleve andre operationer og gøre noget med disken.
Hvorfor så?
Jeg vil dykke lidt ned i detaljerne, men dette emne, hvordan man udfører kontrolpunkttuning, kan resultere i en hel rapport, så jeg vil ikke indlæse meget, men jeg vil skitsere lidt, hvilke vanskeligheder der er.
Hvis kontrolpunktet sker for ofte, og vi opdaterer vores linjer ikke sekventielt, men finder efter indeks, hvilket er godt, fordi vi ikke sletter hele tabellen, så kan det ske, at vi først rørte den første side, derefter den tusinde, og så tilbage til den første. Og hvis checkpoint mellem disse besøg på den første side allerede har gemt det på disken, så gemmer det det igen, fordi vi fik det beskidt en anden gang.
Og vi vil tvinge checkpoint til at gemme det mange gange. Hvordan ville der være overflødige operationer for ham.
Men det er ikke alt. Sider er 8 kilobyte i Postgres og 4 kilobyte i Linux. Og der er en full_page_writes indstilling. Det er aktiveret som standard. Og det er korrekt, for slår vi den fra, så er der fare for, at kun halvdelen af siden bliver gemt, hvis den går ned.
Opførslen ved at skrive til WAL for forward-loggen er sådan, at når vi har et kontrolpunkt, og vi skifter side for første gang, kommer hele siden, dvs. alle 8 kilobytes, ind i forward-loggen, selvom vi kun ændrede linje, som vejer 100 bytes. Og vi skal skrive hele siden ned.
I efterfølgende ændringer vil der kun være en specifik tupel, men for første gang skriver vi alt ned.
Og følgelig, hvis kontrolpunktet skete igen, så er vi nødt til at starte alt fra bunden igen og skubbe hele siden. Med hyppige kontrolpunkter, når vi går gennem de samme sider, vil full_page_writes = on være mere, end det kunne være, dvs. vi genererer mere WAL. Mere sendes til replikaer, til arkivet, til disk.
Og derfor har vi to afskedigelser.
Hvis vi øger max_wal_size, viser det sig, at vi gør det nemmere for både checkpoint og wal writer. Og det er fantastisk.
Lad os lægge en terabyte ind og leve med det. Hvad er der dårligt ved det? Det er slemt, for i tilfælde af en fiasko vil vi klatre i timevis, fordi checkpointet var længe siden, og meget har allerede ændret sig. Og vi er nødt til at gøre alt dette REDO. Og så laver vi den anden serie af eksperimenter.
Vi laver en operation og ser hvornår checkpointet er ved at være færdigt, vi dræber -9 Postgres med vilje.
Og derefter starter vi den igen, og ser hvor længe den vil stige på dette udstyr, altså hvor meget den vil GENOPRET i denne dårlige situation.
To gange vil jeg bemærke, at situationen er dårlig. Først styrtede vi ned lige før checkpointet var forbi, så vi har meget at tabe. Og for det andet havde vi en massiv operation. Og hvis checkpoints var på timeout, så ville der højst sandsynligt være genereret mindre WAL siden det sidste checkpoint. Det vil sige, at det er en dobbelt taber.
Vi måler en sådan situation for forskellige max_wal_size størrelser og forstår, at hvis max_wal_size er 64 gigabyte, så vil vi i et dobbelt værste tilfælde klatre i 10 minutter. Og vi tænker, om det passer os eller ej. Dette er et forretningsspørgsmål. Vi skal vise dette billede til dem, der er ansvarlige for forretningsbeslutninger og spørge: "Hvor længe kan vi højst ligge ned i tilfælde af et problem? Kan vi ligge i den værste situation i 3-5 minutter? Og du træffer en beslutning.
Og her er en interessant pointe. Vi har et par rapporter om Patroni på konferencen. Og måske bruger du det. Dette er en autofailover for Postgres. GitLab og Data Egret talte om dette.
Og hvis du har en autofailover, der kommer om 30 sekunder, så kan vi måske ligge ned i 10 minutter? Fordi vi vil skifte til replikaen på dette tidspunkt, og alt vil være fint. Dette er et omstridt punkt. Jeg kender ikke et klart svar. Jeg føler bare, at dette emne ikke kun handler om crash recovery.
Hvis vi har en lang bedring efter en fiasko, så vil vi være utilpas i mange andre situationer. For eksempel i de samme eksperimenter, når vi gør noget og nogle gange skal vente i 10 minutter.
Jeg ville stadig ikke gå for langt, selvom vi har en autofailover. Som regel er værdier som 64, 100 gigabyte gode værdier. Nogle gange er det endda værd at vælge mindre. Generelt er dette en subtil videnskab.
For at udføre iterationer, for eksempel max_wal_size =1, 8, skal du gentage masseoperationen mange gange. Du gjorde det. Og på samme base vil du gøre det igen, men du har allerede slettet alt. Hvad skal man gøre?
Jeg vil tale senere om vores løsning, hvad vi gør for at gentage i sådanne situationer. Og dette er den mest korrekte tilgang.
Men i dette tilfælde var vi heldige. Hvis, som der står her "BEGIN, DELETE, ROLLBACK", så kan vi gentage SLET. Det vil sige, at hvis vi selv aflyste det, så kan vi gentage det. Og fysisk hos dig vil dataene ligge samme sted. Du får ikke engang nogen oppustethed. Du kan iterere over sådanne DELETEs.
Denne DELETE med ROLLBACK er ideel til tuning af kontrolpunkter, selvom du ikke har en korrekt installeret databaselab.
Vi lavede en plade med en kolonne "i". Postgres har hjælpekolonner. De er usynlige, medmindre der specifikt bliver bedt om det. Disse er: ctid, xmid, xmax.
Ctid er en fysisk adresse. Nul side, den første tuple på siden.
Det kan ses, at efter ROOLBACK forblev tuple på samme sted. Det vil sige, vi kan prøve igen, det vil opføre sig på samme måde. Dette er det vigtigste.
Xmax er tidspunktet for tupelens død. Det var stemplet, men Postgres ved, at transaktionen blev rullet tilbage, så det er lige meget, om det er 0, eller det er en rullet tilbage transaktion. Dette tyder på, at det er muligt at iterere over DELETE og kontrollere bulk-operationerne af systemets adfærd. Du kan lave databaselaboratorier for de fattige.
Det handler om programmører. Også om DBA skælder de altid programmører ud for dette: "Hvorfor laver du så lange og svære operationer?". Dette er et helt andet vinkelret emne. Tidligere var der administration, og nu vil der ske udvikling.
Det er klart, at vi ikke er gået i stykker. Det er klart. Det er umuligt ikke at bryde en sådan DELETE for en bunke af millioner af linjer i dele. Det vil blive gjort i 20 minutter, og alt vil ligge ned. Men desværre laver selv erfarne udviklere fejl, selv i meget store virksomheder.
Hvorfor er det vigtigt at bryde?
-
Hvis vi ser, at disken er hård, så lad os bremse den. Og hvis vi er i stykker, så kan vi tilføje pauser, vi kan bremse gassen.
-
Og vi vil ikke blokere andre i lang tid. I nogle tilfælde er det ligegyldigt, hvis du sletter ægte affald, som ingen arbejder på, så vil du højst sandsynligt ikke blokere nogen undtagen autovakuum-arbejdet, fordi det vil vente på, at transaktionen er fuldført. Men hvis du fjerner noget, som en anden kan anmode om, så bliver de blokeret, der vil være en form for kædereaktion. Lange transaktioner bør undgås på websteder og mobilapplikationer.
Det er interessant. Jeg ser ofte, at udviklere spørger: "Hvilken pakkestørrelse skal jeg vælge?".
Det er klart, at jo større bundtstørrelsen er, jo mindre er transaktionsomkostningerne, dvs. de ekstra omkostninger fra transaktioner. Men samtidig øges tiden for denne transaktion.
Jeg har en meget simpel regel: tag så meget som du kan, men gå ikke over eksekverbare i sekundet.
Hvorfor et sekund? Forklaringen er meget enkel og forståelig for alle, også ikke-tekniske mennesker. Vi ser en reaktion. Lad os tage 50 millisekunder. Hvis noget har ændret sig, vil vores øje reagere. Hvis mindre, så sværere. Hvis noget reagerer efter 100 millisekunder, for eksempel, du klikkede med musen, og det svarede dig efter 100 millisekunder, mærker du allerede denne lille forsinkelse. Et sekund opfattes allerede som bremser.
Følgelig, hvis vi deler vores masseoperationer op i 10-sekunders udbrud, så har vi en risiko for, at vi blokerer nogen. Og det vil virke i et par sekunder, og folk vil allerede bemærke det. Derfor foretrækker jeg ikke at gøre mere end et sekund. Men på samme tid skal du ikke bryde det meget fint op, fordi transaktionens overhead vil være mærkbar. Basen bliver hårdere, og andre forskellige problemer kan opstå.
Vi vælger størrelsen på pakken. I hvert tilfælde kan vi gøre det anderledes. Kan automatiseres. Og vi er overbeviste om effektiviteten af behandlingen af én pakke. Det vil sige, at vi sletter én pakke eller OPDATERING.
Alt, hvad jeg taler om, handler i øvrigt ikke kun om SLET. Som du har gættet, er dette enhver masseoperationer på data.
Og vi ser, at planen er fremragende. Du kan se indeksscanningen, kun indeksscanning er endnu bedre. Og vi har en lille mængde data involveret. Og mindre end et sekund opfylder. Super.
Og vi skal stadig sikre os, at der ikke sker nogen nedbrydning. Det sker, at de første pakker hurtigt løser sig, og så bliver det værre, værre og værre. Processen er sådan, at du skal teste meget. Det er præcis, hvad databaselaboratorier er til.
Og vi skal stadig forberede noget, så det giver os mulighed for at følge dette korrekt i produktionen. For eksempel kan vi skrive tiden i loggen, vi kan skrive hvor vi er nu og hvem vi nu har slettet. Og dette vil give os mulighed for at forstå, hvad der sker senere. Og hvis noget går galt, så find hurtigt problemet.
Hvis vi har brug for at kontrollere effektiviteten af anmodninger, og vi skal gentage mange gange, så er der sådan noget som en kollega-bot. Han er allerede klar. Det bruges af snesevis af udviklere dagligt. Og han ved, hvordan man giver en enorm terabyte-database på anmodning på 30 sekunder, din egen kopi. Og du kan slette noget der og sige RESET, og slette det igen. Du kan eksperimentere med det på denne måde. Jeg ser en fremtid for denne ting. Og vi gør det allerede.
Hvad er opdelingsstrategier? Jeg ser 3 forskellige partitioneringsstrategier, som udviklerne på pakken bruger.
Den første er meget enkel. Vi har et numerisk ID. Og lad os dele det op i forskellige intervaller og arbejde med det. Ulempen er klar. I det første segment kan vi have 100 linjer med ægte affald, i det andet 5 linjer eller slet ikke, eller alle 1 linjer vil vise sig at være affald. Meget ujævnt arbejde, men det er let at bryde. De tog det maksimale ID og smadrede det. Dette er en naiv tilgang.
Den anden strategi er en afbalanceret tilgang. Det bruges i Gitlab. De tog og scannede bordet. Vi fandt grænserne for ID-pakkerne, så hver pakke havde præcis 10 poster. Og sæt dem i kø. Og så behandler vi. Du kan gøre dette i flere tråde.
I den første strategi kan du i øvrigt også gøre dette i flere tråde. Det er ikke svært.
Men der er en køligere og bedre tilgang. Dette er den tredje strategi. Og når det er muligt, er det bedre at vælge det. Det gør vi ud fra et særligt indeks. I dette tilfælde vil det højst sandsynligt være et indeks i henhold til vores affaldstilstand og ID. Vi vil inkludere ID'et, så det kun er en indeksscanning, så vi ikke går til dyngen.
Generelt er kun indeksscanning hurtigere end indeksscanning.
Og vi finder hurtigt vores ID'er, som vi vil fjerne. BATCH_SIZE vælger vi på forhånd. Og vi får dem ikke kun, vi får dem på en særlig måde og hacker dem straks. Men vi låser, så hvis de allerede er låst, låser vi dem ikke, men går videre og tager de næste. Dette er for opdateringsspring låst. Denne superfunktion ved Postgres giver os mulighed for at arbejde i flere tråde, hvis vi vil. Det er muligt i én strøm. Og her er der en CTE - dette er en anmodning. Og vi har en rigtig sletning i gang på anden sal i denne CTE - returning *. Du kan returnere id, men det er bedre *hvis du ikke har mange data på hver linje.
Hvorfor har vi brug for det? Det er det, vi skal melde tilbage. Vi har nu slettet så mange linjer faktisk. Og vi har grænser efter ID eller ved create_at som denne. Du kan lave min, max. Noget andet kan gøres. Du kan fylde meget her. Og det er meget praktisk til overvågning.
Der er endnu en bemærkning om indekset. Hvis vi beslutter, at vi har brug for et særligt indeks til denne opgave, så skal vi sørge for, at det ikke ødelægger bunke-kun tuples-opdateringer. Det vil sige, at Postgres har sådanne statistikker. Dette kan ses i pg_stat_user_tables for din tabel. Du kan se, om varme opdateringer bliver brugt eller ej.
Der er situationer, hvor dit nye indeks simpelthen kan afskære dem. Og du har alle de andre opdateringer, der allerede virker, sæt farten ned. Ikke bare fordi indekset dukkede op (hvert indeks bremser opdateringerne lidt, men lidt), men her ødelægger det det stadig. Og det er umuligt at lave speciel optimering til dette bord. Dette sker nogle gange. Dette er sådan en subtilitet, som de færreste husker. Og denne rive er nem at træde på. Nogle gange sker det, at du skal finde en tilgang fra den anden side og stadig undvære dette nye indeks, eller lave et andet indeks, eller på anden måde, for eksempel, kan du bruge den anden metode.
Men dette er den mest optimale strategi, hvordan man opdeler i batches og skyder på batches med én anmodning, sletter en lille smule osv.
Lange transaktioner
Blokeret autovakuum -
blokeringsproblem -
Fejl nr. 5 er stor. Nikolai fra Okmeter fortalte om Postgres-overvågning. Ideel Postgres-overvågning findes desværre ikke. Nogle er tættere på, nogle er længere. Okmeter er tæt nok på at være perfekt, men der mangler meget og skal tilføjes. Du skal være klar til dette.
For eksempel er døde tupler bedst overvåget. Hvis du har mange døde ting på bordet, så er der noget galt. Det er bedre at reagere nu, ellers kan der komme nedbrydning, og vi kan ligge ned. Det sker.
Hvis der er en stor IO, så er det klart, at dette ikke er godt.
Også lange transaktioner. Lange transaktioner bør ikke tillades på OLTP. Og her er et link til et uddrag, der giver dig mulighed for at tage dette uddrag og allerede lave sporing af lange transaktioner.
Hvorfor er lange transaktioner dårlige? Fordi alle låsene først udløses til sidst. Og vi sviner alle til. Derudover blokerer vi autovakuum for alle borde. Det er slet ikke godt. Selvom du har aktiveret varm standby på replikaen, er det stadig dårligt. Generelt er det ingen steder bedre at undgå lange transaktioner.
Hvis vi har mange borde, der ikke er støvsuget, så skal vi have en alarm. Her er en sådan situation mulig. Vi kan indirekte påvirke driften af autovakuum. Dette er et uddrag fra Avito, som jeg forbedrede lidt. Og det viste sig at være et interessant værktøj til at se, hvad vi har med autovakuum. For eksempel venter nogle borde der og vil ikke vente på deres tur. Du skal også sætte den i overvågning og have en alarm.
Og udsteder blokke. Skov af bloktræer. Jeg kan godt lide at tage noget fra nogen og forbedre det. Her tog jeg en sej rekursiv CTE fra Data Egret, der viser en skov af slusetræer. Dette er et godt diagnostisk værktøj. Og på grundlag heraf kan du også bygge overvågning. Men dette skal gøres omhyggeligt. Du skal lave en lille statement_timeout for dig selv. Og lock_timeout er ønskeligt.
Nogle gange opstår alle disse fejl i sum.
Efter min mening er den største fejl her organisatorisk. Det er organisatorisk, for teknikken trækker ikke. Dette er nummer 2 - de tjekkede det forkerte sted.
Vi tjekkede det forkerte sted, fordi vi ikke havde en produktionsklon, som er nem at tjekke. En udvikler har muligvis slet ikke adgang til produktion.
Og vi tjekkede ikke der. Hvis vi havde tjekket der, havde vi selv set det. Udvikleren så det hele selv uden en DBA, hvis han tjekkede det i et godt miljø, hvor der er den samme mængde data og en identisk placering. Han ville have set al denne nedværdigelse, og han ville skamme sig.
Mere om autovakuum. Efter at vi har foretaget et massivt sweep på flere millioner linjer, mangler vi stadig at PAKKE GEN. Dette er især vigtigt for indekser. De vil have det dårligt, når vi har renset alt der.
Og hvis du vil bringe det daglige rengøringsarbejde tilbage, så vil jeg foreslå at gøre det oftere, men mindre. Det kan være en gang i minuttet eller endda oftere en lille smule. Og du skal overvåge to ting: at denne ting ikke har nogen fejl, og at den ikke halter bagefter. Det trick, jeg viste, vil bare løse dette.
Det, vi gør, er open source. Det er lagt ud på GitLab. Og vi gør det, så folk kan tjekke selv uden en DBA. Vi laver et databaselaboratorium, det vil sige, vi kalder den basiskomponent, som Joe arbejder på i øjeblikket. Og du kan få fat i en kopi af produktionen. Nu er der en implementering af Joe for slack, du kan sige der: "forklar sådan og sådan en anmodning" og straks få resultatet for din kopi af databasen. Du kan endda SLETTE der, og ingen vil bemærke det.
Lad os sige, at du har 10 terabyte, vi gør databaselab også til 10 terabyte. Og med samtidige 10 terabyte databaser kan 10 udviklere arbejde samtidigt. Alle kan gøre, hvad de vil. Kan slette, slippe osv. Det er sådan en fantasi. Det taler vi om i morgen.
Dette kaldes tynd provisionering. Dette er subtil levering. Dette er en form for fantasi, der i høj grad fjerner forsinkelser i udvikling, i test og gør verden til et bedre sted i denne henseende. Det vil sige, at det bare giver dig mulighed for at undgå problemer med bulkoperationer.
Eksempel: 5 terabyte database, får en kopi på mindre end 30 sekunder. Og det afhænger ikke engang af størrelsen, det vil sige, det er lige meget hvor mange terabyte.
I dag kan du gå til og grave i vores værktøjer. Du kan tilmelde dig for at se, hvad der er der. Du kan installere denne bot. Det er gratis. Skrive.
R'RѕRїSЂRѕSЃS <
Meget ofte i virkelige situationer viser det sig, at de data, der skal forblive i tabellen, er meget mindre end det, der skal slettes. Det vil sige, at i en sådan situation er det ofte lettere at implementere en sådan tilgang, når det er lettere at oprette et nyt objekt, kun kopiere de nødvendige data der og trunk den gamle tabel. Det er klart, at en programmatisk tilgang er nødvendig i dette øjeblik, mens du skifter. Hvordan er denne tilgang?
Dette er en meget god tilgang og en meget god opgave. Det minder meget om hvad pg_repack gør, det minder meget om hvad du skal gøre når du laver ID'er til 4 bytes. Mange frameworks gjorde dette for nogle år siden, og bare pladerne er vokset op, og de skal konverteres til 8 bytes.
Denne opgave er ret vanskelig. Vi gjorde det. Og du skal være meget forsigtig. Der er låse osv. Men det bliver gjort. Det vil sige, at standardtilgangen er at gå med pg_repack. Du erklærer en sådan etiket. Og før du begynder at uploade snapshot-data til den, erklærer du også én plade, der sporer alle ændringer. Der er et trick, at du måske ikke engang sporer nogle ændringer. Der er finesser. Og så skifter du ved at rulle ændringer. Der vil være en kort pause, når vi lukker alle ned, men generelt bliver det gjort.
Hvis du ser på pg_repack på GitHub, så var der, når der var en opgave at konvertere et ID fra int 4 til int 8, så var der en idé om at bruge selve pg_repack. Dette er også muligt, men det er lidt af et hack, men det vil også fungere til dette. Du kan gribe ind i den trigger, som pg_repack bruger, og sige der: "Vi behøver ikke disse data", dvs. vi overfører kun det, vi har brug for. Og så skifter han bare, og det er det.
Med denne tilgang får vi stadig en anden kopi af tabellen, hvor dataene allerede er indekseret og stablet meget jævnt med smukke indekser.
Bloat er ikke til stede, det er en god tilgang. Men jeg ved, at der er forsøg på at udvikle en automatisering til dette, altså at lave en universel løsning. Jeg kan sætte dig i kontakt med denne automatisering. Det er skrevet i Python, hvilket er en god ting.
Jeg er bare en lille smule fra MySQL-verdenen, så jeg kom for at lytte. Og vi bruger denne tilgang.
Men det er kun, hvis vi har 90 pct. Hvis vi har 5 %, så er det ikke særlig godt at bruge det.
Tak for rapporten! Hvis der ikke er ressourcer til at lave en komplet kopi af prod, er der så nogen algoritme eller formel til at beregne belastningen eller størrelsen?
Godt spørgsmål. Indtil videre er vi i stand til at finde multi-terabyte databaser. Selvom hardwaren der ikke er den samme, for eksempel mindre hukommelse, mindre processor og diske er ikke helt det samme, men alligevel gør vi det. Hvis der absolut ingen steder er, så skal du tænke dig om. Lad mig tænke til i morgen, du kom, vi vil tale, det er et godt spørgsmål.
Tak for rapporten! Du startede først med, at der er en cool Postgres, som har sådanne og sådanne begrænsninger, men den er under udvikling. Og det hele er i det store og hele en krykke. Er det ikke alt sammen i konflikt med udviklingen af selve Postgres, hvor der vil optræde en eller anden DELETE deferent eller noget andet, der burde holde på et lavt niveau, hvad vi forsøger at smøre med nogle af vores mærkelige midler her?
Hvis vi sagde i SQL at slette eller opdatere mange poster i en transaktion, hvordan kan Postgres så distribuere det der? Vi er fysisk begrænset i driften. Vi vil stadig gøre det i lang tid. Og vi låser på dette tidspunkt osv.
Færdig med indekser.
Jeg kan antage, at den samme kontrolpunkt-indstilling kunne automatiseres. En dag bliver det måske. Men så forstår jeg ikke rigtig spørgsmålet.
Spørgsmålet er, om der er sådan en udviklingsvektor, der går her og der, og her går din parallelt? De der. Har de ikke tænkt over det endnu?
Jeg talte om de principper, der kan bruges nu. Der er en anden bot , med dette kan du lave automatiseret checkpoint tuning. Vil det en dag være i Postgres? Jeg ved det ikke, det er ikke engang blevet diskuteret endnu. Det er vi stadig langt fra. Men der er videnskabsmænd, der laver nye systemer. Og de skubber os ind i automatiske indekser. Der er udviklinger. For eksempel kan du se på auto tuning. Den vælger parametre automatisk. Men han vil ikke foretage checkpoint tuning for dig endnu. Det vil sige, at den vil samle op for ydeevne, shellbuffer osv.
Og til kontrolpunkttuning kan du gøre dette: hvis du har tusinde klynger og forskellig hardware, forskellige virtuelle maskiner i skyen, kan du bruge vores bot lave automatisering. Og max_wal_size vil automatisk blive valgt i henhold til dine målindstillinger. Men indtil videre er dette ikke engang tæt i kernen, desværre.
God eftermiddag Du talte om farerne ved lange transaktioner. Du sagde, at autovakuum er blokeret i tilfælde af sletninger. Hvordan skader det os ellers? For vi taler mere om at frigøre plads og at kunne bruge den. Hvad mangler vi ellers?
Autovacuum er måske ikke det største problem her. Og det faktum, at en lang transaktion kan låse andre transaktioner, er denne mulighed mere farlig. Hun mødes måske eller ikke. Hvis hun mødtes, så kan det være meget slemt. Og med autovakuum - dette er også et problem. Der er to problemer med lange transaktioner i OLTP: låse og autovakuum. Og hvis du har aktiveret varm standby-feedback på replikaen, så vil du stadig modtage en autovakuumlås på masteren, den kommer fra replikaen. Men der kommer i hvert fald ingen låse. Og der vil være loks. Vi taler om dataændringer, så låse er et vigtigt punkt her. Og hvis det hele er i lang, lang tid, så er flere og flere transaktioner låst. De kan stjæle andre. Og der kommer træer frem. Jeg har givet et link til uddraget. Og dette problem bliver hurtigere mærkbart end problemet med autovakuum, som kun kan akkumulere.
Tak for rapporten! Du startede din rapport med at sige, at du testede forkert. Vi fortsatte vores idé om, at vi skal tage det samme udstyr, med basen på samme måde. Lad os sige, at vi gav udvikleren en base. Og han efterkom anmodningen. Og han ser ud til at have det fint. Men han tjekker ikke for live, men for live har vi for eksempel en belastning på 60-70%. Og selvom vi bruger denne tuning, fungerer det ikke særlig godt.
Det er vigtigt at have en ekspert på holdet og bruge DBA-eksperter, der kan forudsige, hvad der vil ske med en reel baggrundsbelastning. Da vi lige har kørt vores rene ændringer, ser vi billedet. Men en mere avanceret tilgang, da vi gjorde det samme igen, men med en belastning simuleret med produktion. Det er ret fedt. Indtil da skal du blive voksen. Det er ligesom en voksen. Vi har lige set på, hvad vi har, og også set på, om vi har ressourcer nok. Det er et godt spørgsmål.
Når vi allerede laver en garbage select, og vi for eksempel har et slettet flag
Dette er, hvad autovacuum gør automatisk i Postgres.
Åh, gør han det?
Autovacuum er skraldeopsamleren.
Tak!
Tak for rapporten! Er der mulighed for straks at designe en database med partitionering på en sådan måde, at alt affald bliver snavset fra hovedbordet et sted til siden?
Selvfølgelig er der.
Er det så muligt at beskytte os selv, hvis vi har låst et bord, der ikke skal bruges?
Selvfølgelig har. Men det er ligesom et spørgsmål om kylling og æg. Hvis vi alle ved, hvad der vil ske i fremtiden, så vil vi selvfølgelig gøre alting cool. Men forretningen ændrer sig, der er nye kolonner, nye anmodninger. Og så – ups, vi vil gerne fjerne det. Men denne ideelle situation, i livet det forekommer, men ikke altid. Men alt i alt er det en god idé. Bare afkort og det er det.
Kilde: www.habr.com