Jeg foreslår, at du læser udskriften af den tidlige 2020-rapport af Georgy Rylov "WAL-G: nye muligheder og udvidelse af fællesskabet"
Open source-vedligeholdere står over for mange udfordringer, efterhånden som de vokser. Hvordan skriver man flere og flere nødvendige funktioner, løser flere og flere problemer og får vist flere og flere pull-anmodninger? Ved at bruge WAL-G (backup-værktøj til PostgreSQL) som et eksempel, vil jeg fortælle dig, hvordan vi løste disse problemer ved at lancere et kursus om Open source-udvikling på universitetet, hvad vi opnåede, og hvor vi vil bevæge os videre.
Hej igen alle sammen! Jeg er en Yandex-udvikler fra Jekaterinburg. Og i dag vil jeg tale om WAL-G.
Rapportens titel sagde ikke, at det handlede om backups. Er der nogen der ved hvad WAL-G er? Eller ved alle det? Ræk hånden op, hvis du ikke ved det. Holy shit, du kom til rapporten og ved ikke, hvad den handler om.
Lad mig fortælle dig, hvad der vil ske i dag. Det sker sådan, at vores team har lavet backups i et stykke tid. Og dette er endnu en rapport i en serie, hvor vi taler om, hvordan vi opbevarer data sikkert, sikkert, bekvemt og effektivt.
I tidligere serier var der mange rapporter af Andrei Borodin og Vladimir Leskov. Vi var mange. Og vi har talt om WAL-G i mange år.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Denne rapport vil adskille sig lidt fra de andre ved, at den handlede mere om den tekniske del, men her vil jeg fortælle om, hvordan vi stødte på problemer forbundet med væksten i samfundet. Og hvordan vi fik en lille idé, der hjælper os med at klare dette.
For nogle år siden var WAL-G et ret lille projekt, som vi fik fra Citus Data. Og vi tog det bare. Og det er udviklet af én person.
Og kun WAL-G havde ikke:
- Sikkerhedskopiering fra en replika.
- Der var ingen trinvise sikkerhedskopier.
- Der var ingen WAL-Delta backups.
- Og der manglede stadig en hel masse.
I løbet af disse få år er WAL-G vokset meget.
Og i 2020 er alt ovenstående allerede dukket op. Og hertil kom hvad vi nu har:
- Mere end 1 stjerner på GitHub.
- 150 gafler.
- Omkring 15 åbne PR'er.
- Og mange flere bidragydere.
- Og åbne problemer hele tiden. Og det på trods af, at vi bogstaveligt talt går der hver dag og gør noget ved det.
Og vi kom til den konklusion, at dette projekt kræver mere af vores opmærksomhed, selv når vi ikke selv skal implementere noget til vores Managed Databases-tjeneste i Yandex.
Og et sted i efteråret 2018 dukkede en idé op. Normalt har teamet flere måder at udvikle nogle funktioner på eller rette fejl, hvis du ikke har nok hænder. For eksempel kan du hyre en anden udvikler og betale ham penge. Eller du kan tage en praktikant i et stykke tid og også betale ham noget løn. Men der er stadig en ret stor gruppe mennesker, hvoraf nogle allerede virkelig ved, hvordan man skriver kode. Man ved bare ikke altid, hvilken kvalitet koden er.
Vi tænkte over det og besluttede at forsøge at tiltrække studerende. Men elever vil ikke deltage i alt hos os. De vil kun udføre en del af arbejdet. Og de vil for eksempel skrive test, rette fejl, implementere funktioner, der ikke påvirker hovedfunktionaliteten. Hovedfunktionaliteten er oprettelse af sikkerhedskopier og gendannelse af sikkerhedskopier. Hvis vi laver en fejl ved at oprette en sikkerhedskopi, vil vi opleve tab af data. Og ingen ønsker dette, selvfølgelig. Alle ønsker, at alt skal være meget sikkert. Derfor ønsker vi selvfølgelig ikke at lade kode, som vi stoler mindre på end vores egen. Det vil sige, at enhver ikke-kritisk kode er, hvad vi gerne vil modtage fra vores ekstra medarbejdere.
Under hvilke betingelser accepteres elev-PR?
- De er forpligtet til at dække deres kode med tests. Alt skal foregå i CI.
- Og vi gennemgår også 2 anmeldelser. En af Andrey Borodin og en af mig.
- Og desuden, for at kontrollere, at dette ikke vil ødelægge noget i vores tjeneste, uploader jeg separat forsamlingen med denne commit. Og vi tjekker i ende-til-ende-tests, at intet fejler.
Særligt kursus om Open Source
Lidt om, hvorfor det er nødvendigt, og hvorfor det, synes jeg, er en fed idé.
For os er overskuddet indlysende:
- Vi får ekstra hænder.
- Og vi søger kandidater til holdet blandt smarte studerende, der skriver smart kode.
Hvad er fordelen for studerende?
De kan være mindre indlysende, fordi elever som minimum ikke modtager penge for den kode, de skriver, men kun får karakterer for deres elevjournaler.
Jeg spurgte dem om dette. Og med deres ord:
- Bidragydererfaring i Open Source.
- Få en linje i dit CV.
- Bevis dig selv og bestå et interview i Yandex.
- Bliv medlem af GSoC.
- +1 specialkursus for dem, der vil skrive kode.
Jeg vil ikke tale om, hvordan kurset var bygget op. Jeg vil bare sige, at WAL-G var hovedprojektet. Vi inkluderede også projekter som Odyssey, PostgreSQL og ClickHouse i dette kursus.
Og de gav problemer ikke kun i dette kursus, men gav også eksamensbeviser og kurser.
Hvad med fordelene for brugerne?
Lad os nu gå videre til den del, der interesserer dig mest. Hvad nytter det dig? Pointen er, at eleverne har rettet en masse fejl. Og vi lavede de anmodningsfunktioner, som du bad os om at gøre.
Og lad mig fortælle dig om de ting, du længe har ønsket dig, og som er blevet realiseret.
Understøttelse af bordpladser. Tablespaces i WAL-G har sandsynligvis været forventet siden udgivelsen af WAL-G, fordi WAL-G er efterfølgeren til et andet backupværktøj WAL-E, hvor databasesikkerhedskopiering med tablespaces blev understøttet.
Lad mig kort minde dig om, hvad det er, og hvorfor det hele er nødvendigt. Typisk optager alle dine Postgres-data én mappe på filsystemet, kaldet basen. Og denne mappe indeholder allerede alle de filer og undermapper, der kræves af Postgres.
Tablespaces er mapper, der indeholder Postgres-data, men de er ikke placeret uden for basismappen. Diasset viser, at tablespaces er placeret uden for basismappen.
Hvordan ser det ud for Postgres selv? Der er en separat undermappe pg_tblspc i basismappen. Og det indeholder symbolske links til mapper, der faktisk indeholder Postgres-data uden for basismappen.
Når du bruger alt dette, så kan disse kommandoer se nogenlunde sådan ud for dig. Det vil sige, at du opretter en tabel i et bestemt tablespace og ser, hvor det er nu. Dette er de sidste to linjer, de sidste to kommandoer kaldet. Og der er det klart, at der er en vej. Men i virkeligheden er dette ikke den rigtige måde. Dette er stien med præfikset fra basismappen til tablespace. Og derfra matches det med et symlink, der fører til dine rigtige data.
Vi bruger ikke alt dette i vores team, men det blev brugt af mange andre WAL-E-brugere, som skrev til os, at de ville flytte til WAL-G, men det stoppede dem. Dette er nu understøttet.
En anden funktion, som vores særlige kursus bragte os, er catchup. Folk, der sandsynligvis har arbejdet mere med Oracle end med Postgres, kender til catchup.
Kort om hvad det er. Klyngetopologien i vores tjeneste kan normalt se nogenlunde sådan ud. Vi har en mester. Der er en replika, der streamer skrive-forud-log fra den. Og replikaen fortæller masteren, hvilken LSN den er på i øjeblikket. Og et sted parallelt hermed kan loggen arkiveres. Og udover at arkivere loggen, sendes der også backups til skyen. Og delta backups sendes.
Hvad kan problemet være? Når du har en ret stor database, kan det vise sig, at din replika begynder at halte langt efter masteren. Og hun halter så langt bagud, at hun aldrig kan hamle op med ham. Dette problem skal normalt løses på en eller anden måde.
Og den nemmeste måde er at fjerne replikaen og uploade den igen, fordi den aldrig vil indhente det, og problemet skal løses. Men det er ret lang tid, for gendannelse af en hel 10 TB database backup er meget, meget lang tid. Og vi ønsker at gøre alt dette så hurtigt som muligt, hvis sådanne problemer opstår. Og det er netop det, catchup er til for.
Catchup giver dig mulighed for at bruge delta backups, som på denne måde gemmes i skyen. Du siger, hvilken LSN den haltende replika er på i øjeblikket, og specificerer den i catchup-kommandoen for at oprette en delta-backup mellem det LSN og det LSN, som din klynge i øjeblikket er placeret på. Og derefter gendanner du denne sikkerhedskopi til den replika, der var bagud.
Andre baser
Eleverne bragte os også en masse funktioner på én gang. Da vi hos Yandex laver mad ikke kun Postgres, vi har også MySQL, MongoDB, Redis, ClickHouse, på et tidspunkt havde vi brug for at kunne lave backups med point-in-time recovery til MySQL, og så der var mulighed for at uploade dem til skyen.
Og vi ønskede at gøre det på en måde, der ligner det, WAL-G gør. Og vi besluttede at eksperimentere og se, hvordan det hele ville se ud.
Og i første omgang, uden at dele denne logik på nogen måde, skrev de koden i gaflen. De så, at vi har en form for fungerende model, og den kan flyve. Så troede vi, at vores hovedfællesskab er postgresister, de bruger WAL-G. Og derfor skal vi på en eller anden måde adskille disse dele. Det vil sige, at når vi redigerer kode til Postgres, bryder vi ikke MySQL; når vi redigerer MySQL, bryder vi ikke Postgres.
Den første idé om, hvordan man adskiller dette, var ideen om at bruge den samme tilgang, som bruges i PostgreSQL-udvidelser. Og faktisk for at lave en MySQL-sikkerhedskopi skulle du installere en form for dynamisk bibliotek.
Men her er asymmetrien i denne tilgang umiddelbart synlig. Når du sikkerhedskopierer Postgres, sætter du en normal backup til Postgres på den, og alt er i orden. Og for MySQL viser det sig, at du installerer en backup til Postgres og også installerer et dynamisk bibliotek til MySQL til det. Det lyder noget mærkeligt. Det troede vi også og besluttede, at det ikke var den løsning, vi havde brug for.
Forskellige builds til Postgres, MySQL, MongoDB, Redis
Men dette tillod os, ser det ud til, at komme til den rigtige beslutning - at tildele forskellige forsamlinger til forskellige baser. Dette gjorde det muligt at isolere logikken knyttet til backups af forskellige databaser, som vil få adgang til den fælles API, som WAL-G implementerer.
Det er den del, vi selv har skrevet - inden vi gav eleverne problemerne. Det vil sige, det er præcis den del, hvor de kunne gøre noget forkert, så vi besluttede, at vi hellere må gøre sådan noget, og alt vil være i orden.
Efter det gav vi problemer ud. De blev straks demonteret. Eleverne skulle støtte tre baser.
Dette er MySQL, som vi har sikkerhedskopieret ved hjælp af WAL-G på denne måde i mere end et år.
Og nu nærmer MongoDB sig produktionen, hvor de afslutter den med en fil. Faktisk skrev vi rammerne for alt dette. Så skrev eleverne nogle brugbare ting. Og så bringer vi dem til en tilstand, som vi kan acceptere i produktionen.
Disse problemer så ikke ud til, at eleverne skulle skrive komplette sikkerhedskopieringsværktøjer til hver af disse databaser. Sådan et problem havde vi ikke. Vores problem var, at vi ønskede punkt-i-tidsgendannelse, og vi ville tage backup til skyen. Og de bad eleverne om at skrive noget kode, der ville løse dette. Eleverne brugte allerede eksisterende backupværktøjer, som på en eller anden måde tager backups, og limede så det hele sammen med WAL-G, som videresendte det hele til skyen. Og de tilføjede også point-in-time recovery til dette.
Hvad havde eleverne ellers med? De bragte Libsodium-krypteringsunderstøttelse til WAL-G.
Vi har også backup-lagringspolitikker. Nu kan sikkerhedskopier markeres som permanente. Og på en eller anden måde er det mere bekvemt for din tjeneste at automatisere processen med at gemme dem.
Hvad var resultatet af dette eksperiment?
Mere end 100 personer meldte sig oprindeligt til kurset. Først sagde jeg ikke, at universitetet i Jekaterinburg er Ural Federal University. Vi annoncerede alt der. 100 personer tilmeldte. I virkeligheden begyndte meget færre mennesker at gøre noget, omkring 30 mennesker.
Endnu færre gennemførte kurset, fordi det var nødvendigt at skrive test til de koder, der allerede findes. Og også ret en fejl eller lav en funktion. Og nogle elever lukkede stadig kurset.
I øjeblikket har eleverne under dette kursus rettet omkring 14 problemer og lavet 10 funktioner i forskellige størrelser. Og det forekommer mig, at dette er en fuldgyldig erstatning af en eller to udviklere.
Vi udstedte blandt andet diplomer og kurser. Og 12 modtog diplomer. 6 af dem har allerede forsvaret sig på "5". De, der blev tilbage, havde endnu ikke beskyttelse, men jeg tror, at alt også vil være godt for dem.
Planer for fremtiden
Hvilke planer har vi for fremtiden?
I det mindste de funktionsanmodninger, som vi allerede har hørt fra brugere og gerne vil gøre. Det her:
- Overvågning af korrektheden af tidslinjesporing i HA-klynge-backup-arkivet. Du kan gøre dette med WAL-G. Og jeg tror, vi får elever, der vil tage den her sag op.
- Vi har allerede en person, der er ansvarlig for at overføre backups og WAL mellem skyerne.
- Og vi har for nylig offentliggjort en idé om, at vi kan fremskynde WAL-G endnu mere ved at pakke trinvise sikkerhedskopier ud uden at omskrive sider og optimere de arkiver, vi sender dertil.
Du kan dele dem her
Hvad var denne rapport til? Desuden har vi nu, udover de 4 personer, der støtter dette projekt, yderligere hænder, som der er en del af. Især hvis du skriver til dem i en personlig besked. Og hvis du tager backup af dine data og gør det ved hjælp af WAL-G eller gerne vil flytte til WAL-G, så kan vi ganske nemt imødekomme dine ønsker.
Dette er en QR-kode og et link. Du kan gå dem igennem og skrive alle dine ønsker. For eksempel retter vi ikke en fejl. Eller du ønsker virkelig en funktion, men af en eller anden grund er den endnu ikke i nogen backup, inklusive vores. Sørg for at skrive om dette.
R'RѕRїSЂRѕSЃS <
Hej! Tak for rapporten! Spørgsmål om WAL-G, men ikke om Postgres. WAL-G sikkerhedskopierer MySQL og kalder en ekstra backup. Hvis vi tager moderne installationer på CentOS, og hvis du yum installerer MySQL, vil MariDB blive installeret. Fra version 10.3 understøttes ekstra backup ikke, MariDB backup er understøttet. Hvordan har du det med det her?
I øjeblikket har vi ikke forsøgt at tage backup af MariDB. Vi har haft anmodninger om FoundationDB-støtte, men generelt, hvis der er en sådan anmodning, så kan vi finde folk, der vil gøre det. Det er ikke så langt eller så svært, som jeg tror.
God eftermiddag Tak for rapporten! Spørgsmål om potentielle nye funktioner. Er du klar til at få WAL-G til at fungere med bånd, så du kan sikkerhedskopiere til bånd?
Sikkerhedskopiering på båndopbevaring betyder tilsyneladende?
Ja.
Der er Andrei Borodin, som kan besvare dette spørgsmål bedre end mig.
(Andrey) Ja, tak for spørgsmålet! Vi havde en anmodning om at overføre en sikkerhedskopi til bånd fra skylager. Og for dette overførsel mellem skyer. Fordi sky-til-sky-overførsel er en generaliseret version af båndoverførsel. Derudover har vi en udvidelig arkitektur i forhold til Storages. Mange Storoges er i øvrigt skrevet af studerende. Og hvis du skriver Storage for tape, så bliver det selvfølgelig understøttet. Vi er klar til at overveje pull-anmodninger. Der skal du skrive en fil, læse en fil. Hvis du gør disse ting i Go, ender du normalt med 50 linjer kode. Og så vil bånd blive understøttet i WAL-G.
Tak for rapporten! Interessant udviklingsproces. Sikkerhedskopiering er et seriøst stykke funktionalitet, der bør dækkes godt af tests. Da du implementerede funktionalitet til nye databaser, skrev eleverne så også testene, eller skrev du selv testene og gav derefter implementeringen til eleverne?
Eleverne skrev også prøver. Men eleverne skrev mere for funktioner såsom nye databaser. De skrev integrationstest. Og de skrev enhedsprøver. Hvis integrationen passerer, det vil sige i øjeblikket, er dette et script, som du udfører manuelt, eller du har f.eks. cron til at gøre det. Det vil sige, at manuskriptet der er meget klart.
Eleverne har ikke meget erfaring. Tager gennemgang meget tid?
Ja, anmeldelser tager ret meget tid. Det vil sige, som regel, når der kommer flere committere på én gang og siger, at jeg gjorde det her, så gjorde jeg det, så skal man tænke sig om og sætte en halv dag af til at finde ud af, hvad de skrev der. Fordi koden skal læses omhyggeligt. De havde ikke et interview. Vi kender dem ikke så godt, så det tager meget tid.
Tak for rapporten! Tidligere udtalte Andrey Borodin, at archive_command i WAL-G skulle kaldes direkte. Men i tilfælde af en slags klyngepatron har vi brug for yderligere logik for at bestemme knudepunktet, hvorfra akslerne skal sendes. Hvordan løser du selv dette problem?
Hvad er dit problem her? Lad os sige, at du har en synkron kopi, som du laver en backup med? Eller hvad?
(Andrey) Faktum er, at WAL-G faktisk er beregnet til at blive brugt uden shell-scripts. Hvis der mangler noget, så lad os tilføje den logik, der burde være inde i WAL-G. Hvad angår hvor arkivering skal komme fra, mener vi, at arkivering bør ske fra den nuværende master i klyngen. Arkivering fra en replika er en dårlig idé. Der er forskellige mulige scenarier med problemer. Især problemer med arkivering af tidslinjer og eventuelle yderligere oplysninger. Tak for spørgsmålet!
(Afklaring: Vi slap af med shell-scripts )
God aften! Tak for rapporten! Jeg er interesseret i den indhentningsfunktion, du talte om. Vi stod over for en situation, hvor en replika var bagud og ikke kunne indhente det. Og jeg fandt ikke en beskrivelse af denne funktion i WAL-G-dokumenter.
Catchup dukkede bogstaveligt talt op den 20. januar 2020. Dokumentationen kræver muligvis noget mere arbejde. Vi skriver det selv, og vi skriver det ikke super godt. Og måske skulle vi begynde at kræve, at eleverne skriver det.
Er den allerede udgivet?
Pull-anmodningen er allerede død, dvs. jeg tjekkede den. Jeg prøvede dette på en testklynge. Indtil videre har vi ikke haft en situation, hvor vi kunne teste dette i et kampeksempel.
Hvornår kan man forvente?
Jeg ved ikke. Vent en måned, så tjekker vi med sikkerhed.
Kilde: www.habr.com