Jeg foreslår, at du læser udskriften af rapporten fra begyndelsen af 2019 af Andrey Borodin "Sikkerhedskopier med WAL-G. Hvad er der i 2019?"
Hej alle! Mit navn er Andrey Borodin. Jeg er udvikler hos Yandex. Jeg har været interesseret i PostgreSQL siden 2016, efter at jeg talte med udviklerne, og de sagde, at alt er simpelt - du tager kildekoden og bygger den, og alt vil fungere. Og siden kan jeg ikke stoppe - jeg skriver alle mulige forskellige ting.
En af de ting, jeg arbejder på, er et backup-system. . Generelt har vi hos Yandex arbejdet på backup-systemer i PostgreSQL i meget lang tid. Og du kan på internettet finde en serie på seks rapporter om, hvordan vi laver backup-systemer. Og hvert år udvikler de sig lidt, udvikler sig lidt og bliver mere pålidelige.
Men i dag handler rapporten ikke kun om, hvad vi har gjort, men også om, hvor enkelt det er, og hvad der er. Hvor mange af jer har allerede set mine rapporter om WAL-G? Det er godt, at en del mennesker ikke så med, for jeg starter med det enkleste.
Hvis du pludselig har en PostgreSQL-klynge, og jeg tror, at alle har et par af dem med sig, og der pludselig ikke er noget backup-system endnu, så skal du have et hvilket som helst S3-lager eller Google Cloud-kompatibelt lager.
Du kan for eksempel komme til vores stand og tage en kampagnekode til Yandex Object Storage, som er S3-kompatibel.
Opret derefter en Bucket. Det er blot en beholder til information.
Opret en tjenestebruger.
Opret en adgangsnøgle til tjenestebrugeren: aws-s3-key.
Download den seneste stabile udgivelse af WAL-G.
Hvordan adskiller vores pre-releases sig fra udgivelser? Jeg bliver ofte bedt om at slippe tidligt. Og hvis der ikke er nogen fejl i versionen i tilstrækkelig tid, for eksempel en måned, så frigiver jeg den. Her er denne udgivelse fra november. Og det betyder, at vi hver måned fandt en slags fejl, normalt i ikke-kritisk funktionalitet, men vi har endnu ikke udgivet en udgivelse. Den tidligere version er kun november. Der er ingen fejl, vi kender til i den, dvs. fejl blev tilføjet, efterhånden som projektet skred frem.
Når du har downloadet WAL-G, kan du køre en simpel "backup list"-kommando ved at sende miljøvariablerne ind. Og den vil oprette forbindelse til Object Storage og fortælle dig, hvilke sikkerhedskopier du har. I første omgang skal du selvfølgelig ikke have sikkerhedskopier. Pointen med denne slide er at vise, at alt er ret simpelt. Dette er en konsolkommando, der accepterer miljøvariabler og udfører underkommandoer.
Herefter kan du lave din første backup. Sig "backup-push" i WAL-G og angiv i WAL-G pgdata-placeringen for din klynge. Og højst sandsynligt vil PostgreSQL fortælle dig, hvis du ikke allerede har et backup-system, at du skal aktivere "arkiv-tilstand".
Det betyder, at du skal gå til indstillinger og slå “archive_mode = on” til og tilføje “archive_command”, som også er en underkommando i WAL-G. Men af en eller anden grund bruger folk ofte bar scripts om dette emne og pakker det rundt om WAL-G. Gør venligst ikke dette. Brug den funktionalitet, der findes i WAL-G. Hvis du mangler noget, så skriv til . WAL-G antager, at det er det eneste program, der kører i archive_command.
Vi bruger hovedsageligt WAL-G til at skabe en High Availability-klynge i Yandex Database Management.
Og det bruges normalt i en topologi af en Master og flere replikationer. Samtidig laver den en sikkerhedskopi i Yandex Object Storage.
De mest almindelige scenarier er at oprette kopier af en klynge ved hjælp af gendannelse af tidspunkt. Men i dette tilfælde er ydeevnen af backupsystemet ikke så vigtig for os. Vi skal bare uploade en ny klynge fra sikkerhedskopien.
Typisk har vi brug for backup-systemydeevne, når vi tilføjer en ny node. Hvorfor er det vigtigt? Typisk tilføjer folk en ny node til en klynge, fordi den eksisterende klynge ikke kan håndtere læsebelastningen. De skal tilføje en ny replika. Hvis vi tilføjer belastningen fra pg_basebackup til masteren, kan masteren kollapse. Derfor var det meget vigtigt for os, at vi hurtigt kunne uploade en ny node fra arkivet, hvilket skabte minimal belastning på Masteren.
Og en anden lignende situation. Dette er behovet for at genstarte den gamle master efter at have skiftet Cluster Master fra det datacenter, som forbindelsen gik tabt med.
- Som et resultat, da vi formulerede kravene til kopisystemet, indså vi, at pg_basebackup ikke er egnet til os, når vi opererer i skyen.
- Vi ønskede at kunne komprimere vores data. Men næsten ethvert backup-system, bortset fra det, der følger med i kassen, vil give datakomprimering.
- Vi ønskede at parallelisere alt, fordi en bruger i skyen køber et stort antal processorkerner. Men hvis vi ikke har parallelitet i en eller anden operation, så bliver et stort antal kerner ubrugelige.
- Vi har brug for kryptering, fordi dataene ofte ikke er vores og ikke kan gemmes i klartekst. Vores bidrag til WAL-G begyndte i øvrigt med kryptering. Vi gennemførte krypteringen i WAL-G, hvorefter vi blev spurgt: "Måske vil en af os udvikle projektet?" Og siden da har jeg arbejdet med WAL-G i mere end et år.
- Vi havde også brug for ressourcebegrænsning, for med tiden ved brug af skyen fandt vi ud af, at nogle gange har folk en vigtig dagligvarebelastning om natten, og denne belastning kan ikke forstyrres. Det er derfor, vi tilføjede ressourceregulering.
- Samt notering og ledelse.
- Og verifikation.
Vi kiggede på en masse forskellige værktøjer. Heldigvis har vi et kæmpe udvalg i PostgreSQL. Og overalt manglede vi noget, en lille funktion, en lille funktion.
Og efter at have undersøgt de eksisterende systemer, kom vi til den konklusion, at vi vil udvikle WAL-G. Det var et nyt projekt dengang. Det var ret nemt at påvirke udviklingen hen imod backupsystemets cloud-infrastruktur.
Den vigtigste ideologi, som vi holder os til, er, at WAL-G skal være så simpel som en balalajka.
WAL-G har 4 kommandoer. Det her:
WAL-PUSH – arkivér skaftet.
WAL-FETCH – få et skaft.
BACKUP-PUSH – lav en sikkerhedskopi.
BACKUP-FETCH – få en backup fra backup-systemet.
Faktisk har WAL-G også styring af disse sikkerhedskopier, det vil sige at liste og slette poster og sikkerhedskopier i historikken, som ikke længere er nødvendige i øjeblikket.
En af de vigtige funktioner for os er funktionen med at skabe deltakopier.
Delta-kopier betyder, at vi ikke laver en fuld backup af hele klyngen, men kun de ændrede sider af de ændrede filer i klyngen. Det ser ud til, at dette funktionelt ligner meget evnen til at gendanne ved hjælp af WAL. Men vi kan rulle op en WAL enkelt-trådet delta backup parallelt. Derfor, når vi har lavet en grundlæggende backup om lørdagen, delta backups dagligt, og om torsdagen fejler vi, så er vi nødt til at rulle op 4 delta backups og 10 timers WAL. Det vil tage omtrent samme tid, fordi delta backups ruller parallelt.
LSN-baserede deltaer - dette betyder, at når vi opretter en sikkerhedskopi, bliver vi nødt til at kombinere hver side og kontrollere dens LSN med LSN for den tidligere backup for at forstå, at den har ændret sig. Enhver side, der potentielt kan indeholde ændrede data, bør være til stede i delta-backupen.
Som sagt var der ret meget opmærksomhed på parallelitet.
Men arkiv-API'en i PostgreSQL er konsekvent. PostgreSQL arkiverer én WAL-fil og anmoder om én WAL-fil, når den gendannes. Men når databasen anmoder om én WAL-fil ved hjælp af kommandoen "WAL-FETCH", kalder vi kommandoen "WAL-PREFETCH", som forbereder de næste 8 filer til at hente data fra objektlageret parallelt.
Og når databasen beder os om at arkivere én fil, ser vi på archive_status og ser, om der er andre WAL-filer. Og vi forsøger også at downloade WAL parallelt. Dette giver en betydelig ydelsesforøgelse og reducerer afstanden i antallet af ikke-arkiverede WALs markant. Mange udviklere af backup-systemer mener, at dette er så risikabelt et system, fordi vi stoler på vores viden om det interne af kode, der ikke er PostgreSQL API. PostgreSQL garanterer ikke tilstedeværelsen af mappen archive_status for os og garanterer ikke semantikken, tilstedeværelsen af parathedssignaler til WAL-filer der. Ikke desto mindre studerer vi kildekoden, vi ser, at det er sådan, og vi forsøger at udnytte det. Og vi kontrollerer retningen, som PostgreSQL udvikler sig i; hvis denne mekanisme pludselig er brudt, stopper vi med at bruge den.
I sin rene form kræver LSN-baseret WAL delta læsning af enhver klyngefil, hvis tilstandstid i filsystemet er ændret siden den forrige sikkerhedskopiering. Det levede vi med i lang tid, næsten et år. Og til sidst kom vi til den konklusion, at vi har WAL-deltaer.
Det betyder, at hver gang vi arkiverer WAL på Master, komprimerer vi det ikke kun, krypterer det og sender det til netværket, men vi læser det også på samme tid. Vi analyserer og læser optegnelserne i den. Vi forstår hvilke blokke der har ændret sig og indsamler deltafiler.
En delta-fil beskriver et bestemt udvalg af WAL-filer, beskriver information om, hvilke blokke der blev ændret i dette WAL-område. Og så bliver disse deltafiler også arkiveret.
Her står vi over for, at vi paralleliserede alt ret hurtigt, men vi kan ikke læse en sekventiel historie parallelt, fordi vi i et bestemt segment kan støde på slutningen af den tidligere WAL-rekord, som vi ikke har noget at forbinde med endnu, fordi parallellæsning førte til, at vi først analyserer fremtiden, som endnu ikke har en fortid.
Som et resultat var vi nødt til at lægge uforståelige stykker ind i _delta_partial-filer. Som et resultat, når vi vender tilbage til fortiden, limer vi stykkerne af WAL-posten ind i en, derefter vil vi analysere den og forstå, hvad der er ændret i den.
Hvis der i historien om vores akselparsing er mindst et punkt, hvor vi ikke forstår, hvad der skete, så vil vi derfor under den næste backup blive tvunget til at læse hele klyngen igen, ligesom vi gjorde med en almindelig LSN -baseret delta.
Som et resultat førte al vores lidelse til, at vi åbnede WAL-G-parsingbiblioteket. Så vidt jeg ved, er der ingen, der bruger det endnu, men hvis nogen vil, så skriv og brug det, er det i offentlig ejendom. (Opdateret link )
Som følge heraf ser alle informationsstrømme ret komplicerede ud. Vores Master arkiverer skakten og arkiverer deltafiler. Og den replika, der laver sikkerhedskopien, skal modtage deltafiler i den tid, der er gået mellem sikkerhedskopieringerne. I dette tilfælde skal dele af historien tilføjes i bulk og parses, fordi ikke hele historien passer ind i store segmenter. Og først efter dette kan replikaen arkivere en fuld delta backup.
På graferne ser alt meget enklere ud. Dette er en download fra en af vores rigtige klynger. Vi har LSN-baseret, lavet på én dag. Og vi ser, at den LSN-baserede delta-backup kørte fra tre om morgenen til fem om morgenen. Dette er belastningen i antallet af processorkerner. WAL-delta tog os omkring 20 minutter her, det vil sige, at det blev væsentligt hurtigere, men samtidig var der en mere intens udveksling over netværket.
Da vi har information om, hvilke blokke der er ændret og på hvilket tidspunkt i databasens historie, gik vi videre og besluttede at integrere funktionalitet - en PostgreSQL-udvidelse kaldet "pg_prefaulter"
Dette betyder, at når standby-basen udfører gendannelseskommandoen, fortæller den WAL-G om at hente den næste WAL-fil. Vi forstår omtrent hvilke datablokke WAL-gendannelsesprocessen vil få adgang til i den nærmeste fremtid og starter en læseoperation på disse blokke. Dette blev gjort for at øge ydeevnen af SSD-controllere. Fordi WAL-rullen vil nå den side, der skal ændres. Denne side er på disk og er ikke i sidecachen. Og han vil vente synkront på, at denne side kommer. Men i nærheden er WAL-G, som ved, at vi i de næste par hundrede megabyte WAL får brug for bestemte sider og samtidig begynder at varme dem op. Starter flere diskadgange, så de udføres parallelt. Dette fungerer godt på SSD-drev, men desværre er det absolut ikke anvendeligt til en harddisk, fordi vi kun forstyrrer det med vores prompter.
Det er det, der står i koden nu.
Der er funktioner, som vi gerne vil tilføje.
Dette billede viser, at WAL-delta tager relativt kort tid. Og dette er at læse de ændringer, der skete i databasen i løbet af dagen. Vi kunne lave WAL-delta ikke kun om natten, fordi det ikke længere er en væsentlig kilde til belastning. Vi kan læse WAL-delta hvert minut, fordi det er billigt. På et minut kan vi scanne alle de ændringer, der er sket i klyngen. Og dette kunne kaldes "instant WAL-delta".
Pointen er, at når vi gendanner klyngen, reducerer vi antallet af historier, som vi skal rulle op sekventielt. Det vil sige mængden af WAL, som PostgreSQL ruller, bør reduceres, fordi det tager betydelig tid.
Men det er ikke alt. Hvis vi ved, at en eller anden blok vil blive ændret til punktet af backupkonsistens, kan vi ikke ændre det tidligere. Det vil sige, nu har vi fil-for-fil optimering af WAL-delta forwarding. Det betyder, at hvis for eksempel en tabel tirsdag blev fuldstændig slettet, eller nogle filer blev slettet helt fra tabellen, så vil vi ikke engang oprette disse data, når delta ruller over mandag og lørdagens pg_basebackup gendannes.
Vi ønsker at udvide denne teknologi til sideniveau. Det vil sige, at hvis en del af filen ændres på mandag, men vil blive overskrevet på onsdag, så behøver vi ikke at skrive de første par versioner af sider til disken, når vi gendanner til et punkt på torsdag.
Men det er stadig en idé, der diskuteres aktivt i os, men den har endnu ikke nået koden.
Vi ønsker at lave endnu en funktion i WAL-G. Vi vil gerne gøre det udvideligt, fordi vi skal understøtte forskellige databaser og gerne vil kunne gribe backuphåndteringen an på samme måde. Men problemet er, at MySQL API'erne er radikalt forskellige. I MySQL er PITR ikke baseret på den fysiske WAL-log, men på binlog. Og vi har ikke et arkiveringssystem i MySQL, der fortæller et eksternt system, at denne binlog er færdig og skal arkiveres. Vi skal stå et sted i cron med databasen og tjekke om der er noget klar?
Og på samme måde, under en MySQL-gendannelse, er der ingen gendannelseskommando, der kunne fortælle systemet, at jeg har brug for sådanne og sådanne filer. Før du begynder at genopbygge din klynge, skal du vide, hvilke filer du skal bruge. Du skal selv gætte, hvilke filer du skal bruge. Men disse problemer kan muligvis omgås på en eller anden måde. (Afklaring: MySQL er allerede understøttet)
I rapporten ville jeg også tale om de tilfælde, hvor WAL-G ikke er egnet til dig.
Hvis du ikke har en synkron replika, garanterer WAL-G ikke, at det sidste segment bliver bevaret. Og hvis arkivering halter bagefter de sidste par segmenter af historien, er det en risiko. Hvis der ikke er nogen synkron replika, vil jeg ikke anbefale at bruge WAL-G. Alligevel er det hovedsageligt designet til en cloud-installation, hvilket indebærer en High Availability-løsning med en synkron replika, som er ansvarlig for sikkerheden af de sidste bytes, der er begået.
Jeg ser ofte folk forsøger at køre både WAL-G og WAL-E på samme tid. Vi understøtter bagudkompatibilitet i den forstand, at WAL-G kan gendanne en fil fra WAL-E og kan gendanne en sikkerhedskopi lavet i WAL-E. Men da begge disse systemer bruger parallel wal-push, begynder de at stjæle filer fra hinanden. Hvis vi fikser det i WAL-G, forbliver det stadig i WAL-E. I WAL-E ser den på arkivstatus, ser de færdige filer og arkiverer dem, mens andre systemer simpelthen ikke vil vide, at denne WAL-fil eksisterede, fordi PostgreSQL ikke vil forsøge at arkivere den en anden gang.
Hvad skal vi rette her på WAL-G-siden? Vi vil ikke informere PostgreSQL om, at denne fil blev overført parallelt, og når PostgreSQL beder os om at arkivere den, vil vi allerede vide, at en sådan fil med denne mode-time og med denne md5 allerede er blevet arkiveret, og vi vil blot sige PostgreSQL - OK, alt er klar uden egentlig at gøre noget.
Men dette problem vil næppe blive løst på WAL-E-siden, så det er i øjeblikket umuligt at oprette en arkivkommando, der vil arkivere filen i både WAL-G og WAL-E.
Derudover er der tilfælde, hvor WAL-G ikke er egnet til dig nu, men vi vil helt sikkert ordne det.
For det første har vi i øjeblikket ikke indbygget sikkerhedskopiering. Vi har hverken bekræftelse under backup eller gendannelse. Dette er selvfølgelig implementeret i skyen. Men dette implementeres blot ved at forhåndstjekke, blot ved at gendanne klyngen. Jeg vil gerne give denne funktionalitet til brugerne. Men ved verifikation antager jeg, at det i WAL-G vil være muligt at gendanne klyngen og starte den, og køre røgtest: pg_dumpall til /dev/null og amcheck index verification.
I øjeblikket i WAL-G er der ingen måde at udsætte en sikkerhedskopiering fra WAL. Det vil sige, at vi understøtter et eller andet vindue. For eksempel lagring af de sidste syv dage, lagring af de sidste ti sikkerhedskopier, lagring af de sidste tre fulde sikkerhedskopier. Ganske ofte kommer folk og siger: "Vi har brug for en backup af, hvad der skete på nytår, og vi vil beholde det for altid." WAL-G kan ikke gøre dette endnu. (Bemærk - Dette er allerede blevet rettet. Læs mere - Backup-mærke mulighed i )
Og vi har ikke sidekontrolsummer og integritetstjek for alle akselsegmenter ved validering af PITR.
Ud fra alt dette sammensatte jeg et projekt til Google Summer of Code. Hvis du kender smarte studerende, der gerne vil skrive noget i Go og få flere tusinde dollars fra én virksomhed med bogstavet "G", så anbefal vores projekt til dem. Jeg vil fungere som mentor for dette projekt, de kan gøre det. Hvis der ikke er elever, så tager jeg det og gør det selv om sommeren.
Og vi har mange andre små problemer, som vi efterhånden arbejder på. Og der sker nogle ret mærkelige ting.
Hvis du for eksempel giver WAL-G en tom backup, falder den simpelthen. For eksempel, hvis du fortæller ham, at han skal tage backup af en tom mappe. pg_control filen vil ikke være der. Og han vil tro, at han ikke forstår noget. I teorien skal du i dette tilfælde skrive en normal besked til brugeren for at forklare ham, hvordan du bruger værktøjet. Men dette er ikke engang en funktion ved programmering, men en funktion af et godt, forståeligt sprog.
Vi ved ikke, hvordan man laver offline backup. Hvis databasen lyver, kan vi ikke tage backup af den. Men alt er meget enkelt her. Vi kalder backups af LSN, da det startede. LSN for den underliggende base skal læses fra kontrolfilen. Og dette er sådan en urealiseret funktion. Mange backup-systemer kan tage backup af en underliggende database. Og det er praktisk.
Vi kan i øjeblikket ikke håndtere manglen på backup-plads ordentligt. For vi arbejder som regel med store backups derhjemme. Og de kom ikke uden om det. Men hvis nogen ønsker at programmere i Go lige nu, skal du tilføje håndtering af fejl på pladsen til bøtten. Jeg vil helt sikkert undersøge pull-anmodningen.
Og det vigtigste, der bekymrer os, er, at vi ønsker så mange docker-integrationstest som muligt, der kontrollerer forskellige scenarier. Lige nu tester vi kun grundlæggende scenarier. På hver commit, men vi ønsker at kontrollere commit-by-commit al den funktionalitet, vi understøtter. Især vil vi for eksempel have nok support til PostgreSQL 9.4-9.5. Vi støtter dem, fordi fællesskabet understøtter PostgreSQL, men vi tjekker ikke commit-by-commit for at sikre, at alt ikke er i stykker. Og det forekommer mig, at dette er en ret alvorlig risiko.
Vi har WAL-G kørende på mere end tusinde klynger i Yandex Database Management. Og den sikkerhedskopierer flere hundrede terabyte data hver dag.
Vi har en masse TODO i vores kode. Hvis du vil programmere, så kom, vi venter på pull requests, vi venter på spørgsmål.
R'RѕRїSЂRѕSЃS <
God aften! Tak skal du have! Mit gæt er, at hvis du bruger WAL-delta, er du sandsynligvis meget afhængig af helsidesskrivninger. Og hvis ja, kørte du tests? Du viste en smuk graf. Hvor meget smukkere bliver det, hvis FPW er slukket?
Helsideskrivning er aktiveret for os, vi har ikke forsøgt at deaktivere det. Det vil sige, at jeg som udvikler ikke har forsøgt at slå det fra. Systemadministratorer, der har undersøgt, har sandsynligvis undersøgt dette problem. Men vi har brug for FPW. Næsten ingen deaktiverer det, for ellers er det umuligt at tage en backup fra en replika.
Tak for rapporten! Jeg har to spørgsmål. Det første spørgsmål er, hvad der vil ske med tablespaces?
Vi venter på en pull-anmodning. Vores databaser lever på SSD- og NMVE-diske, og vi har ikke rigtig brug for denne funktion. Jeg er ikke klar til at bruge seriøs tid lige nu på at gøre det godt. Jeg går helhjertet ind for, at vi støtter dette. Der er mennesker, der støttede det, men støttede det på en måde, der passer dem. De lavede en gaffel, men de fremsætter ikke pull-anmodninger. (Tilføjet i version 0.2.13)
Og det andet spørgsmål. Du sagde i begyndelsen, at WAL-G antager, at den fungerer alene, og at der ikke er behov for indpakninger. Jeg bruger selv indpakninger. Hvorfor skulle de ikke bruges?
Vi ønsker, at det skal være så enkelt som en balalajka. Det betyder, at du ikke behøver noget som helst undtagen en balalaika. Vi ønsker, at systemet skal være enkelt. Hvis du har funktionalitet, som du skal lave i et script, så kom og fortæl os - vi gør det i Go.
God aften! Tak for rapporten! Vi var ikke i stand til at få WAL-G til at fungere med GPG-dekryptering. Den krypterer normalt, men ønsker ikke at dekryptere. Er det noget, der ikke fungerede for os? Situationen er deprimerende.
Opret et problem på GitHub, og lad os finde ud af det.
Det vil sige, du er ikke stødt på dette?
Der er en funktion af fejlrapporten, at når WAL-G ikke forstår, hvilken slags fil det er, spørger den: "Måske er den krypteret?" Måske er problemet slet ikke kryptering. Jeg ønsker at forbedre logningen om dette emne. Han skal tyde det. Vi arbejder i øjeblikket på dette emne i den forstand, at vi ikke rigtig kan lide, hvordan systemet til at få offentlige og private nøgler er organiseret. Fordi vi kalder ekstern GPG, så den giver os sine nøgler. Og så tager vi disse nøgler og overfører dem til den interne GPG, som er åben PGP, som er kompileret til os inde i WAL-G, og der kalder vi kryptering. I den forbindelse ønsker vi at forbedre systemet og ønsker at understøtte Libsodium-kryptering (Tilføjet i version 0.2.15). Selvfølgelig skal afkodning fungere, lad os finde ud af det - du har brug for mere et symptom end et par ord. I kan samles i højttalerens værelse engang og se på systemet. (PGP-kryptering uden ekstern GPG - v0.2.9)
Hej! Tak for rapporten! Jeg har to spørgsmål. Jeg har et mærkeligt ønske om at lave pg_basebackup og WAL log i to udbydere, dvs. jeg vil lave en sky og en anden. Er der en måde at gøre dette på?
Det findes ikke nu, men det er en interessant idé.
Jeg stoler bare ikke på én udbyder, jeg vil gerne have den samme hos en anden, for en sikkerheds skyld.
Ideen er interessant. Teknisk set er dette slet ikke svært at implementere. For at forhindre, at ideen forsvinder, kan jeg bede dig om at lave et problem på GitHub?
Ja sikkert.
Og så, når eleverne kommer til Google Summer of Code, vil vi tilføje dem til projektet, så der er mere arbejde for at få mere ud af dem.
Og det andet spørgsmål. Der er et problem på GitHub. Jeg tror, det allerede er lukket. Der er panik under gendannelse. Og for at besejre det lavede du en separat forsamling. Det er rigtigt i spørgsmål. Og der er en mulighed for at lave et variabelt miljø i én tråd. Og derfor virker det meget langsomt. Og vi stødte på dette problem, og det er ikke blevet rettet endnu.
Problemet er, at lageret (CEPH) af en eller anden grund nulstiller forbindelsen, når vi kommer til det med høj samtidighed. Hvad kan man gøre ved dette? Genforsøgslogikken ser sådan ud. Vi forsøger at downloade filen igen. I en omgang havde vi et antal filer, der ikke blev downloadet, vi vil lave en anden til alle dem, der ikke loggede ind. Og så længe der er indlæst mindst én fil pr. iteration, gentager vi og gentager og gentager. Vi forbedrede logikken i genforsøg - eksponentiel backoff. Men det er ikke helt klart, hvad man skal gøre med, at forbindelsen simpelthen går i stykker på lagersystemsiden. Det vil sige, at når vi uploader til én stream, bryder det ikke disse forbindelser. Hvad kan vi forbedre her? Vi har netværksregulering, vi kan begrænse hver forbindelse med antallet af bytes, den sender. Ellers ved jeg ikke, hvordan jeg skal håndtere det faktum, at objektlagring ikke tillader os at downloade eller downloade fra det parallelt.
Ingen SLA? Er det ikke skrevet til dem, hvordan de lader sig pine?
Pointen er, at folk, der kommer med dette spørgsmål, normalt har deres egen hvælving. Det vil sige, at ingen kommer fra Amazon eller Google Cloud eller Yandex Object Storage.
Måske er spørgsmålet ikke længere til dig?
Spørgsmålet her i denne sag er ligegyldigt for hvem. Hvis der er nogen ideer til, hvordan man håndterer dette, så lad os gøre det i WAL-G. Men indtil videre har jeg ingen gode ideer til, hvordan jeg skal håndtere dette. Der er nogle Object Storage, der understøtter opstilling af sikkerhedskopier anderledes. Du beder dem om at liste objekter, og de tilføjer mappe der. WAL-G bliver bange for dette - der er en slags ting her, som ikke er en fil, jeg kan ikke gendanne den, hvilket betyder, at sikkerhedskopien ikke blev gendannet. Det vil sige, at du faktisk har en fuldstændig gendannet klynge, men det giver dig en fejlagtig status, fordi Object Storage returnerede nogle mærkelige oplysninger, som den ikke helt forstod.
Dette er noget, der sker i Mail-skyen.
Hvis du kan bygge en reproduktion...
Det er konsekvent gengivet...
Hvis der er en gengivelse, så tror jeg, vi vil eksperimentere med genforsøgsstrategier og finde ud af, hvordan vi prøver igen og forstå, hvad skyen kræver af os. Måske vil det være stabilt for os på tre forbindelser og vil ikke bryde forbindelsen, så når vi forsigtigt tre. For nu slipper vi forbindelsen meget hurtigt, dvs. hvis vi lancerede en gendannelse med 16 tråde, så vil der efter det første genforsøg være 8 tråde, 4 tråde, 2 tråde og en. Og så trækker den filen i én strøm. Hvis der er nogle magiske værdier som 7,5 tråde er de bedste til at pumpe, så vil vi dvæle ved dem og prøve at lave yderligere 7,5 tråde. Her er en idé.
Tak for rapporten! Hvordan ser en komplet arbejdsgang til at arbejde med WAL-G ud? For eksempel i det dumme tilfælde, når der ikke er delta på tværs af sider. Og vi tager og fjerner den indledende backup, og arkiverer derefter skaftet, indtil vi er blå i ansigtet. Her er der, som jeg forstår det, et sammenbrud. På et tidspunkt skal du lave en delta backup af sider, dvs. en ekstern proces driver dette eller hvordan sker det?
Delta backup API er ret simpelt. Der er et tal der - max delta-trin, det hedder det. Den er som standard nul. Det betyder, at hver gang du laver en backup-push, downloader den en fuld backup. Hvis du ændrer det til et hvilket som helst positivt tal, for eksempel 3, så ser den på historikken for tidligere sikkerhedskopier, næste gang du laver en backup-push. Han ser, at du ikke overskrider kæden af 3 deltaer og laver et delta.
Det vil sige, hver gang vi starter WAL-G, forsøger den at lave en fuld backup?
Nej, vi kører WAL-G, og det forsøger at lave et delta, hvis dine politikker tillader det.
Groft sagt, hvis du kører det med nul hver gang, vil det opføre sig som pg_basebackup?
Nej, det vil stadig køre hurtigere, fordi det bruger kompression og parallelitet. Pg_basebackup vil lægge skaftet ved siden af dig. WAL-G antager, at du har konfigureret arkivering. Og den vil udsende en advarsel, hvis den ikke er konfigureret.
Pg_basebackup kan køres uden aksler.
Ja, så vil de opføre sig næsten ens. Pg_basebackup kopierer til filsystemet. Vi har i øvrigt en ny funktion, som jeg glemte at nævne. Vi kan nu sikkerhedskopiere til filsystemet fra pg_basebackup. Jeg ved ikke, hvorfor det er nødvendigt, men det er der.
For eksempel på CephFS. Ikke alle ønsker at konfigurere Object Storage.
Ja, det er nok derfor, de stillede et spørgsmål om denne funktion, så vi kunne gøre det. Og vi gjorde det.
Tak for rapporten! Der er bare et spørgsmål om kopiering til filsystemet. Ud af æsken, understøtter du nu kopiering til fjernlager, for eksempel hvis der er en eller anden hylde i datacentret eller andet?
I denne formulering er dette et svært spørgsmål. Ja, vi understøtter, men denne funktionalitet er ikke inkluderet i nogen udgivelse endnu. Det vil sige, at alle pre-releases understøtter dette, men det gør udgivelsesversionerne ikke. Denne funktionalitet blev tilføjet i version 0.2. Det vil helt sikkert blive frigivet snart, så snart vi har rettet alle de kendte fejl. Men lige nu kan dette kun gøres i pre-release. Der er to fejl i pre-releasen. Problem med WAL-E-gendannelse, vi har ikke rettet det. Og i den seneste pre-release blev der tilføjet en fejl om delta-backup. Derfor anbefaler vi alle at bruge udgivelsesversionerne. Så snart der ikke er flere fejl i pre-releasen, kan vi sige, at vi understøtter Google Cloud, S3-kompatible ting og fillagring.
Hej, tak for rapporten. Som jeg forstår det, er WAL-G ikke en form for centraliseret system som barmen? Planlægger du at bevæge dig i denne retning?
Problemet er, at vi har bevæget os væk fra denne retning. WAL-G lever på basisværten, på klyngeværten og på alle værter i klyngen. Da vi flyttede til flere tusinde klynger, havde vi mange bartenderinstallationer. Og hver gang noget falder fra hinanden i dem, er det et stort problem. Fordi de skal repareres, skal du forstå, hvilke klynger der nu ikke har sikkerhedskopier. Jeg har ikke planer om at udvikle WAL-G i retning af fysisk hardware til backup-systemer. Hvis fællesskabet vil have noget funktionalitet her, gider jeg slet ikke.
Vi har teams, der er ansvarlige for opbevaring. Og vi har det så godt, at det ikke er os, at der er særlige mennesker, der lægger vores filer, hvor filerne er sikre. De laver alle mulige smarte kodninger der for at modstå tabet af et vist antal filer. De er ansvarlige for netværkets båndbredde. Når du har en bartender, kan du pludselig finde ud af, at der er samlet små databaser med meget trafik på den samme server. Du ser ud til at have meget plads på den, men af en eller anden grund passer alt ikke gennem netværket. Det kan vise sig omvendt. Der er mange netværk der, der er processorkerner, men der er ingen diske her. Og vi blev trætte af dette behov for at jonglere med noget, og vi gik over til, at datalagring er en separat tjeneste, som særskilte personer er ansvarlige for.
PS En ny version er blevet frigivet , hvor du kan bruge .walg.json-konfigurationsfilen, som er placeret i postgres-hjemmemappen som standard. Du kan opgive bash-scripts. Eksempel .walg.json er i dette nummer
Video:
Kilde: www.habr.com