Jeg foreslår at du leser utskriften av rapporten fra begynnelsen av 2019 av Andrey Borodin "Sikkerhetskopier med WAL-G. Hva er der i 2019?"
Hei alle sammen! Mitt navn er Andrey Borodin. Jeg er utvikler hos Yandex. Jeg har vært interessert i PostgreSQL siden 2016, etter at jeg snakket med utviklerne og de sa at alt er enkelt – du tar kildekoden og bygger den, og alt ordner seg. Og siden da kan jeg ikke stoppe - jeg skriver alle slags forskjellige ting.
En av tingene jeg jobber med er et backup-system. . Generelt har vi hos Yandex jobbet med sikkerhetskopieringssystemer i PostgreSQL i veldig lang tid. Og du kan finne på Internett en serie på seks rapporter om hvordan vi lager backup-systemer. Og hvert år utvikler de seg litt, utvikler seg litt og blir mer pålitelige.
Men i dag handler rapporten ikke bare om hva vi har gjort, men også om hvor enkelt det er og hva som er. Hvor mange av dere har allerede sett rapportene mine om WAL-G? Det er bra at ganske mange ikke så på, for jeg starter med det enkleste.
Hvis du plutselig har en PostgreSQL-klynge, og jeg tror alle har et par av dem med seg, og det plutselig ikke er noe backup-system ennå, så må du få en hvilken som helst S3-lagring eller Google Cloud-kompatibel lagring.
Du kan for eksempel komme til standen vår og ta en kampanjekode for Yandex Object Storage, som er S3-kompatibel.
Lag deretter en bøtte. Det er bare en beholder for informasjon.
Opprett en tjenestebruker.
Opprett en tilgangsnøkkel for tjenestebrukeren: aws-s3-key.
Last ned den siste stabile utgaven av WAL-G.
Hvordan er våre forhåndsutgivelser forskjellige fra utgivelser? Jeg blir ofte bedt om å slippe tidlig. Og hvis det ikke er noen feil i versjonen i tilstrekkelig tid, for eksempel en måned, slipper jeg den. Her er denne utgivelsen fra november. Og dette betyr at vi hver måned fant en slags feil, vanligvis i ikke-kritisk funksjonalitet, men vi har ennå ikke gitt ut en utgivelse. Den forrige versjonen er bare november. Det er ingen feil kjent for oss i den, det vil si at bugs ble lagt til etter hvert som prosjektet skred frem.
Når du har lastet ned WAL-G, kan du kjøre en enkel "backup list"-kommando ved å sende inn miljøvariablene. Og den vil koble til Object Storage og fortelle deg hvilke sikkerhetskopier du har. Først bør du selvfølgelig ikke ha sikkerhetskopier. Poenget med dette lysbildet er å vise at alt er ganske enkelt. Dette er en konsollkommando som godtar miljøvariabler og utfører underkommandoer.
Etter dette kan du ta din første sikkerhetskopi. Si "backup-push" i WAL-G og spesifiser i WAL-G pgdata-plasseringen til klyngen din. Og mest sannsynlig vil PostgreSQL fortelle deg, hvis du ikke allerede har et sikkerhetskopisystem, at du må aktivere "arkivmodus".
Dette betyr at du må gå til innstillinger og slå på "archive_mode = on" og legge til "archive_command", som også er en underkommando i WAL-G. Men av en eller annen grunn bruker folk ofte bar scripts om dette emnet og vikler det rundt WAL-G. Vennligst ikke gjør dette. Bruk funksjonaliteten som finnes i WAL-G. Hvis du mangler noe, skriv til . WAL-G antar at det er det eneste programmet som kjører i archive_command.
Vi bruker WAL-G hovedsakelig for å lage en High Availability-klynge i Yandex Database Management.
Og det brukes vanligvis i en topologi av en Master og flere replikasjoner. Samtidig lager den en sikkerhetskopi i Yandex Object Storage.
De vanligste scenariene er å lage kopier av en klynge ved å bruke Point in time recovery. Men i dette tilfellet er ikke ytelsen til backupsystemet så viktig for oss. Vi trenger bare å laste opp en ny klynge fra sikkerhetskopien.
Vanligvis trenger vi backupsystemytelse når vi legger til en ny node. Hvorfor er det viktig? Vanligvis legger folk til en ny node til en klynge fordi den eksisterende klyngen ikke kan håndtere lesebelastningen. De må legge til en ny kopi. Hvis vi legger til lasten fra pg_basebackup til masteren, kan masteren kollapse. Derfor var det veldig viktig for oss at vi raskt kunne laste opp en ny node fra arkivet, og skape minimal belastning på Master.
Og en annen lignende situasjon. Dette er behovet for å starte den gamle masteren på nytt etter å ha byttet klyngemasteren fra datasenteret som tilkoblingen gikk tapt med.
- Som et resultat, da vi formulerte kravene til kopisystemet, innså vi at pg_basebackup ikke er egnet for oss når vi opererer i skyen.
- Vi ønsket å kunne komprimere dataene våre. Men nesten alle andre backup-systemer enn det som følger med i esken vil gi datakomprimering.
- Vi ønsket å parallellisere alt fordi en bruker i skyen kjøper et stort antall prosessorkjerner. Men hvis vi ikke har parallellitet i en eller annen operasjon, blir et stort antall kjerner ubrukelig.
- Vi trenger kryptering fordi dataene ofte ikke er våre og kan ikke lagres i klartekst. Forresten, vårt bidrag til WAL-G begynte med kryptering. Vi fullførte krypteringen i WAL-G, hvoretter vi ble spurt: "Kanskje en av oss vil utvikle prosjektet?" Og siden den gang har jeg jobbet med WAL-G i mer enn ett år.
- Vi trengte også struping av ressurser, for over tid ved bruk av skyen fant vi ut at noen ganger har folk en viktig dagligvarebelastning om natten, og denne belastningen kan ikke forstyrres. Derfor la vi til ressursregulering.
- Samt notering og ledelse.
- Og verifisering.
Vi så på mange forskjellige verktøy. Heldigvis har vi et enormt utvalg i PostgreSQL. Og overalt manglet vi noe, en liten funksjon, en liten funksjon.
Og etter å ha undersøkt de eksisterende systemene, kom vi til den konklusjon at vi vil utvikle WAL-G. Det var et nytt prosjekt da. Det var ganske enkelt å påvirke utviklingen mot skyinfrastrukturen til backupsystemet.
Hovedideologien vi holder oss til er at WAL-G skal være like enkel som en balalaika.
WAL-G har 4 kommandoer. Dette:
WAL-PUSH – arkiver skaftet.
WAL-FETCH – få et skaft.
BACKUP-PUSH – ta en sikkerhetskopi.
BACKUP-FETCH – få en sikkerhetskopi fra backup-systemet.
Faktisk har WAL-G også administrasjon av disse sikkerhetskopiene, det vil si å liste og slette filer og sikkerhetskopier i historikken som ikke lenger er nødvendig for øyeblikket.
En av de viktige funksjonene for oss er funksjonen med å lage deltakopier.
Deltakopier gjør at vi ikke lager en fullstendig sikkerhetskopi av hele klyngen, men kun de endrede sidene til de endrede filene i klyngen. Det ser ut til at dette funksjonelt sett er veldig likt muligheten til å gjenopprette ved hjelp av WAL. Men vi kan rulle opp en WAL enkelt-trådet delta backup parallelt. Følgelig, når vi har en grunnleggende sikkerhetskopi på lørdag, delta backup daglig, og på torsdag vi mislykkes, må vi rulle opp 4 delta backup og 10 timer WAL. Det vil ta omtrent samme tid fordi delta-backupene ruller parallelt.
LSN-baserte deltaer - dette betyr at når vi oppretter en sikkerhetskopi, må vi kombinere hver side og sjekke dens LSN med LSN for forrige sikkerhetskopi for å forstå at den har endret seg. Enhver side som potensielt kan inneholde endrede data bør være til stede i delta-sikkerhetskopien.
Som sagt ble det lagt ganske stor vekt på parallellitet.
Men arkiv-APIet i PostgreSQL er konsekvent. PostgreSQL arkiverer én WAL-fil og ber om én WAL-fil når den gjenopprettes. Men når databasen ber om én WAL-fil ved å bruke kommandoen "WAL-FETCH", kaller vi kommandoen "WAL-PREFETCH", som forbereder de neste 8 filene til å hente data fra objektlageret parallelt.
Og når databasen ber oss om å arkivere én fil, ser vi på archive_status og ser om det finnes andre WAL-filer. Og vi prøver også å laste ned WAL parallelt. Dette gir en betydelig ytelsesforsterkning og reduserer avstanden betydelig i antall uarkiverte WAL-er. Mange utviklere av sikkerhetskopieringssystem mener at dette er et så risikabelt system fordi vi stoler på vår kunnskap om innsiden av koden som ikke er PostgreSQL API. PostgreSQL garanterer ikke tilstedeværelsen av mappen archive_status for oss og garanterer ikke semantikken, tilstedeværelsen av beredskapssignaler for WAL-filer der. Likevel studerer vi kildekoden, vi ser at det er slik og vi prøver å utnytte den. Og vi kontrollerer retningen PostgreSQL utvikler seg i; hvis denne mekanismen plutselig brytes, vil vi slutte å bruke den.
I sin rene form krever LSN-basert WAL delta lesing av alle klyngefiler hvis modustid i filsystemet har endret seg siden forrige sikkerhetskopiering. Vi levde med dette lenge, nesten ett år. Og til slutt kom vi til den konklusjonen at vi har WAL-deltaer.
Dette betyr at hver gang vi arkiverer WAL på Master, komprimerer vi den ikke bare, krypterer den og sender den til nettverket, men vi leser den samtidig. Vi analyserer og leser postene i den. Vi forstår hvilke blokker som har endret seg og samler deltafiler.
En deltafil beskriver et visst utvalg av WAL-filer, beskriver informasjon om hvilke blokker som ble endret i dette området av WAL. Og så blir også disse deltafilene arkivert.
Her står vi overfor det faktum at vi parallelliserte alt ganske raskt, men vi kan ikke lese en sekvensiell historie parallelt, fordi vi i et bestemt segment kan møte slutten på den forrige WAL-rekorden, som vi ikke har noe å koble til ennå, fordi parallelllesing førte til at vi først analyserer fremtiden, som ennå ikke har en fortid.
Som et resultat måtte vi legge inn uforståelige deler i _delta_partial-filer. Som et resultat, når vi går tilbake til fortiden, vil vi lime bitene av WAL-posten til en, etter det vil vi analysere den og forstå hva som endret seg i den.
Hvis det i historien til akselparsingen vår er minst ett punkt hvor vi ikke forstår hva som skjedde, vil vi følgelig under neste sikkerhetskopiering bli tvunget til å lese hele klyngen på nytt, akkurat som vi gjorde med en vanlig LSN -basert delta.
Som et resultat førte all vår lidelse til det faktum at vi åpnet WAL-G-parsing-biblioteket. Så vidt jeg vet er det ingen som bruker det ennå, men hvis noen vil, skrive og bruke det, er det offentlig eiendom. (Oppdatert lenke )
Som et resultat ser all informasjonsflyt ganske komplisert ut. Vår Mester arkiverer skaftet og arkiverer deltafiler. Og replikaen som lager sikkerhetskopien må motta deltafiler i løpet av tiden som har gått mellom sikkerhetskopieringene. I dette tilfellet må deler av historien legges til i bulk og analyseres, fordi ikke hele historien passer inn i store segmenter. Og først etter dette kan replikaen arkivere en full delta backup.
På grafene ser alt mye enklere ut. Dette er en nedlasting fra en av våre virkelige klynger. Vi har LSN-basert, laget på en dag. Og vi ser at den LSN-baserte delta-backupen kjørte fra tre om morgenen til fem om morgenen. Dette er belastningen i antall prosessorkjerner. WAL-delta tok oss ca 20 minutter her, det vil si at det ble betydelig raskere, men samtidig ble det en mer intens utveksling over nettet.
Siden vi har informasjon om hvilke blokker som ble endret og på hvilket tidspunkt i databasens historie, gikk vi videre og bestemte oss for å integrere funksjonalitet - en PostgreSQL-utvidelse kalt "pg_prefaulter"
Dette betyr at når standby-basen utfører gjenopprettingskommandoen, forteller den WAL-G å hente neste WAL-fil. Vi forstår omtrent hvilke datablokker WAL-gjenopprettingsprosessen vil få tilgang til i nær fremtid og starter en leseoperasjon på disse blokkene. Dette ble gjort for å øke ytelsen til SSD-kontrollere. Fordi WAL-rullen kommer til siden som må endres. Denne siden er på disk og er ikke i sidebufferen. Og han vil vente synkront på at denne siden kommer. Men i nærheten er WAL-G, som vet at i løpet av de neste hundre megabyte med WAL vil vi trenge visse sider og samtidig begynner å varme dem opp. Starter flere disktilganger slik at de kjøres parallelt. Dette fungerer bra på SSD-stasjoner, men dessverre er det absolutt ikke aktuelt for en harddisk, fordi vi bare forstyrrer den med våre meldinger.
Dette er det som står i koden nå.
Det er funksjoner vi ønsker å legge til.
Dette bildet viser at WAL-deltaet tar relativt kort tid. Og dette er å lese endringene som skjedde i databasen i løpet av dagen. Vi kunne gjøre WAL-delta ikke bare om natten, fordi det ikke lenger er en betydelig kilde til belastning. Vi kan lese WAL-delta hvert minutt fordi det er billig. På ett minutt kan vi skanne alle endringene som har skjedd i klyngen. Og dette kan kalles "instant WAL-delta".
Poenget er at når vi gjenoppretter klyngen, reduserer vi antallet historier som vi må rulle opp sekvensielt. Det vil si at mengden WAL som PostgreSQL ruller bør reduseres, fordi det tar betydelig tid.
Men det er ikke alt. Hvis vi vet at en blokk vil bli endret til et punkt for sikkerhetskopiering, kan vi ikke endre det tidligere. Det vil si at nå har vi fil-for-fil-optimalisering av WAL-delta-videresending. Dette betyr at hvis, for eksempel på tirsdag, en tabell ble fullstendig slettet eller noen filer ble slettet helt fra tabellen, vil vi ikke engang opprette disse dataene når delta ruller over på mandag og lørdagens pg_basebackup gjenopprettes.
Vi ønsker å utvide denne teknologien til sidenivå. Det vil si at hvis en del av filen endres på mandag, men vil bli overskrevet på onsdag, så når vi gjenoppretter til et punkt på torsdag, trenger vi ikke å skrive de første versjonene av sidene til disken.
Men dette er fortsatt en idé som diskuteres aktivt i oss, men den har ennå ikke nådd koden.
Vi ønsker å lage en funksjon til i WAL-G. Vi ønsker å gjøre det utvidbart fordi vi trenger å støtte ulike databaser og ønsker å kunne nærme oss sikkerhetskopiering på samme måte. Men problemet er at MySQL API-ene er radikalt forskjellige. I MySQL er PITR ikke basert på den fysiske WAL-loggen, men på binloggen. Og vi har ikke et arkiveringssystem i MySQL som vil fortelle et eksternt system at denne binloggen er ferdig og må arkiveres. Vi må stå et sted i cron med databasen og sjekke om det er noe klart?
Og på samme måte, under en MySQL-gjenoppretting, er det ingen gjenopprettingskommando som kan fortelle systemet at jeg trenger slike og slike filer. Før du begynner å gjenoppbygge klyngen din, må du vite hvilke filer du trenger. Du må selv gjette hvilke filer du trenger. Men disse problemene kan kanskje omgås på en eller annen måte. (Forklaring: MySQL støttes allerede)
I rapporten ønsket jeg også å snakke om de tilfellene der WAL-G ikke passer for deg.
Hvis du ikke har en synkron kopi, garanterer ikke WAL-G at det siste segmentet vil bli bevart. Og hvis arkivering henger etter de siste delene av historien, er det en risiko. Hvis det ikke er noen synkron kopi, vil jeg ikke anbefale å bruke WAL-G. Likevel er den hovedsakelig designet for en skyinstallasjon, noe som innebærer en High Availability-løsning med en synkron replika, som er ansvarlig for sikkerheten til de siste bytene som ble forpliktet.
Jeg ser ofte folk som prøver å kjøre både WAL-G og WAL-E samtidig. Vi støtter bakoverkompatibilitet i den forstand at WAL-G kan gjenopprette en fil fra WAL-E og kan gjenopprette en sikkerhetskopi laget i WAL-E. Men siden begge disse systemene bruker parallell wal-push, begynner de å stjele filer fra hverandre. Hvis vi fikser det i WAL-G, vil det fortsatt forbli i WAL-E. I WAL-E ser den på arkivstatus, ser de ferdige filene og arkiverer dem, mens andre systemer rett og slett ikke vil vite at denne WAL-filen eksisterte, fordi PostgreSQL ikke vil prøve å arkivere den en gang til.
Hva skal vi fikse her på WAL-G-siden? Vi vil ikke informere PostgreSQL om at denne filen ble overført parallelt, og når PostgreSQL ber oss om å arkivere den, vil vi allerede vite at en slik fil med denne modus-tiden og med denne md5 allerede er arkivert, og vi vil ganske enkelt si PostgreSQL - OK, alt er klart uten å gjøre noe.
Men dette problemet blir neppe løst på WAL-E-siden, så det er for øyeblikket umulig å lage en arkivkommando som vil arkivere filen i både WAL-G og WAL-E.
I tillegg er det tilfeller der WAL-G ikke passer for deg nå, men vi vil definitivt fikse det.
For det første har vi for øyeblikket ikke innebygd sikkerhetskopiering. Vi har ikke verifisering verken under sikkerhetskopiering eller gjenoppretting. Dette er selvfølgelig implementert i skyen. Men dette implementeres ganske enkelt ved å forhåndssjekke, ganske enkelt ved å gjenopprette klyngen. Jeg vil gjerne gi denne funksjonaliteten til brukerne. Men ved verifisering antar jeg at det i WAL-G vil være mulig å gjenopprette klyngen og starte den, og kjøre røyktester: pg_dumpall til /dev/null og amcheck indeksverifisering.
For øyeblikket i WAL-G er det ingen måte å utsette en sikkerhetskopi fra WAL. Det vil si at vi støtter et eller annet vindu. For eksempel lagring av de siste syv dagene, lagring av de siste ti sikkerhetskopiene, lagring av de siste tre fullstendige sikkerhetskopiene. Ganske ofte kommer folk og sier: "Vi trenger en sikkerhetskopi av det som skjedde på nyttår, og vi vil beholde det for alltid." WAL-G vet ennå ikke hvordan dette skal gjøres. (Merk - Dette er allerede fikset. Les mer - Backup-merke alternativ i )
Og vi har ikke sidesjekksummer og integritetssjekker for alle akselsegmenter når vi validerer PITR.
Fra alt dette satte jeg sammen et prosjekt for Google Summer of Code. Hvis du kjenner smarte studenter som ønsker å skrive noe i Go og få flere tusen dollar fra ett selskap med bokstaven "G", så anbefal prosjektet vårt til dem. Jeg skal fungere som mentor for dette prosjektet, de kan gjøre det. Hvis det ikke er elever, så tar jeg det og gjør det selv til sommeren.
Og vi har mange andre småproblemer som vi etter hvert jobber med. Og noen ganske merkelige ting skjer.
Hvis du for eksempel gir WAL-G en tom sikkerhetskopi, vil den rett og slett falle. For eksempel hvis du forteller ham at han trenger å sikkerhetskopiere en tom mappe. Pg_control-filen vil ikke være der. Og han vil tro at han ikke forstår noe. I teorien må du i dette tilfellet skrive en vanlig melding til brukeren for å forklare ham hvordan du bruker verktøyet. Men dette er ikke engang en funksjon ved programmering, men en funksjon av et godt, forståelig språk.
Vi vet ikke hvordan vi gjør offline backup. Hvis databasen lyver, kan vi ikke sikkerhetskopiere den. Men alt er veldig enkelt her. Vi kaller backup av LSN når det startet. LSN for den underliggende basen må leses fra kontrollfilen. Og dette er en så urealisert funksjon. Mange backup-systemer kan ta backup av en underliggende database. Og det er praktisk.
Vi kan for øyeblikket ikke håndtere mangelen på reserveplass på riktig måte. For vi jobber vanligvis med store sikkerhetskopier hjemme. Og de kom ikke til det. Men hvis noen ønsker å programmere i Go akkurat nå, legg til håndtering for feil på plass i bøtten. Jeg skal definitivt se nærmere på pull-forespørselen.
Og det viktigste som bekymrer oss er at vi ønsker så mange docker-integrasjonstester som mulig som sjekker ulike scenarier. Akkurat nå tester vi bare grunnleggende scenarier. På hver commit, men vi ønsker å sjekke commit-by-commit all funksjonaliteten vi støtter. Spesielt vil vi for eksempel ha nok støtte for PostgreSQL 9.4-9.5. Vi støtter dem fordi fellesskapet støtter PostgreSQL, men vi sjekker ikke commit-by-commit for å sikre at alt ikke er ødelagt. Og det virker for meg som om dette er en ganske alvorlig risiko.
Vi har WAL-G som kjører på mer enn tusen klynger i Yandex Database Management. Og den sikkerhetskopierer flere hundre terabyte med data hver dag.
Vi har mye TODO i koden vår. Hvis du vil programmere, kom, vi venter på pull requests, vi venter på spørsmål.
spørsmål
God kveld! Takk skal du ha! Min gjetning er at hvis du bruker WAL-delta, er du sannsynligvis avhengig av helsidesskrivinger. Og i så fall, kjørte du tester? Du viste en vakker graf. Hvor mye vakrere blir det hvis FPW er slått av?
Helsideskriving er aktivert for oss, vi har ikke prøvd å deaktivere det. Det vil si at jeg som utvikler ikke har prøvd å skru den av. Systemadministratorer som har undersøkt har sannsynligvis undersøkt dette problemet. Men vi trenger FPW. Nesten ingen deaktiverer det, for ellers er det umulig å ta en sikkerhetskopi fra en kopi.
Takk for rapporten! Jeg har to spørsmål. Det første spørsmålet er hva som vil skje med tablespaces?
Vi venter på en pull-forespørsel. Databasene våre lever på SSD- og NMVE-disker, og vi trenger egentlig ikke denne funksjonen. Jeg er ikke klar til å bruke seriøs tid akkurat nå på å gjøre det bra. Jeg går helhjertet inn for at vi støtter dette. Det er folk som støttet det, men støttet det på en måte som passer dem. De laget en gaffel, men de gjør ikke pull-forespørsler. (Lagt til i versjon 0.2.13)
Og det andre spørsmålet. Du sa helt i begynnelsen at WAL-G antar at den fungerer alene og at det ikke trengs innpakninger. Jeg bruker selv omslag. Hvorfor skal de ikke brukes?
Vi vil at det skal være så enkelt som en balalaika. Dette betyr at du ikke trenger noe annet enn en balalaika. Vi ønsker at systemet skal være enkelt. Hvis du har funksjonalitet som du trenger å gjøre i et skript, så kom og fortell oss - vi gjør det i Go.
God kveld! Takk for rapporten! Vi klarte ikke å få WAL-G til å fungere med GPG-dekryptering. Den krypterer normalt, men ønsker ikke å dekryptere. Er det noe som ikke fungerte for oss? Situasjonen er deprimerende.
Opprett et problem på GitHub og la oss finne ut av det.
Det vil si at du ikke har vært borti dette?
Det er en funksjon i feilrapporten at når WAL-G ikke forstår hva slags fil det er, spør den: "Kanskje den er kryptert?" Kanskje problemet ikke er kryptering i det hele tatt. Jeg ønsker å forbedre loggingen på dette emnet. Han må tyde det. Vi jobber for tiden med dette emnet i den forstand at vi egentlig ikke liker hvordan systemet for å skaffe offentlige og private nøkler er organisert. Fordi vi kaller ekstern GPG slik at den gir oss nøklene. Og så tar vi disse nøklene og overfører dem til den interne GPG, som er åpen PGP, som er kompilert for oss inne i WAL-G, og der kaller vi kryptering. I denne forbindelse ønsker vi å forbedre systemet og ønsker å støtte Libsodium-kryptering (Lagt til i versjon 0.2.15). Selvfølgelig skal dekoding fungere, la oss finne ut av det - du trenger mer et symptom enn et par ord. Du kan samles på høyttalerens rom en gang og se på systemet. (PGP-kryptering uten ekstern GPG - v0.2.9)
Hallo! Takk for rapporten! Jeg har to spørsmål. Jeg har et merkelig ønske om å logge inn pg_basebackup og WAL på to leverandører, det vil si at jeg vil gjøre en sky og en annen. Er det noen måte å gjøre dette på?
Dette eksisterer ikke nå, men det er en interessant idé.
Jeg stoler bare ikke på én leverandør, jeg vil ha den samme hos en annen, i tilfelle.
Ideen er interessant. Teknisk sett er dette slett ikke vanskelig å gjennomføre. For å forhindre at ideen blir borte, kan jeg be deg om å lage et problem på GitHub?
Ja, selvfølgelig.
Og så, når elevene kommer til Google Summer of Code, vil vi legge dem til i prosjektet slik at det blir mer arbeid for å få mer ut av dem.
Og det andre spørsmålet. Det er et problem på GitHub. Jeg tror den allerede er stengt. Det er panikk under gjenoppretting. Og for å beseire det, laget du en egen forsamling. Det er rett i saker. Og det er et alternativ for å gjøre et variabelt miljø i en tråd. Og det er derfor det går veldig sakte. Og vi støtt på dette problemet, og det er ikke løst ennå.
Problemet er at lagringen (CEPH) av en eller annen grunn tilbakestiller forbindelsen når vi kommer til den med høy samtidighet. Hva kan gjøres med dette? Forsøkslogikken på nytt ser slik ut. Vi prøver å laste ned filen på nytt. I ett pass hadde vi en rekke filer som ikke ble lastet ned, vi vil lage en andre for alle de som ikke logget på. Og så lenge minst én fil er lastet per iterasjon, gjentar vi og gjentar og gjentar. Vi forbedret logikken for å prøve på nytt - eksponentiell backoff. Men det er ikke helt klart hva man skal gjøre med det faktum at forbindelsen rett og slett bryter på lagringssystemsiden. Det vil si at når vi laster opp til én strøm, bryter den ikke disse forbindelsene. Hva kan vi forbedre her? Vi har nettverksregulering, vi kan begrense hver tilkobling med antall byte den sender. Ellers vet jeg ikke hvordan jeg skal håndtere det faktum at objektlagring ikke tillater oss å laste ned eller laste ned fra det parallelt.
Ingen SLA? Er det ikke skrevet for dem hvordan de lar seg plage?
Poenget er at folk som kommer med dette spørsmålet vanligvis har sitt eget hvelv. Det vil si at ingen kommer fra Amazon eller Google Cloud eller Yandex Object Storage.
Kanskje spørsmålet ikke lenger er for deg?
Spørsmålet her i denne saken spiller ingen rolle for hvem. Hvis det er noen ideer om hvordan vi skal håndtere dette, la oss gjøre det i WAL-G. Men så langt har jeg ingen gode ideer om hvordan jeg skal håndtere dette. Det er noen objektlagring som støtter oppføring av sikkerhetskopier på en annen måte. Du ber dem om å liste objekter, og de legger til mappe der. WAL-G blir redd av dette - det er en slags ting her som ikke er en fil, jeg kan ikke gjenopprette den, noe som betyr at sikkerhetskopien ikke ble gjenopprettet. Det vil si at du faktisk har en fullstendig gjenopprettet klynge, men den gir deg en feilstatus fordi Object Storage returnerte noe merkelig informasjon som den ikke helt forsto.
Dette er en ting som skjer i Mail-skyen.
Hvis du kan bygge en reproduser...
Det er konsekvent gjengitt...
Hvis det er en gjengivelse, så tror jeg vi vil eksperimentere med strategier for å prøve på nytt og finne ut hvordan vi kan prøve på nytt og forstå hva skyen krever av oss. Kanskje det vil være stabilt for oss på tre forbindelser og vil ikke bryte forbindelsen, da når vi forsiktig tre. For nå avbryter vi forbindelsen veldig raskt, det vil si at hvis vi startet en gjenoppretting med 16 tråder, vil det etter første forsøk på nytt være 8 tråder, 4 tråder, 2 tråder og en. Og så vil den trekke filen inn i én strøm. Hvis det er noen magiske verdier som 7,5 tråder er de beste for pumping, vil vi dvele ved dem og prøve å lage ytterligere 7,5 tråder. Her er en idé.
Takk for rapporten! Hvordan ser en komplett arbeidsflyt for arbeid med WAL-G ut? For eksempel i det dumme tilfellet når det ikke er delta på tvers av sider. Og vi tar og fjerner den første sikkerhetskopien, så arkiverer vi skaftet til vi er blå i ansiktet. Her er det, slik jeg forstår det, et sammenbrudd. På et tidspunkt må du lage en delta backup av sider, det vil si at en ekstern prosess driver dette eller hvordan skjer dette?
Delta backup API er ganske enkelt. Det er et tall der – maks deltatrinn, det heter det. Den er som standard null. Dette betyr at hver gang du gjør en backup-push, laster den ned en fullstendig sikkerhetskopi. Hvis du endrer det til et positivt tall, for eksempel 3, så ser den på historikken til tidligere sikkerhetskopier neste gang du gjør en backup-push. Han ser at du ikke overskrider kjeden av 3 deltaer og lager et delta.
Det vil si at hver gang vi starter WAL-G, prøver den å lage en fullstendig sikkerhetskopi?
Nei, vi kjører WAL-G, og den prøver å lage et delta hvis retningslinjene tillater det.
Grovt sett, hvis du kjører den med null hver gang, vil den oppføre seg som pg_basebackup?
Nei, den vil fortsatt kjøre raskere fordi den bruker kompresjon og parallellitet. Pg_basebackup vil legge skaftet ved siden av deg. WAL-G forutsetter at du har konfigurert arkivering. Og den vil gi en advarsel hvis den ikke er konfigurert.
Pg_basebackup kan kjøres uten aksler.
Ja, da vil de oppføre seg nesten likt. Pg_basebackup kopierer til filsystemet. Vi har forresten en ny funksjon som jeg glemte å nevne. Vi kan nå sikkerhetskopiere til filsystemet fra pg_basebackup. Jeg vet ikke hvorfor dette er nødvendig, men det er der.
For eksempel på CephFS. Ikke alle ønsker å konfigurere objektlagring.
Ja, det er sannsynligvis derfor de stilte et spørsmål om denne funksjonen slik at vi kunne gjøre det. Og vi klarte det.
Takk for rapporten! Det er bare et spørsmål om kopiering til filsystemet. Ut av esken, støtter du nå kopiering til ekstern lagring, for eksempel hvis det er en hylle i datasenteret eller noe annet?
I denne formuleringen er dette et vanskelig spørsmål. Ja, vi støtter, men denne funksjonaliteten er ikke inkludert i noen utgivelser ennå. Det vil si at alle forhåndsutgivelser støtter dette, men det gjør ikke utgivelsesversjonene. Denne funksjonaliteten ble lagt til i versjon 0.2. Det vil definitivt bli utgitt snart, så snart vi fikser alle kjente feil. Men akkurat nå kan dette bare gjøres i pre-release. Det er to feil i forhåndsutgivelsen. Problem med WAL-E-gjenoppretting, vi har ikke fikset det. Og i den siste forhåndsutgivelsen ble det lagt til en feil om delta-backup. Derfor anbefaler vi alle å bruke utgivelsesversjonene. Så snart det ikke er flere feil i forhåndsutgivelsen, kan vi si at vi støtter Google Cloud, S3-kompatible ting og fillagring.
Hei, takk for rapporten. Slik jeg forstår det, er ikke WAL-G et slags sentralisert system som barmen? Har du planer om å bevege deg i denne retningen?
Problemet er at vi har beveget oss bort fra denne retningen. WAL-G lever på baseverten, på klyngeverten og på alle verter i klyngen. Da vi flyttet til flere tusen klynger hadde vi mange bartenderinstallasjoner. Og hver gang noe faller fra hverandre i dem, er det et stort problem. Fordi de må repareres, må du forstå hvilke klynger som nå ikke har sikkerhetskopier. Jeg har ikke tenkt å utvikle WAL-G i retning av fysisk maskinvare for backup-systemer. Hvis fellesskapet vil ha litt funksjonalitet her, har jeg ikke noe imot det i det hele tatt.
Vi har team som har ansvar for oppbevaring. Og vi har det så bra at det ikke er oss, at det er spesielle personer som legger filene våre der filene er trygge. De gjør all slags smart koding der for å motstå tap av et visst antall filer. De er ansvarlige for nettverksbåndbredden. Når du har en bartender, kan du plutselig finne ut at det har samlet seg små databaser med mye trafikk på samme server. Du ser ut til å ha mye plass på den, men av en eller annen grunn passer ikke alt gjennom nettverket. Det kan vise seg omvendt. Det er mange nettverk der, det er prosessorkjerner, men det er ingen disker her. Og vi ble lei av dette behovet for å sjonglere noe, og vi gikk over til at datalagring er en egen tjeneste, som egne spesialpersoner er ansvarlige for.
PS En ny versjon har blitt utgitt , der du kan bruke .walg.json-konfigurasjonsfilen, som ligger i postgres-hjemmekatalogen som standard. Du kan forlate bash-skript. Eksempel .walg.json er i denne utgaven
Video:
Kilde: www.habr.com