Jeg foreslår at du leser utskriften av den tidlige 2020-rapporten av Georgy Rylov "WAL-G: nye muligheter og utvidelse av samfunnet"
Åpen kildekode vedlikeholdere møter mange utfordringer etter hvert som de vokser. Hvordan skrive flere og flere nødvendige funksjoner, fikse flere og flere problemer og klare å se flere og flere pull-forespørsler? Ved å bruke WAL-G (backup-verktøy for PostgreSQL) som et eksempel, skal jeg fortelle deg hvordan vi løste disse problemene ved å lansere et kurs om åpen kildekode-utvikling ved universitetet, hva vi oppnådde og hvor vi skal gå videre.
Hei igjen alle sammen! Jeg er en Yandex-utvikler fra Jekaterinburg. Og i dag skal jeg snakke om WAL-G.
Tittelen på rapporten sa ikke at det var noe om sikkerhetskopiering. Er det noen som vet hva WAL-G er? Eller vet alle det? Rekk opp hånden hvis du ikke vet. Herregud, du kom til rapporten og vet ikke hva den handler om.
La meg fortelle deg hva som vil skje i dag. Det har seg slik at teamet vårt har gjort sikkerhetskopiering en god stund. Og dette er nok en rapport i en serie hvor vi snakker om hvordan vi lagrer data trygt, sikkert, praktisk og effektivt.
I tidligere serier var det mange rapporter fra Andrei Borodin og Vladimir Leskov. Vi var mange. Og vi har snakket om WAL-G i mange år.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Denne rapporten vil være litt forskjellig fra de andre ved at den handlet mer om den tekniske delen, men her vil jeg snakke om hvordan vi møtte problemer knyttet til veksten av fellesskapet. Og hvordan vi kom på en liten idé som hjelper oss å takle dette.
For noen år siden var WAL-G et ganske lite prosjekt som vi fikk fra Citus Data. Og vi bare tok det. Og den ble utviklet av én person.
Og bare WAL-G hadde ikke:
- Sikkerhetskopiering fra en kopi.
- Det var ingen inkrementelle sikkerhetskopier.
- Det var ingen WAL-Delta-sikkerhetskopier.
- Og det manglet fortsatt mye.
I løpet av disse få årene har WAL-G vokst mye.
Og innen 2020 har alt det ovennevnte allerede dukket opp. Og til dette kom det vi nå har:
- Mer enn 1 stjerner på GitHub.
- 150 gafler.
- Omtrent 15 åpne PR-er.
- Og mange flere bidragsytere.
- Og åpne problemer hele tiden. Og dette til tross for at vi bokstavelig talt går dit hver dag og gjør noe med det.
Og vi kom til den konklusjonen at dette prosjektet krever mer av vår oppmerksomhet, selv når vi selv ikke trenger å implementere noe for vår Managed Database-tjeneste i Yandex.
Og et sted høsten 2018 dukket det opp en idé. Vanligvis har teamet flere måter å utvikle noen funksjoner på eller fikse feil hvis du ikke har nok hender. Du kan for eksempel ansette en annen utvikler og betale ham penger. Eller du kan ansette en praktikant for en stund og også betale ham litt lønn. Men det er fortsatt en ganske stor gruppe mennesker, hvorav noen allerede virkelig vet hvordan man skriver kode. Du vet bare ikke alltid hvilken kvalitet koden er.
Vi tenkte på det og bestemte oss for å prøve å tiltrekke oss studenter. Men studenter vil ikke være med på alt hos oss. De vil bare gjøre en del av arbeidet. Og de skal for eksempel skrive tester, fikse feil, implementere funksjoner som ikke påvirker hovedfunksjonaliteten. Hovedfunksjonaliteten er å lage sikkerhetskopier og gjenopprette sikkerhetskopier. Hvis vi gjør en feil ved å lage en sikkerhetskopi, vil vi oppleve tap av data. Og ingen ønsker dette, selvfølgelig. Alle vil at alt skal være veldig trygt. Derfor ønsker vi selvfølgelig ikke å la kode som vi stoler mindre på enn vår egen. Det vil si at enhver ikke-kritisk kode er det vi ønsker å motta fra våre ekstra arbeidere.
Under hvilke betingelser aksepteres student-PR?
- De er pålagt å dekke koden sin med tester. Alt skal foregå i CI.
- Og vi går også gjennom 2 anmeldelser. En av Andrey Borodin og en av meg.
- Og i tillegg, for å sjekke at dette ikke vil ødelegge noe i tjenesten vår, laster jeg opp forsamlingen separat med denne forpliktelsen. Og vi sjekker i ende-til-ende-tester at ingenting feiler.
Spesialkurs om åpen kildekode
Litt om hvorfor dette er nødvendig og hvorfor dette, synes jeg, er en kul idé.
For oss er overskuddet åpenbart:
- Vi får ekstra hender.
- Og vi ser etter kandidater til teamet blant smarte studenter som skriver smartkode.
Hva er fordelen for studentene?
De kan være mindre åpenbare, fordi studentene, som et minimum, ikke mottar penger for koden de skriver, men bare får karakterer for studentpostene sine.
Jeg spurte dem om dette. Og med deres ord:
- Bidragsytererfaring med åpen kildekode.
- Få en linje i CV-en din.
- Bevis deg selv og bestå et intervju i Yandex.
- Bli GSoC-medlem.
- +1 spesialkurs for de som ønsker å skrive kode.
Jeg skal ikke snakke om hvordan kurset var bygget opp. Jeg vil bare si at WAL-G var hovedprosjektet. Vi inkluderte også prosjekter som Odyssey, PostgreSQL og ClickHouse i dette kurset.
Og de ga problemer ikke bare i dette kurset, men ga også ut vitnemål og kurs.
Hva med fordelene for brukerne?
La oss nå gå videre til den delen som interesserer deg mest. Hva hjelper dette deg? Poenget er at elevene fikset mange feil. Og vi laget forespørselsfunksjonene du ba oss om å gjøre.
Og la meg fortelle deg om tingene du lenge har ønsket deg og som har blitt realisert.
Støtte for bordplasser. Tabellplasser i WAL-G har trolig vært forventet siden utgivelsen av WAL-G, fordi WAL-G er etterfølgeren til et annet sikkerhetskopieringsverktøy WAL-E, der databasesikkerhetskopiering med tabellplasser ble støttet.
La meg kort minne deg på hva det er og hvorfor det er nødvendig. Vanligvis opptar alle dine Postgres-data én katalog på filsystemet, kalt basen. Og denne katalogen inneholder allerede alle filene og underkatalogene som kreves av Postgres.
Tabellplasser er kataloger som inneholder Postgres-data, men de er ikke plassert utenfor basiskatalogen. Lysbildet viser at tabellplassene er plassert utenfor basiskatalogen.
Hvordan ser dette ut for Postgres selv? Det er en egen underkatalog pg_tblspc i basiskatalogen. Og den inneholder symbolkoblinger til kataloger som faktisk inneholder Postgres-data utenfor basiskatalogen.
Når du bruker alt dette, kan disse kommandoene se omtrent slik ut for deg. Det vil si at du oppretter en tabell i et spesifisert tabellområde og ser hvor det er nå. Dette er de to siste linjene, de to siste kommandoene kalt. Og der er det tydelig at det er en vei. Men i virkeligheten er ikke dette den virkelige måten. Dette er prefiksbanen fra basiskatalogen til tabellområdet. Og derfra matches den med en symbolkobling som fører til dine virkelige data.
Vi bruker ikke alt dette i teamet vårt, men det ble brukt av mange andre WAL-E-brukere som skrev til oss at de ønsket å flytte til WAL-G, men dette stoppet dem. Dette er nå støttet.
En annen funksjon som spesialkurset vårt ga oss er catchup. Folk som sannsynligvis har jobbet mer med Oracle enn med Postgres vet om catchup.
Kort om hva det er. Klyngetopologien i tjenesten vår kan vanligvis se omtrent slik ut. Vi har en mester. Det er en replika som streamer en logg for å skrive videre fra den. Og replikaen forteller masteren hvilket LSN den er på for øyeblikket. Og et sted parallelt med dette kan loggen arkiveres. Og i tillegg til å arkivere loggen, sendes det også sikkerhetskopier til skyen. Og delta sikkerhetskopier sendes.
Hva kan være problemet? Når du har en ganske stor database, kan det vise seg at replikaen din begynner å ligge langt etter masteren. Og hun henger så langt etter at hun aldri kan ta igjen ham. Dette problemet må vanligvis løses på en eller annen måte.
Og den enkleste måten er å fjerne kopien og laste den opp på nytt, fordi den aldri vil ta igjen, og problemet må håndteres. Men dette er ganske lang tid, fordi å gjenopprette en hel 10 TB databasesikkerhetskopi er veldig, veldig lang tid. Og vi ønsker å gjøre alt dette så raskt som mulig dersom slike problemer oppstår. Og det er nettopp det catchup er for.
Catchup lar deg bruke delta backup, som lagres i skyen på denne måten. Du sier hvilket LSN den etterslepende replikaen er på for øyeblikket og spesifiserer den i catchup-kommandoen for å lage en delta backup mellom den LSN og LSN som klyngen din befinner seg på. Og etter det gjenoppretter du denne sikkerhetskopien til kopien som ble hengende etter.
Andre baser
Elevene brakte oss også mange funksjoner på en gang. Siden vi hos Yandex lager mat ikke bare Postgres, vi har også MySQL, MongoDB, Redis, ClickHouse, på et tidspunkt trengte vi å kunne ta sikkerhetskopier med punkt-i-tidsgjenoppretting for MySQL, og slik at det var en mulighet til å laste opp dem til skyen.
Og vi ønsket å gjøre det på en lignende måte som WAL-G gjør. Og vi bestemte oss for å eksperimentere og se hvordan det hele ville se ut.
Og til å begynne med, uten å dele denne logikken på noen måte, skrev de koden i gaffelen. De så at vi har en slags fungerende modell og den kan fly. Da tenkte vi at hovedfellesskapet vårt er postgresister, de bruker WAL-G. Og derfor må vi på en eller annen måte skille disse delene. Det vil si at når vi redigerer kode for Postgres, bryter vi ikke MySQL; når vi redigerer MySQL, bryter vi ikke Postgres.
Den første ideen om hvordan å skille dette var ideen om å bruke samme tilnærming som brukes i PostgreSQL-utvidelser. Og faktisk, for å lage en MySQL-sikkerhetskopi, måtte du installere et slags dynamisk bibliotek.
Men her er asymmetrien i denne tilnærmingen umiddelbart synlig. Når du sikkerhetskopierer Postgres, legger du en vanlig sikkerhetskopi for Postgres på den, og alt er i orden. Og for MySQL viser det seg at du installerer en sikkerhetskopi for Postgres og også installerer et dynamisk bibliotek for MySQL for det. Det høres litt rart ut. Det trodde vi også og bestemte oss for at dette ikke var løsningen vi trengte.
Ulike bygg for Postgres, MySQL, MongoDB, Redis
Men dette tillot oss, ser det ut til, å komme til den riktige avgjørelsen - å tildele forskjellige forsamlinger for forskjellige baser. Dette gjorde det mulig å isolere logikken knyttet til sikkerhetskopier av ulike databaser som vil få tilgang til felles API som WAL-G implementerer.
Dette er den delen vi skrev selv – før vi ga elevene oppgavene. Det vil si at dette er akkurat den delen der de kan gjøre noe galt, så vi bestemte oss for at vi burde gjøre noe sånt som dette og alt vil bli bra.
Etter det ga vi ut problemer. De ble umiddelbart demontert. Studentene ble pålagt å støtte tre baser.
Dette er MySQL, som vi har sikkerhetskopiert med WAL-G på denne måten i mer enn ett år.
Og nå nærmer MongoDB seg produksjon, hvor de avslutter den med en fil. Faktisk skrev vi rammeverket for alt dette. Så skrev elevene noen gangbare ting. Og så bringer vi dem til en tilstand som vi kan akseptere i produksjonen.
Disse problemene så ikke ut som elevene trengte å skrive komplette sikkerhetskopieringsverktøy for hver av disse databasene. Vi hadde ikke et slikt problem. Problemet vårt var at vi ønsket punkt-i-tidsgjenoppretting og vi ønsket å sikkerhetskopiere til skyen. Og de ba elevene skrive noe kode som skulle løse dette. Elevene brukte allerede eksisterende sikkerhetskopieringsverktøy, som på en eller annen måte tar sikkerhetskopier, og limte så det hele sammen med WAL-G, som videresendte det hele til skyen. Og de la også til punkt-i-tidsgjenoppretting til dette.
Hva mer hadde elevene med seg? De brakte Libsodium-krypteringsstøtte til WAL-G.
Vi har også retningslinjer for sikkerhetskopiering. Nå kan sikkerhetskopier merkes som permanente. Og på en eller annen måte er det mer praktisk for tjenesten din å automatisere prosessen med å lagre dem.
Hva ble resultatet av dette eksperimentet?
Mer enn 100 personer meldte seg opprinnelig på kurset. Først sa jeg ikke at universitetet i Jekaterinburg er Ural Federal University. Vi annonserte alt der. 100 personer påmeldt. I virkeligheten var det mye færre som begynte å gjøre noe, rundt 30 personer.
Enda færre fullførte kurset, fordi det var nødvendig å skrive prøver for kodene som allerede finnes. Og også fikse en feil eller lage en funksjon. Og noen studenter stengte likevel kurset.
For øyeblikket, i løpet av dette kurset, har studentene fikset rundt 14 problemer og laget 10 funksjoner i forskjellige størrelser. Og, det virker for meg, dette er en fullverdig erstatning av en eller to utviklere.
Vi ga blant annet ut diplomer og kurs. Og 12 fikk diplomer. 6 av dem har allerede forsvart seg på "5". De som ble igjen hadde ennå ikke beskyttelse, men jeg tror at alt vil gå bra for dem også.
Planer for fremtiden
Hvilke planer har vi for fremtiden?
I det minste de funksjonsforespørslene som vi allerede har hørt fra brukere og ønsker å gjøre. Dette:
- Overvåking av riktigheten av tidslinjesporing i HA-klynge-backup-arkivet. Du kan gjøre dette med WAL-G. Og jeg tror vi får studenter som vil ta opp denne saken.
- Vi har allerede en person som er ansvarlig for å overføre sikkerhetskopier og WAL mellom skyer.
- Og vi publiserte nylig en idé om at vi kan øke hastigheten på WAL-G ytterligere ved å pakke ut inkrementelle sikkerhetskopier uten å omskrive sider og optimalisere arkivene vi sender dit.
Du kan dele dem her
Hva var denne rapporten for? Dessuten har vi nå, i tillegg til de 4 personene som støtter dette prosjektet, flere hender, som det er ganske mange av. Spesielt hvis du skriver til dem i en personlig melding. Og hvis du sikkerhetskopierer dataene dine og gjør det med WAL-G eller ønsker å flytte til WAL-G, så kan vi ganske enkelt imøtekomme dine ønsker.
Dette er en QR-kode og en lenke. Du kan gå gjennom dem og skrive alle dine ønsker. For eksempel, vi fikser ikke noen feil. Eller du virkelig vil ha en funksjon, men av en eller annen grunn er den ennå ikke i noen sikkerhetskopi, inkludert vår. Husk å skrive om dette.
spørsmål
Hallo! Takk for rapporten! Spørsmål om WAL-G, men ikke om Postgres. WAL-G sikkerhetskopierer MySQL og kaller en ekstra backup. Hvis vi tar moderne installasjoner på CentOS og hvis du installerer MySQL, vil MariDB bli installert. Fra versjon 10.3 støttes ikke ekstra backup, MariDB backup støttes. Hvordan har du det med dette?
For øyeblikket har vi ikke prøvd å ta backup av MariDB. Vi har hatt forespørsler om FoundationDB-støtte, men generelt, hvis det er en slik forespørsel, så kan vi finne folk som vil gjøre det. Det er ikke så langt eller så vanskelig som jeg tror.
God ettermiddag Takk for rapporten! Spørsmål om potensielle nye funksjoner. Er du klar til å få WAL-G til å fungere med bånd slik at du kan sikkerhetskopiere til bånd?
Sikkerhetskopiering på båndlagring betyr tilsynelatende?
Ja.
Det er Andrei Borodin, som kan svare på dette spørsmålet bedre enn meg.
(Andrey) Ja, takk for spørsmålet! Vi hadde en forespørsel om å overføre en sikkerhetskopi til tape fra skylagring. Og for dette overføring mellom skyer. Fordi sky-til-sky-overføring er en generalisert versjon av båndoverføring. I tillegg har vi en utvidbar arkitektur når det gjelder lagring. Mange Storoges ble forresten skrevet av studenter. Og hvis du skriver Storage for tape, så vil det selvfølgelig støttes. Vi er klare til å vurdere pull-forespørsler. Der må du skrive en fil, lese en fil. Hvis du gjør disse tingene i Go, ender du vanligvis opp med 50 linjer med kode. Og da vil tape støttes i WAL-G.
Takk for rapporten! Interessant utviklingsprosess. Sikkerhetskopiering er en seriøs funksjonalitet som bør dekkes godt av tester. Når du implementerte funksjonalitet for nye databaser, skrev elevene også prøvene, eller skrev du prøvene selv og ga deretter implementeringen til elevene?
Elevene skrev også prøver. Men studentene skrev mer for funksjoner som nye databaser. De skrev integreringsprøver. Og de skrev enhetstester. Hvis integrasjonen passerer, det vil si for øyeblikket, er dette et script du kjører manuelt eller du har for eksempel cron som gjør det. Det vil si at manuset der er veldig tydelig.
Elevene har ikke mye erfaring. Tar gjennomgang mye tid?
Ja, anmeldelser tar ganske mye tid. Det vil si at som regel når flere formidlere kommer på en gang og sier at jeg gjorde dette, så gjorde jeg det, da må du tenke og sette av en halv dag til å finne ut hva de skrev der. Fordi koden må leses nøye. De hadde ikke intervju. Vi kjenner dem ikke så godt, så det tar mye tid.
Takk for rapporten! Tidligere har Andrey Borodin uttalt at archive_command i WAL-G skulle kalles direkte. Men i tilfelle av en slags klyngepatron, trenger vi ytterligere logikk for å bestemme noden som skal sendes akslene fra. Hvordan løser du dette problemet selv?
Hva er problemet ditt her? La oss si at du har en synkron kopi som du tar backup med? Eller hva?
(Andrey) Faktum er at WAL-G faktisk er ment å brukes uten shell-skript. Hvis noe mangler, la oss legge til logikken som skal være inne i WAL-G. Når det gjelder hvor arkivering skal komme fra, mener vi at arkivering bør være fra gjeldende master i klyngen. Arkivering fra en kopi er en dårlig idé. Det er ulike mulige scenarier med problemer. Spesielt problemer med arkivering av tidslinjer og eventuell tilleggsinformasjon. Takk for spørsmålet!
(Forklaring: Vi ble kvitt shell-scripts )
God kveld! Takk for rapporten! Jeg er interessert i catchup-funksjonen du snakket om. Vi ble møtt med en situasjon der en kopi var bak og ikke kunne ta igjen. Og jeg fant ikke en beskrivelse av denne funksjonen i WAL-G-dokumenter.
Catchup dukket bokstavelig talt opp 20. januar 2020. Dokumentasjonen kan trenge litt mer arbeid. Vi skriver det selv, og vi skriver det ikke superbra. Og kanskje vi burde begynne å kreve at elevene skriver det.
Er den allerede utgitt?
Trekningsforespørselen er allerede død, det vil si at jeg sjekket den. Jeg prøvde dette på en testklynge. Så langt har vi ikke hatt en situasjon hvor vi kunne teste dette i et kampeksempel.
Når kan du forvente?
Jeg vet ikke. Vent en måned, så sjekker vi det.
Kilde: www.habr.com