Jag föreslår att du läser utskriften av den tidiga 2020-rapporten av Georgy Rylov "WAL-G: nya möjligheter och expansion av samhället"
Open-source underhållare står inför många utmaningar när de växer. Hur man skriver fler och fler nödvändiga funktioner, fixar fler och fler problem och lyckas se fler och fler pull-förfrågningar? Med hjälp av WAL-G (backup-verktyg för PostgreSQL) som ett exempel ska jag berätta hur vi löste dessa problem genom att lansera en kurs om öppen källkodsutveckling på universitetet, vad vi uppnådde och vart vi kommer att gå härnäst.
Hej igen alla! Jag är en Yandex-utvecklare från Jekaterinburg. Och idag ska jag prata om WAL-G.
Rubriken på rapporten sa inte att det handlade om säkerhetskopior. Är det någon som vet vad WAL-G är? Eller vet alla? Räck upp handen om du inte vet. Herregud, du kom till rapporten och vet inte vad den handlar om.
Låt mig berätta vad som kommer att hända idag. Det råkar vara så att vårt team har gjort säkerhetskopior ganska länge. Och det här är ytterligare en rapport i en serie där vi pratar om hur vi lagrar data säkert, säkert, bekvämt och effektivt.
I tidigare serier fanns det många rapporter av Andrei Borodin och Vladimir Leskov. Vi var många. Och vi har pratat om WAL-G i många år.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Den här rapporten kommer att skilja sig lite från de andra genom att den handlade mer om den tekniska delen, men här kommer jag att prata om hur vi stötte på problem i samband med samhällets tillväxt. Och hur vi kom på en liten idé som hjälper oss att klara av detta.
För några år sedan var WAL-G ett ganska litet projekt som vi fick från Citus Data. Och vi bara tog det. Och det utvecklades av en person.
Och bara WAL-G hade inte:
- Säkerhetskopiering från en replik.
- Det fanns inga inkrementella säkerhetskopior.
- Det fanns inga WAL-Delta-säkerhetskopior.
- Och det saknades fortfarande en hel del.
Under dessa få år har WAL-G vuxit mycket.
Och 2020 har allt ovanstående redan dykt upp. Och till detta kom det vi nu har:
- Mer än 1 000 stjärnor på GitHub.
- 150 gafflar.
- Cirka 15 öppna PR.
- Och många fler bidragsgivare.
- Och öppna frågor hela tiden. Och detta trots att vi bokstavligen går dit varje dag och gör något åt det.
Och vi kom fram till att det här projektet kräver mer av vår uppmärksamhet, även när vi själva inte behöver implementera något för vår Managed Databases-tjänst i Yandex.
Och någonstans under hösten 2018 kom en idé till oss. Vanligtvis har teamet flera sätt att utveckla vissa funktioner eller fixa buggar om du inte har tillräckligt med händer. Du kan till exempel anlita en annan utvecklare och betala honom pengar. Eller så kan du anställa en praktikant ett tag och även betala honom lite lön. Men det finns fortfarande en ganska stor grupp människor, av vilka några redan verkligen vet hur man skriver kod. Man vet bara inte alltid vilken kvalitet koden är.
Vi funderade på det och bestämde oss för att försöka locka studenter. Men studenter kommer inte att delta i allt hos oss. De kommer bara att göra en del av arbetet. Och de kommer till exempel att skriva tester, fixa buggar, implementera funktioner som inte påverkar huvudfunktionaliteten. Huvudfunktionaliteten är att skapa säkerhetskopior och återställa säkerhetskopior. Om vi gör ett misstag när vi skapar en säkerhetskopia kommer vi att uppleva dataförlust. Och det här vill ingen förstås. Alla vill att allt ska vara väldigt säkert. Därför vill vi naturligtvis inte låta kod som vi litar mindre på än vår egen. Det vill säga att alla icke-kritiska koder är vad vi skulle vilja få från våra ytterligare anställda.
Under vilka förutsättningar accepteras student-PR?
- De måste täcka sin kod med tester. Allt ska ske i CI.
- Och vi går även igenom 2 recensioner. En av Andrey Borodin och en av mig.
- Och dessutom, för att kontrollera att detta inte kommer att bryta något i vår tjänst, laddar jag upp sammansättningen separat med denna commit. Och vi kontrollerar i end-to-end-tester att inget misslyckas.
Specialkurs om öppen källkod
Lite om varför detta behövs och varför detta, tycker jag, är en cool idé.
För oss är vinsten uppenbar:
- Vi får extra händer.
- Och vi söker kandidater till teamet bland smarta studenter som skriver smart kod.
Vad är fördelen för studenterna?
De kan vara mindre uppenbara, eftersom studenter, som ett minimum, inte får pengar för koden de skriver, utan bara får betyg för sina studentuppgifter.
Jag frågade dem om detta. Och med deras ord:
- Bidragsgivares erfarenhet av öppen källkod.
- Få en rad i ditt CV.
- Bevisa dig själv och klara en intervju i Yandex.
- Bli GSoC-medlem.
- +1 specialkurs för dig som vill skriva kod.
Jag ska inte prata om hur kursen var uppbyggd. Jag ska bara säga att WAL-G var huvudprojektet. Vi inkluderade även projekt som Odyssey, PostgreSQL och ClickHouse i den här kursen.
Och de gav problem inte bara i den här kursen, utan delade också ut diplom och kursuppgifter.
Hur är det med fördelarna för användarna?
Låt oss nu gå vidare till den del som intresserar dig mest. Vad hjälper detta dig? Poängen är att eleverna fixade många buggar. Och vi gjorde förfrågningsfunktionerna som du bad oss att göra.
Och låt mig berätta om de saker som du länge velat ha och som har förverkligats.
Stöd för bordsytor. Tabellutrymmen i WAL-G har troligen förväntats sedan lanseringen av WAL-G, eftersom WAL-G är efterföljaren till ett annat säkerhetskopieringsverktyg WAL-E, där säkerhetskopiering av databas med tabellutrymmen stöddes.
Låt mig kort påminna dig om vad det är och varför det behövs. Vanligtvis upptar alla dina Postgres-data en katalog i filsystemet, kallad basen. Och den här katalogen innehåller redan alla filer och underkataloger som krävs av Postgres.
Tabellutrymmen är kataloger som innehåller Postgres-data, men de är inte placerade utanför baskatalogen. Bilden visar att tabellutrymmena är placerade utanför baskatalogen.
Hur ser det här ut för Postgres själv? Det finns en separat underkatalog pg_tblspc i baskatalogen. Och den innehåller symboliska länkar till kataloger som faktiskt innehåller Postgres-data utanför baskatalogen.
När du använder allt detta kan dessa kommandon se ut ungefär så här för dig. Det vill säga att du skapar en tabell i någon angiven tabellyta och ser var den är nu. Dessa är de två sista raderna, de två sista kommandona anropade. Och där är det tydligt att det finns någon väg. Men i verkligheten är detta inte det riktiga sättet. Detta är sökvägen med prefixet från baskatalogen till tabellutrymmet. Och därifrån matchas den med en symbollänk som leder till din riktiga data.
Vi använder inte allt detta i vårt team, men det användes av många andra WAL-E-användare som skrev till oss att de ville flytta till WAL-G, men detta stoppade dem. Detta stöds nu.
En annan funktion som vår specialkurs gav oss är catchup. Människor som förmodligen har arbetat mer med Oracle än med Postgres vet om catchup.
Kort om vad det är. Klustertopologin i vår tjänst kan vanligtvis se ut ungefär så här. Vi har en mästare. Det finns en replik som strömmar skriv-förut-logg från den. Och repliken berättar för mastern vilket LSN den för närvarande är på. Och någonstans parallellt med detta kan loggen arkiveras. Och förutom att arkivera loggen skickas även säkerhetskopior till molnet. Och delta säkerhetskopior skickas.
Vad kan problemet vara? När du har en ganska stor databas kan det visa sig att din replik börjar släpa långt efter mastern. Och hon ligger så långt efter att hon aldrig kan hinna med honom. Detta problem måste vanligtvis lösas på något sätt.
Och det enklaste sättet är att ta bort repliken och ladda upp den igen, eftersom den aldrig kommer ikapp, och problemet måste åtgärdas. Men det här är ganska lång tid, för att återställa en hel 10 TB databassäkerhetskopiering är väldigt, väldigt lång tid. Och vi vill göra allt detta så snabbt som möjligt om sådana problem uppstår. Och det är precis vad catchup är till för.
Catchup låter dig använda delta-säkerhetskopior, som lagras i molnet på detta sätt. Du säger vilket LSN den eftersläpande repliken för närvarande är på och specificerar den i catchup-kommandot för att skapa en deltabackup mellan det LSN och det LSN som ditt kluster för närvarande befinner sig på. Och efter det återställer du denna säkerhetskopia till repliken som släpade efter.
Andra baser
Eleverna tog också med oss många funktioner på en gång. Eftersom vi på Yandex lagar mat inte bara Postgres, vi har även MySQL, MongoDB, Redis, ClickHouse, någon gång behövde vi kunna göra säkerhetskopior med punkt-i-tidsåterställning för MySQL, och så att det fanns möjlighet att ladda upp dem till molnet.
Och vi ville göra det på något liknande sätt som WAL-G gör. Och vi bestämde oss för att experimentera och se hur det hela skulle se ut.
Och till en början, utan att dela denna logik på något sätt, skrev de koden i gaffeln. De såg att vi har någon form av fungerande modell och den kan flyga. Sedan trodde vi att vårt huvudcommunity är postgresister, de använder WAL-G. Och därför måste vi på något sätt separera dessa delar. Det vill säga när vi redigerar kod för Postgres bryter vi inte MySQL; när vi redigerar MySQL bryter vi inte Postgres.
Den första idén om hur man separerar detta var idén om att använda samma tillvägagångssätt som används i PostgreSQL-tillägg. Och faktiskt, för att göra en MySQL-säkerhetskopia var du tvungen att installera något slags dynamiskt bibliotek.
Men här är asymmetrin i detta tillvägagångssätt omedelbart synlig. När du säkerhetskopierar Postgres lägger du en normal säkerhetskopia för Postgres på den och allt är bra. Och för MySQL visar det sig att du installerar en säkerhetskopia för Postgres och även installerar ett dynamiskt bibliotek för MySQL för det. Det låter lite konstigt. Det tyckte vi också och kom fram till att det här inte var den lösning vi behövde.
Olika builds för Postgres, MySQL, MongoDB, Redis
Men detta tillät oss, tycks det, komma till rätt beslut - att fördela olika församlingar för olika baser. Detta gjorde det möjligt att isolera logiken kopplad till säkerhetskopior av olika databaser som kommer åt det gemensamma API som WAL-G implementerar.
Det här är den del som vi skrev själva – innan vi gav eleverna problemen. Det vill säga, det här är precis den delen där de kan göra något fel, så vi bestämde oss för att det är bättre att göra något sånt här och allt kommer att bli bra.
Efter det gav vi ut problem. De monterades omedelbart ned. Eleverna var tvungna att stödja tre baser.
Detta är MySQL, som vi har säkerhetskopierat med WAL-G på detta sätt i mer än ett år.
Och nu närmar sig MongoDB produktion, där de avslutar den med en fil. Faktum är att vi skrev ramverket för allt detta. Sedan skrev eleverna några fungerande saker. Och sedan för vi dem till ett tillstånd som vi kan acceptera i produktionen.
Dessa problem såg inte ut som att eleverna behövde skriva kompletta säkerhetskopieringsverktyg för var och en av dessa databaser. Vi hade inte ett sådant problem. Vårt problem var att vi ville ha punkt-i-tid återställning och vi ville säkerhetskopiera till molnet. Och de bad eleverna skriva någon kod som skulle lösa detta. Eleverna använde redan befintliga säkerhetskopieringsverktyg, som på något sätt tar säkerhetskopior, och limmade sedan ihop det hela med WAL-G, som vidarebefordrade det hela till molnet. Och de lade också till punkt-i-tidsåterhämtning till detta.
Vad mer hade eleverna med sig? De tog med Libsodium-krypteringsstöd till WAL-G.
Vi har även säkerhetskopieringspolicyer. Nu kan säkerhetskopior markeras som permanenta. Och på något sätt är det bekvämare för din tjänst att automatisera processen att lagra dem.
Vad blev resultatet av detta experiment?
Mer än 100 personer anmälde sig initialt till kursen. Först sa jag inte att universitetet i Jekaterinburg är Ural Federal University. Vi tillkännagav allt där. 100 personer anmälda. I verkligheten var det mycket färre som började göra något, cirka 30 personer.
Ännu färre gick kursen, eftersom det var nödvändigt att skriva prov för de koder som redan finns. Och även fixa någon bugg eller skapa någon funktion. Och några elever stängde fortfarande kursen.
För närvarande, under den här kursen, har studenterna fixat cirka 14 problem och gjort 10 funktioner i olika storlekar. Och, det verkar för mig, detta är en fullfjädrad ersättning av en eller två utvecklare.
Vi delade bland annat ut diplom och kursuppgifter. Och 12 fick diplom. 6 av dem har redan försvarat sig på "5". De som blev kvar hade ännu inte skydd, men jag tror att allt kommer att gå bra för dem också.
Planer för framtiden
Vilka planer har vi för framtiden?
Åtminstone de funktionsförfrågningar som vi redan har hört från användare och vill göra. Detta:
- Övervaka korrektheten av tidslinjespårning i HA-klustrets säkerhetskopieringsarkiv. Du kan göra detta med WAL-G. Och jag tror att vi kommer att ha elever som tar upp den här frågan.
- Vi har redan en person som ansvarar för att överföra säkerhetskopior och WAL mellan molnen.
- Och vi publicerade nyligen en idé om att vi kan snabba upp WAL-G ytterligare genom att packa upp inkrementella säkerhetskopior utan att skriva om sidor och optimera arkiven vi skickar dit.
Du kan dela dem här
Vad var den här rapporten till för? Dessutom har vi nu, förutom de 4 personerna som stödjer detta projekt, ytterligare händer, som det finns ganska många av. Speciellt om du skriver till dem i ett personligt meddelande. Och om du säkerhetskopierar dina data och gör det med hjälp av WAL-G eller skulle vilja flytta till WAL-G, så kan vi ganska enkelt tillgodose dina önskemål.
Detta är en QR-kod och en länk. Du kan gå igenom dem och skriva alla dina önskemål. Till exempel, vi fixar inte någon bugg. Eller så vill du verkligen ha någon funktion, men av någon anledning finns den ännu inte i någon backup, inklusive vår. Var noga med att skriva om detta.
frågor
Hallå! Tack för rapporten! Fråga om WAL-G, men inte om Postgres. WAL-G säkerhetskopierar MySQL och anropar en extra backup. Om vi tar moderna installationer på CentOS och om du installerar MySQL så kommer MariDB att installeras. Från version 10.3 stöds inte extra backup, MariDB backup stöds. Hur mår du med detta?
För tillfället har vi inte försökt säkerhetskopiera MariDB. Vi har haft förfrågningar om FoundationDB-stöd, men i allmänhet, om det finns en sådan begäran, så kan vi hitta personer som kommer att göra det. Det är inte så långt eller så svårt som jag tror.
God eftermiddag Tack för rapporten! Fråga om potentiella nya funktioner. Är du redo att få WAL-G att fungera med band så att du kan säkerhetskopiera till band?
Säkerhetskopiering på bandlagring betyder tydligen?
Ja.
Det finns Andrei Borodin, som kan svara på denna fråga bättre än jag.
(Andrey) Ja, tack för frågan! Vi hade en begäran om att överföra en säkerhetskopia till band från molnlagring. Och för detta överföring mellan moln. Eftersom moln-till-moln-överföring är en generaliserad version av bandöverföring. Dessutom har vi en utbyggbar arkitektur vad gäller Storages. Förresten, många Storoges skrevs av studenter. Och om du skriver Storage for tape, så kommer det naturligtvis att stödjas. Vi är redo att överväga pull-förfrågningar. Där behöver du skriva en fil, läsa en fil. Om du gör dessa saker i Go får du vanligtvis 50 rader kod. Och sedan kommer band att stödjas i WAL-G.
Tack för rapporten! Intressant utvecklingsprocess. Säkerhetskopiering är en seriös del av funktionalitet som bör täckas väl av tester. När ni implementerade funktionalitet för nya databaser, skrev eleverna också proven, eller skrev ni själva proven och gav sedan implementeringen till eleverna?
Eleverna skrev också prov. Men eleverna skrev mer för funktioner som nya databaser. De skrev integrationstester. Och de skrev enhetstester. Om integrationen går, det vill säga för tillfället, är detta ett script som du kör manuellt eller så har du till exempel cron som gör det. Det vill säga manuset där är väldigt tydligt.
Eleverna har inte mycket erfarenhet. Tar granskningen mycket tid?
Ja, recensioner tar ganska lång tid. Det vill säga, oftast när det kommer flera hängivna på en gång och säger att jag gjorde det här så gjorde jag det, då behöver man tänka till och avsätta ungefär en halv dag för att komma på vad de skrivit där. Eftersom koden måste läsas noggrant. De hade ingen intervju. Vi känner dem inte så väl, så det tar mycket tid.
Tack för rapporten! Tidigare har Andrey Borodin sagt att archive_command i WAL-G borde anropas direkt. Men i fallet med någon form av klusterpatron behöver vi ytterligare logik för att bestämma noden från vilken axlarna ska skickas. Hur löser du det här problemet själv?
Vad är ditt problem här? Låt oss säga att du har en synkron kopia som du gör en säkerhetskopia med? Eller vad?
(Andrey) Faktum är att WAL-G verkligen är tänkt att användas utan skalskript. Om något saknas, låt oss lägga till logiken som borde finnas inuti WAL-G. När det gäller var arkivering ska komma ifrån anser vi att arkivering bör ske från den nuvarande mastern i klustret. Att arkivera från en replik är en dålig idé. Det finns olika möjliga scenarier med problem. I synnerhet problem med arkivering av tidslinjer och eventuell ytterligare information. Tack för frågan!
(Förtydligande: Vi blev av med skalskript )
God kväll! Tack för rapporten! Jag är intresserad av catchup-funktionen du pratade om. Vi stod inför en situation där en replik låg bakom och inte kunde komma ikapp. Och jag hittade ingen beskrivning av denna funktion i WAL-G-dokument.
Catchup dök upp bokstavligen den 20 januari 2020. Dokumentationen kan behöva lite mer arbete. Vi skriver det själva och vi skriver det inte superbra. Och vi kanske borde börja kräva att eleverna skriver det.
Är den redan släppt?
Pullbegäran är redan död, d.v.s. jag kontrollerade den. Jag provade detta på ett testkluster. Hittills har vi inte haft en situation där vi skulle kunna testa detta i ett stridsexempel.
När kan man förvänta sig?
jag vet inte. Vänta en månad, vi kollar säkert.
Källa: will.com